--=_courier-14758-1041727587-0001-2
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Actually, we ask for 36 and get 36, but the field in the response which is
supposed to tell us how much there is total is zeroed out, instead of
having a real value.
All we need to do is recognize when that field indicates less than 36
bytes, and then stop asking for anything else. Either (a) the device is
lying, in which case our original INQUIRY is fine, or (b) the device really
has less than 36 bytes, which means that we already have all the data.
Matt
On Fri, Jan 03, 2003 at 06:44:58PM -0800, Patrick Mansfield wrote:
> On Fri, Jan 03, 2003 at 05:04:04PM -0800, Matthew Dharm wrote:
> > Actually, 5 isn't minimal... it's sub-minimal. That's an error in the
> > INQUIRY data. The minimum (by spec) is 36 bytes.
> >=20
> > There should probably be a sanity check to never ask for INQUIRY less t=
han
> > 36 bytes. I thought there used to be such a thing....
> >=20
> > Matt
>=20
> Well we do ask for 36, but in Andries case only got back 5.
>=20
> The zero fill is a good solution and matches what the device should do if=
it
> can't get all of the INQUIRY data.
>=20
> There should be a warning output, in case other bad things happen, and so
> people know they have a borken device, and maybe a comment like:
>=20
> /*
> * If the response length is less than 36 the rest of the INQUIRY
> * is zero filled.
> *
> * etc.
> */
>=20
> >=20
> > On Sat, Jan 04, 2003 at 01:21:11AM +0100, Andries.Brouwer@cwi.nl wrote:
> > > Got a new USB device and noticed some scsi silliness while playing wi=
th it.
> > >=20
> > > A bug in scsi_scan.c is
> > >=20
> > > sdev->inquiry =3D kmalloc(sdev->inquiry_len, GFP_ATOMIC);
> > > memcpy(sdev->inquiry, inq_result, sdev->inquiry_len);
> > > sdev->vendor =3D (char *) (sdev->inquiry + 8);
> > > sdev->model =3D (char *) (sdev->inquiry + 16);
> > > sdev->rev =3D (char *) (sdev->inquiry + 32);
> > >=20
> > > since it happens that inquiry_len is short (in my case it is 5)
> > > and the vendor/model/rev pointers are wild.
> > > Catting /proc/scsi/scsi now yields random garbage.
>=20
> > > I made a patch but hesitated between a small patch and a larger one.
> > > Why do we have this malloced inquiry field? As far as I can see
> > > nobody uses it. And the comment in scsi_add_lun() advises us
> > > not to save the inquiry, precisely what we did until recently.
> > > So, should this change from 2.5.11 be reverted?
>=20
> The INQUIRY was saved so that users could avoid sending a long INQUIRY to
> a borken device and hang it, and just send an ioctl to retrieve it, but no
> ioctl was ever added.
>=20
> Rather than not saving it, we should just get the INQUIRY again (and
> implicitly overwrite vendor/model/rev) after spin up or if we get a unit
> attention with additional sense code of INQUIRY DATA HAS CHANGED; this
> would probably break somehow for some devices (changing the INQUIRY after
> a spin up is not out of spec), and is hard to handle with our current
> scanning (scsi_scan.c sends the INQUIRY, but sd.c has the spin up code),
> as per comments in scsi_probe_lun.
>=20
> -- Patrick Mansfield
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--=20
Matthew Dharm Home: mdharm-usb@one-eyed-alien.=
net=20
Maintainer, Linux USB Mass Storage Driver
It was a new hope.
-- Dust Puppy
User Friendly, 12/25/1998
--=_courier-14758-1041727587-0001-2
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE+F4ArIjReC7bSPZARAhvBAJ0RuF2le/aXz1Ux/DHoyrK9NWKGEQCfVmFM
i2lRyiFeFccp+kP1kG0jPF0=
=FBSE
-----END PGP SIGNATURE-----
--=_courier-14758-1041727587-0001-2--