From owner-freebsd-current Wed Nov 25 11:44:48 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA03267 for freebsd-current-outgoing; Wed, 25 Nov 1998 11:44:48 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA03257 for ; Wed, 25 Nov 1998 11:44:37 -0800 (PST) (envelope-from gibbs@narnia.plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.9.1/8.9.1) with ESMTP id MAA06556; Wed, 25 Nov 1998 12:43:57 -0700 (MST) (envelope-from gibbs@narnia.plutotech.com) Message-Id: <199811251943.MAA06556@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Warner Losh cc: gfm@mira.net (Graham Menhennitt), current@FreeBSD.ORG Subject: Re: Adaptec 1542B still not detected In-reply-to: Your message of "Wed, 25 Nov 1998 12:15:58 MST." <199811251915.MAA26254@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 25 Nov 1998 12:36:31 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >In message <199811222334.QAA08681@narnia.plutotech.com> "Justin T. Gibbs" writ >es: >: The patch is inappropriate as it won't necessarily solve the problem >: on all machines (loop is CPU speed dependant). > >I've fixed this by using DELAY. But we have no way of knowing how long of a wait is enough. >: I've been meening >: to re-examine the aha probe code to see if we even need to look at >: the geometry register. A better approach may be to try an extended >: command and succeed the probe only if it fails. This requires the >: ability to recovery from an invalid command in the driver and >: ensuring that this works on all aha models. Ping me later in the >: week and I should have something for you to test. > >I've tried that in the aha probe, but it locks up some cards (none of >the ones that I have, but others that people have reported to me). This makes no sense considering that in the GENERIC kernel the bt probe occurs before the aha probe and the bt probe will cause an extended setup command to go to the aha (assuming it shows up as having a geometry register). I would suspect that we aren't clearing the invalid command status properly if sending an extended setup command doesn't work. Which cards had problems with the extended setup command? -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message