From owner-freebsd-bugs Mon Jul 26 11:50:26 1999 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 68A9214D1C for ; Mon, 26 Jul 1999 11:50:24 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id LAA20440; Mon, 26 Jul 1999 11:50:03 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Mon, 26 Jul 1999 11:50:03 -0700 (PDT) Message-Id: <199907261850.LAA20440@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Wilko Bulte Subject: Re: kern/12495: 3.1 install fails to detect Toshiba CDROM on AHA1740 adapter Reply-To: Wilko Bulte Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/12495; it has been noted by GNATS. From: Wilko Bulte To: gibbs@caspian.plutotech.com (Justin T. Gibbs) Cc: ken@plutotech.com, wilko@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG, freebsd-gnats-submit@FreeBSD.ORG Subject: Re: kern/12495: 3.1 install fails to detect Toshiba CDROM on AHA1740 adapter Date: Sat, 10 Jul 1999 18:56:11 +0200 (CEST) As Justin T. Gibbs wrote ... > >> The old SCSI layer probed things sequentially, so you would finish probing > >> everything, no matter how long it took, before any booting took place. > > > >Right. Maybe the install kernel should stick to sequential probing? > >I don't particularly like 'time dependent' probing with the variety of > >hardware that is out there. > > All CAM device instances 'exist' before the boot up is allowed to progress. > If you attempt to open the device while it is initializing, you will block > in open until the initialization is complete, but the open will eventually > succeed (assuming we were successful in our attempts to initialize the device). > The same probing mechanism (parallel probing) is used to find our root > device, and I have not heard of an instance where that has failed. I would > not expect sysintall to see the world any differently than the mount root > code. > > Perhaps there is another bug in the ahb driver... No. Today I did the following experiment (on the same machine): - 3.1-release install on Adaptec 1740A (ahb driver): cdrom not detected - 3.1-release install on Adaptec 2740 (ahc driver): cdrom not detected - 3.2-release install on Adaptec 2740 (ahc driver): cdrom detected on one occasion, subsequent attempts resulted in cdrom not detected. We decided to install 3.1-release (that is the cd version the machine owner has bought) via het Ethernet. This went fine. Booting the installed system results in detection of the cdrom drive just fine, reliable and all. We left the 2740 in the machine for the 3.1 network installation. My new theory is that sysinstall is the culprit, not the CAM/scsi subsystem. Any idea how I can verify this idea? NB the same guy that has this problem reported an identical "cdrom not found" problem on an IDE system. I remember having seen some discussions on this subject on the lists. But I am strictly SCSI-only so I did not pay too much attention. Wilko -- | / o / / _ Arnhem, The Netherlands - Powered by FreeBSD - |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message