Re: regression in vinum

On Sat, Jun 19, 2004 at 08:37:40AM +0200, Thierry Herbelot wrote:
> Hello,
> 
> with the latest GENERIC, I can no longer auto-load vinum (from the loader with 
> vinum_load="YES" and vinum.autostart="YES" in /boot/loader.conf)
> the machine is an oldish BP6, used here as a tinderbox (sans ACPI).
> 
> the crash is :
> 
> Timecounters tick every 1.000 msec
> ad0: 6149MB <Maxtor 86480D6> [13328/15/63] at ata0-master UDMA33
> acd0: CDROM <NEC CD-ROM DRIVE:28B> at ata1-master PIO4
> ad4: 9671MB <IBM-DTTA-351010> [19650/16/63] at ata2-master UDMA33
> ad6: 9671MB <IBM-DTTA-351010> [19650/16/63] at ata3-master UDMA33
> vinum: loaded
> 
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address   = 0x4
> fault code              = supervisor read, page not present
> instruction pointer     = 0x8:0xc0639ec2
> stack pointer           = 0x10:0xc0c21a2c
> frame pointer           = 0x10:0xc0c21a38
> 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         = 0 (swapper)
> kernel: type 12 trap, code=0
> Stopped at      vaccess+0x26:   cmpl    %eax,0x4(%edx)
> db> where
> vaccess(2,16d,0,0,40) at vaccess+0x26
> devfs_access(c0c21ac4) at devfs_access+0x40
> devfs_lookupx(c0c21b80,c13c759c,1,0,c0886820) at devfs_lookupx+0x10c
> devfs_lookup(c0c21b80) at devfs_lookup+0x31
> lookup(c0c21bc8,c1523005) at lookup+0x2cb
> getdiskbyname(c1523000,c0827e20,c1594000,61,c1523000) at getdiskbyname+0x141
> open_drive(c1523000,c0886820,0,c0c21c78,c09b009b) at open_drive+0x22
> init_drive(c1523000,0,b,61,1) at init_drive+0x1c
> read_drive_label(c1523000,0,c0c21cb4,0,61) at read_drive_label+0x14
> check_drive(c1594400,c1594408,408,c09bc7dd,1) at check_drive+0x48
> vinum_scandisk(c13a8990,756e6976,656c706d,313378,c07ca480) at 
> vinum_scandisk+0x210
> vinumattach(0,0,c13aa0c0,c0c21d84,c05e4466) at vinumattach+0x299
> vinum_modevent(c13aa0c0,0,0,c088a320,c07ca480) at vinum_modevent+0x27
> module_register_init(c09be2ac,c1ec00,c1e000,0,c043dd65) at 
> module_register_init+0x52
> mi_startup() at mi_startup+0x96
> begin() at begin+0x2c
> db>
> 
> the gdb trace is :
> (gdb) list *(vaccess+0x26)
> 0xc0639ec2 is in vaccess (/files3/src/sys/kern/vfs_subr.c:3507).
> 3502                    *privused = 0;
> 3503
> 3504            dac_granted = 0;
> 3505
> 3506            /* Check the owner. */
> 3507            if (cred->cr_uid == file_uid) {
> 3508                    dac_granted |= VADMIN;
> 3509                    if (file_mode & S_IXUSR)
> 3510                            dac_granted |= VEXEC;
> 3511                    if (file_mode & S_IRUSR)
> (gdb)
> 
> with 
> /files3/src/sys/kern/vfs_subr.c:
>      $FreeBSD: src/sys/kern/vfs_subr.c,v 1.494 2004/06/17 17:16:49 phk Exp $
> 
> the previously working kernel used
>      $FreeBSD: src/sys/kern/vfs_subr.c,v 1.492 2004/06/14 14:25:03 phk Exp $
> 
> no obvious problem seen via cvsweb
> 
> 	TfH
> 
> PS : no kernel dump available (because the geom layer was crashed ?)

I have similar (if not the same) problem... But it crashed about 2
months ago (with then -current) and when I added second disk to raid1.
then after each boot... I have not tried any kernel since then... (but
I'll do on monday hopefully)

roman