Re: www/chromium crashing whole system
On Wed, 17 Nov 2010 21:30:13 -0800, Julian Elischer wrote: On 11/17/10 12:15 PM, Marcin Wisnicki wrote: Probably not. I thought about it a bit more and realized that you will miss state of cpu registers which is rather important. How does debugging over firewire work if it only has access to host RAM ? registers are saved to ram as part of exception handling.. So I guess it means it's not possible to debug complete lockup (caused by driver) where no panic() occured ? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: www/chromium crashing whole system
On Wed, 17 Nov 2010 03:35:20 +, Alexander Best wrote: On Tue Nov 16 10, Alexander Best wrote: WOW! this is the first time i hear of such a concept. it seems great for people like me who are desktop users without any serial/firewire consoles or any additional debugging hardware. is there a way of trying this out somehow? personally i wouldn't need the memory dump to work in partitions. i'd simply blug in a blank usb stick and have the memory dump dd'ed onto it. i think adding partition awareness is not really needed. ok i read some more details and i think i figured out how to dump the memory to a usb stick. question still remains however: will i be able to use that memory snapshot in kgdb or gdb? Probably not. I thought about it a bit more and realized that you will miss state of cpu registers which is rather important. How does debugging over firewire work if it only has access to host RAM ? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: www/chromium crashing whole system
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_Port ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
