Dear colleagues,
I am working on a patch that adds a new feature to the ramoops kernel
feature.
The patch is an extension of the current ramoops facility, see
http://lwn.net/Articles/377890/.
The patch adds a platform-specific reservation of ramoops memory in early
boot, so that the ramoops area can be:
a) at a constant physical RAM address
b) guaranteed never to be overwritten by the kernel or userspace (other
than by the ramoops driver that is)
These two features mean that even for volatile RAM, as long as:
a) power is maintained
b) the bootloader does not clear the RAM
c) subsequent reboots use kernels that have the new feature and define the
ramoops area at the same RAM address
then the contents of the ramoops memory is preserved through reboot and
you can recover the contents of an oops or panic dump that happened before
the reboot. In fact, you can even log arbitrary data in RAM accross
reboots.
Why do you need this great feature so badly?
You need this feature to help you debug or to monitor various drivers and
kernel features that oops or panic while in interrupt context or on boards
where there is no other candidate memory mapped device to write to, (i.e.
no available NVRAM, no FLASH or no free FLASH) and there is no way to
write to a device that might be protected by a lock or a mutex, such as a
write to an EEPROM from interrupt context.
From your experience, does this feature have a chance of being accepted
into the mainline kernel if implemented for ARM and PPC?
TIA and hag sameach,
- yba
--
EE 77 7F 30 4A 64 2E C5 83 5F E7 49 A6 82 29 BA ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- [email protected] - tel: +972.2.679.5364, http://www.tkos.co.il -
_______________________________________________
Linux-il mailing list
[email protected]
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
