Fatal trap 9: general protection fault while in kernel mode

Been tracking -CURENT (& -STABLE, though that is of marginal relevance
to this) on a daily basis for a couple of years now.  Gone fairly well,
usually; sometimes there's turbulence.  I suspect this is just a bump,
though -- and it's the first one I've encountered in at least a couple
of weeeks.

Sources updated as of 0347 hrs. US/Pacific; mirror I normally use is
cvsup14 (though I noticed that my script fell back to others in the
last few days, and I recall that cvsup13 was used yesterday).  I'd
need to reboot the system to be more definite than that.

Got -CURRENT (re-)built; booted, logged in, poked around, seemed OK;
issued:

	sudo boot0cfg -s 1 ad0 && sudo halt -p

(to switch to default to booting from -STABLE next time I bring the
machine up, then power the machine off).

Was greeted on the xterm that has the serial console by:

...
Starting background file system checks in 60 seconds.

Fri Mar 28 08:24:10 PST 2003

FreeBSD/i386 (freebeast.catwhisker.org) (cuaa0)

login: [0] f:00 typ:165 s(CHS):0/1/1 e(CHS):4/254/127 s:63 l:4192902
[1] f:00 typ:165 s(CHS):5/0/65 e(CHS):9/254/191 s:4192965 l:4192965
[2] f:00 typ:165 s(CHS):10/0/129 e(CHS):14/254/25Expensive timeout(9) function: 0xc02cf3a0(50xc4025000) 0.067257430 s
 s:8385930 l:4192965
[3] f:80 typ:165 s(CHS):15/0/193 e(CHS):255/254/255 s:12578895 l:67697910
GEOM: Reconfigure ad0s1, start 32256 length 2146765824 end 2146798079
GEOM: Reconfigure ad0s2, start 2146798080 length 2146798080 end 4293596159
GEOM: Reconfigure ad0s3, start 4293596160 length 2146798080 end 6440394239
GEOM: Reconfigure ad0s4, start 6440394240 length 34661329920 end 41101724159
boot() called on cpu#0
Waiting (max 60 seconds) for system process `vnlru' to stop...stopped
s) fong (max 60 second
r system process `bufdaemon' to stop...
Fatal trap 9: general protection fault while in kernel mode
cpuid = 1; lapic.id = 01000000
instruction pointer     = 0x8:0xd68e2d0a
stack pointer           = 0x10:0xd68e2ce4
frame pointer           = 0x10:0x8
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         = 11 (idle: cpu1)stopped
r' to stop...60 seconds) for system process `synce
kernel: type 9 trap, code=0
Stopped at      0xd68e2d0a:     mov     %si,%ss
db> tr


Fatal trap 12: page fault while in kernel mode
cpuid = 1; lapic.id = 01000000
fault virtual address   = 0xc
fault code              = supervisor read, page not present
instruction pointer     = 0x8:0xc0341a00
stack pointer           = 0x10:0xd68e29e8
frame pointer           = 0x10:0xd68e29ec
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = resume, IOPL = 0
current process         = 11 (idle: cpu1)
kernel: type 12 trap, code=0
db> show pcpu 0
cpuid        = 0
curthread    = 0xc1505a50: pid 12 "idle: cpu0"
curpcb       = 0xd68e5da0
fpcurthread  = none
idlethread   = 0xc1505a50: pid 12 "idle: cpu0"
currentldt   = 0x28
spin locks held:
db> show pcpu 1
cpuid        = 1
curthread    = 0xc1505960: pid 11 "idle: cpu1"
curpcb       = 0xd68e2da0
fpcurthread  = none
idlethread   = 0xc1505960: pid 11 "idle: cpu1"
currentldt   = 0x28
spin locks held:
db> show locks
db> 

I have nothing urgent such that I need to get the machine up & running
soon, so I can leave it this way for a while.  (Note that I had planned
to power it off until tonight.)

As you can see, the box is SMP (2x886 MHz PIIIs); 512 MB RAM iirc.  Very
little customization for the kernel beyond tweaking GENERIC for SMP.

I'll try to check back here from time to time (have a project in the
back yard that will require attention & labor).

I'm presently building -CURRENT from equivalent sources on my (UP)
laptop.

Anyway, if anyone thinks of something useful I can do to help figure
this out and/or test patches, please let me know.  (I do keep a private
mirror of the CVS repo here, and testing patches is pretty
straightforward for me.)

Thanks,
david
--
David H. Wolfskill				david_at_catwhisker.org
Based on what I have seen to date, the use of Microsoft products is not
consistent with reliability.  I recommend FreeBSD for reliable systems.