On Thu, Feb 16, 2012 at 10:09:27AM -0500, Paul Mather wrote:
> On Feb 14, 2012, at 7:47 PM, Konstantin Belousov wrote:
> 
> > On Tue, Feb 14, 2012 at 09:38:18AM -0500, Paul Mather wrote:
> >> I have a problem with RELENG_8 (FreeBSD/amd64 running a GENERIC kernel, 
> >> last built 2012-02-08).  It will panic during the daily periodic scripts 
> >> that run at 3am.  Here is the most recent panic message:
> >> 
> >> Fatal trap 9: general protection fault while in kernel mode
> >> cpuid = 0; apic id = 00
> >> instruction pointer     = 0x20:0xffffffff8069d266
> >> stack pointer           = 0x28:0xffffff8094b90390
> >> frame pointer           = 0x28:0xffffff8094b903a0
> >> code segment            = base 0x0, limit 0xfffff, type 0x1b
> >>                        = DPL 0, pres 1, long 1, def32 0, gran 1
> >> processor eflags        = resume, IOPL = 0
> >> current process         = 72566 (ps)
> >> trap number             = 9
> >> panic: general protection fault
> >> cpuid = 0
> >> KDB: stack backtrace:
> >> #0 0xffffffff8062cf8e at kdb_backtrace+0x5e
> >> #1 0xffffffff805facd3 at panic+0x183
> >> #2 0xffffffff808e6c20 at trap_fatal+0x290
> >> #3 0xffffffff808e715a at trap+0x10a
> >> #4 0xffffffff808cec64 at calltrap+0x8
> >> #5 0xffffffff805ee034 at fill_kinfo_thread+0x54
> >> #6 0xffffffff805eee76 at fill_kinfo_proc+0x586
> >> #7 0xffffffff805f22b8 at sysctl_out_proc+0x48
> >> #8 0xffffffff805f26c8 at sysctl_kern_proc+0x278
> >> #9 0xffffffff8060473f at sysctl_root+0x14f
> >> #10 0xffffffff80604a2a at userland_sysctl+0x14a
> >> #11 0xffffffff80604f1a at __sysctl+0xaa
> >> #12 0xffffffff808e62d4 at amd64_syscall+0x1f4
> >> #13 0xffffffff808cef5c at Xfast_syscall+0xfc
> > 
> > Please look up the line number for the fill_kinfo_thread+0x54.
> 
> 
> Is there a way for me to do this from the above information? As
> I said in the original message, I failed to get a crash dump after
> reboot (because, it turns out, I hadn't set up my gmirror swap device
> properly). Alas, with the latest panic, it appears to have hung[1]
> during the "Dumping" phase, so it looks like I won't get a saved crash
> dump this time, either. :-(

Load the kernel.debug into kgdb, and from there do
"list *fill_kinfo_thread+0x54".

Attachment: pgpYsD5idJdoe.pgp
Description: PGP signature

Reply via email to