From owner-freebsd-stable Wed Mar 6 0:21:38 2002 Delivered-To: freebsd-stable@freebsd.org Received: from freebsd.dk (fw-rl0.freebsd.dk [212.242.86.114]) by hub.freebsd.org (Postfix) with ESMTP id 4CA6937B404 for ; Wed, 6 Mar 2002 00:21:31 -0800 (PST) Received: (from sos@localhost) by freebsd.dk (8.11.6/8.11.6) id g268LR045942; Wed, 6 Mar 2002 09:21:27 +0100 (CET) (envelope-from sos) From: Søren Schmidt Message-Id: <200203060821.g268LR045942@freebsd.dk> Subject: Re: Request for testers of new ATA driver patches In-Reply-To: <3C8515E5.1000302@meoqu.gank.org> To: Craig Boston Date: Wed, 6 Mar 2002 09:21:27 +0100 (CET) Cc: stable@freebsd.org Reply-To: sos@freebsd.dk X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG It seems Craig Boston wrote: > Here lies the problem. I have each drive configured with its own span > array covering the whole drive, mostly to get the card's firmware to > shut up and not complain about not being configured. Once BSD boots I'm > using it as a dumb ATA controller and accessing the subdisks directly. > / is mounted from /dev/ad4s1a, and there are vinum partitions on ad4s1e > and ad6s1e. I know this probably isn't supported and so I didn't really > expect it to work with the new driver, but I really have no other > choice. Vinum doesn't recognize ar* as a valid disk device and refuses > to use it. Hmm, the ATA driver doesn't allow access to the individual disks in a RAID for security reasons, but if you need it you just need to rip out the test for raid disk and return EBUSY in ata-disk.c:adopen(). Why binum wont play ball I have no idea, ask groggy... > Also, while I've got your attention :), there is a long (about 30 > second) pause right after detecting atapci0. It seems to be present in > all the 4-STABLE kernels, and the same thing happened in the patched > kernel. This is an SMP kernel, but all of the ata stuff seems to be > initialized long before the second CPU is brought up. The system is > otherwise solid as a rock. Any clues or tips on how to get useful > debugging information that might help isolate the prob^H^H^H^Hannoyance? Thats the fake slave problem, or a device that doesn't respond properly. > And of course I'd be very grateful if anyone can suggest a better way of > setting up this disk array so that it's not so horribly hacked up :D I'd use it as a ATA RAID :) -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message