From owner-freebsd-hackers Tue Aug 29 15:59:36 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id PAA27532 for hackers-outgoing; Tue, 29 Aug 1995 15:59:36 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id PAA27509 for ; Tue, 29 Aug 1995 15:59:26 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id IAA05012; Wed, 30 Aug 1995 08:56:12 +1000 Date: Wed, 30 Aug 1995 08:56:12 +1000 From: Bruce Evans Message-Id: <199508292256.IAA05012@godzilla.zeta.org.au> To: bde@zeta.org.au, jdl@chrome.onramp.net Subject: Re: wd0 detect fails Cc: hackers@freebsd.org, vak@cronyx.ru Sender: hackers-owner@freebsd.org Precedence: bulk >> A user reported that the status was 0x52 for the old code (0x02 = IDX). >> The spec says 0x50 :-). >> >> We could ignore some bits, perhaps all except 0x51, but the old code >> essentially ignored all except 0x50 (and BUSY). Why did it fail exactly? >With minor cable finagling here, I can easily, :-(, construct a failing >probe case. Would you like to go a few rounds with me on this one? >I was getting the CDROM detect failure when trying to put the CDROM >as the only device of the wdc1 controller. (The wdc0 had either 1 or 2 >drives on it.) >Is this the failure mode you were interested in? It's not very surprising that it fails with no drives. I would expect both wdprobe() and the diagnostics command to succeed unless the timeout is too short (it is too short - should be 31000 ms). But it wouldn't be surprising for the diagnostics commands to report that both drives aren't their - something different from an IDE drive is there. Then wdprobe() would fail, so wdattach() wouldn't be called, so atapi_ attach() wouldn't be called, although atapi_attach() might work if it was called. Bruce