From owner-freebsd-hackers Fri Jan 20 05:58:13 1995 Return-Path: hackers-owner Received: (from root@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id FAA10163 for hackers-outgoing; Fri, 20 Jan 1995 05:58:13 -0800 Received: from hda.com (hda.com [199.232.40.182]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id FAA10157 for ; Fri, 20 Jan 1995 05:58:09 -0800 Received: (dufault@localhost) by hda.com (8.6.9/8.3) id IAA00792; Fri, 20 Jan 1995 08:20:14 -0500 From: Peter Dufault Message-Id: <199501201320.IAA00792@hda.com> Subject: Re: NEC 4xi CDROM - what now? To: pw@snoopy.MV.COM (Paul F. Werkowski) Date: Fri, 20 Jan 1995 08:20:13 -0500 (EST) Cc: hackers@FreeBSD.org In-Reply-To: <199501192331.SAA01416@snoopy.mv.com> from "Paul F. Werkowski" at Jan 19, 95 06:31:37 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 3057 Sender: hackers-owner@FreeBSD.org Precedence: bulk Paul F. Werkowski writes: > > > It may be true that the NEC 4Xi is the first SCSI device to > hit FreeBSD-land that actually returns XS_BUSY status to > the Inquire command. The immediate problem is that this gets > into a code branch in scsi_base.c that looks like this: > > case XS_BUSY: > /*should somehow arange for a 1 sec delay here (how?) */ > /* XXX tsleep(&localvar, priority, "foo", hz); > that's how! */ > case XS_TIMEOUT: > /* > * If we can, resubmit it to the adapter. > */ > if (xs->retries--) { > xs->error = XS_NOERROR; > xs->flags &= ~ITSDONE; > goto retry; > > This seems to result in rapidly depleting the retry count (2) on > probe and not finding the drive. > > Questions: > > 1. What the hell to do to correctly process the > BUSY status. The SCSI-II draft spec says try again later but > maybe some device specific thing has to happend to un-busy > the thing. > > 2. Does tsleep work during probe conditions? I tried it and it > seemed to have no effect. DELAY did seem to slow things down a > bit although it never got a non-busy status in 3 attempts with > 10 second delays. > > 3. Does the re-probe feature work? (eg scsi -f /dev/sd0d -r -t2 -l0) > On this system I see an eventual response to the inquire command but > the 1740A board seems confused by the time it gets it. Any SCSI > experts make sense of this? Yes, it works OK. > probe0(ahb0:2:0): scsi_cmd I think this is test_unit_ready > probe0(ahb0:2:0): ahb_scsi_cmd adapter gets called > probe0(ahb0:2:0): ahb_done adapter finished > probe0(ahb0:2:0): scsi_done 'done' processing gets called > probe0(ahb0:2:0): command: 0,0,0,0,0,0-[0 bytes] <= result > < long wait > > ahb0: board not responding <= from ahb_poll > ahb0: board not responding <= ditto > abort failed in wait > probe0(ahb0:2:0): scsi_cmd I think this is inquiry > probe0(ahb0:2:0): ahb_scsi_cmd > probe0(ahb0:2:0): ahb_done > probe0(ahb0:2:0): scsi_done > probe0(ahb0:2:0): command: 12,0,0,0,2c,0-[44 bytes] > ------------------------------ > 000: 05 80 02 02 1f 00 00 00 4e 45 43 20 20 20 20 20 <=== looks like ok data > 016: 43 44 2d 52 4f 4d 20 44 52 49 56 45 3a 35 30 31 <=== > 032: 32 2e 32 20 32 20 32 20 32 20 32 20 <=== > ------------------------------ > < long wait > > ahb0: board not responding > cmd fail > ahb0: board not responding > abort failed in wait An interesting thing about this is that the data is coming back OK (you see the inquiry data that came back, "NEC CD-ROM DRIVE") At least in this case it seems you want to treat BUSY like DONE. I have a feeling (and you've verified it) that lengthening timeouts aren't going to help. You probably said this earlier, but: This unit works OK under DOS? Does it work the same with and without a disk installed? Peter -- Peter Dufault Real Time Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 dufault@hda.com Fax: 508 433 5267 -- Formerly hd@world.std.com. E-mail problems? Tell hdslip@iii.net