--3Pql8miugIZX0722
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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@h252.dhw.mail-abuse.org.:/common/S3/obj/usr/s=
rc/sys/CANARY i386
h252(7.0)[7]=20
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]
=2E..
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 =3D 0; apic id =3D 00
fault virtual address =3D 0xc8283178
fault code =3D supervisor write, page not present
instruction pointer =3D 0x20:0xc04daaf7
stack pointer =3D 0x28:0xe2987c5c
frame pointer =3D 0x28:0xe2987c78
code segment =3D base 0x0, limit 0xfffff, type 0x1b
=3D DPL 0, pres 1, def32 1, gran 1
processor eflags =3D interrupt enabled, resume, IOPL =3D 0
current process =3D 12 (swi4: clock sio)
trap number =3D 12
panic: page fault
cpuid =3D 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" : "=3Dr" (td));
(kgdb) bt
#0 doadump () at pcpu.h:195
#1 0xc073b637 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:4=
09
#2 0xc073b8f9 in panic (fmt=3DVariable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:563
#3 0xc0a005dc in trap_fatal (frame=3D0xe2987c1c, eva=3D3358077304)
at /usr/src/sys/i386/i386/trap.c:872
#4 0xc0a00860 in trap_pfault (frame=3D0xe2987c1c, usermode=3D0, eva=3D3358=
077304)
at /usr/src/sys/i386/i386/trap.c:785
#5 0xc0a011d5 in trap (frame=3D0xe2987c1c) 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=3D0xc8282000) at atomic.h:149
#8 0xc074d7ea in softclock (dummy=3D0x0) at /usr/src/sys/kern/kern_timeout=
..c:274
#9 0xc071ef0b in ithread_loop (arg=3D0xc3f0d2f0)
at /usr/src/sys/kern/kern_intr.c:1036
#10 0xc071bc19 in fork_exit (callout=3D0xc071ed60 ,=20
arg=3D0xc3f0d2f0, frame=3D0xe2987d38) at /usr/src/sys/kern/kern_fork.c:=
796
#11 0xc09e7260 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:=
205
(kgdb)=20

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
--=20
David H. Wolfskill david@catwhisker.org
Proprietary data formats obfuscate, rather than disseminate, information.

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

--3Pql8miugIZX0722
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (FreeBSD)

iEYEARECAAYFAkcmLi8ACgkQmprOCmdXAD0RXwCfbab8qYHTOW B6W3W94NP6DOEi
vsoAn3Lxuz7j76qCTQu7dJksp2+pN6a2
=lh1g
-----END PGP SIGNATURE-----

--3Pql8miugIZX0722--