Issues with vinum on current?

From: Chris Hedley <cbh_at_chrishedley.com>
Date: Wed, 9 Jul 2003 21:40:43 +0100 (BST)
Hi all,

I had a quick look for the subject topic but didn't find anything, so...
is anybody aware of outstanding problems with vinum?  I'm getting sporadic
crashes (see below) and vinum frequently fails to start properly, losing
state information and occasionally barfing when an attempt is made to
open/read a vinum device once it's been brought up manually.  Anyway, I'm
running 5.1-CURRENT updated on sat 5th, although this problem has been
around for a while; the vinum config is fairly straightforward, a pair of
mirrored discs with several partitions, and another pair of discs which
are just managed with vinum, no mirroring or striping or anything like
that, which also contain several partitions.  The crashes I've been
getting are as follows:

Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic.id = 00000000
fault virtual address   = 0x14
fault code              = supervisor write, page not present
instruction pointer     = 0x8:0xc01e5e69
stack pointer           = 0x10:0xd740d96c
frame pointer           = 0x10:0xd740d9a0
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         = 39 (syncer)
trap number             = 12
panic: page fault
cpuid = 0; lapic.id = 00000000
boot() called on cpu#0

syncing disks, buffers remaining...

Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic.id = 00000000
fault virtual address   = 0x14
fault code              = supervisor write, page not present
instruction pointer     = 0x8:0xc01e5e69
stack pointer           = 0x10:0xd740d594
frame pointer           = 0x10:0xd740d5c8
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         = 39 (syncer)
trap number             = 12
panic: page fault
cpuid = 0; lapic.id = 00000000
boot() called on cpu#0
Uptime: 7h50m46s
Dumping 511 MB
 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320
336 352 368 384 400 416 432 448 464 480 496

"where" shows:

#0  0xc022c41b in doadump ()
#1  0xc022cabf in boot ()
#2  0xc022cef8 in panic ()
#3  0xc03c2de2 in trap_fatal ()
#4  0xc03c2a92 in trap_pfault ()
#5  0xc03c2614 in trap ()
#6  0xc03ab078 in calltrap ()
#7  0xc01e16e1 in spec_xstrategy ()
#8  0xc01e170b in spec_specstrategy ()
#9  0xc01e0808 in spec_vnoperate ()
#10 0xc0274799 in bwrite ()
#11 0xc0276176 in vfs_bio_awrite ()
#12 0xc027e458 in vop_stdfsync ()
#13 0xc01e1340 in spec_fsync ()
#14 0xc01e0808 in spec_vnoperate ()
#15 0xc034892d in ffs_sync ()
#16 0xc028beab in sync ()
#17 0xc022c5e1 in boot ()
#18 0xc022cef8 in panic ()
#19 0xc03c2de2 in trap_fatal ()
#20 0xc03c2a92 in trap_pfault ()
#21 0xc03c2614 in trap ()
#22 0xc03ab078 in calltrap ()
#23 0xc2f29288 in launch_requests (rq=0xc2eb3bc0, reviveok=0)
    at /usr/src/sys/dev/vinum/vinumrequest.c:448
#24 0xc2f28e22 in vinumstart (bp=0xcd2eb6d0, reviveok=0)
    at /usr/src/sys/dev/vinum/vinumrequest.c:296
#25 0xc2f28b56 in vinumstrategy (biop=0xcd2eb6d0) at
/usr/src/sys/dev/vinum/vinumrequest.c:159
#26 0xc01e16e1 in spec_xstrategy ()
#27 0xc01e170b in spec_specstrategy ()
#28 0xc01e0808 in spec_vnoperate ()
#29 0xc0357c7d in ufs_strategy ()
#30 0xc0358b18 in ufs_vnoperate ()
#31 0xc02747c7 in bwrite ()

and "l /usr/src/sys/dev/vinum/vinumrequest.c:448" produces:

443                         microtime(&rqe->launchtime);            /*
time we launched this request */
444                         logrq(loginfo_rqe, (union rqinfou) rqe,
rq->bp);
445                     }
446     #endif
447                     /* fire off the request */
448                     DEV_STRATEGY(&rqe->b);
449                 }
450             }
451         }
452         return 0;

Any ideas?  Or should I provide a bit more info first?  My system is a
dual PIII 600, and has several discs attached via 3 scsi channels.

Chris.
Received on Wed Jul 09 2003 - 11:40:46 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:14 UTC