[8913] in linux-scsi channel archive
Re: LINUX Jobs for 2.4 update [scsi]
daemon@ATHENA.MIT.EDU (Jens Axboe)
Sat May 27 17:22:07 2000
Date: Sat, 27 May 2000 23:07:27 +0200
From: Jens Axboe <axboe@suse.de>
To: Paul Gortmaker <p_gortmaker@yahoo.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
linux-kernel@vger.rutgers.edu, linux-scsi@vger.rutgers.edu
Message-ID: <20000527230727.D246@suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <39300F87.24A9B5EC@yahoo.com>; from p_gortmaker@yahoo.com on Sat, May 27, 2000 at 02:10:15PM -0400
On Sat, May 27 2000, Paul Gortmaker wrote:
> > To Do
> > -----
> > Linux sends a 1K buffer with SCSI inquiries. The ANSI-SCSI limit is 255.
>
> I don't see how this can be. In scan_scsis() scsi_result0[256] is
> declared, and if that isn't appropriate for host needing DMA then
> we kmalloc(512, GFP_DMA) - either way it doesn't matter since the
> allocation length field in the CCB for INQUIRY is only a byte (and
> we set it to 255). Even scsi_wait_req() is told the the result buffer
> length is 255 when the INQUIRY command is lodged.
Exactly, I told Alan this several weeks ago also.
> > Linux uses TEST_UNIT_READY to chck for device presence on a PUN/LUN. The
> > INQUIRY is the only valid test allowed by the spec.
>
> The draft of SCSI-2 spec I have here hints that INQUIRY should be used
> to probe system configuration and that TEST_UNIT_READY is more for
> polling on devices with removable media. I tossed the TEST_UNIT_READY
> part out and INQUIRY alone works fine (one disk, 2 CDs and a tape on
> a BusLogic clone - all found as per usual).
Looks good to me. Although I can't possibly see what harm a TEST_UNIT_READY
command could do...
--
* Jens Axboe <axboe@suse.de>
* Linux CD/DVD-ROM, SuSE Labs
* http://kernel.dk
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
