Freebsd 8.0 system freeze

[Jeremy Chadwick]

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 at 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 at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |