On Sat, 13 Nov 2010 14:17:35 -0800, Julian Elischer wrote: > On 11/13/10 2:08 PM, Robert Watson wrote: >> >> If regular crashdumps appear unreliable, try setting up a textdump with >> an automatic reboot, that might provde more reliable (small chance, but >> it could). > > we did have some people working on an ethernet version of the > dcons/remote debugging stuff > I guess it only supports a small subset of ethernet chips though.. > Anyone know the status of that work? > I don't know about ethernet dump but how about simply dumping memory after reset ? See: - http://en.wikipedia.org/wiki/Cold_boot_attack - http://citp.princeton.edu/memory/ - http://www.mcgrewsecurity.com/tools/msramdmp/ Last link contains a tool to dump memory to usb disk after reset. If kgdb works with raw memory dumps, it may already work. This has the potential to solve all tricky debugging cases without needing firewire. A boot time kernel option to avoid certain memory areas which are overwritten during boot by bios and ram dumping tool could be useful or maybe necessary. It can even be completely automated, eg. if kernel would maintain some kind of "RAM dirty" flag, then during boot something (loader or kernel) would check for it and perform dump if needed. Another idea worth implementing or at least adding to project ideas list is to implement everything that is currently possible with serial (boot0, loader, kernel console, ddb) over EHCI debug port: - http://www.coreboot.org/EHCI_Debug_PortReceived on Tue Nov 16 2010 - 00:00:05 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:09 UTC