On Tue, 29 Jun 2004, Phil Brunner wrote:
> >Right. A lot of devices aren't careful about sending too much data. They
> >probably expect always to be asked for 192 bytes, which is what Windows
> >does.
> >
> >
> >
> Since Windows asks for 192 bytes and most/all devices are designed to
> work
Alan Stern wrote:
On Sun, 27 Jun 2004, Phil Brunner wrote:
The attached Matthew Dharm patch
Just to set the record straight, I wrote the majority of that patch. It
was submitted to Matt Dharm, who changed it slightly by making the option
to use the MODE SENSE command selectable in the
On Sun, 27 Jun 2004, Phil Brunner wrote:
> > The attached Matthew Dharm patch
Just to set the record straight, I wrote the majority of that patch. It
was submitted to Matt Dharm, who changed it slightly by making the option
to use the MODE SENSE command selectable in the kernel configuration.
The attached Matthew Dharm patch (which should probably be in 2.6.8
per Alan Stern) fixed the problem for 2.6.5, 2.6.6 and all 2.6.7
varieties. There were no problems with 2.6.4.
The patch seems to make the MODE_SENSE command (try to) transfer 192
bytes rather than 4 bytes - results in "babble
On Thu, 24 Jun 2004, Ian E. Morgan wrote:
> On Wed, 23 Jun 2004, Phil Brunner wrote:
>
> > I had a similar problem with different hardware see "smartcard reader kills
> > usb hub on 2.6.5+, OK on 2.6.4" thread.
> >
> > The attached Matthew Dharm patch (which should probably be in 2.6.8 per Alan
On Wed, 23 Jun 2004, Phil Brunner wrote:
I had a similar problem with different hardware see "smartcard reader kills
usb hub on 2.6.5+, OK on 2.6.4" thread.
The attached Matthew Dharm patch (which should probably be in 2.6.8 per Alan
Stern) fixed the problem for 2.6.5, 2.6.6 and all 2.6.7 variet
On Wed, 23 Jun 2004, Phil Brunner wrote:
>
> Ian Morgan wrote:
>
> > On Wed, 23 Jun 2004, Ian E. Morgan wrote:
> >
> >> The only immediate thing that stands out to me is that in 2.4 the
> >> INQUIRY is
> >> '12 00 00 00 FF 00' (Allocation length 255), while in 2.6 it is '12
> >> 00 00 00 24 00
On Wed, 23 Jun 2004, Ian Morgan wrote:
> On Wed, 23 Jun 2004, Ian E. Morgan wrote:
>
> > The only immediate thing that stands out to me is that in 2.4 the INQUIRY is
> > '12 00 00 00 FF 00' (Allocation length 255), while in 2.6 it is '12 00 00 00
> > 24 00' (Allocation length 36 (makes sense)).
Ian Morgan wrote:
On Wed, 23 Jun 2004, Ian E. Morgan wrote:
The only immediate thing that stands out to me is that in 2.4 the
INQUIRY is
'12 00 00 00 FF 00' (Allocation length 255), while in 2.6 it is '12
00 00 00 24 00' (Allocation length 36 (makes sense)).
I had a similar problem with differen
On Wed, 23 Jun 2004, Ian E. Morgan wrote:
The only immediate thing that stands out to me is that in 2.4 the INQUIRY is
'12 00 00 00 FF 00' (Allocation length 255), while in 2.6 it is '12 00 00 00
24 00' (Allocation length 36 (makes sense)).
I added an unusual_devs.h entry:
UNUSUAL_DEV( 0x0dbf, 0x
On Wed, 23 Jun 2004, Alan Stern wrote:
It sure would be nice to know why the card reader has problems with the
commands sent by 2.6 but not 2.4...
I finally got Fedora's 2.4 kernel rebuilt with debugging.. Here's what it
looks like in 2.4 which never fails:
Jun 23 15:56:05 localhost kernel: hub.c:
On Wed, 23 Jun 2004, Ian E. Morgan wrote:
> On Wed, 23 Jun 2004, Alan Stern wrote:
>
> > It's much more likely that the same failure occurs in 2.4, but the bus
> > reset code there works better than in 2.6 so you recover without deadlock.
>
> I would have expected to see delays then as the bus w
On Wed, 23 Jun 2004, Alan Stern wrote:
Transferring a command involves 2 or 3
phases: the command phase, the optional data phase, and the status phase.
The successful 31-byte transfer was the command phase; that doesn't
require the reader to actually communicate with the card. The
unsuccessful 36-
On Tue, 22 Jun 2004, Ian E. Morgan wrote:
> On Tue, 22 Jun 2004, Alan Stern wrote:
>
> > It's a little suspicious that your drive fails so quickly -- on the very
> > first command it receives.
>
> It's not quite the first command (see below).
No, it is the first command. Transferring a command
On Tue, 22 Jun 2004, Alan Stern wrote:
Anyway, it looks like there's a problem with the hub that's plugged into
your computer. Does your device attach to an external hub? Apparently
that hub has died; that's the reason for all those repeated -84 or -71
errors at the end of the logs. Or maybe you
On Tue, 22 Jun 2004, Ian E. Morgan wrote:
> I concur with your assessment, but I am at a loss to explain it, or where to
> start digging to further debug the issue.
>
> Do you have any patches I could test out now? I'm getting desperate.
>
> I've discovered that the deadlock does NOT occur with
On Sat, 19 Jun 2004, Alan Stern wrote:
I can't offer any detailed help right now, but this looks like you're
encountering problems with device locking during bus resets. Or maybe
some other problem, but clearly related to bus resets. I've been spending
a lot of time working on that code recently.
On Sat, 19 Jun 2004, Ian Morgan wrote:
> Originally posted as a reply to an earlier thread, thinking the problems
> were related, but apparently not, so I'm reposting as a new thread so more
> people might see it. Thanks to anyone who can help.
>
> I have 3 Addonics 4-slot PCMCIA card reader atta
Originally posted as a reply to an earlier thread, thinking the problems
were related, but apparently not, so I'm reposting as a new thread so more
people might see it. Thanks to anyone who can help.
I have 3 Addonics 4-slot PCMCIA card reader attached via two 7-port D-Link
hub. All units are USB
On Tue, Mar 12, 2002 at 01:15:08AM +0100, Peter Osterlund wrote:
> Hi!
>
> I was doing some stress testing on the packet writing patch for the
> 2.4.19-pre2 kernel. I was unpacking a kernel tarball to a cdrw disk on
> a freecom usb cdrw device. After a while, some problem occurred which
> made us
> I see that some changes went into 2.5.4-pre2 which I think would fix
> this problem. (Addition of a "mem_flags" parameter to various memory
> allocating functions in the usb subsystem.)
>
> Are there any plans to include this fix in the 2.4.x kernel tree? (I
> didn't see it in the latest batch
Hi!
I was doing some stress testing on the packet writing patch for the
2.4.19-pre2 kernel. I was unpacking a kernel tarball to a cdrw disk on
a freecom usb cdrw device. After a while, some problem occurred which
made usb-storage decide to perform a bus reset. Unfortunately it
needed to allocate
22 matches
Mail list logo
