From owner-freebsd-scsi Tue May 26 09:11:34 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA24400 for freebsd-scsi-outgoing; Tue, 26 May 1998 09:11:34 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from sendero.simon-shapiro.org (sendero.simon-shapiro.org.142.69.207.in-addr.arpa [207.69.142.25] (may be forged)) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id JAA24395 for ; Tue, 26 May 1998 09:11:30 -0700 (PDT) (envelope-from shimon@sendero.simon-shapiro.org) Received: (qmail 18024 invoked by uid 1000); 26 May 1998 17:13:10 -0000 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Tue, 26 May 1998 13:13:10 -0400 (EDT) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: Tom Subject: Re: DPT install problem Cc: freebsd-scsi@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG, Eivind Eklund Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 23-May-98 Tom wrote: > > On Fri, 22 May 1998, Eivind Eklund wrote: > >> On Fri, May 22, 1998 at 10:41:41AM -0700, Tom wrote: >> > Yes, it seems to be a sysinstall interaction. If I leave the space >> > unallocated, and then disklabel and newfs it later, it works fine. >> > >> > Currently it is pretty hard to bootstrap a new DPT system. You have >> > to >> > be able to build a kernel somewhere else as sysinstall will install a >> > non-DPT kernel, and you can't use sysinstall to allocate large DPT >> > partitions. I fear for the new user. >> >> sysinstall doesn't do this anymore. The DPT driver is activated as >> part of the standard sysinstall now. > > I've noticed that. But this won't help anyone until 2.2.7 is released, > or somone makes a 2.2.6 snapshot with the new GENERIC kernel. I should have a kernel image in ftp://ftp.simon-shapiro.org/FreeBSD. >> As for large arrays: I think that will have to be left to you that >> actually have those large arrays - it is kind of difficult for us >> others to find out where the problem is. I suspect libdisk might be >> the culprit; it interact with the slice code using different IOCTLs >> than disklabel, IIRC. > > So you think that sysinstall makes a bogus label? Remember, sysinstall > hangs basically right after newfs'ing the large filesystem. Either newfs > hangs while cleaning up, or something that sysinstall does after > newfs'ing > all the filesystems hangs. > > Another interesting tibbit, is that sysinstall seems to be generating > once a second disk i/o requests during this hung state. Could be stuck > in > loop. > >> Eivind. > > Tom > --- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG 770.265.7340 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message