From owner-freebsd-scsi Sat Jan 4 04:21:39 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id EAA15949 for freebsd-scsi-outgoing; Sat, 4 Jan 1997 04:21:39 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id EAA15938 for ; Sat, 4 Jan 1997 04:21:33 -0800 (PST) Resent-From: j@uriah.heep.sax.de Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id NAA12535 for ; Sat, 4 Jan 1997 13:21:24 +0100 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id NAA04961 for scsi@freebsd.org; Sat, 4 Jan 1997 13:21:23 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id MAA19976 for scsi@freebsd.org; Sat, 4 Jan 1997 12:41:07 +0100 (MET) Resent-Message-Id: <199701041141.MAA19976@uriah.heep.sax.de> Message-ID: Date: Sat, 4 Jan 1997 12:38:54 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: gurney_j@resnet.uoregon.edu (John-Mark Gurney) Subject: Re: Ideas on CD changers sought References: X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from John-Mark Gurney on Jan 4, 1997 03:12:14 -0800 Resent-Date: Sat, 4 Jan 1997 12:41:07 +0100 Resent-To: scsi@freebsd.org Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As John-Mark Gurney wrote: > well... I tried this patch... it looks like it doesn't work... Too bad. So it looks Julian's idea doesn't do it either. That means we are stuck with the current method, to disable multi-LUN probes for CD-ROM devices, except of a few that are known to be media changer devices. > patch... as you can see different firmware revisions do different > things... Yep. Though not _very_ different. > (bt0:3:0): "CHINON CD-ROM CDS-535 Q20" type 5 removable SCSI 2 > cd1(bt0:3:0): CD-ROM cd present [207247 x 2048 byte records] > (bt0:3:1): UNIT ATTENTION asc:28,0 > (bt0:3:1): Not ready to ready transition, medium may have changed The unit attention is weird, but could not be taken as a reliable indication. > (bt0:3:1): "unknown unknown ????" type 0 fixed SCSI 0 We could perhaps treat this null result to the inquiry as ``target doesn't support that LUN'', but that's at least a similar crock as the hard-coded list of known-to-be-good devices. > sd2(bt0:3:1): Direct-Access > sd2(bt0:3:1): ILLEGAL REQUEST asc:24,0 Invalid field in CDB That's the consequence out of assuming `direct access' from the null inquiry. I think this should be killed, the device should be assigned to the `uk' driver (unknown SCSI device) in case it failed to deliver inquiry data. It makes things only worse this way. (The docking station of our Toshiba T5100 notebook contains an AIC7850 and an unknown CD drive. Since it times out during inquiry, the driver also assumes it to be an `sd0', which finally causes the kernel to panic.) > (bt0:4:0): "CHINON CD-ROM CDS-535 Q10" type 5 removable SCSI 2 > cd2(bt0:4:0): CD-ROM cd present [300077 x 2048 byte records] > (bt0:4:1): UNIT ATTENTION asc:28,0 > (bt0:4:1): Not ready to ready transition, medium may have changed > (bt0:4:1): "unknown unknown ????" type 0 fixed SCSI 0 > sd3(bt0:4:1): Direct-Access 586MB (300077 2048 byte sectors) The only difference here is that it apparently groks the geometry page for direct-access devices, and eventually delivers the correct number of blocks per device, and bytes per block. That's why you don't get the ``Invalid field in CDB'' here, but the result is bogus anyway since this device _ain't_ an `sd' device. Thanks for the response! -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)