This is a discussion on Detach of an0 induced kernel panic in 7.0-PRE - FreeBSD ; --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 ...
Content-Type: text/plain; charset=us-ascii
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
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.
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.
h252(7.0) uname -a
FreeBSD h252.dhw.mail-abuse.org. 7.0-BETA1 FreeBSD 7.0-BETA1 #573: Mon Oct =
29 10:24:52 PDT 2007 firstname.lastname@example.org.:/common/S3/obj/usr/s=
h252(7.0) cd /usr/obj/usr/src/sys/CANARY/
h252(7.0) 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
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
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));
#0 doadump () at pcpu.h:195
#1 0xc073b637 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:4=
#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)
#4 0xc0a00860 in trap_pfault (frame=3D0xe2987c1c, usermode=3D0, eva=3D3358=
#5 0xc0a011d5 in trap (frame=3D0xe2987c1c) at /usr/src/sys/i386/i386/trap.=
#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=
#9 0xc071ef0b in ithread_loop (arg=3D0xc3f0d2f0)
#10 0xc071bc19 in fork_exit (callout=3D0xc071ed60
arg=3D0xc3f0d2f0, frame=3D0xe2987d38) at /usr/src/sys/kern/kern_fork.c:=
#11 0xc09e7260 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:=
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
(And I'm fine with testing changes & patches -- given enough hints, I
can cause moderate damage to unsuspecting source files, even.)
David H. Wolfskill email@example.com
Proprietary data formats obfuscate, rather than disseminate, information.
See http://www.catwhisker.org/~david/publickey.gpg for my public key.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (FreeBSD)
-----END PGP SIGNATURE-----