This system is a PII-300, 128M RAM, an IDE boot drive with an array of
8 seagate baracuda UW drives connected to an Adaptec U2W card.
This system has been around as a test box. It is running a recent 4.1.1
kernel from the middle of last week for vinum testing. I have been
experiencing this panic when rsync'ing a large nfs volume to the RAID5
vinum volume. It usually takes several hours for this to occur.
Originally, I was running on a generic kernel, but after I started having
difficulties, I compiled a minimal kernel (I had been using soft updates
on the vinum volume)
I forgot to set dumpdev this time around, but this problem seems easily
reproducable. Thanks to all for their fantastic work.
Regards,
Stephen
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x14
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0138c63
stack pointer = 0x10:0xc8c31cc8
frame pointer = 0x10:0xc8c31d30
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = trace trap, interrupt enabled, resume, IOPL = 0
current process = 4 (bufdaemon)
interrupt mask = bio
kernel: type 12 trap, code=0
Stopped at ahc_action+0x1ef: movl 0x14(%esi),%eax
db>
db> trace
ahc_action(c0d29980,c0d75c00,1,c0d7e730,6c4000) at ahc_action+0x1ef
xpt_run_dev_sendq(c0d29940) at xpt_run_dev_sendq+0x1cb
xpt_action(c0d75c00,684000) at xpt_action+0x23f
dastart(c0d6e880,c0d75c00,c0d75c00,c0d7e730,1,684000,c0d6f830,1) at dastart+0x1cc
xpt_run_dev_allocq(c0d29940,c0d6e880,c0d85800,c0edc988,684000) at
xpt_run_dev_allocq+0x80
xpt_schedule(c0d6e880,1,684000,c0d85800,c0edc988) at xpt_schedule+0xbf
dastrategy(c0edc988,c0edc988,2,c8c31e74,c0dab6ea) at dastrategy+0x88
diskstrategy(c0edc988,c0e67980,c0d99000,c369cb28,c0ee0540) at diskstrategy+0x95
launch_requests(c0ee0540,0,c369cb28,c8c1ef40,684000) at launch_requests+0x2ee
vinumstart(c369cb28,0,c369cb28,c8c31ec4,c0187bb0) at vinumstart+0x1ce
vinumstrategy(c369cb28,c0d8a080,c369cb28,1,c8c31ed0) at vinumstrategy+0x96
spec_strategy(c8c31ef8,c8c31edc,c01f7eb9,c8c31ef8,c8c31f04) at spec_strategy+0x8c
spec_vnoperate(c8c31ef8,c8c31f04,c01750ea,c8c31ef8,2000) at spec_vnoperate+0x15
ufs_vnoperatespec(c8c31ef8) at ufs_vnoperatespec+0x15
bwrite(c369cb28,c8c31f1c,c017a449,c8c31f68,c8c31f28) at bwrite+0x1de
vop_stdbwrite(c8c31f68,c8c31f28,c0187685,c8c31f68,c8c31f34) at vop_stdbwrite+0xe
vop_defaultop(c8c31f68,c8c31f34,c01f7eb9,c8c31f68,c8c31f74) at vop_defaultop+0x15
spec_vnoperate(c8c31f68,c8c31f74,c0175f8e,c8c31f68,c369cb28) at spec_vnoperate+0x15
ufs_vnoperatespec(c8c31f68,c369cb28,c027c198,c015dfb5,c0154d09) at
ufs_vnoperatespec+0x15
vfs_bio_awrite(c369cb28,39,c01764c4,c015dfb5,0) at vfs_bio_awrite+0x23e
flushbufqueues(0,8000,c02280ec,0,b0246) at flushbufqueues+0x116
buf_daemon(0) at buf_daemon+0x8f
fork_trampoline() at fork_trampoline+0x8
Stephen Spencer |
| "Mutton yesterday, mutton today, and blimey,
| if it don't look like mutton again tomarrer"
| -Bert
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
