Re: request: patch for oracom mp3 stick --> usb-storage: unusual_devs.h
I'm glad this problem has been solved for good. Listening to music is such a nice thing :-) thanks everybody ! robert - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: request: patch for oracom mp3 stick --> usb-storage: unusual_devs.h
On Tue, Feb 12, 2008 at 03:51:22PM -0500, Alan Stern wrote: > On Sat, 2 Feb 2008, Matthew Dharm wrote: > > > On Sat, Feb 02, 2008 at 05:12:29PM -0500, Alan Stern wrote: > > > IMO this indicates we shouldn't issue any clear-halts at all unless the > > > device actually needs it. In general it's not a good idea to do a > > > clear-halt for an endpoint that isn't actually halted; devices are > > > prone to misinterpret the request. > > > > > > And since the only device we know of that does need the clear-halts is > > > long obsolete, the simplest strategy is just to leave them out. That > > > ancient ZIP-100 drive can be accomodated by adding a US_FL_SINGLE_LUN > > > flag for it, since the Get-Max-LUN is never issued when that flag is > > > set. > > > > My only issue is that we're effectively dropping support for a device that > > currently works. An obsolete device, I admit, but a device we currently > > support nevertheless. > > > > I suppose that really is the best option, tho. We just need to be on the > > lookout for reports of very old ZIP-100 drives breaking. > > I found the original thread where we diagnosed the problem with the old > ZIP-100. This message is near the end of the thread, but it includes > the descriptor values for the device: > > https://lists.one-eyed-alien.net/pipermail/usb-storage/2004-March/51.html > > Interestingly, the bcdUSB value is 0x0100 -- USB 1.0 rather than 1.1. > Maybe we should automatically set the SINGLE_LUN flag for any device > with that value? Or would we be better off with an explicit > unusual_devs entry for this ZIP-100 model? We should have as narrow a scope of influence as possible. A single entry would be best. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Why am I talking to a toilet brush? -- CEO User Friendly, 4/30/1998 pgpLQIsveifdm.pgp Description: PGP signature
Re: request: patch for oracom mp3 stick --> usb-storage: unusual_devs.h
On Sat, 2 Feb 2008, Matthew Dharm wrote: > On Sat, Feb 02, 2008 at 05:12:29PM -0500, Alan Stern wrote: > > IMO this indicates we shouldn't issue any clear-halts at all unless the > > device actually needs it. In general it's not a good idea to do a > > clear-halt for an endpoint that isn't actually halted; devices are > > prone to misinterpret the request. > > > > And since the only device we know of that does need the clear-halts is > > long obsolete, the simplest strategy is just to leave them out. That > > ancient ZIP-100 drive can be accomodated by adding a US_FL_SINGLE_LUN > > flag for it, since the Get-Max-LUN is never issued when that flag is > > set. > > My only issue is that we're effectively dropping support for a device that > currently works. An obsolete device, I admit, but a device we currently > support nevertheless. > > I suppose that really is the best option, tho. We just need to be on the > lookout for reports of very old ZIP-100 drives breaking. I found the original thread where we diagnosed the problem with the old ZIP-100. This message is near the end of the thread, but it includes the descriptor values for the device: https://lists.one-eyed-alien.net/pipermail/usb-storage/2004-March/51.html Interestingly, the bcdUSB value is 0x0100 -- USB 1.0 rather than 1.1. Maybe we should automatically set the SINGLE_LUN flag for any device with that value? Or would we be better off with an explicit unusual_devs entry for this ZIP-100 model? Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: request: patch for oracom mp3 stick --> usb-storage: unusual_devs.h
On Sat, 2 Feb 2008, Matthew Dharm wrote: > On Sat, Feb 02, 2008 at 05:12:29PM -0500, Alan Stern wrote: > > IMO this indicates we shouldn't issue any clear-halts at all unless the > > device actually needs it. In general it's not a good idea to do a > > clear-halt for an endpoint that isn't actually halted; devices are > > prone to misinterpret the request. > > > > And since the only device we know of that does need the clear-halts is > > long obsolete, the simplest strategy is just to leave them out. That > > ancient ZIP-100 drive can be accomodated by adding a US_FL_SINGLE_LUN > > flag for it, since the Get-Max-LUN is never issued when that flag is > > set. > > My only issue is that we're effectively dropping support for a device that > currently works. An obsolete device, I admit, but a device we currently > support nevertheless. > > I suppose that really is the best option, tho. We just need to be on the > lookout for reports of very old ZIP-100 drives breaking. If we add an unusual_devs entry for the old ZIP-100 with US_FL_SINGLE_LUN then it should continue to work okay. But we can't do that without the proper ID values. Maybe they're buried somewhere in the mailing list archives, or maybe Pat Lavarre can provide them. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: request: patch for oracom mp3 stick --> usb-storage: unusual_devs.h
On Sat, Feb 02, 2008 at 05:12:29PM -0500, Alan Stern wrote: > IMO this indicates we shouldn't issue any clear-halts at all unless the > device actually needs it. In general it's not a good idea to do a > clear-halt for an endpoint that isn't actually halted; devices are > prone to misinterpret the request. > > And since the only device we know of that does need the clear-halts is > long obsolete, the simplest strategy is just to leave them out. That > ancient ZIP-100 drive can be accomodated by adding a US_FL_SINGLE_LUN > flag for it, since the Get-Max-LUN is never issued when that flag is > set. My only issue is that we're effectively dropping support for a device that currently works. An obsolete device, I admit, but a device we currently support nevertheless. I suppose that really is the best option, tho. We just need to be on the lookout for reports of very old ZIP-100 drives breaking. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Somebody call an exorcist! -- Dust Puppy User Friendly, 5/16/1998 pgps8Umt5SEwf.pgp Description: PGP signature
Re: request: patch for oracom mp3 stick --> usb-storage: unusual_devs.h
On Sat, 2 Feb 2008, Robert Spitzenpfeil wrote:
> if I understand right you wanted me to make my system mimic this:
>
> Loop 3 times {
> Get-Max-LUN => STALL
> clear-halt(ep0)
> }
>
> I don't know how to hack usb-storage to run this very loop (lack of
> knowledge / understanding of the inner workings).
> Usually I just have to deal with perl/bash and not c/c++.
>
> the closest thing I could manage was to activate these subroutines
> within transport.c:
>
> if (result == -EPIPE) {
> /*
> * usb_stor_clear_halt(us, us->recv_bulk_pipe);
> * usb_stor_clear_halt(us, us->send_bulk_pipe);
> */
>
> /* sb_stor_clear_halt(us, us->send_ctrl_pipe); */
>
> usb_stor_clear_halt(us, us->recv_bulk_pipe); /* A */
> usb_stor_clear_halt(us, us->send_bulk_pipe); /* B */
> usb_stor_clear_halt(us, us->send_ctrl_pipe); /* C */
> }
>
>
> combinations of ABC: (order not changed, no multiple runs, A = A was
> executed, a = A was not executed):
>
> * abc : OK
> * Abc : FAILS
> * aBc : OK
> * abC : OK
> * aBC : OK
> * ABc : FAILS
> * AbC : FAILS
> * ABC : FAILS
>
> so for this order running A is the killer.
That's impressively thorough testing!
IMO this indicates we shouldn't issue any clear-halts at all unless the
device actually needs it. In general it's not a good idea to do a
clear-halt for an endpoint that isn't actually halted; devices are
prone to misinterpret the request.
And since the only device we know of that does need the clear-halts is
long obsolete, the simplest strategy is just to leave them out. That
ancient ZIP-100 drive can be accomodated by adding a US_FL_SINGLE_LUN
flag for it, since the Get-Max-LUN is never issued when that flag is
set.
Alan Stern
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: request: patch for oracom mp3 stick --> usb-storage: unusual_devs.h
Matthew Dharm wrote:
On Sat, Feb 02, 2008 at 12:22:14AM +0100, Robert Spitzenpfeil wrote:
Alan Stern wrote:
On Fri, 1 Feb 2008, Robert Spitzenpfeil wrote:
Alan Stern wrote:
So Robert, this suggests an experiment for you to try. First remove
the US_FL_FIX_INQUIRY flag in your unusual_devs entry, of course. But
then edit transport.c, and in usb_stor_Bulk_max_lun() replace the two
lines saying
usb_stor_clear_halt(us, us->recv_bulk_pipe);
usb_stor_clear_halt(us, us->send_bulk_pipe);
with a single line saying
usb_stor_clear_halt(us, us->send_ctrl_pipe);
This should duplicate Windows' actions, except for the two retries.
Maybe then the device will work...
IT WORKS.
And just out of curiousity, what happens if you remove the
usb_stor_clear_halt() entirely?
still works :-)
What happens if you do all three usb_stor_clear_halt() calls?
Matt
if I understand right you wanted me to make my system mimic this:
Loop 3 times {
Get-Max-LUN => STALL
clear-halt(ep0)
}
I don't know how to hack usb-storage to run this very loop (lack of
knowledge / understanding of the inner workings).
Usually I just have to deal with perl/bash and not c/c++.
the closest thing I could manage was to activate these subroutines
within transport.c:
if (result == -EPIPE) {
/*
* usb_stor_clear_halt(us, us->recv_bulk_pipe);
* usb_stor_clear_halt(us, us->send_bulk_pipe);
*/
/* sb_stor_clear_halt(us, us->send_ctrl_pipe); */
usb_stor_clear_halt(us, us->recv_bulk_pipe); /* A */
usb_stor_clear_halt(us, us->send_bulk_pipe); /* B */
usb_stor_clear_halt(us, us->send_ctrl_pipe); /* C */
}
combinations of ABC: (order not changed, no multiple runs, A = A was
executed, a = A was not executed):
* abc : OK
* Abc : FAILS
* aBc : OK
* abC : OK
* aBC : OK
* ABc : FAILS
* AbC : FAILS
* ABC : FAILS
so for this order running A is the killer.
robert
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: request: patch for oracom mp3 stick --> usb-storage: unusual_devs.h
On Sat, Feb 02, 2008 at 12:22:14AM +0100, Robert Spitzenpfeil wrote: > Alan Stern wrote: > >On Fri, 1 Feb 2008, Robert Spitzenpfeil wrote: > > > >>Alan Stern wrote: > >>>So Robert, this suggests an experiment for you to try. First remove > >>>the US_FL_FIX_INQUIRY flag in your unusual_devs entry, of course. But > >>>then edit transport.c, and in usb_stor_Bulk_max_lun() replace the two > >>>lines saying > >>> > >>> usb_stor_clear_halt(us, us->recv_bulk_pipe); > >>> usb_stor_clear_halt(us, us->send_bulk_pipe); > >>> > >>>with a single line saying > >>> > >>> usb_stor_clear_halt(us, us->send_ctrl_pipe); > >>> > >>>This should duplicate Windows' actions, except for the two retries. > >>>Maybe then the device will work... > >>> > >>> > >>> > >>IT WORKS. > >> > > > >And just out of curiousity, what happens if you remove the > >usb_stor_clear_halt() entirely? > > > > > still works :-) What happens if you do all three usb_stor_clear_halt() calls? Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Now payink attention, please. This is mouse. Click-click. Easy to use, da? Now you try... -- Pitr to Miranda User Friendly, 10/11/1998 pgpFxgF8sWKoH.pgp Description: PGP signature
Re: request: patch for oracom mp3 stick --> usb-storage: unusual_devs.h
Alan Stern wrote: On Fri, 1 Feb 2008, Robert Spitzenpfeil wrote: Alan Stern wrote: So Robert, this suggests an experiment for you to try. First remove the US_FL_FIX_INQUIRY flag in your unusual_devs entry, of course. But then edit transport.c, and in usb_stor_Bulk_max_lun() replace the two lines saying usb_stor_clear_halt(us, us->recv_bulk_pipe); usb_stor_clear_halt(us, us->send_bulk_pipe); with a single line saying usb_stor_clear_halt(us, us->send_ctrl_pipe); This should duplicate Windows' actions, except for the two retries. Maybe then the device will work... IT WORKS. And just out of curiousity, what happens if you remove the usb_stor_clear_halt() entirely? still works :-) btw. thanks a lot. robert l - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: request: patch for oracom mp3 stick --> usb-storage: unusual_devs.h
On Fri, 1 Feb 2008, Oliver Neukum wrote: > Am Freitag, 1. Februar 2008 20:16:05 schrieb Alan Stern: > > I'm speculating that the device doesn't need the clear-halt for ep0 at > > all; Robert should be able to check whether that's true or not. It > > seems clear that the clear-halts for the bulk endpoints are causing > > problems. > > What's clear about that? The available traces would also be compatible > with the device needing a clear halt on ep0. We should investigate whether > the device can cope with clearing halts on all endpoints before we talk > additional quirks. The key fact was that after receiving the clear-halt requests for the bulk endpoints, the device sent back a garbage 13-byte packet in response to an INQUIRY command. But I admit, it's only intuition saying that the clear-halts were the underlying cause of the problem. We're all waiting to hear what Robert finds. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: request: patch for oracom mp3 stick --> usb-storage: unusual_devs.h
On Fri, Feb 01, 2008 at 08:40:41PM +0100, Oliver Neukum wrote: > Am Freitag, 1. Februar 2008 20:16:05 schrieb Alan Stern: > > I'm speculating that the device doesn't need the clear-halt for ep0 at > > all; Robert should be able to check whether that's true or not. It > > seems clear that the clear-halts for the bulk endpoints are causing > > problems. > > What's clear about that? The available traces would also be compatible > with the device needing a clear halt on ep0. We should investigate whether > the device can cope with clearing halts on all endpoints before we talk > additional quirks. This is my position exactly. I speculate that the windows-issued clear-halt on ep0 is required by the device. There's no way to know until Robert tests with no clear-halt at all. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Hi. I have my back hairs caught in my computer fan. -- Customer User Friendly, 8/20/1998 pgpN7i2Sz2Xu6.pgp Description: PGP signature
Re: request: patch for oracom mp3 stick --> usb-storage: unusual_devs.h
Am Freitag, 1. Februar 2008 20:16:05 schrieb Alan Stern: > I'm speculating that the device doesn't need the clear-halt for ep0 at > all; Robert should be able to check whether that's true or not. It > seems clear that the clear-halts for the bulk endpoints are causing > problems. What's clear about that? The available traces would also be compatible with the device needing a clear halt on ep0. We should investigate whether the device can cope with clearing halts on all endpoints before we talk additional quirks. Regards Oliver - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: request: patch for oracom mp3 stick --> usb-storage: unusual_devs.h
On Fri, 1 Feb 2008, Matthew Dharm wrote:
> > > Do we really need another quirk? If the 'popular' OS does it, it's likely
> > > safe to do for all deveices when GetMaxLUN fails...
> >
> > You missed the point. Windows does _not_ do it -- i.e., does not clear
> > a halt on either bulk endpoint. Linux does so only because somebody
> > (either Pete Zaitcev or Pat Lavarre, I can't remember which) pointed
> > out that the ZIP-100 drive needs it.
> >
> > The clear-halt for endpoint 0 probably isn't needed by anything; I
> > don't know why Windows does it.
>
> Anything except this device, that is. I thought we had traces of Windows
> issuing a clear-halt to endpoint 0 after a failed GetMaxLUN. Or did I read
> the thread wrong?
Here's the precise situation in a nutshell. Robert has provided traces
for his mp3 player showing the following:
Linux (uncustomized):
Get-Max-LUN => STALL
clear-halt(bulk-in ep)
clear-halt(bulk-out ep)
INQUIRY => failure
Windows:Loop 3 times {
Get-Max-LUN => STALL
clear-halt(ep0)
}
INQUIRY => success
Linux (customized usb-storage -- no trace posted, just the final result):
Get-Max-LUN => STALL
clear-halt(ep0)
INQUIRY => success
I'm speculating that the device doesn't need the clear-halt for ep0 at
all; Robert should be able to check whether that's true or not. It
seems clear that the clear-halts for the bulk endpoints are causing
problems.
As Pete mentioned, the only devices which do seem to need the
clear-halts on the bulk endpoints are some really old ZIP-100 drives
with outdated firmware. As I see it, we could either stop supporting
them altogether or else add a quirk indicating that the bulk endpoints
need to be cleared following a Get-Max-LUN STALL
(US_FL_CLEAR_BULK_EPS_AFTER_GET_MAX_LUN_STALL ?!).
Alan Stern
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: request: patch for oracom mp3 stick --> usb-storage: unusual_devs.h
On Fri, 1 Feb 2008 11:59:56 -0500 (EST), Alan Stern <[EMAIL PROTECTED]> wrote: > You missed the point. Windows does _not_ do it -- i.e., does not clear > a halt on either bulk endpoint. Linux does so only because somebody > (either Pete Zaitcev or Pat Lavarre, I can't remember which) pointed > out that the ZIP-100 drive needs it. I have a ZIP-100 which does not need it. Pat said the firmware was changed, so it was only the case for really old ones. BTW, ub does not touch bulk pipes when or after doing GetMaxLUN, and it seems to work, for what it's worth: the installed base is quite small. My ZIP drive stalls ep0 and then works. -- Pete - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: request: patch for oracom mp3 stick --> usb-storage: unusual_devs.h
On Fri, Feb 01, 2008 at 11:59:56AM -0500, Alan Stern wrote: > On Fri, 1 Feb 2008, Matthew Dharm wrote: > > > On Fri, Feb 01, 2008 at 10:17:24AM -0500, Alan Stern wrote: > > > On Thu, 31 Jan 2008, David Brownell wrote: > > > > > > > On Thursday 31 January 2008, Alan Stern wrote: > > > > > The interesting difference lay in what Windows did when the > > > > > Get-Max-LUN > > > > > stalled. It sent a Clear-Halt request to endpoint 0! > > > > > > > > Yes that *is* strange! Considering that ep0 wasn't stalling ... > > > > > > No, ep0 did stall (at least, that's the way it looks from the SnoopyPro > > > trace and that's what happened under Linux). This was in response to > > > the Bulk-only-transport class-specific Get-Max-LUN request. Devices > > > are permitted not to support that request if they have only one LUN. > > > > > > Right now usb-storage responds to this stall by clearing the halt > > > feature from the bulk-in and bulk-out endpoints, not because the spec > > > says to do so but because one ancient device (a ZIP-100) requires it. > > > Now it looks as though we've found a device which can't handle it. > > > Time for another quirk? > > > > Do we really need another quirk? If the 'popular' OS does it, it's likely > > safe to do for all deveices when GetMaxLUN fails... > > You missed the point. Windows does _not_ do it -- i.e., does not clear > a halt on either bulk endpoint. Linux does so only because somebody > (either Pete Zaitcev or Pat Lavarre, I can't remember which) pointed > out that the ZIP-100 drive needs it. > > The clear-halt for endpoint 0 probably isn't needed by anything; I > don't know why Windows does it. Anything except this device, that is. I thought we had traces of Windows issuing a clear-halt to endpoint 0 after a failed GetMaxLUN. Or did I read the thread wrong? Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Somebody call an exorcist! -- Dust Puppy User Friendly, 5/16/1998 pgpakLrLf2mi6.pgp Description: PGP signature
Re: request: patch for oracom mp3 stick --> usb-storage: unusual_devs.h
On Fri, 1 Feb 2008, Matthew Dharm wrote: > On Fri, Feb 01, 2008 at 10:17:24AM -0500, Alan Stern wrote: > > On Thu, 31 Jan 2008, David Brownell wrote: > > > > > On Thursday 31 January 2008, Alan Stern wrote: > > > > The interesting difference lay in what Windows did when the Get-Max-LUN > > > > stalled. It sent a Clear-Halt request to endpoint 0! > > > > > > Yes that *is* strange! Considering that ep0 wasn't stalling ... > > > > No, ep0 did stall (at least, that's the way it looks from the SnoopyPro > > trace and that's what happened under Linux). This was in response to > > the Bulk-only-transport class-specific Get-Max-LUN request. Devices > > are permitted not to support that request if they have only one LUN. > > > > Right now usb-storage responds to this stall by clearing the halt > > feature from the bulk-in and bulk-out endpoints, not because the spec > > says to do so but because one ancient device (a ZIP-100) requires it. > > Now it looks as though we've found a device which can't handle it. > > Time for another quirk? > > Do we really need another quirk? If the 'popular' OS does it, it's likely > safe to do for all deveices when GetMaxLUN fails... You missed the point. Windows does _not_ do it -- i.e., does not clear a halt on either bulk endpoint. Linux does so only because somebody (either Pete Zaitcev or Pat Lavarre, I can't remember which) pointed out that the ZIP-100 drive needs it. The clear-halt for endpoint 0 probably isn't needed by anything; I don't know why Windows does it. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: request: patch for oracom mp3 stick --> usb-storage: unusual_devs.h
On Fri, 1 Feb 2008, Xiaofan Chen wrote: > On Feb 1, 2008 11:17 PM, Alan Stern <[EMAIL PROTECTED]> wrote: > > On Thu, 31 Jan 2008, David Brownell wrote: > > > > > On Thursday 31 January 2008, Alan Stern wrote: > > > > The interesting difference lay in what Windows did when the Get-Max-LUN > > > > stalled. It sent a Clear-Halt request to endpoint 0! > > > > > > Yes that *is* strange! Considering that ep0 wasn't stalling ... > > > > No, ep0 did stall (at least, that's the way it looks from the SnoopyPro > > trace and that's what happened under Linux). This was in response to > > the Bulk-only-transport class-specific Get-Max-LUN request. Devices > > are permitted not to support that request if they have only one LUN. > > So I will think this is a "protocol stall" for endpoint 0. Am I right? Yes. > > Right now usb-storage responds to this stall by clearing the halt > > feature from the bulk-in and bulk-out endpoints, not because the spec > > says to do so but because one ancient device (a ZIP-100) requires it. > > Now it looks as though we've found a device which can't handle it. > > Time for another quirk? > > If my previous assumption is correct, I will think the Windows driver behavior > can be said to be a bit strange since normally you do not need to clear halt > for protocol stall. I will think the Linux USB behavior is even stranger. > I know quite some USB devices which do not handle clear halt feature > request nicely. Linux does it only because that one device needs it. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: request: patch for oracom mp3 stick --> usb-storage: unusual_devs.h
On Fri, Feb 01, 2008 at 10:17:24AM -0500, Alan Stern wrote: > On Thu, 31 Jan 2008, David Brownell wrote: > > > On Thursday 31 January 2008, Alan Stern wrote: > > > The interesting difference lay in what Windows did when the Get-Max-LUN > > > stalled. It sent a Clear-Halt request to endpoint 0! > > > > Yes that *is* strange! Considering that ep0 wasn't stalling ... > > No, ep0 did stall (at least, that's the way it looks from the SnoopyPro > trace and that's what happened under Linux). This was in response to > the Bulk-only-transport class-specific Get-Max-LUN request. Devices > are permitted not to support that request if they have only one LUN. > > Right now usb-storage responds to this stall by clearing the halt > feature from the bulk-in and bulk-out endpoints, not because the spec > says to do so but because one ancient device (a ZIP-100) requires it. > Now it looks as though we've found a device which can't handle it. > Time for another quirk? Do we really need another quirk? If the 'popular' OS does it, it's likely safe to do for all deveices when GetMaxLUN fails... Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver C: Like the Furby? DP: He gives me the creeps. Think the SPCA will take him? -- Cobb and Dust Puppy User Friendly, 1/2/1999 pgp418LiNMzoV.pgp Description: PGP signature
Re: request: patch for oracom mp3 stick --> usb-storage: unusual_devs.h
On Feb 1, 2008 11:17 PM, Alan Stern <[EMAIL PROTECTED]> wrote: > On Thu, 31 Jan 2008, David Brownell wrote: > > > On Thursday 31 January 2008, Alan Stern wrote: > > > The interesting difference lay in what Windows did when the Get-Max-LUN > > > stalled. It sent a Clear-Halt request to endpoint 0! > > > > Yes that *is* strange! Considering that ep0 wasn't stalling ... > > No, ep0 did stall (at least, that's the way it looks from the SnoopyPro > trace and that's what happened under Linux). This was in response to > the Bulk-only-transport class-specific Get-Max-LUN request. Devices > are permitted not to support that request if they have only one LUN. So I will think this is a "protocol stall" for endpoint 0. Am I right? > Right now usb-storage responds to this stall by clearing the halt > feature from the bulk-in and bulk-out endpoints, not because the spec > says to do so but because one ancient device (a ZIP-100) requires it. > Now it looks as though we've found a device which can't handle it. > Time for another quirk? If my previous assumption is correct, I will think the Windows driver behavior can be said to be a bit strange since normally you do not need to clear halt for protocol stall. I will think the Linux USB behavior is even stranger. I know quite some USB devices which do not handle clear halt feature request nicely. Sorry if my understanding is wrong. I am always a bit confused by this halt/stall thingy. Last time I've a long discussion with the FreeBSD usb developers and I am not so convinced that they are dealing with it correctly (but the Microchip firmware is the main culprit). http://forum.microchip.com/tm.aspx?m=243771 Xiaofan - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: request: patch for oracom mp3 stick --> usb-storage: unusual_devs.h
On Fri, 1 Feb 2008, Robert Spitzenpfeil wrote: > Alan Stern wrote: > > So Robert, this suggests an experiment for you to try. First remove > > the US_FL_FIX_INQUIRY flag in your unusual_devs entry, of course. But > > then edit transport.c, and in usb_stor_Bulk_max_lun() replace the two > > lines saying > > > > usb_stor_clear_halt(us, us->recv_bulk_pipe); > > usb_stor_clear_halt(us, us->send_bulk_pipe); > > > > with a single line saying > > > > usb_stor_clear_halt(us, us->send_ctrl_pipe); > > > > This should duplicate Windows' actions, except for the two retries. > > Maybe then the device will work... > > > > > IT WORKS. And just out of curiousity, what happens if you remove the usb_stor_clear_halt() entirely? Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: request: patch for oracom mp3 stick --> usb-storage: unusual_devs.h
On Thu, 31 Jan 2008, David Brownell wrote: > On Thursday 31 January 2008, Alan Stern wrote: > > The interesting difference lay in what Windows did when the Get-Max-LUN > > stalled. It sent a Clear-Halt request to endpoint 0! > > Yes that *is* strange! Considering that ep0 wasn't stalling ... No, ep0 did stall (at least, that's the way it looks from the SnoopyPro trace and that's what happened under Linux). This was in response to the Bulk-only-transport class-specific Get-Max-LUN request. Devices are permitted not to support that request if they have only one LUN. Right now usb-storage responds to this stall by clearing the halt feature from the bulk-in and bulk-out endpoints, not because the spec says to do so but because one ancient device (a ZIP-100) requires it. Now it looks as though we've found a device which can't handle it. Time for another quirk? Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: request: patch for oracom mp3 stick --> usb-storage: unusual_devs.h
Alan Stern wrote: On Thu, 31 Jan 2008, Robert Spitzenpfeil wrote: this mp3 stick has always worked with windows xp. it used to work with older kernels (e.g. 2.4.21-144, suse 9.0) but I could never make it work with any 2.6.xx before I found that patch. find attached: snoopypro log (binary + xml) : plugin/xp autoplay/safely remove... Thank you. This is indeed strange. Since the trace wasn't posted to the mailing list, I'll summarize what it contained. Just as with Linux, the Get-Max-LUN request failed (presumably with a STALL; it's hard to tell from the trace). Unlike Linux, Windows tried the request 3 times, with the same result each time. Following that, the INQUIRY command succeeded: Correct data was returned with no error status. The interesting difference lay in what Windows did when the Get-Max-LUN stalled. It sent a Clear-Halt request to endpoint 0! So Robert, this suggests an experiment for you to try. First remove the US_FL_FIX_INQUIRY flag in your unusual_devs entry, of course. But then edit transport.c, and in usb_stor_Bulk_max_lun() replace the two lines saying usb_stor_clear_halt(us, us->recv_bulk_pipe); usb_stor_clear_halt(us, us->send_bulk_pipe); with a single line saying usb_stor_clear_halt(us, us->send_ctrl_pipe); This should duplicate Windows' actions, except for the two retries. Maybe then the device will work... IT WORKS. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: request: patch for oracom mp3 stick --> usb-storage: unusual_devs.h
On Thursday 31 January 2008, Alan Stern wrote: > The interesting difference lay in what Windows did when the Get-Max-LUN > stalled. It sent a Clear-Halt request to endpoint 0! Yes that *is* strange! Considering that ep0 wasn't stalling ... - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: request: patch for oracom mp3 stick --> usb-storage: unusual_devs.h
On Thu, 31 Jan 2008, Robert Spitzenpfeil wrote: > this mp3 stick has always worked with windows xp. it used to work with > older kernels (e.g. 2.4.21-144, suse 9.0) > but I could never make it work with any 2.6.xx before I found that patch. > > find attached: snoopypro log (binary + xml) : plugin/xp > autoplay/safely remove... Thank you. This is indeed strange. Since the trace wasn't posted to the mailing list, I'll summarize what it contained. Just as with Linux, the Get-Max-LUN request failed (presumably with a STALL; it's hard to tell from the trace). Unlike Linux, Windows tried the request 3 times, with the same result each time. Following that, the INQUIRY command succeeded: Correct data was returned with no error status. The interesting difference lay in what Windows did when the Get-Max-LUN stalled. It sent a Clear-Halt request to endpoint 0! So Robert, this suggests an experiment for you to try. First remove the US_FL_FIX_INQUIRY flag in your unusual_devs entry, of course. But then edit transport.c, and in usb_stor_Bulk_max_lun() replace the two lines saying usb_stor_clear_halt(us, us->recv_bulk_pipe); usb_stor_clear_halt(us, us->send_bulk_pipe); with a single line saying usb_stor_clear_halt(us, us->send_ctrl_pipe); This should duplicate Windows' actions, except for the two retries. Maybe then the device will work... Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: request: patch for oracom mp3 stick --> usb-storage: unusual_devs.h
On Wed, 30 Jan 2008, Robert Spitzenpfeil wrote: > * unusual_devs.h: entry which does NOT work ( lacks: > US_FL_IGNORE_RESIDUE | US_FL_FIX_INQUIRY), ) > > UNUSUAL_DEV( 0x0f19, 0x0103, 0x0100, 0x0100, >"Oracom Co., Ltd", >"ORC-200M", > US_SC_DEVICE, US_PR_DEVICE, NULL, > US_FL_IGNORE_RESIDUE), > > > * /sys/module/usb_storage/parameters/delay_use = 1 (5 or 15 seconds does > not help either. tested for opensuse people) > > * /var/log/messages: plugin/unplug of mp3 stick ... > usbmon trace: ... Thanks for the detailed logs. This device seems to have at least two serious bugs. We were able to recover from the first one (the device sent a 13-byte packet containing garbage instead of the 36-byte INQUIRY data), but the second one was a killer (the device responded correctly to INQUIRY but then claimed that the command was invalid). Does this device work okay under Windows? If it does, can you provide a SnoopyPro trace showing the initialization? Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: request: patch for oracom mp3 stick --> usb-storage: unusual_devs.h
* unusual_devs.h: entry which does NOT work ( lacks: US_FL_IGNORE_RESIDUE | US_FL_FIX_INQUIRY), ) UNUSUAL_DEV( 0x0f19, 0x0103, 0x0100, 0x0100, "Oracom Co., Ltd", "ORC-200M", US_SC_DEVICE, US_PR_DEVICE, NULL, US_FL_IGNORE_RESIDUE), * /sys/module/usb_storage/parameters/delay_use = 1 (5 or 15 seconds does not help either. tested for opensuse people) * /var/log/messages: plugin/unplug of mp3 stick Jan 30 17:38:11 linux kernel: usb 1-3: new full speed USB device using ohci_hcd and address 6 Jan 30 17:38:11 linux kernel: usb 1-3: new device found, idVendor=0f19, idProduct=0103 Jan 30 17:38:11 linux kernel: usb 1-3: new device strings: Mfr=0, Product=0, SerialNumber=0 Jan 30 17:38:11 linux kernel: usb 1-3: configuration #1 chosen from 1 choice Jan 30 17:38:11 linux kernel: usb-storage: USB Mass Storage device detected Jan 30 17:38:11 linux kernel: usb-storage: -- associate_dev Jan 30 17:38:11 linux kernel: usb-storage: Vendor: 0x0f19, Product: 0x0103, Revision: 0x0100 Jan 30 17:38:11 linux kernel: usb-storage: Interface Subclass: 0x06, Protocol: 0x50 Jan 30 17:38:11 linux kernel: usb-storage: Transport: Bulk Jan 30 17:38:11 linux kernel: usb-storage: Protocol: Transparent SCSI Jan 30 17:38:11 linux kernel: scsi14 : SCSI emulation for USB Mass Storage devices Jan 30 17:38:11 linux kernel: usb-storage: *** thread sleeping. Jan 30 17:38:11 linux kernel: usb-storage: device found at 6 Jan 30 17:38:11 linux kernel: usb-storage: waiting for device to settle before scanning Jan 30 17:38:12 linux kernel: usb-storage: usb_stor_control_msg: rq=fe rqtype=a1 value= index=00 len=1 Jan 30 17:38:12 linux kernel: usb-storage: GetMaxLUN command result is -32, data is 0 Jan 30 17:38:12 linux kernel: usb-storage: usb_stor_control_msg: rq=01 rqtype=02 value= index=82 len=0 Jan 30 17:38:12 linux kernel: usb-storage: usb_stor_clear_halt: result = 0 Jan 30 17:38:12 linux kernel: usb-storage: usb_stor_control_msg: rq=01 rqtype=02 value= index=01 len=0 Jan 30 17:38:12 linux kernel: usb-storage: usb_stor_clear_halt: result = 0 Jan 30 17:38:12 linux kernel: usb-storage: queuecommand called Jan 30 17:38:12 linux kernel: usb-storage: *** thread awakened. Jan 30 17:38:12 linux kernel: usb-storage: Command INQUIRY (6 bytes) Jan 30 17:38:12 linux kernel: usb-storage: 12 00 00 00 24 00 Jan 30 17:38:12 linux kernel: usb-storage: Bulk Command S 0x43425355 T 0x1 L 36 F 128 Trg 0 LUN 0 CL 6 Jan 30 17:38:12 linux kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes Jan 30 17:38:12 linux kernel: usb-storage: Status code 0; transferred 31/31 Jan 30 17:38:12 linux kernel: usb-storage: -- transfer complete Jan 30 17:38:12 linux kernel: usb-storage: Bulk command transfer result=0 Jan 30 17:38:12 linux kernel: usb-storage: usb_stor_bulk_transfer_sglist: xfer 36 bytes, 1 entries Jan 30 17:38:12 linux kernel: usb-storage: Status code -121; transferred 13/36 Jan 30 17:38:12 linux kernel: usb-storage: -- short read transfer Jan 30 17:38:12 linux kernel: usb-storage: Bulk data transfer result 0x1 Jan 30 17:38:12 linux kernel: usb-storage: Attempting to get CSW... Jan 30 17:38:12 linux kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes Jan 30 17:38:12 linux kernel: usb-storage: Status code 0; transferred 13/13 Jan 30 17:38:12 linux kernel: usb-storage: -- transfer complete Jan 30 17:38:12 linux kernel: usb-storage: Bulk status result = 0 Jan 30 17:38:12 linux kernel: usb-storage: Bulk Status S 0x1008000 T 0x1f R 538976288 Stat 0x20 Jan 30 17:38:12 linux kernel: usb-storage: Bulk logical error Jan 30 17:38:12 linux kernel: usb-storage: -- transport indicates error, resetting Jan 30 17:38:12 linux kernel: usb-storage: storage_pre_reset Jan 30 17:38:12 linux kernel: usb 1-3: reset full speed USB device using ohci_hcd and address 6 Jan 30 17:38:12 linux kernel: usb-storage: storage_post_reset Jan 30 17:38:12 linux kernel: usb-storage: usb_reset_composite_device returns 0 Jan 30 17:38:12 linux kernel: usb-storage: scsi cmd done, result=0x7 Jan 30 17:38:12 linux kernel: usb-storage: *** thread sleeping. Jan 30 17:38:12 linux kernel: usb-storage: queuecommand called Jan 30 17:38:12 linux kernel: usb-storage: *** thread awakened. Jan 30 17:38:12 linux kernel: usb-storage: Command INQUIRY (6 bytes) Jan 30 17:38:12 linux kernel: usb-storage: 12 00 00 00 24 00 Jan 30 17:38:12 linux kernel: usb-storage: Bulk Command S 0x43425355 T 0x2 L 36 F 128 Trg 0 LUN 0 CL 6 Jan 30 17:38:12 linux kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes Jan 30 17:38:12 linux kernel: usb-storage: Status code 0; transferred 31/31 Jan 30 17:38:12 linux kernel: usb-storage: -- transfer complete Jan 30 17:38:12 linux kernel: usb-storage: Bulk command transfer result=0 Jan 30 17:38:12 linux kernel: usb-storage: usb_stor_bulk_transfer_sglist: xfer 36 bytes, 1 entries Jan 30 17:38:12 linux kernel: usb-storage: Status code 0; transferred 36/36 Jan
Re: request: patch for oracom mp3 stick --> usb-storage: unusual_devs.h
On Tue, 29 Jan 2008, Robert Spitzenpfeil wrote: > as per request, I've checked whether the patch works WITHOUT the > "US_FL_FIX_INQUIRY" flag. > result: NO, only works with said flag included. (2.6.22.13-0.3-default > #1 SMP - opensuse 10.3) Really? That's very strange... Devices needing that flag won't work with Windows, as far as I know. Could you please send a usbmon trace (see the instructions in the kernel source file Documentation/usb/usbmon.txt) showing what happens when you plug the device in and the US_FL_FIX_INQUIRY flag isn't set? Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: request: patch for oracom mp3 stick --> usb-storage: unusual_devs.h
as per request, I've checked whether the patch works WITHOUT the "US_FL_FIX_INQUIRY" flag. result: NO, only works with said flag included. (2.6.22.13-0.3-default #1 SMP - opensuse 10.3) as per request, I resubmit the patch with outputs of "/proc/bus/usb/devices/" "lsusb" "lsusb -v" (only relevant sections included). as I did not develop the patch, but only found it on the web and tested it on my system I will only add "Acked-by:", if I understand the docs right ! --- cut here --- Acked-by: [EMAIL PROTECTED] From: [EMAIL PROTECTED] --- --- unusual_devs.h2008-01-29 17:30:04.0 +0100 +++ ./oracom/unusual_devs.h2008-01-29 17:34:54.0 +0100 @@ -1354,6 +1354,16 @@ US_SC_DEVICE, US_PR_DEVICE, NULL, US_FL_IGNORE_RESIDUE | US_FL_GO_SLOW | US_FL_MAX_SECTORS_64), +/* Patch by Leonid Petrov mail at lpetrov.net + * http://www.qbik.ch/usb/devices/showdev.php?id=1705 + * Updated to 103 device by MJ Ray mjr at phonecoop.coop + */ +UNUSUAL_DEV( 0x0f19, 0x0103, 0x0100, 0x0100, + "Oracom Co., Ltd", + "ORC-200M", +US_SC_DEVICE, US_PR_DEVICE, NULL, +US_FL_IGNORE_RESIDUE | US_FL_FIX_INQUIRY), + /* David Kuehling <[EMAIL PROTECTED]>: * for MP3-Player AVOX WSX-300ER (bought in Japan). Reports lots of SCSI * errors when trying to write. --- cut here --- /proc/bus/usb/devices: T: Bus=01 Lev=01 Prnt=01 Port=02 Cnt=03 Dev#= 5 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=32 #Cfgs= 1 P: Vendor=0f19 ProdID=0103 Rev= 1.00 C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr= 98mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=83(I) Atr=03(Int.) MxPS= 8 Ivl=1ms lsusb: Bus 001 Device 004: ID 0f19:0103 Oracom Co., Ltd lsusb -v: Bus 001 Device 004: ID 0f19:0103 Oracom Co., Ltd Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize032 idVendor 0x0f19 Oracom Co., Ltd idProduct 0x0103 bcdDevice1.00 iManufacturer 0 iProduct0 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 39 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 98mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk (Zip) iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 1 Device Status: 0x (Bus Powered) - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: request: patch for oracom mp3 stick --> usb-storage: unusual_devs.h
On Tue, 29 Jan 2008, Robert Spitzenpfeil wrote: > --- linux/drivers/usb/storage/unusual_devs.h.orig 2007-07-03 > 18:44:59.0 +0100 > +++ linux/drivers/usb/storage/unusual_devs.h2007-07-03 > 19:01:47.0 +0100 > @@ -1317,6 +1317,16 @@ > US_SC_DEVICE, US_PR_DEVICE, NULL, > US_FL_IGNORE_RESIDUE | US_FL_GO_SLOW | > US_FL_MAX_SECTORS_64), > > +/* Patch by Leonid Petrov mail at lpetrov.net > + * http://www.qbik.ch/usb/devices/showdev.php?id=1705 > + * Updated to 103 device by MJ Ray mjr at phonecoop.coop > + */ > +UNUSUAL_DEV( 0x0f19, 0x0103, 0x0100, 0x0100, > + "Oracom Co., Ltd", > + "ORC-200M", > +US_SC_DEVICE, US_PR_DEVICE, NULL, > +US_FL_IGNORE_RESIDUE | US_FL_FIX_INQUIRY), > + The US_FL_FIX_INQUIRY flag almost certainly isn't needed. Can you verify that the device works okay without that flag? Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: request: patch for oracom mp3 stick --> usb-storage: unusual_devs.h
On Tue, Jan 29, 2008 at 11:34:24AM +0100, Robert Spitzenpfeil wrote: > greetings, > > opensuse people wanted me to forward this patch to the list: > > > The new patch for linux-2.6.21.5 is: Can you resend this, your email client ate all the tabs for lunch and spit out spaces instead and then decided to line-wrap the patch as well :( Also, we need a "Signed-off-by:" line as per the Documentation/SubmittingPatches file, as well as the output of /proc/bus/usb/devices with this device plugged in. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
