Mystical panic when RPI2 is left idle for a while
Jukka A. Ukkonen
jau789 at gmail.com
Tue Apr 26 07:43:57 UTC 2016
On 04/24/16 19:41, Ian Lepore wrote:
> On Sun, 2016-04-24 at 13:53 +0300, Jukka A. Ukkonen wrote:
>
>> I have a faint recollection that some others have also said
>> their RPI2 panics when it is left idle for too long.
>> Mine has been giving me those little surprises quite regularly,
>> but until I got a 3,3V serial console cable I have had no
>> chance to debug the problem any further.
>> I hope the attached backtrace is more informative to someone
>> else. All I was able to understand was that some process
>> apparently tries to sleep while it is not allowed to do that.
>> Maybe it is holding some locks or semaphores or something,
>> and does not release them before trying to sleep.
>
> Based on resettodr() appearing in the backtrace, I'm going to guess
> that you have an i2c-based realtime clock chip on the system? If so,
> that's the root of the problem, it gets automatically updated and the
> kernel can't tolerate sleeping during the process, and i2c drivers
> usually have to sleep as part of talking to their devices.
>
> You can work around it by adding
>
> machdep.disable_rtc_set=0
>
> to /etc/sysctl.conf. But that disables keeping the RTC up to date (I
> think it still gets updated when you manually set the time, but I'm not
> sure of that).
>
> It's on my slow-motion to-do list to fix the resettodr() function, but
> doing so is complicated and affects every arch, so I never quite seem
> to find time for it.
That was a splendid guess. There is a ds3231 RTC attached to
this RPI2. Checking the current sysctl value I see this...
# sysctl machdep.disable_rtc_set
machdep.disable_rtc_set: 0
Should it be the other way around, perhaps?
machdep.disable_rtc_set=1
At least the naming of the variable kind of seems to be hinting
that. And after a bit of testing the box now seems to be up and
running, though, it was totally idle for some 15 minutes or so.
Previously roughly 15 min of idle time has been quite enough to
drive the system to panic.
--jau
More information about the freebsd-arm
mailing list