Date: Fri, 20 Jan 1995 08:20:13 -0500 (EST) From: Peter Dufault <dufault@hda.com> To: pw@snoopy.MV.COM (Paul F. Werkowski) Cc: hackers@FreeBSD.org Subject: Re: NEC 4xi CDROM - what now? Message-ID: <199501201320.IAA00792@hda.com> In-Reply-To: <199501192331.SAA01416@snoopy.mv.com> from "Paul F. Werkowski" at Jan 19, 95 06:31:37 pm
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199501201320.IAA00792>