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-in
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 n
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 actu
On Sat, Feb 02, 2008 at 10:30:51PM -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 n
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 actu
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
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 l
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
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,
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() repl
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 e
On Fri, 1 Feb 2008 11:54:12 -0800, Matthew Dharm <[EMAIL PROTECTED]> wrote:
> There's no way to know until Robert tests with no clear-halt at all.
Which is very easy to do: enable ub, run usbmon... voila.
-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body
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
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 abo
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.
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
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 inte
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
> > > > s
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
> > > > s
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!
>
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!
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
> > line
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 ...
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
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 "unsub
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) : plugi
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,
* 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),
* /s
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
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 rele
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_D
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 decid
greetings,
opensuse people wanted me to forward this patch to the list:
The new patch for linux-2.6.21.5 is:
--- 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
@@ -1
33 matches
Mail list logo
