Date: Wed, 2 Dec 2009 14:17:20 -0800 From: Jeremy Chadwick <freebsd@jdc.parodius.com> To: freebsd-stable@freebsd.org Subject: Re: Freebsd 8.0 system freeze Message-ID: <20091202221720.GA71012@icarus.home.lan> In-Reply-To: <200912022134.28639.peter@peterpieczora.com> References: <200912021622.13264.peter@peterpieczora.com> <20091202164346.GA63853@icarus.home.lan> <200912022134.28639.peter@peterpieczora.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.html http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-post-mortem.html http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-options.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! -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091202221720.GA71012>