On Wednesday 02 December 2009 22:17:20 Jeremy Chadwick wrote:
> On Wed, Dec 02, 2009 at 09:34:28PM +0000, Peter Pieczora wrote:
> > You're absolutely right, adding dumpdev="AUTO" solved generating dump
> > files.
> >
> > I may be totally wrong, but it seems that wlan0 causes system panic:
> > I remember when using ndis device (linksys pcmcia wifi card) similar
> > situation took place.
> >
> > Thanks for your help.
> >
> >
> > local dumped core - see /var/crash/vmcore.3
> >
> > Wed Dec 2 19:20:24 GMT 2009
> >
> > FreeBSD local 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:48:17 UTC
> > 2009 r...@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386
> >
> > panic: page fault
> >
> > GNU gdb 6.1.1 [FreeBSD]...
> >
> > Unread portion of the kernel message buffer:
> > wlan0: ieee80211_new_state_locked: pending SCAN -> AUTH transition lost
> >
> >
> > Fatal trap 12: page fault while in kernel mode
> > cpuid = 0; apic id = 00
> > fault virtual address = 0xc5e931d5
> > fault code = supervisor read, page not present
> > instruction pointer = 0x20:0xc0f78b0c
> > stack pointer = 0x28:0xe52deb7c
> > frame pointer = 0x28:0xe52dec34
> > code segment = base 0x0, limit 0xfffff, type 0x1b
> > = DPL 0, pres 1, def32 1, gran 1
> > processor eflags = interrupt enabled, resume, IOPL = 0
> > current process = 0 (iwi0 taskq)
> > trap number = 12
> > panic: page fault
> > cpuid = 0
> > Uptime: 2m25s
> > Physical memory: 1518 MB
>
> You're welcome! (I often wonder if dumpdev should be set to "AUTO" by
> default these days, but that discussion is for elsewhere and another
> time...)
>
> With regards to providing kernel dump/crash details: relevant Handbook
> details on this process are below. They're dated circa RELENG_5_3, but
> I think they still apply today for getting proper data out of vmcore.
>
> http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-gdb.htm
> l
> http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-post-m
> ortem.html
> http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-option
> s.html
>
> As I understand it, the basic requirements are:
>
> 1) "makeoptions DEBUG=-g" in your kernel configuration file
> 2) /usr/obj properly populated with the built kernel + modules + etc.
> that you're running at the time of the crash. (/boot/kernel/* isn't
> enough to accomplish this)
>
> Easiest way to achieve the latter is to go through the 11-step procedure
> listed in /usr/src/Makefile, then afterwards, **do not** clear /usr/obj
> on your own (some admins have a tendency to do this -- it makes
> debugging a kernel panic a pain). To decrease confusion, you might nuke
> everything in /var/crash *except* the file called "minfree" -- keep
> that!
>
> You'll also (obviously) need the box in a stable state -- meaning use
> local Ethernet and not iwi(4) for the time being.
>
> Someone else will have to help with post-analysis of the dump; kernel
> debugging has never been my forte aside from the "backtrace" (stack
> trace) part. :-)
>
> Filing a PR about this problem would also be a great thing to do, as
> it's good to have an official bug report developers and users can refer
> to. If you file a PR, please provide the number here for reference.
>
> Good luck!
>
Thank you again.
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
