From owner-freebsd-hackers Thu Jan 19 16:09:36 1995 Return-Path: hackers-owner Received: (from root@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id QAA00927 for hackers-outgoing; Thu, 19 Jan 1995 16:09:36 -0800 Received: from snoopy.mv.com (snoopy.mv.com [199.125.64.182]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id QAA00907 for ; Thu, 19 Jan 1995 16:09:24 -0800 Received: (from pw@localhost) by snoopy.mv.com (8.6.9/8.6.6) id SAA01416; Thu, 19 Jan 1995 18:31:37 -0500 Date: Thu, 19 Jan 1995 18:31:37 -0500 From: "Paul F. Werkowski" Message-Id: <199501192331.SAA01416@snoopy.mv.com> To: hackers@FreeBSD.org Subject: Re: NEC 4xi CDROM - what now? Sender: hackers-owner@FreeBSD.org Precedence: bulk Q. How can you recognize a pioneer? A. He's one with the arrows sticking out of his a^H but. 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? 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 # Any enlightened observations would be more than welcome. Paul