From owner-freebsd-stable@FreeBSD.ORG Mon Feb 28 15:18:42 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E42CE16A4D3 for ; Mon, 28 Feb 2005 15:18:42 +0000 (GMT) Received: from net2.wur.nl (net2.wur.nl [137.224.248.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 369E643D4C for ; Mon, 28 Feb 2005 15:18:42 +0000 (GMT) (envelope-from daniel@flipse.org) Received: from localhost (vscan1.wurnet.nl [137.224.10.55]) by net2.wur.nl (Postfix) with ESMTP id 1CC3C33EB2; Mon, 28 Feb 2005 16:18:41 +0100 (CET) Received: from net2.wur.nl ([137.224.248.102]) by localhost (vscan1.wurnet.nl [137.224.10.55]) (amavisd-new, port 10024) with ESMTP id 11888-01; Mon, 28 Feb 2005 16:18:38 +0100 (CET) Received: from thesaloon.flipse.org (haar170.athome220.wau.nl [137.224.220.170]) by net2.wur.nl (Postfix) with ESMTP id CBDF733E92; Mon, 28 Feb 2005 16:18:38 +0100 (CET) Received: from webmail.flipse.org (localhost.flipse.org [127.0.0.1]) by thesaloon.flipse.org (8.13.1/8.13.1) with ESMTP id j1SFIqRV000443; Mon, 28 Feb 2005 16:18:53 +0100 (CET) (envelope-from daniel@flipse.org) From: daniel@flipse.org To: Doug White Date: Mon, 28 Feb 2005 16:18:52 +0100 Message-Id: <20050228145117.M62060@flipse.org> In-Reply-To: <20050225165257.Y30975@carver.gumbysoft.com> References: <20050216102337.M31650@flipse.org> <421B1D15.9090507@Spoor.NU> <20050222164547.M22241@flipse.org> <20050225165257.Y30975@carver.gumbysoft.com> X-Mailer: Open WebMail 2.50 20050106 X-OriginatingIP: 193.67.51.174 (daniel) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Virus-Scanned: by amavisd-new at WUR-vscan1 cc: freebsd-stable@freebsd.org Subject: Re: Panics with 5-stable - vinum? raid5? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 15:18:43 -0000 On Fri, 25 Feb 2005 17:00:36 -0800 (PST), Doug White wrote > On Tue, 22 Feb 2005 daniel@flipse.org wrote: (..) > > Turned to debugging kernel, unattended reboot and crash dumping via swap, > > however this doesn't work at all. Kernel options added to GENERIC: > > "makeoptions DEBUG=-g" > > "options KDB, GDB, DDB, KDB_UNATTENDED" > > This is not the correct syntax. The options need to be on their own lines. OK, thanks for that, I didn't know that and will put them on a separate line from now on. (..) > > kldstat: > > Id Refs Address Size Name > > 1 3 0xc0400000 3b05c8 kernel > > 2 1 0xc189c000 dd000 vinum.ko > > 3 1 0xc1a0a000 7000 nullfs.ko > > I'd strongly, strongly suggest migrating to gvinum if you can. My > experience has found it vastly more stable on 5.X and seems free of the > odd config problems that have plagued vinum in the 4.X days. > > > vinum dumpconfig: > > Drive vinumdrive0: Device /dev/ad0s1e > > Drive vinumdrive1: Device /dev/ad2s1e > > Drive vinumdrive2: Device /dev/ad4s1e > > Drive vinumdrive3: Device /dev/ad6s1e > > This is ok, but: > > disklabel /dev/ad0s1: > # /dev/ad0s1: > 8 partitions: > # size offset fstype [fsize bsize bps/cpg] > a: 77075519 0 4.2BSD 2048 16384 28552 > b: 1048576 77075519 swap > c: 398283417 0 unused 0 0 > e: 320159322 78124095 vinum > > Unfortnately since you've elected to share vinumdrive0 with your root > partition you can't do the gvinum migration. I'd strongly suggest finding > a separate root disk, migrate to it, then convert the remaining 4 > disks to gvinum. If you switched to gvinum now your root partition > (ad0s1a) would be masked (and quite possibly destroyed) by the > gvinum conversion. > > gvinum generally expects to have the whole disk (or slice?) to > itself. le may be able to expound on the exact reasons for this and > if your setup is actually supported. Since replacing the Realtec NIC, I haven't had anymore panics just yet. This looks promising but keeping fingers crossed. I have no experience with odd config problems with vinum on 4.X nor 5.X. Although, I haven't succeeded in having vinum loaded, started and their devices fsck-ed automatically at boot time on 5.X. I did in fact give gvinum a try, presumably risking loosing all my data, as I did NOT convert anything (e.g. disklabels) other than using /dev/gvinum/* instead of /dev/vinum/* as fs devices. I have been using gvinum for a couple of weeks and quite naturally I would have noticed fs corruptions and/or raid5 parity problems. A checkparity always (both, vinum and gvinum) runs cleanly. Though, the performance of gvinum during such a f.i. checkparity run, was every so much slower than for vinum. Does that make sense? Daniel