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>