Detach of an0 induced kernel panic in 7.0-PRE

This may well qualify as something for which the appropriate remedy is
"Don't do that, then."  :-}

As is my habit,I built today's RELENG_6 on my laptop's slice 1, then
booted it & updated ports,  then booted RELENG_7 (on slice 3) and
started building today's RELENG_7.

Shortly thereafter, I headed in to work, leaving the laptop in the trunk
of the car as I drove in (about 30 minutes),busily building stuff.

Now, at home, I normally use the miniPCI wi0 NIC.  Since I can't get the
wi0 NIC to associate running RELENG_7 or HEAD, I use a PCMCIA an0 NIC at
home when I run those.

But at work, the access points are configured for 802.11g only -- no
802.11b compatibility.  So there, I switch to the laptop's built-in xl0
NIC.

So I got to my desk, started the Perk script I cobbled up to handle NIC
transitions, wandered off to fill my water bottle, came back,and saw
that the script was trying to get the an0 NIC to associate -- and then I
realized that I had negelcted to plug the cable in to the xl0 NIC.

Oh.  :-(

So I hot ^C to interrupt the script and plugged the cable in to the xl0
NIC.  I was about to re-run the script and saw that I didn't yet have a
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.)

Peace,
david
-- 
David H. Wolfskill				david_at_catwhisker.org
Proprietary data formats obfuscate, rather than disseminate, information.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.