Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

camera.close() with long exposure hangs, then kernel panics #528

Open
avenhaus opened this issue Nov 6, 2018 · 4 comments
Open

camera.close() with long exposure hangs, then kernel panics #528

avenhaus opened this issue Nov 6, 2018 · 4 comments

Comments

@avenhaus
Copy link

avenhaus commented Nov 6, 2018

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.

@jaimemarijke
Copy link

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")

pageauc added a commit to pageauc/pi-timolo that referenced this issue Feb 11, 2019
Stretch and pi-timolo.py 11.11 and earlier has long exposure low light camera freezing issue that requires a reboot to gain
control of camera back per waveform80/picamera#528  This adhoc fix will resolve issue if running the latest Stretch firmware.
@samtygier
Copy link

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!

@dirtbirb
Copy link

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?

@danielfett
Copy link

danielfett commented Apr 27, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants