camera.close() with long exposure hangs, then kernel panics
avenhaus opened this issue · comments
picamera V1.13 with camera module V2.1 on Pi Zero W:
Calling close() after setting low frame rate hangs. After some minutes the Pi crashes with a kernel panic "Fatal exception in interrupt". I can consistently reproduce with the following code:
from picamera import PiCamera
import time
camera = PiCamera()
camera.awb_mode = 'off'
camera.exposure_mode = 'off'
camera.iso = 800
camera.shutter_speed = 10 * 1000 * 1000
camera.framerate = 0.1
time.sleep(2)
print("Close")
camera.close()
print("Done")
Background: I am trying to take a long time lapse. I am closing the camera after each shot to save battery power. Reproduced on 2 different boars with 4.8A power supply.
I am having exactly the same issue!
picamera V1.13 with camera module V2.1 on Pi 3 B+.
It seems to me like the issue is specifically around trying to close the camera while the framerate is < 1, as I was able to workaround the issue by setting the framerate back up to 1 before calling camera.close():
Editing @avenhaus 's example with my workaround:
from picamera import PiCamera
import time
camera = PiCamera()
camera.awb_mode = 'off'
camera.exposure_mode = 'off'
camera.iso = 800
camera.shutter_speed = 10 * 1000 * 1000
camera.framerate = 0.1
time.sleep(2)
# camera.capture(...)
# Setting the framerate back above 1 allows camera.close() to actually succeed
camera.framerate = 1
print("Close")
camera.close()
print("Done")
Seeing this as well.
Mar 02 22:52:33 gascampi kernel: Unable to handle kernel paging request at virtual address e597343c
Mar 02 22:52:33 gascampi kernel: pgd = d5280000
Mar 02 22:52:33 gascampi kernel: [e597343c] *pgd=00000000
Mar 02 22:52:33 gascampi kernel: Internal error: Oops: 80000005 [#1] ARM
Mar 02 22:52:34 gascampi kernel: Modules linked in: xt_multiport iptable_filter bnep hci_uart btbcm serdev bluetooth ecdh_generic brcmfmac brcmutil snd_bcm2835(C) cfg80211 snd_pcm snd_timer rfkill snd uio_pdrv_genirq uio fixed ip_tables x_tables ipv6
Mar 02 22:52:34 gascampi kernel: CPU: 0 PID: 20 Comm: kworker/dying Tainted: G C 4.14.98+ #1200
Mar 02 22:52:34 gascampi kernel: Hardware name: BCM2835
Mar 02 22:52:34 gascampi kernel: task: d7218de0 task.stack: d720e000
Mar 02 22:52:34 gascampi kernel: PC is at 0xe597343c
Mar 02 22:52:34 gascampi kernel: LR is at task_rq_lock+0x2c/0xac
Mar 02 22:52:34 gascampi kernel: pc : [<e597343c>] lr : [<c00472f4>] psr: 80000093
Mar 02 22:52:34 gascampi kernel: sp : d720fef8 ip : d720fef8 fp : d720ff0c
Mar 02 22:52:34 gascampi kernel: r10: d70f9e94 r9 : d71e26d8 r8 : 00000001
Mar 02 22:52:34 gascampi kernel: r7 : 00000000 r6 : d71e9460 r5 : d7218de0 r4 : d720ff10
Mar 02 22:52:34 gascampi kernel: r3 : 00000001 r2 : 00000000 r1 : d720ff10 r0 : d7218de0
Mar 02 22:52:34 gascampi kernel: Flags: Nzcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user
Mar 02 22:52:34 gascampi kernel: Control: 00c5387d Table: 15280008 DAC: 00000055
Mar 02 22:52:34 gascampi kernel: Process kworker/dying (pid: 20, stack limit = 0xd720e188)
Mar 02 22:52:34 gascampi kernel: Stack: (0xd720fef8 to 0xd7210000)
Mar 02 22:52:34 gascampi kernel: fee0: d7218de0 00000000
Mar 02 22:52:34 gascampi kernel: ff00: d720ff34 d720ff10 c004a79c c00472d4 60000013 d7219324 d7218de0 00000000
Mar 02 22:52:34 gascampi kernel: ff20: d71e9460 00000000 d720ff44 d720ff38 c0054324 c004a784 d720ff7c d720ff48
Mar 02 22:52:34 gascampi kernel: ff40: c0024d84 c0054318 d71daae0 00000000 d71e26d8 d71e26c0 00000000 d71e9460
Mar 02 22:52:34 gascampi kernel: ff60: d71daae0 c0039630 d71e26d8 d70f9e94 d720ffac d720ff80 c003f53c c0024a5c
Mar 02 22:52:34 gascampi kernel: ff80: ffffffff d71e9460 c003f448 00000000 00000000 00000000 00000000 00000000
Mar 02 22:52:34 gascampi kernel: ffa0: 00000000 d720ffb0 c000fe2c c003f454 00000000 00000000 00000000 00000000
Mar 02 22:52:34 gascampi kernel: ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Mar 02 22:52:34 gascampi kernel: ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
Mar 02 22:52:34 gascampi kernel: [<c00472f4>] (task_rq_lock) from [<c004a79c>] (sched_move_task+0x24/0x174)
Mar 02 22:52:34 gascampi kernel: [<c004a79c>] (sched_move_task) from [<c0054324>] (sched_autogroup_exit_task+0x18/0x1c)
Mar 02 22:52:34 gascampi kernel: [<c0054324>] (sched_autogroup_exit_task) from [<c0024d84>] (do_exit+0x334/0xab4)
Mar 02 22:52:34 gascampi kernel: [<c0024d84>] (do_exit) from [<c003f53c>] (kthread+0xf4/0x15c)
Mar 02 22:52:34 gascampi kernel: [<c003f53c>] (kthread) from [<c000fe2c>] (ret_from_fork+0x14/0x28)
Mar 02 22:52:34 gascampi kernel: Code: bad PC value
Mar 02 22:52:34 gascampi kernel: ---[ end trace 0a1b7f1fb01db828 ]---
Mar 02 22:52:34 gascampi kernel: Fixing recursive fault but reboot is needed!
I also have this problem on a Computer Module 3 with rpi-upgrade, apt packages, and picamera all recent as of this post. Using a V1 (OmniVision) camera. The workaround worked for me.
I see that sensor mode 3 is used for full-frame captures with fps < 1; is it possible that mode 3 is the culprit for some reason?
Apart from the issue before .close(), there seems to be a problem with the timings, maybe also the order of how settings are applied. It seems that a good amount of sleep before starting the capture helps. The following code works for me (it also includes a workaround if you hit the timeout):
from picamera import PiCamera
from datetime import datetime
from time import sleep
class SkyPiCamera(PiCamera):
def __init__(self, *args, **kwargs):
# self.CAPTURE_TIMEOUT = 120 # enable if you hit the timeout
super().__init__(*args, **kwargs)
with SkyPiCamera(resolution=[3280, 2464], sensor_mode=3, framerate=1 / 10) as camera:
print("opened successfully!")
camera.shutter_speed = 10000000
#sleep(0.5)
camera.iso = 800
camera.exposure_mode = "sports"
print("camera configured")
sleep(20)
for cnt, _ in enumerate(
camera.capture_continuous("test{counter}.jpg", format="jpeg", burst=True)
):
print ('click!')
break
camera.framerate = 1