On Thu, 7 Feb 2002, Matthew Dharm wrote:
> Is the sym driver the only problematic one?
Why do you want the driver to be problematic ?
The sym driver will apply what it sees.
If a SCSI 4 device will appear to be only featured as a SCSI 1 device, the
driver will handle it as a SCSI 1 device. :-
On Thu, 7 Feb 2002, Matthew Dharm wrote:
> On Wed, Feb 06, 2002 at 11:39:00PM +0100, Gérard Roudier wrote:
> > On Thu, 7 Feb 2002, Martin Wilck wrote:
> > > Just for curiosity about SCSI-4: If a SCSI-4 device answers an INQUIRY
> > > (even with only 36 bytes), won't it identify itself as a SCSI
Is the sym driver the only problematic one?
Matt
On Thu, Feb 07, 2002 at 12:29:04AM +0100, Gérard Roudier wrote:
>
>
> On Thu, 7 Feb 2002, Matthew Dharm wrote:
>
> > If you need 56 bytes for SCSI-4, then why not get 36 bytes, see if the
> > device is SCSI 4, then ask for the 56 bytes if it is
On Thu, 7 Feb 2002, Matthew Dharm wrote:
> If you need 56 bytes for SCSI-4, then why not get 36 bytes, see if the
> device is SCSI 4, then ask for the 56 bytes if it is.
Nobody disagreed with this proposal.
> Look, this issue is going to continue to haunt us as more and more
> "emulated SCSI"
On Thu, 7 Feb 2002, Alan Cox wrote:
> > > Possible, but not required for the initial INQUIRY
> >
> > The Linux SCSI layer performs a single INQUIRY for the device discovery
> > process. It was proposed to shorten this INQUIRY to 36 bytes.
>
> Which is fine. We do a 36 byte inquiry just like win
On Wed, 6 Feb 2002, Gérard Roudier wrote:
g >For my part, if I had a device that fails INQUIRY I would try to get
g >reimbursed and if not possible I would break it into pieces and throw it
g >far away. Software is hard to maintain. Any additional code or complexity
g >adds possible bugs for a lo
On Wed, Feb 06, 2002 at 11:39:00PM +0100, Gérard Roudier wrote:
> On Thu, 7 Feb 2002, Martin Wilck wrote:
> > Just for curiosity about SCSI-4: If a SCSI-4 device answers an INQUIRY
> > (even with only 36 bytes), won't it identify itself as a SCSI-4 device,
> > thereby showing the driver that it sh
On Wed, Feb 06, 2002 at 10:26:29PM +0100, Gérard Roudier wrote:
> On paper, performing some short INQUIRY prior to a normal INQUIRY should
> not harm. Just it will change behaviour and may confuse drivers that snoop
> the INQUIRY data. Please do it first in development kernel so that this
> will a
If you need 56 bytes for SCSI-4, then why not get 36 bytes, see if the
device is SCSI 4, then ask for the 56 bytes if it is.
Look, this issue is going to continue to haunt us as more and more
"emulated SCSI" devices and busses appear. And, no version of windows will
make an initial INQUIRY reque
> > Possible, but not required for the initial INQUIRY
>
> The Linux SCSI layer performs a single INQUIRY for the device discovery
> process. It was proposed to shorten this INQUIRY to 36 bytes.
Which is fine. We do a 36 byte inquiry just like windows. If the device
turns out to be scsi-4 we can
On Thu, 7 Feb 2002, Alan Cox wrote:
> > A SCSI device that is broken for INQUIRY is definitely broken for SCSI.
> > FYI, we need at least 56 bytes of INQUIRY data to be possible for SPC2
> > (SCSI 4).
>
> Possible, but not required for the initial INQUIRY
The Linux SCSI layer performs a single
On Thu, 7 Feb 2002, Martin Wilck wrote:
> On Wed, 6 Feb 2002, Gérard Roudier wrote:
>
> g >For my part, if I had a device that fails INQUIRY I would try to get
> g >reimbursed and if not possible I would break it into pieces and throw it
> g >far away. Software is hard to maintain. Any addition
On Wed, 6 Feb 2002, Matthew Dharm wrote:
> Martin --
>
> What you've found is an issue I'm still trying to find the best solution
> to.
>
> The Linux-SCSI people (now on the CC:) have rejected the idea of making all
> INQUIRYs 36-bytes. Apparently, there are some HBA drivers which want to
> sn
> A SCSI device that is broken for INQUIRY is definitely broken for SCSI.
> FYI, we need at least 56 bytes of INQUIRY data to be possible for SPC2
> (SCSI 4).
Possible, but not required for the initial INQUIRY
___
[EMAIL PROTECTED]
To unsubscribe, use
Alan Cox wrote:
>
> > If understand Martin's proposal right, the SCSI layer should first issue
> > a standard 36 byte INQUIRY, even if an application or high level SCSI
> > driver wants to get more data; and if byte 4 of the returned data
> > indicates that the device can provide more data, a sec
On Thu, 7 Feb 2002, Martin Wilck wrote:
>
>
> > Generally, I think that the SG driver, the mid-level and the low level
> > drivers should avoid messing with the details of a SCSI command -- they
> > should simply pass a command to the device and return the result; any
> > implicit assumptions a
On Thu, 7 Feb 2002, Alan Cox wrote:
> > > SCSI layer proper. The only problem I can see is a broken device
> > > that violates the specs by truncating the additonal length
> > > parameter to the buffer length provided. Other than that,
> >
> > I have the documentation from a scanner vendor whic
> If understand Martin's proposal right, the SCSI layer should first issue
> a standard 36 byte INQUIRY, even if an application or high level SCSI
> driver wants to get more data; and if byte 4 of the returned data
> indicates that the device can provide more data, a second INQUIRY is
> issued.
P
> Generally, I think that the SG driver, the mid-level and the low level
> drivers should avoid messing with the details of a SCSI command -- they
> should simply pass a command to the device and return the result; any
> implicit assumptions about a SCSI command may lead to unneccasry
> hassles.
Alan Cox wrote:
>
> > > SCSI layer proper. The only problem I can see is a broken device
> > > that violates the specs by truncating the additonal length
> > > parameter to the buffer length provided. Other than that,
> >
> > I have the documentation from a scanner vendor which indicates exactly
On Thu, 7 Feb 2002, abel deuring wrote:
adeuri >I have the documentation from a scanner vendor which indicates exactly
adeuri >this broken behaviour.
Your device doesn't handle small requests, mine large. That's brilliance!
However, as a workaround in usb-storage my patch _should_ do no harm.
C
> > SCSI layer proper. The only problem I can see is a broken device
> > that violates the specs by truncating the additonal length
> > parameter to the buffer length provided. Other than that,
>
> I have the documentation from a scanner vendor which indicates exactly
> this broken behaviour.
So
[EMAIL PROTECTED] wrote:
>
> Here is a patch for usb-storage that approaches the problem
> like this:
>
> - Submit a 36-byte INQUIRY.
> - Check additional length in response.
> - If the device tells us it provides more than 36 bytes,
> INQUIRY again, setting the length to the number of bytes
>
Here is a patch for usb-storage that approaches the problem
like this:
- Submit a 36-byte INQUIRY.
- Check additional length in response.
- If the device tells us it provides more than 36 bytes,
INQUIRY again, setting the length to the number of bytes
the device promises to deliver.
> Umm.. I'm talking about the SCSI probing function... it requests 255 bytes
> of then throws it away after processing the first 36. The remainder never
> gets sent to anywhere (if I'm reading the code right). It would be up to
> the scanner driver to request an INQUIRY data again...
Which it w
Umm.. I'm talking about the SCSI probing function... it requests 255 bytes
of then throws it away after processing the first 36. The remainder never
gets sent to anywhere (if I'm reading the code right). It would be up to
the scanner driver to request an INQUIRY data again...
Which it would do
> The Linux-SCSI people (now on the CC:) have rejected the idea of making all
> INQUIRYs 36-bytes. Apparently, there are some HBA drivers which want to
> snoop the INQUIRY data in the vendor-specific area for some reason.
For one the full INQ data is needed by some scanner drivers
> I'm thinkin
Martin --
What you've found is an issue I'm still trying to find the best solution
to.
The Linux-SCSI people (now on the CC:) have rejected the idea of making all
INQUIRYs 36-bytes. Apparently, there are some HBA drivers which want to
snoop the INQUIRY data in the vendor-specific area for some
28 matches
Mail list logo
