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>