Re: Detach of an0 induced kernel panic in 7.0-PRE

On Mon, 29 Oct 2007, David Wolfskill wrote:
[...]
> command-line prompt.  In an attempt to speed things up(!), I detached
> the an0 NIC.
>
> Boom!
>
> h252(7.0)[6] uname -a
> FreeBSD h252.dhw.mail-abuse.org. 7.0-BETA1 FreeBSD 7.0-BETA1 #573: Mon Oct 29 10:24:52 PDT 2007     root_at_h252.dhw.mail-abuse.org.:/common/S3/obj/usr/src/sys/CANARY  i386
> h252(7.0)[7]
> h252(7.0)[1] cd /usr/obj/usr/src/sys/CANARY/
> h252(7.0)[2] kgdb kernel.debug /var/crash/vmcore.5
> [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"]
> GNU gdb 6.1.1 [FreeBSD]
> ...
> This GDB was configured as "i386-marcel-freebsd".
>
> Unread portion of the kernel message buffer:
> an0: RID access failed
> an0: detached
>
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address   = 0xc8283178
> fault code              = supervisor write, page not present
> instruction pointer     = 0x20:0xc04daaf7
> stack pointer           = 0x28:0xe2987c5c
> frame pointer           = 0x28:0xe2987c78
> 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         = 12 (swi4: clock sio)
> trap number             = 12
> panic: page fault
> cpuid = 0
> Uptime: 31m46s
> Physical memory: 1011 MB
> Dumping 173 MB: 158 142 126 110 94 78 62 46 30 14
>
> #0  doadump () at pcpu.h:195
> 195             __asm __volatile("movl %%fs:0,%0" : "=r" (td));
> (kgdb) bt
> #0  doadump () at pcpu.h:195
> #1  0xc073b637 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
> #2  0xc073b8f9 in panic (fmt=Variable "fmt" is not available.
> ) at /usr/src/sys/kern/kern_shutdown.c:563
> #3  0xc0a005dc in trap_fatal (frame=0xe2987c1c, eva=3358077304)
>    at /usr/src/sys/i386/i386/trap.c:872
> #4  0xc0a00860 in trap_pfault (frame=0xe2987c1c, usermode=0, eva=3358077304)
>    at /usr/src/sys/i386/i386/trap.c:785
> #5  0xc0a011d5 in trap (frame=0xe2987c1c) at /usr/src/sys/i386/i386/trap.c:463
> #6  0xc09e71eb in calltrap () at /usr/src/sys/i386/i386/exception.s:139
> #7  0xc04daaf7 in an_stats_update (xsc=0xc8282000) at atomic.h:149
> #8  0xc074d7ea in softclock (dummy=0x0) at /usr/src/sys/kern/kern_timeout.c:274
> #9  0xc071ef0b in ithread_loop (arg=0xc3f0d2f0)
>    at /usr/src/sys/kern/kern_intr.c:1036
> #10 0xc071bc19 in fork_exit (callout=0xc071ed60 <ithread_loop>,
>    arg=0xc3f0d2f0, frame=0xe2987d38) at /usr/src/sys/kern/kern_fork.c:796
> #11 0xc09e7260 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:205
> (kgdb)
>
> Any hints would be welcome.
>
> (Save for this -- well, and the fact that I can't really use wi0(4) while
> running 7.x or 8 -- RELENG_7 seems OK so far.)
>
> I'm about to flip over to slice 4 (to build today's HEAD), but after
> that's done, I should be able to look at the crash dump a bit
> more.
>
> (And I'm fine with testing changes & patches -- given enough hints, I
> can cause moderate damage to unsuspecting source files, even.)

   Does the attached patch help?

-- 
Cheers,

Tai-hwa Liang