linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Douglas Gilbert <dougg@torque.net>
To: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>,
	Mike Anderson <andmike@linux.vnet.ibm.com>,
	Mike Christie <michaelc@cs.wisc.edu>,
	sekharan@us.ibm.com, dm-devel@redhat.com,
	linux-scsi@vger.kernel.org, jens.axboe@oracle.com,
	linux-hotplug@vger.kernel.org
Subject: Re: no INQUIRY from userspace please
Date: Tue, 19 Feb 2008 15:53:38 -0500	[thread overview]
Message-ID: <47BB41D2.2070209@torque.net> (raw)
In-Reply-To: <47AB3C47.6060805@s5r6.in-berlin.de>

Stefan Richter wrote:
>> James Bottomley wrote:
>>> It's all very well to say this, but I think if you look at what udev
>>> does, you'll find that it uses scsi_id to send a VPD inquiry to the
>>> device so it can populate /dev/disk/by-id, so the point is already
>>> conceded
> 
> PS:  Alas we don't have a practicable way to know how many of the
>   - doesn't work with Linux but works to some degree with Windows,
>   - doesn't work with a 2.6 based Linux distro but did work with a
>     2.4 based distro
> kinds of devices are those with this INQUIRY bug or similar bugs.
> 
> While non-udev distros slowly went out of fashion on the desktop, there
> was a certain frequency of reports of the latter kind of FireWire
> devices, but this was before I became aware of that kind of firmware
> bug, therefore I don't have any data whether it played a role for these
> cases.

Just a small point here. To my knowledge all devices
that understand the SCSI command set will accept a
36 byte INQUIRY (i.e. an INQUIRY with an "allocation length"
of 36). That is a practical consideration since they would
crash on Windows otherwise.

Now scsi_id (and probably other programs of that ilk
(including some of mine)) get excited when they get a
response to a "36 byte" INQUIRY and go onto ask for
VPD page 0x80 (serial number) or page 0x83 (device id)
via an INQUIRY command with the EVPD bit set.
Now if they were clever they would make sure that
the "allocation length" of the _first_ such VPD inquiry
was 36! That way they could have a close look at the
response and if it wasn't valid for a VPD page
(e.g. requested_VPD_page_num != response[1]) then
they would leave the damn device alone **.

<<< Special case: removable media >>>
Since response[1] of a standard INQUIRY has RMB (removable
medium bit) set in its top bit and the rest of the byte
reserved, 0x80 is a possibility. That could give a
false positive when the serial number VPD page is
requested. So try looking for VPD page 0x83 (with
alloc_len=36) first.


** The logic here is that a brain dead SCSI target
interpreter doesn't look at the EVPD bit and can
only handle an "allocation length" of 36. So if
it receives an INQUIRY cdb with the EVPD bit set
it will just respond with its standard INQUIRY
response.

Doug Gilbert

  reply	other threads:[~2008-02-19 20:53 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-24  0:30 [PATCH 0/9] scsi_dh: Move dm device handler to SCSI layer Chandra Seetharaman
2008-01-24  0:30 ` [PATCH 1/9] scsi_dh: add REQ_LB_OP_TRANSITION and errors Chandra Seetharaman
2008-01-24  0:30 ` [PATCH 2/9] scsi_dh: change sd_prep_fn to call common code Chandra Seetharaman
2008-01-24  0:30 ` [PATCH 3/9] scsi_dh: scsi handling of REQ_LB_OP_TRANSITION Chandra Seetharaman
2008-02-01 20:00   ` Mike Christie
2008-02-04 18:59     ` Chandra Seetharaman
2008-02-04 19:02     ` James Bottomley
2008-02-06 19:00       ` Mike Anderson
2008-02-06 20:52         ` James Bottomley
2008-01-24  0:31 ` [PATCH 4/9] scsi_dh: add skeleton for SCSI Device Handlers Chandra Seetharaman
2008-02-01 19:53   ` Mike Christie
2008-02-01 20:27     ` Mike Anderson
2008-02-04 18:54     ` Chandra Seetharaman
2008-01-24  0:31 ` [PATCH 5/9] scsi_dh: add EMC Clariion device handler Chandra Seetharaman
2008-01-24  0:31 ` [PATCH 6/9] scsi_dh: add hp sw " Chandra Seetharaman
2008-01-24  0:32 ` [PATCH 7/9] scsi_dh: Add support for SDEV_PASSIVE Chandra Seetharaman
2008-02-04 18:58   ` James Bottomley
2008-02-04 20:15     ` Chandra Seetharaman
2008-02-04 20:28       ` James Bottomley
2008-02-04 21:19         ` Chandra Seetharaman
2008-02-09 12:45           ` Matthew Wilcox
2008-02-11 18:27             ` Chandra Seetharaman
2008-02-11 19:18               ` Matthew Wilcox
2008-02-28  1:03                 ` Chandra Seetharaman
2008-02-05 20:04         ` Mike Christie
2008-02-05 21:56           ` Mike Anderson
2008-02-06  0:46             ` Chandra Seetharaman
2008-02-07 10:08             ` no INQUIRY from userspace please (was Re: [PATCH 7/9] scsi_dh: Add support for SDEV_PASSIVE) Stefan Richter
2008-02-07 15:01               ` James Bottomley
2008-02-07 17:05                 ` no INQUIRY from userspace please Stefan Richter
2008-02-07 17:13                   ` Stefan Richter
2008-02-19 20:53                     ` Douglas Gilbert [this message]
2008-03-04  9:06                       ` Hannes Reinecke
2008-02-07 20:42                 ` no INQUIRY from userspace please (was Re: [PATCH 7/9] scsi_dh: Add support for SDEV_PASSIVE) Luben Tuikov
2008-02-04 20:26     ` [PATCH 7/9] scsi_dh: Add support for SDEV_PASSIVE Mike Anderson
2008-01-24  0:32 ` [PATCH 8/9] scsi_dh: add lsi rdac device handler Chandra Seetharaman
2008-01-24  0:32 ` [PATCH 9/9] scsi_dh: add scsi device handler to dm Chandra Seetharaman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47BB41D2.2070209@torque.net \
    --to=dougg@torque.net \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=andmike@linux.vnet.ibm.com \
    --cc=dm-devel@redhat.com \
    --cc=jens.axboe@oracle.com \
    --cc=linux-hotplug@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=michaelc@cs.wisc.edu \
    --cc=sekharan@us.ibm.com \
    --cc=stefanr@s5r6.in-berlin.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).