From owner-freebsd-questions@FreeBSD.ORG Fri Mar 28 03:32:59 2003 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E1A437B401 for ; Fri, 28 Mar 2003 03:32:59 -0800 (PST) Received: from greebo.hisser.org (greebo.hisser.org [62.49.72.114]) by mx1.FreeBSD.org (Postfix) with SMTP id 48C6D43FA3 for ; Fri, 28 Mar 2003 03:32:57 -0800 (PST) (envelope-from jamesp@hisser.org) Received: (qmail 2911 invoked by uid 500); 28 Mar 2003 11:32:48 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 28 Mar 2003 11:32:48 -0000 Date: Fri, 28 Mar 2003 11:32:48 +0000 (GMT) From: james To: Greg 'groggy' Lehey In-Reply-To: <20030328010810.GE72254@wantadilla.lemis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-20.4 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: freebsd-questions@freebsd.org Subject: Re: PANIC: vinum / atacontrol (5.0-STABLE / 4.8-RC2) X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2003 11:33:00 -0000 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 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 > > > > > > 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 >