PANIC: vinum / atacontrol (5.0-STABLE / 4.8-RC2)

james jamesp at hisser.org
Fri Mar 28 03:33:00 PST 2003


Hi Greg

I will be able to analyse the 5.0-stable panic a little more when I get home. 
In the meantime I've been doing simliar tests with 4.8-RC2. I get slightly more 
progress, but still a panic at the end.

Sequence of events:

1, create volume, 2 plexes on 2 disks
2, vinum stop volume.p1
3, atacontrol detach 1 (drive b)
4, atacontrol attach 1 - this WORKS, doesn't panic like 5.0-STABLE
5, vinum start volume.p1
<PANIC>

As before, I have a debug kernel and core dump. I can't seem to configure my 
mailer to not wrap lines, so I've posted all relevant information to 
http://web.hisser.org/vinum/4.8-crash/ . They are plain text files.

The kenel is panicking in dsioctl(), kern/subr_diskslice.c:356. I've had a look 
in there, but I really have no idea what it's trying to do - I can't even work 
out what the ioctl is. I'm no kernel guy :(

I appreciate this may not be a bug in Vinum, but it certainly seems like it's 
being triggered by vinum. I can access the drive, query the disklabel, and 
format the partition after the attach - it's only when I restart the plex does 
it panic.

If I detach the plex before removing it, I get the same panic in dsioctl() when 
I re-attach the plex, without even getting the opportunity to start the plex.

I would love to be able to help get this working, as I'm unable to hotswap at
all in Linux, which is what has made me move to FreeBSD.

Thanks

James

On Fri, 28 Mar 2003, Greg 'groggy' Lehey wrote:

> [Format recovered--see http://www.lemis.com/email/email-format.html]
> 
> Computer output wrapped.
> 
> On Thursday, 27 March 2003 at 14:18:43 +0000, james wrote:
> > Hi
> >
> > I am trying to configure hotswap-raid and vinum on my machine, and have found I
> > can cause the kernel to panic at will.
> >
> > Ideally I would like to be able to stop a plex, use atacontrol attach/detach to
> > replace the disk, and rebuild the plex. Would this work in theory?
> 
> Apparently.  There was a time when people claimed that ATA drives
> couldn't be hot swapped, but that seems to be incorrect nowadays.
> 
> > Now I stop and unload vinum, and try to run atacontrol:
> >
> > eddie# vinum stop
> > vinum unloaded
> > eddie# kldstat | grep vinum
> > eddie#
> > eddie# atacontrol detach 3
> > <PANIC>
> >
> > I have built a debug kernel, and have a core. The backtrace is below.
> >
> > If you need any more info please let me know!
> >
> > James
> >
> > Now follows the gdb-output:
> >
> > (kgdb) bt
> > #9  0xc01a9223 in panic () at /usr/src/sys/kern/kern_shutdown.c:517
> > #10 0xc02e311e in trap_fatal (frame=0xc0b94e00, eva=0x0) at /usr/src/sys/i386/i386/trap.c:844
> > #11 0xc02e2e32 in trap_pfault (frame=0xc873fa74, usermode=0x0, eva=0x24) at /usr/src/sys/i386/i386/trap.c:758
> > #12 0xc02e2a1d in trap (frame=
> >       {tf_fs = 0xc0380018, tf_es = 0xc0b90010, tf_ds = 0x10, tf_edi = 0x0,
> > tf_esi = 0xc1857530, tf_ebp = 0xc873fab4, tf_isp = 0xc873faa0, tf_
> > ebx = 0xc19a6c00, tf_edx = 0xe7, tf_ecx = 0xc032a340, tf_eax = 0x0, tf_trapno =
> > 0xc, tf_err = 0x0, tf_eip = 0xc01c6de6, tf_cs = 0x8, tf_eflag
> > s = 0x10292, tf_esp = 0xc873faf0, tf_ss = 0xc01296ae})
> >     at /usr/src/sys/i386/i386/trap.c:445
> > #13 0xc02d44f8 in calltrap () at {standard input}:98
> > #14 0xc01296ae in ata_command (atadev=0xc1857530, command=0xe7, lba=0x0, count=0x0, feature=0x0, flags=0x4)
> >     at bus_at386.h:526
> > #15 0xc01396df in adclose (dev=0x0, flags=0x3, fmt=0x0, td=0x0) at /usr/src/sys/dev/ata/ata-disk.c:292
> 
> (etc)
> 
> The trap occurred between frames 12 and 13 at address 0xc873faa0, in
> the ATA code.  Depending on your prowess with kernel code, you may be
> able to find out what has gone wrong.  I'd be inclined to look at
> frame 13:
> 
>  (gdb) f 13		        select frame
>  (gdb) l			list the code
>  (gdb) i loc			show local variables
> 
> My guess is that something has not been initialized.  It's probably
> worth submitting a bug report.
> 
> Greg
> --
> When replying to this message, please copy the original recipients.
> If you don't, I may ignore the reply or reply to the original recipients.
> For more information, see http://www.lemis.com/questions.html
> See complete headers for address and phone numbers
> 








More information about the freebsd-questions mailing list