On Fri, Oct 03, 2003 at 10:05:52AM -0500, James Bottomley wrote:
> Well, the patch isn't quite correct because if it's not going to probe
> the cache it should set up a write through cache (or disabled cache) as
> the default.
Alan's original patch is included in my patch.
> Patrick's patch
>
>
There haven't been any replies to my suggestion from a week ago
http://marc.theaimsgroup.com/?l=linux-scsi&m=106462295800726&w=2
for a way to resolve the mode-sense page 8 problem. One way or another, I
wish somebody would do _something_ about this, particularly before
2.6.0-final comes out.
On Fri, 2003-10-03 at 09:18, Alan Stern wrote:
> There haven't been any replies to my suggestion from a week ago
>
> http://marc.theaimsgroup.com/?l=linux-scsi&m=106462295800726&w=2
>
> for a way to resolve the mode-sense page 8 problem. One way or another, I
> wish somebody would do _something
On Wed, 24 Sep 2003, Linus Torvalds wrote:
> Ok. I committed my version as "better than what is there now", but clearly
> it's not good enough.
>
> So we should really add code to sd_read_cache_type() to default to
> write-through for USB devices. The question is, what kind of flag do we
> want
On Wed, 24 Sep 2003, Ruud Linders wrote:
> >
> > Is this different from a plain kernel _without_ the patch?
>
> No difference.
Ok. I committed my version as "better than what is there now", but clearly
it's not good enough.
So we should really add code to sd_read_cache_type() to default to
wr
Linus Torvalds wrote:
On Tue, 23 Sep 2003, Ruud Linders wrote:
I tried the patch but it doesn't work for me using an USB-2 Memory stick
"DiskonKey" on an USB-2 port (with uhci_hcd & ehci_hcd loaded).
After a 3 minute time-out I get
"SCSI device sda: drive cache: write through"
and the device
On Tue, 2003-09-23 at 10:23, Alan Stern wrote:
> Is there any way to notify the system that you are about to unplug a
> drive? It seems to me that the best approach is to flush the cache on an
> unmount. People naturally assume that it's safe to unplug a device once
> it has been unmounted, a
From [EMAIL PROTECTED] Tue Sep 23 16:05:21 2003
> Also "conservative mode" sounds like a flag that describes some
> way of being broken.
>
> On the other hand "hot-pluggable" describes a positive asset,
> and if we can conclude from that that it is unnecessary to ask
I tried the patch but it doesn't work for me using an USB-2 Memory stick
"DiskonKey" on an USB-2 port (with uhci_hcd & ehci_hcd loaded).
After a 3 minute time-out I get
"SCSI device sda: drive cache: write through"
and the device starts working just fine.
Unloading the ehci_hcd module doesn't
On Tue, 23 Sep 2003, Ruud Linders wrote:
>
> I tried the patch but it doesn't work for me using an USB-2 Memory stick
> "DiskonKey" on an USB-2 port (with uhci_hcd & ehci_hcd loaded).
>
> After a 3 minute time-out I get
> "SCSI device sda: drive cache: write through"
> and the device starts
On Tue, 23 Sep 2003 [EMAIL PROTECTED] wrote:
>
> No, the design goal of "hot-pluggable" is that it indicates that
> the device can disappear any moment. Nothing at all about SCSI
> compliance.
You're talking past each other.
Server people think that "hot-pluggable" means "I will tell the system
On 23 Sep 2003, James Bottomley wrote:
> On Tue, 2003-09-23 at 09:37, [EMAIL PROTECTED] wrote:
>
> > Pulling out a device while it is actively reading or writing
> > will probably break something. But if a device is hot-pluggable
> > it should be OK to pull it out when it has been inactive for
>
On Tue, 2003-09-23 at 09:37, [EMAIL PROTECTED] wrote:
> No, the design goal of "hot-pluggable" is that it indicates that
> the device can disappear any moment. Nothing at all about SCSI
> compliance.
Actually, then, these are two issues...hotplug is being worked on
separately at the moment.
I tho
On Mon, 2003-09-22 at 14:56, [EMAIL PROTECTED] wrote:
> I have seen proposals around here for flags that are far too specific
> (like "do not ask for mode page 8"). If we go to that level of detail
> then we'll soon have fifty flags.
> Black lists, and flags that describe various ways of being brok
From [EMAIL PROTECTED] Mon Sep 22 21:29:06 2003
On Mon, 2003-09-22 at 13:55, [EMAIL PROTECTED] wrote:
> if (sdkp->media_present) {
> sd_read_capacity(sdkp, disk->disk_name, sreq, buffer);
> if (sdp->removable)
>
On Mon, 22 Sep 2003 [EMAIL PROTECTED] wrote:
> I have seen proposals around here for flags that are far too specific
> (like "do not ask for mode page 8"). If we go to that level of detail
> then we'll soon have fifty flags.
> Black lists, and flags that describe various ways of being broken
> are
On Mon, Sep 22, 2003 at 09:56:38PM +0200, [EMAIL PROTECTED] wrote:
> A scsi device declares its level of scsi compliance.
> Most USB storage devices are not very scsi compliant at all,
> and report 0 there.
Not exactly. The reporting of 0, 1, 2, or something random in that field
appears to be com
On 22 Sep 2003, James Bottomley wrote:
>
> I think we could try 4 bytes for this (even to avoid wide residue
> problems) and see how it goes.
How about just trusting the size (and as far as I can tell from the SCSI
specs, the size is the size _without_ the header and block descriptors),
and ca
On Mon, 2003-09-22 at 13:55, [EMAIL PROTECTED] wrote:
> if (sdkp->media_present) {
> sd_read_capacity(sdkp, disk->disk_name, sreq, buffer);
> if (sdp->removable)
> sd_read_write_protect_flag(sdkp, disk->disk_name,
>
On Mon, 22 Sep 2003, Linus Torvalds wrote:
> Yes. Additional testing (making the code just increase the size of the
> transfer until it fails) shows that a size of 63 still works, but a size
> of 64 bytes fails.
>
> Actually - with a 64-byte transfer, we appear to get the 64 bytes ok, but
> th
On Mon, 22 Sep 2003, Christoph Hellwig wrote:
> If we want drivers to mess with blist flags that's the more general
> solution, yes. But the blist flags really are a target thing and
> I'd prefer to keep host drivers a bit away from this. Of course
> this doesn't really work for the usb case whe
> Basically, Andries Brouwer's strategy of making sd.c more conservative has
> been a very successful one in the past. Why not continue on that?
% I would be interested in hearing what Andries has to say. ...
% The variety of ways in which these things fail is truly amazing.
Yes.
We have just se
On Llu, 2003-09-22 at 17:09, Linus Torvalds wrote:
> - page len=1538 (pretty obviously crap)
> - header len=8 (correct)
> - block descriptor len=0 (correct)
1538 smells like they forgot to clear the top byte
---
This sf.net email is sponsor
On Mon, 22 Sep 2003, David Brownell wrote:
> > Again, this case worked fine with the sd.c changes, so it does seem to be
> > all related to "big" transfers out of the mode page.
>
> Or at any rate, "big enough" to confuse the device.
Yes. Additional testing (making the code just increase the si
On Mon, 2003-09-22 at 12:41, Linus Torvalds wrote:
> Ok, thanks. In particular, it seems to be pointless to read anything past
> byte 20 - nothing past there is even defined.
>
> What's the general sense of things - for a random SCSI device with bugs
> (and they all have _some_ sort of bugs, let
Linus Torvalds wrote:
On Mon, 22 Sep 2003, David Brownell wrote:
In this case, because it's not "EHCI + USB 2.0 hub", it's still using
the OHCI companion controller. So that wasn't a new case.
Ok. Here's the broken case with an added usb-2 hub in between. It is
indeed a bit different.
Yes. In
On Mon, 22 Sep 2003, Patrick Mansfield wrote:
> On Mon, Sep 22, 2003 at 09:09:47AM -0700, Linus Torvalds wrote:
> >
> > (Btw, where are the different mode sense pages documented?)
>
> The latest SCSI 3 draft standards are online as follows, the SCSI 2 specs
> are also online at www.t10.org (.ORG
On Mon, 22 Sep 2003, David Brownell wrote:
>
> In this case, because it's not "EHCI + USB 2.0 hub", it's still using
> the OHCI companion controller. So that wasn't a new case.
Ok. Here's the broken case with an added usb-2 hub in between. It is
indeed a bit different.
Again, this case worked
On Mon, Sep 22, 2003 at 09:09:47AM -0700, Linus Torvalds wrote:
>
> (Btw, where are the different mode sense pages documented?)
>
The latest SCSI 3 draft standards are online as follows, the SCSI 2 specs
are also online at www.t10.org (.ORG!).
For block (applies to some USB mass storage) speci
On Mon, Sep 22, 2003 at 09:44:04AM -0700, Patrick Mansfield wrote:
> The current code allows us to set or clear a given bit, but not both. So
> if we set them in slave_alloc, they can't be cleared without adding
> other flags or code.
If we want drivers to mess with blist flags that's the more gen
Martin Diehl wrote:
Unfortunately I don't see an easy way to check the sourced packed size on
the wire - except using a bus analyzer of course.
Right. There are not-easy ways to do this, involving tricked out
host controller drivers usable only to debug things like this, but
I wouldn't want to g
Linus Torvalds wrote:
On Mon, 22 Sep 2003, David Brownell wrote:
Linus Torvalds wrote:
Interesting data-point: the device is a happy EHCI camper, and is
totally able to read codepage 8 on EHCI.
However, if I put it behind a USB-1 hub on the EHCI port, I see the
same problems I saw with OHCI.
Can
On Mon, 22 Sep 2003, David Brownell wrote:
> > So it is somehow related to USB-1 vs USB-2. I don't understand why the
> > device would make a difference for something like mode page 8, but it
> > looks like it transfers data fine for _small_ mode page requests under
> > USB-1, and under USB-2 i
On Mon, Sep 22, 2003 at 05:37:32PM +0100, Christoph Hellwig wrote:
>
> What I meant is not adding a blist flags member at all but rather
> setting skip_ms_page_8 and skip_ms_page_3f from ->slave_alloc.
>
> But I probably missed something obvious :)
The current code allows us to set or clear a gi
On Mon, 22 Sep 2003, Linus Torvalds wrote:
>
> [ Andries added to the cc ]
>
> On Mon, 22 Sep 2003, Patrick Mansfield wrote:
> >
> > I can modify the patch for that.
>
> How about just making the sd.c layer more robust? That has worked well in
> the past, and it seems wrong to have to add mor
On Mon, Sep 22, 2003 at 11:50:47AM -0400, Alan Stern wrote:
> Interestingly, my original patch was a lot like you describe. It can be
> found in
>
> http://marc.theaimsgroup.com/?l=linux-scsi&m=106340167723122&w=2
Yupp, that's what I meant. Much less complicated :)
-
On Mon, Sep 22, 2003 at 08:49:30AM -0700, Patrick Mansfield wrote:
> On Mon, Sep 22, 2003 at 04:11:04PM +0100, Christoph Hellwig wrote:
> > On Mon, Sep 22, 2003 at 03:31:24PM +0100, Christoph Hellwig wrote:
> > > Patch looks mostly fine to me, but please all flags should be unsigned instead
> > > o
On Mon, 22 Sep 2003, David Brownell wrote:
>
> Linus Torvalds wrote:
> > Interesting data-point: the device is a happy EHCI camper, and is
> > totally able to read codepage 8 on EHCI.
> >
> > However, if I put it behind a USB-1 hub on the EHCI port, I see the
> > same problems I saw with OHCI.
>
On Mon, 22 Sep 2003, Patrick Mansfield wrote:
> On Mon, Sep 22, 2003 at 11:50:47AM -0400, Alan Stern wrote:
>
> > I don't care which version of the patch gets accepted, so long as
> > _something_ is done. Patrick, what do you think?
>
> I would rather we can modify the flags for any broken devi
Linus Torvalds wrote:
On Mon, 22 Sep 2003, Alan Stern wrote:
This problem has been cropping up with many, many USB storage devices.
Interesting data-point: the device is a happy EHCI camper, and is totally
able to read codepage 8 on EHCI.
However, if I put it behind a USB-1 hub on the EHCI p
[ Andries added to the cc ]
On Mon, 22 Sep 2003, Patrick Mansfield wrote:
>
> I can modify the patch for that.
How about just making the sd.c layer more robust? That has worked well in
the past, and it seems wrong to have to add more and more flags.
In particular, while hunting down the usb-1
On Mon, Sep 22, 2003 at 11:50:47AM -0400, Alan Stern wrote:
> Interestingly, my original patch was a lot like you describe. It can be
> found in
>
> http://marc.theaimsgroup.com/?l=linux-scsi&m=106340167723122&w=2
>
> Patrick Mansfield later beefed it up to the version you were looking at.
>
On Mon, 22 Sep 2003, Christoph Hellwig wrote:
> On Mon, Sep 22, 2003 at 03:31:24PM +0100, Christoph Hellwig wrote:
> > Patch looks mostly fine to me, but please all flags should be unsigned instead
> > of signed and scsi_devinfo.h needs some inclusion guards.
>
> Actually I think it could be made
On Mon, Sep 22, 2003 at 04:11:04PM +0100, Christoph Hellwig wrote:
> On Mon, Sep 22, 2003 at 03:31:24PM +0100, Christoph Hellwig wrote:
> > Patch looks mostly fine to me, but please all flags should be unsigned instead
> > of signed and scsi_devinfo.h needs some inclusion guards.
>
> Actually I th
Linus Torvalds wrote:
I'll try to change that max size thing (maybe it really always wants to
transfer just the header, or then the full page?), but regardless it looks
like OHCI is a bit fragile.
Usually this sort of stuff is the device being fragile. OHCI can
only report that the USB protocol
On Mon, 22 Sep 2003, Alan Stern wrote:
>
> This problem has been cropping up with many, many USB storage devices.
Interesting data-point: the device is a happy EHCI camper, and is totally
able to read codepage 8 on EHCI.
However, if I put it behind a USB-1 hub on the EHCI port, I see the same
On Mon, Sep 22, 2003 at 03:31:24PM +0100, Christoph Hellwig wrote:
> Patch looks mostly fine to me, but please all flags should be unsigned instead
> of signed and scsi_devinfo.h needs some inclusion guards.
Actually I think it could be made much simpler by killing the per-template
bflags and just
This problem has been cropping up with many, many USB storage devices.
They just don't handle MODE-SENSE page 8 correctly. Some devices are okay
with a 128-byte transfer and others aren't. Some are okay with a 64-byte
transfer and others aren't. Some are okay transferring the actual size of
th
On Mon, Sep 22, 2003 at 10:25:28AM -0400, Alan Stern wrote:
> http://marc.theaimsgroup.com/?l=linux-scsi&m=106366112221507&w=2
>
> At the moment, this MODE-SENSE page 8 is probably the most severe
> outstanding problem with the usb-storage driver. I'm all in favor of the
> patch being adopted (
On Mon, 22 Sep 2003, Matthew Dharm wrote:
>
> You say this worked with UHCI 'some time ago'? Perhaps that was before all
> this mode page 8 stuff got settled?
Quite possible. But it definitely works with EHCI today, so it's still a
HC issue..
Linus
-
On Sun, Sep 21, 2003 at 09:57:06PM -0700, Linus Torvalds wrote:
>
> On Sun, 21 Sep 2003, Linus Torvalds wrote:
> > >
> > > Odd... why do we ask for the first 8 bytes of page 8? The header alone is
> > > 8 bytes anyway, the response looks good.
> >
> > It tries to read the cache type. It tri
On Sun, 21 Sep 2003, Linus Torvalds wrote:
> >
> > Odd... why do we ask for the first 8 bytes of page 8? The header alone is
> > 8 bytes anyway, the response looks good.
>
> It tries to read the cache type. It tries to read the header first, in
> order to figure out how much of page 8 it c
On Sun, 21 Sep 2003, Matthew Dharm wrote:
>
> > usb-storage: queuecommand called
> > usb-storage: *** thread awakened.
> > usb-storage: Command READ_CAPACITY (10 bytes)
> >
> > SCSI device sda: 2000880 512-byte hdwr sectors (1024 MB)
>
> Normal READ_CAPACITY -- is that size correct?
Yes. I've
On Sun, Sep 21, 2003 at 06:41:43PM -0700, Linus Torvalds wrote:
> Ideas? Anything that stands out except for the "babble" thing?
So, here is what I see in the log...
> hub 2-0:0: new USB device on port 1, assigned address 2
> usb-storage: USB Mass Storage device detected
> usb-storage: act_altset
On Sun, Sep 21, 2003 at 08:00:07PM -0700, David Brownell wrote:
> Matthew Dharm wrote:
> > There's more to analyize, but on first inspection that babble looks bad.
> >
> > We submitted a single URB with a 128 byte buffer. We received 64 bytes. I
> > don't think a babble is actually possible here
Matthew Dharm wrote:
There's more to analyize, but on first inspection that babble looks bad.
We submitted a single URB with a 128 byte buffer. We received 64 bytes. I
don't think a babble is actually possible here
It's possible if the last packet received was bigger than
the endpoint's maxp
On Sun, 21 Sep 2003, Matthew Dharm wrote:
>
> There's more to analyize, but on first inspection that babble looks bad.
>
> We submitted a single URB with a 128 byte buffer. We received 64 bytes. I
> don't think a babble is actually possible here
>
> So something has gone bad at a lower lev
There's more to analyize, but on first inspection that babble looks bad.
We submitted a single URB with a 128 byte buffer. We received 64 bytes. I
don't think a babble is actually possible here
So something has gone bad at a lower level
Matt
On Sun, Sep 21, 2003 at 06:41:43PM -0700, L
58 matches
Mail list logo
