www/chromium crashing whole system
Alexander Best
arundel at freebsd.org
Wed Nov 17 03:35:20 UTC 2010
On Tue Nov 16 10, Alexander Best wrote:
> On Tue Nov 16 10, Marcin Wisnicki wrote:
> > 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.
>
> 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?
cheers.
alex
>
> cheers.
> alex
>
> >
> > 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
> >
>
> --
> a13x
--
a13x
More information about the freebsd-current
mailing list