> That flag already exists. SG_FLAG_LUN_INHIBIT -- see
> sg.torque.net for
> details.
>
> Matt
Thanks, I somehow missed that. It should solve my problem.
Tim
---
SF.Net email is sponsored by:
Tame your development challenges with Apache's
On Wed, Sep 14, 2005 at 01:18:52PM -0700, Timothy Thelin wrote:
>
> > It ought to be possible to add a flag that would prevent the
> > SCSI midlayer
> > from overlaying the LUN bits on top of cdb[1]. Then we could
> > still set
> > the revision number to 2 and you would be happy.
>
> Sounds
On Wed, Sep 14, 2005 at 12:19:39PM -0700, Timothy Thelin wrote:
>
> > > Why would a usb-storage device ever report itself as scsi0
> > if it actually
> > > supports scsi3? Is it because the USB/ATA bridge spec
> > doesn't support asking
> > > the device it self, so the usb-subsystem just makes
> It ought to be possible to add a flag that would prevent the
> SCSI midlayer
> from overlaying the LUN bits on top of cdb[1]. Then we could
> still set
> the revision number to 2 and you would be happy.
Sounds plausable, but i'm not an expert on the Linux scsi stack
to know where the flag
On Wed, 14 Sep 2005, Timothy Thelin wrote:
> > SCSI 3 triggers new and exciting behavior from SCSI core.
Note that usb-storage even sets the version number for SCSI-3 devices back
to 2. That's because a lot of them report SCSI-3 and then crash when
asked to carry out a REPORT LUNS command.
It
> > Why would a usb-storage device ever report itself as scsi0
> if it actually
> > supports scsi3? Is it because the USB/ATA bridge spec
> doesn't support asking
> > the device it self, so the usb-subsystem just makes an (un?
> ;)-educated
> > guess? Or is it because it is possible, but the
> On Wed, Sep 14, 2005 at 10:45:37AM -0700, Timothy Thelin wrote:
> >
> > I was curious about the reasoning behind this decision and
> how to fix an
> > issue that came up because of it.
>
> The reasoning goes something like this: There are lots of
> devices which
> report 0, but need the SCS
> On Wednesday 14 September 2005 19:45, Timothy Thelin wrote:
> > I was curious about the reasoning behind this decision and
> how to fix an
> > issue that came up because of it.
> > ...
> > (1) Is easy to do, but is it going to cause other issues?
> I'd imagine any
> > *usb storage* device tha
On Wed, Sep 14, 2005 at 08:29:19PM +0200, Christian Iversen wrote:
> On Wednesday 14 September 2005 19:45, Timothy Thelin wrote:
> > I was curious about the reasoning behind this decision and how to fix an
> > issue that came up because of it.
> > ...
> > (1) Is easy to do, but is it going to cause
On Wed, Sep 14, 2005 at 10:45:37AM -0700, Timothy Thelin wrote:
>
> I was curious about the reasoning behind this decision and how to fix an
> issue that came up because of it.
The reasoning goes something like this: There are lots of devices which
report 0, but need the SCSI-II 10-byte commands
On Wednesday 14 September 2005 19:45, Timothy Thelin wrote:
> I was curious about the reasoning behind this decision and how to fix an
> issue that came up because of it.
> ...
> (1) Is easy to do, but is it going to cause other issues? I'd imagine any
> *usb storage* device that reports scsi0 rea
I was curious about the reasoning behind this decision and how to fix an
issue that came up because of it.
Here is the issue found:
1) Some USB storage peripherals identify themselves as following scsi spec 0
(i.e. "we don't follow a spec, we just kinda magically work with some of the
commands fo
12 matches
Mail list logo
