On Wed, Feb 20, 2002 at 01:23:42AM -0500, Johannes Erdfelt wrote:
> uhci.c didn't work well with USB storage. It would tend to stall
> relatively quickly and sometimes locked up the system. It usually only
> took me a couple of tries ripping a CD to reproduce the problem.
>
> I took a long hard l
mats wolpers wrote:
>hello,
>
> matthew dharm suggested i should inform you of the following:
>
>i had all manner of trouble connecting/mounting my hp318 digital camera using
>suse 7.2. (freeze in usb) so i asked (first greg then) matt for help.
>
>after upgradig from kernel 2.4.4 to 2.4.1
uhci.c didn't work well with USB storage. It would tend to stall
relatively quickly and sometimes locked up the system. It usually only
took me a couple of tries ripping a CD to reproduce the problem.
I took a long hard look at the locking in uhci.c and decided to clean
it up, fixing a couple of
There was a bug where we unmap the PCI DMA mapping and then sync the
data afterwards. This reverses the ordering as well as insures we don't
unmap the region more than once.
JE
--- linux-2.4.18-pre9.orig/drivers/usb/uhci.c Tue Feb 19 22:08:22 2002
+++ linux-2.4.18-pre9/drivers/usb/uhci.c
This patch fixes a bug where an interrupt URB is unlinked in the drivers
completion handler and we'll try to resubmit it anyway.
JE
--- linux-2.4.18-pre9.orig/drivers/usb/uhci.c Tue Feb 19 22:05:50 2002
+++ linux-2.4.18-pre9/drivers/usb/uhci.cTue Feb 19 22:07:42 2002
@@ -2255,7 +2255,7
This patch fixes another toggle bug and reverts the previous bogus
patch which caused compile warnings.
It also adds a quick comment explaining the criteria.
JE
--- linux-2.4.18-pre9.orig/drivers/usb/uhci.c Tue Feb 19 21:57:46 2002
+++ linux-2.4.18-pre9/drivers/usb/uhci.cTue Feb 19 22
On Tue, Feb 19, 2002 at 05:55:19PM -0800, Steve Calfee wrote:
>
> If I remember correctly, Win98 did a quick 100 ms attempt and if it failed
> then retried reset using a longer delay. Win98 did lots of retries, maybe
> infinite, probably to get around problem devices. I dont have a catc right
At 06:52 PM 2/19/02 -0500, Pete Zaitcev wrote:
> > Date: Wed, 20 Feb 2002 00:36:14 +0100 (CET)
> > From: Martin Diehl <[EMAIL PROTECTED]>
>
> > Johannes, Pete - if it's ok for you I'd like to suggest this could go into
> > early 2.4.19-pre series.
>
>I do not mind. If I remember JE's argument righ
Perhaps I'm just being thick here but I'm missing a vital point about
interrupt transfers (well interrupt out transfers at least).
With an interrupt in, you get a callback every now and again, you
look to see what actual_length is, if it's not zero, you copy data
to your own buffer and return. Th
On Tue, 19 Feb 2002, Johannes Erdfelt wrote:
> Maybe we can do this asynchronously?
Yep. A per-port statemachine with transitions triggered by both the hub
INT-IN urb and some timers sounds like a good idea to me.
> I want correctness over performance, so this patch is good for now and I
> thin
On Tue, 19 Feb 2002, Pete Zaitcev wrote:
> I do not mind. If I remember JE's argument right, he did not
> like how long it takes to renumber a bus with a dozen of
> devices (about 6..8 seconds: noticeable timeout).
>
> I understand that it's a kludge, but would it be possible
> to tighten up the
> Date: Wed, 20 Feb 2002 00:36:14 +0100 (CET)
> From: Martin Diehl <[EMAIL PROTECTED]>
> Johannes, Pete - if it's ok for you I'd like to suggest this could go into
> early 2.4.19-pre series.
I do not mind. If I remember JE's argument right, he did not
like how long it takes to renumber a bus wit
On Tue, Feb 19, 2002, Pete Zaitcev <[EMAIL PROTECTED]> wrote:
> > Date: Wed, 20 Feb 2002 00:36:14 +0100 (CET)
> > From: Martin Diehl <[EMAIL PROTECTED]>
>
> > Johannes, Pete - if it's ok for you I'd like to suggest this could go into
> > early 2.4.19-pre series.
>
> I do not mind. If I remember
On Mon, 18 Feb 2002, Greg KH wrote:
> Here's the 2.4 version of the patch. Anyone have any problems with it?
>
> How about the time delay patch on top of this patch Martin?
OK, I've updated it for 2.4.18-rc2, applies after the usb_port_status
thing. Debounce delay is now 400ms, which seems to
Brad Hards wrote:
>
> Glad you liked it. Have you got the exact model handy?
>
It's this guy: a linksys BEFCMU10 Cable Modem w/USB and Ethernet.
http://www.linksys.com/products/product.asp?grid=23&prid=404
> > The USB port works great, with linux-2.4.18-rc1.
> Can I ask what chipset and contr
Hi all,
Here's a patch against 2.5.5-pre1 that finishes up the urb reference
counting logic, by implementing usb_get_urb() and usb_put_urb() in the
uhci, usb-uhci, and usb-ohci drivers (currently it's only in the
ehci-hcd and ohci-hcd drivers.)
I've been running with this patch for a while now a
On Wed, 20 Feb 2002 06:53, Thomas Davis wrote:
> I'd like to say thanks! to the people who wrote the CDCEther driver - I
> picked up the Linksys cable modem, with both USB and Ethernet ports.
Glad you liked it. Have you got the exact model handy?
> The USB port works great, with linux-2.4.18-rc1.
On Tue, Feb 19, 2002 at 11:30:02AM -0800, David Brownell wrote:
> > > And why there's that issue I mentioned (reported in Janary by
> > > Wolfgang Mües) about changing the _length_ of an OUT transfer.
> > > I've some comments I hope to send out, but can't do so much before
> > > Wednesday.
> >
> >
I'd like to say thanks! to the people who wrote the CDCEther driver - I
picked up the Linksys cable modem, with both USB and Ethernet ports.
The USB port works great, with linux-2.4.18-rc1.
The /proc/bus/usb/devices info:
T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 3 Spd=12 MxCh= 0
D: Ver
On Wed, 20 Feb 2002 04:48, Stephen J. Gowdy wrote:
> BTW, I've just fixed the missing three slides (for some reason the ticks
> were missing from those slides when I did the export).
Ah, I turned them off when I interrupted the presentation to do a usbview demo
at that point. I didn't want to sho
Hello David!
> So, the INTR-OUT problem. For example, maxpacket size is 64,
> period is maybe 8, but the driver needs to send 100 bytes. That
> adds up to 64 bytes in one frame, then 36 bytes after a delay of
> 8 frames ... then wanting to stop/unlink. This is one problem that
> the LEGO folk
> > And why there's that issue I mentioned (reported in Janary by
> > Wolfgang Mües) about changing the _length_ of an OUT transfer.
> > I've some comments I hope to send out, but can't do so much before
> > Wednesday.
>
> It would work if most of the time the interrupt OUT URB could have a
> tran
> I'm puzzled about this thread. As I understand the discussion, seems that
> someone is using an interrupt out for a small amount of data and, for some
> unknown reason, the last data packet is being resent on each "interrupt"
> interval. ...
There are some known reasons this failure mode might
This is starting to make more sense now. I've been playing with the LEGO driver and
that's why I started asking these types of questions several days ago.
When the original urb is submitted, are you supposed to put 64 bytes in the urb, and
then 36 bytes in the next urb (you as in the driver wr
"> " = Vladimir Dergachev
"> > " = Vojtech Pavlik
"> > > " = David Brownell
> > > By the host controller driver. It's a "periodic" transfer,
> > > which _by design_ is going to be happening over and
> > > over and over again.
> >
> > Which is a problem. All uses of interrupt out I have me
On Tue, 19 Feb 2002, Vojtech Pavlik wrote:
> On Tue, Feb 19, 2002 at 02:59:28AM -0800, David Brownell wrote:
>
> > By the host controller driver. It's a "periodic" transfer,
> > which _by design_ is going to be happening over and
> > over and over again.
>
> Which is a problem. All uses of int
I'm puzzled about this thread. As I understand the discussion, seems that
someone is using an interrupt out for a small amount of data and, for some
unknown reason, the last data packet is being resent on each "interrupt"
interval. If this is the case, then I'm pretty sure that it isn't supposed
BTW, I've just fixed the missing three slides (for some reason the ticks
were missing from those slides when I did the export).
On Tue, 19 Feb 2002, Brad Hards wrote:
> The Ottowa people are calling for submissions, cf:
> http://lwn.net/daily/olscfp.php3
>
> It would be good if one of the USB
hello,
matthew dharm suggested i should inform you of the following:
i had all manner of trouble connecting/mounting my hp318 digital camera using
suse 7.2. (freeze in usb) so i asked (first greg then) matt for help.
after upgradig from kernel 2.4.4 to 2.4.16, there was no longer any f
On Tue, Feb 19, 2002 at 02:12:43AM -0800, David Brownell wrote:
> > Here's the 2.4 version of the patch. Anyone have any problems with it?
>
> Not so long as the eventual merged patch restores the
> attached pair of lines, which I extracted from the SF.net
> patch database and usb2-ehci-0114.pat
On Tue, Feb 19, 2002 at 02:59:28AM -0800, David Brownell wrote:
> By the host controller driver. It's a "periodic" transfer,
> which _by design_ is going to be happening over and
> over and over again.
Which is a problem. All uses of interrupt out I have met don't need to
be periodic - they're
> It seems to me that the distinction between interrupt transfers and bulk
> transfers is somewhat artificial.
If you ignore bandwidth and other resource allocation issues, yes.
But those are very real issues in many systems.
"On the wire" you don't see much difference, except that there are
par
The Ottowa people are calling for submissions, cf:
http://lwn.net/daily/olscfp.php3
It would be good if one of the USB developers were able to deliver a
presentation. These technical conferences are a good way to raise visibility
and recruit users and developers.
Stephen Gowdy has put my note
> Hmm.. What would happen if I try to send a URB with 0 data size ?
UTSL ... or experiment!
Frankly it seems to me like a poor idea to be sending periodic
empty interrupt transfers, but I'm sure someone will say they
would like to use that as a device keepalive function!
- Dave
_
"> > " == Roland King
"> " == Vojtech Pavlik
> > This is a little similar to the discussion we were having last
> > week about how to do interrupt transfers on the usbdevfs
> > interface. The answer seemed to end up being that you should
> > just do bulk transfers.
"Seemed" -- if you can arrang
> Here's the 2.4 version of the patch. Anyone have any problems with it?
Not so long as the eventual merged patch restores the
attached pair of lines, which I extracted from the SF.net
patch database and usb2-ehci-0114.patch ... there's
a conflict with this patch, as well as in the more complete
36 matches
Mail list logo
