Date: Fri, 28 Mar 2003 08:46:39 -0800 (PST) From: David Wolfskill <david@catwhisker.org> To: current@freebsd.org Subject: Fatal trap 9: general protection fault while in kernel mode Message-ID: <200303281646.h2SGkd9m019357@bunrab.catwhisker.org>
next in thread | raw e-mail | index | archive | help
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@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200303281646.h2SGkd9m019357>