Re: ia64/171814: [panic] bioq_init or bioq_remove (unsure which)

The following reply was made to PR ia64/171814; it has been noted by GNATS.

From: John Baldwin <[email protected]>
To: [email protected]
Cc: Paul Procacci <[email protected]>,
 [email protected]
Subject: Re: ia64/171814: [panic] bioq_init or bioq_remove (unsure which)
Date: Tue, 25 Sep 2012 08:45:59 -0400

 On Thursday, September 20, 2012 1:37:14 pm Paul Procacci wrote:
 > 
 > >Number:         171814
 > >Category:       ia64
 > >Synopsis:       [panic] bioq_init or bioq_remove (unsure which)
 > >Confidential:   no
 > >Severity:       non-critical
 > >Priority:       low
 > >Responsible:    freebsd-ia64
 > >State:          open
 > >Quarter:        
 > >Keywords:       
 > >Date-Required:
 > >Class:          sw-bug
 > >Submitter-Id:   current-users
 > >Arrival-Date:   Thu Sep 20 17:40:03 UTC 2012
 > >Closed-Date:
 > >Last-Modified:
 > >Originator:     Paul Procacci
 > >Release:        9.0-RELEASE-p3
 > >Organization:
 > Datapipe
 > >Environment:
 > FreeBSD db1.xxxxxxxxxxxxx.com 9.0-RELEASE-p3 FreeBSD 9.0-RELEASE-p3 #0: Tue 
 Jun 12 02:52:29 UTC 2012     root@amd64-
 builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64
 > >Description:
 > cpuid = 5; acpic id = 13
 > fault virtual address      = 0x20
 > fault code                 = supervisor read data, page not present
 > instruction pointer        = 0x20 :0xffffffff80865023
 > stack pointer              = 0x28 :0xffffff80002b3b30
 > frame pointer              = 0x28 :0xffffff80002b3b50
 > code segment               = base 0x0, limit 0xfffff, type 0x1b
 >                            = DPL 0, pres 1, long 1, def32 0, gran 1
 > processor eflags           = interrupt enabled, resume, IOPL = 0
 > current process            = 13 (g_event)
 > trap number                = 12
 > panic: page fault
 > cpuid = 5
 > KDB: stack backtrace:
 > #0 0xffffffff808680fe at kdb_backtrace+0x5e
 > #1 0xffffffff8x832cb7 at panic+0x187
 > #2 0xffffffff80b185a0 at trap_fatal+0x290
 > #3 0xffffffff80b188e9 at trap_pfault+0x1f9
 > #4 0xffffffff80b18daf at trap+0x3df
 > #5 0xffffffff80b0324f at calltrap+0x8
 > #6 0xffffffff807d165c at g_destroy_consumer+0x4c
 > #7 0xffffffff807ce6cc at g_run_events+0x1ec
 > #8 0xffffffff8080682f at fork_exit+0x11f
 > #9 0xffffffff80b0377e at fork_trampoline+0xe
 > 
 > #############################################################
 > 
 > - I'm using a GENERIC kernel.
 > - Following the instructions here: 
 http://www.freebsd.org/doc/faq/advanced.html
 >   I'm able to ascertain that the problem exists in one of the following two 
 functions:
 > 
 > db1# nm -n /boot/kernel/kernel | fgrep ffffffff808650
 > ffffffff80865080 T bioq_init
 > ffffffff808650b0 T bioq_remove
 
 No, I think it occurred in some other routine.  Note that 5023 < 5080, so the 
 PC is before the start of 'bioq_init()'.  It's probably in some static 
 function called by g_destroy_consumer() such as g_do_wither().  Do you have
 a kernel.symbols file?  If so, doing 'gdb /boot/kernel/kernel' followed by
 'l *0xffffffff80865023' would be very helpful.
 
 -- 
 John Baldwin
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ia64
To unsubscribe, send any mail to "[email protected]"