Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 3 Dec 2009 09:42:14 +0000
From:      Peter Pieczora <peter@peterpieczora.com>
To:        freebsd-stable@freebsd.org
Subject:   Re: Freebsd 8.0 system freeze
Message-ID:  <200912030942.14949.peter@peterpieczora.com>
In-Reply-To: <20091202221720.GA71012@icarus.home.lan>
References:  <200912021622.13264.peter@peterpieczora.com> <200912022134.28639.peter@peterpieczora.com> <20091202221720.GA71012@icarus.home.lan>

next in thread | previous in thread | raw e-mail | index | archive | help
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 root@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. 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200912030942.14949.peter>