[PATCH] RFC: don't aggravate kernel panics

Andy Green andy at openmoko.com
Tue Jan 20 16:43:56 CET 2009

Hash: SHA1

Somebody in the thread at some point said:
| Andy Green wrote:
|> You just repeated exactly what you quoted from what I wrote :-)
| Ah, okay ;-) I wasn't quite sure if you meant just a normal reboot
| or still something a littlw special.
|> It'd be enough if it displays it and saves it to SD Card where it can be
|> recovered at will, it's a long way ahead of where we are today if the
|> user doesn't have a debug board.  It also covers the case where Qi can't
|> start due to rootfs issue, the kernel will panic and the user can see
| Yup, sounds good. And anything that helps to debug a Qi setup will
| certainly save everyone lots of pain.

Well in GTA03 case the Qi setup is coming working from factory, and the
SD image is re-nukable.

But for GTA02 Qi users or for any other reason where the machine will
just die silently without debug board, it'd be a nice feature and
definitely help us figure out otherwise blind issues.  The same work
will also pay off on GTA02 / 03 cases (and maybe -01 too).

|> But we should set a flag or erase the panic dump after dumping it once,
|> otherwise if the backup rootfs has trouble it'll just loop :-)
| Hmm, besides the general undesirability of encountering trouble in
| your backup as well, why would that be a problem ? Or do you mean
| to check in Qi if there's a message and make this affect the boot
| choices ?

No if the backup kernel panciked and was set to do the reboot, it'd just
keep blowing chunks until you took the battery out for long enough.
What's wanted is only ever forcing entry to backup kernel after a panic
once so the "rendezvous point" would need marking as shown maybe by Qi.
~ Qi'd need to check for the signature and skip the first matching kernel
/ rootfs it would've done otherwise.

- -Andy
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org


More information about the openmoko-kernel mailing list