new kernel ... / meaning of stable-tracking

Werner Almesberger werner at
Wed Oct 1 01:34:07 CEST 2008

andrzej zaborowski wrote:
> First was when I was booting off the sd for the first time and the sd
> had errors so the kernel loaded from nand okay and then init loaded
> but then subsequent programs or scripts loaded corrupt and something
> locked up, so I used the power button.

Hmm, and then you booted from NAND and went on to repair the uSD card
using the system booted from NAND ? Thanks, that's indeed a case where
there's a visible difference, because we wouldn't even reach the point
where neodog is running, yet the kernel isn't completely dead yet.

> Second time was when I was hacking the timers yesterday and apparently
> I broke gettimeofday and one of the first processes hung waiting for
> something, I used the power button (for kicks) and it worked. (99% of
> the times I was just taking the battery out and wouldn't mind doing it
> that time also)

You're very brave to do this kind of low-level hacking without a debug
board ;-)

By the way, my solution for quickly resetting the Neo without too much
physical effort is to just toggle the debug board reset:

I almost always keep the debug board attached, since I don't want to
miss any clues printed on the serial console, and I also like to copy
and paste printks for later reference (which I couldn't do if I only
had them on the screen).

> Something to consider is that Linux has something called SysRq key for
> like 15 years and it's a similar concept.  It's something that works
> at all times even after the kernel panicked and nobody doubts its
> usefulness.

Yes, SysRq is pretty close to this. Even there, the low-level driver
only provides the SysRq keycode, but it's higher-level code that
decides what to do with it. But I take your point that this is still
in the kernel, not in user space.

How about the following compromise: we leave the power-down code in
the kernel, but move it from the interrupt handler to a separate
function (perhaps in a separate file as well) that just gets called
on ONKEY/SECOND events and that's responsible for handling
onkey_seconds and perhaps also PCF50633_F_PWR_PRESSED.

That makes it easier to remove/restructure/etc. it in case there are
objections or if a future use of the PCF50633 by us or others does
not agree with this specific emergency shutdown mechanism.
pcf50633_work should be broken down into more manageable pieces
anyway, see CodingStyle, chapter 6.

Does that sound good ?

- Werner

More information about the openmoko-kernel mailing list