Openmoko Bug #2135: write kernel crash message somewhere where it can be retrieved after reboot?

Openmoko Public Trac bugs at
Mon Apr 13 16:28:07 CEST 2009

#2135: write kernel crash message somewhere where it can be retrieved after
 Reporter:  lindi            |          Owner:  openmoko-kernel     
     Type:  enhancement      |         Status:  new                 
 Priority:  high             |      Milestone:  stable-kernel-2009.1
Component:  System Software  |        Version:  unspecified         
 Severity:  normal           |       Keywords:                      
 Haspatch:  0                |      Blockedby:                      
Estimated:                   |    Patchreview:                      
 Blocking:                   |   Reproducible:                      

Comment(by lindi):

 The current shortcoming of ramconsole-1.patch are:
 1) It needs mem=127M option
 2) panic=20 and/or watchdog is needed so that user can recover the message
 after reboot
 3) It prints contents of the ringbuffer to console on bootup. This can be
 very slow if the ringbuffer holds the full 1M of data.
 4) Often after a crash there is an fsck and after that the system is
 rebooted. This means the contents of ringbuffer is actually printed twice
 to console.
 5) Since contents of ringbuffer is printed to console using printk it is
 limited by the size of the printk buffer, sometimes fsck+reboot is enough
 to add so much data that when syslogd is finally started it can not read
 the original panic message from /proc/kmsg anymore.
 6) Sometimes when the system is so stuck that I need to remove the battery
 to reboot it the contents of the ringbuffer starts to fade when no RAM
 refresh is done. This is usually harmless but if it happens to hit the
 magic word then ramconsole-1.patch will not print the contents of the
 ringbuffer and there is no way to access it from userland either (I
 couldn't do it via /dev/mem for some reason).

 Advantages are:
 1) It works and provides useful info
 2) It is quite simple patch that does not modify kernel logging logic
 much, it merely adds its own ringbuffer in parallel to the normal logging
 which should reduce the likelyhood that it breaks something important.

Ticket URL: <> <>
openmoko trac

More information about the openmoko-kernel mailing list