I'm trying to work out which bit of code actually
sends an URB "down the wire". As far as I can
see submit_urb passes the urb to hcd_submit_urb
which sends it on to the appropriate urb_enqueue,
which hooks it into some lists and... forgets about it!
Who runs the lists? Who does the timing? Wher
On Tue, 9 Jul 2002, David Brownell wrote:
> > * append length=0 packet in the correct situation only,
> > i.e. basically when (length%maxpacketsize)==0
>
> Good, that's basically a "should be ==, not !=" patch, yes?
> Whoops!
Exactly!
> > * make USB_ZERO_PACKET only effective on
Hello
Could someone please tell me how to enable debugging for the Linux
OHCI controller and where to check for the debug messages .Does it imply
recompiling the kernel ?
Please cc me the answer since I am not subscribed to this list. In case this
is not the place for this question I am so
You may want to backport patch 1167/3 to 2.4. The sa-pcibuf.c in
rmk's 2.4.x and 2.5.x source tree has several serious bugs.
I dobut that's enough to get you around the "not in interrupt" assertion
...
-ch
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED
Good news:
2.5.24 + rmk1 + patch 1167/3 (or 1167/2) is more winning than ever with
usb-storage. Before this, dd'ing off a CF device would *ALWAYS* crash
the kernel in bizarre fashion. Woohoo!
Thanks to all.
-ch
# uname -a
Linux localhost.localdomain 2.5.24-rmk1-ch1 #1 Tue Jul 9 16:08:17
Simon Gittins wrote:
> I'm looking into a problem with my USB modem and have traced it to usb-ohci
> (2.4.19-pre10).
Then presumably it's also in the 2.5 "ohci-hcd" too, unless it's
one of the bugs that's fixed there (mostly for ED queues, not
TD queues).
> The problem appears to be that there
>>I've got one fix in that area still queued, which I'll send
>>separately on the chance it makes a difference in this case.
>
>
> That fix made only things worse
... broken patch, sorry. I thought I'd sanity checked it, but
that was a couple weeks ago and I suspect I really didn't. Turns
out
That stack trace looks broken to me, since
it has impossible call sequences...
It may not matter though: yes, allocation in interrupt
shouldn't blow up. Returning 0 on error would be better,
even though davem wants a designated error value #defined,
since layers above should handle such errors
Hi
Finally I succesfully loaded all USB related
drivers
my lsmod gives
Module Size Used by
usb-uhci-hcd 20432 0 (unused)
ohci-hcd 23216 0 (unused)
ehci-hcd 26640 0 (unused)
usbcore75584 1 [usb-uhci-hcd
ohci-hcd
Thanks Martin,
> Finally, it turned out the decision when to append a length=0 usb-packet
> is partly done just the wrong way.
>
> The patch below does
> * append length=0 packet in the correct situation only,
> i.e. basically when (length%maxpacketsize)==0
Good, that's basically
On Wed, Jul 10, 2002 at 01:14:32AM +0100, Russell King - ARM Linux wrote:
> On Tue, Jul 09, 2002 at 05:05:07PM -0700, Pering, Trevor wrote:
> > Hello -- this is a re-post of an earlier problem from last week I'm still
> > working on.
>
> The problem is consistent_alloc(). When it was written, it
On Tue, Jul 09, 2002 at 05:05:07PM -0700, Pering, Trevor wrote:
> Hello -- this is a re-post of an earlier problem from last week I'm still
> working on.
The problem is consistent_alloc(). When it was written, it didn't need
to handle allocations from interrupts. However, the spec changed, and
Hello -- this is a re-post of an earlier problem from last week I'm still
working on.
I'm using an ARM-based 2.4.18-rmk4 system that is using a USB Bluetooth
device to do file transfer. When I transfer a large file, the system hits a
"not in interrupt" assertion in consistent_alloc (arch/arm/mm/c
On Tue, Jul 09, 2002 at 11:48:38PM +0200, Oliver Neukum wrote:
> Hi,
>
> the recent discussion on the BKL made me check whether the BKL
> really leads to bad locking. Most uses of BKL in drivers/usb/core
> are in usbfs.
>
> I am afraid the guy claiming that was not totally removed from
> reality
Hi,
the recent discussion on the BKL made me check whether the BKL
really leads to bad locking. Most uses of BKL in drivers/usb/core
are in usbfs.
I am afraid the guy claiming that was not totally removed from
reality.
- devio.c::usbdev_open
Here we have an open with no protection at all again
Hi Dave and Jean,
did some investigation into the "irda-usb doesn't work with ohci-hcd"
issue. Symptoms are on one hand the outgoing irda-packets get transmitted
(but corrupted) by the OHCI-HC and on the other hand the urb's are staying
queued without ever getting unlinked (but callback called).
Greg KH wrote:
> Here's a patch from devik that seems to help some people out who are
> having oopses with the usb-ohci driver on slower/busy machines.
Note that it's a backport of a patch of mine from 2.5, which
other users have also reported as helping ... one of those
"that code can't be right
Hi,
> I'd guess this to be a relabled DataFab ML4-USB.
> Incase yes, it contains a NeoDio chip (for CF/SM/SD) and a MemoryStick chip
> plus a USB hub.
> Check http://www.qbik.ch/usb/devices/showdev.php?id=1146.
>
> Also note: the MemoryStick part takes extremly long to get started. Mostly
> the l
On Mon, Jul 08, 2002 at 03:51:09AM -0700, Mark McClelland wrote:
> The attached BK-patch upgrades the ov511 driver in 2.5.25 to version
> 1.61. This is cleanup and minor bug-fix release. As usual, it compiles
> cleanly but I can't promise that it works (at least until I get 2.5
> working here).
Here's a patch from devik that seems to help some people out who are
having oopses with the usb-ohci driver on slower/busy machines.
If you have this problem, please test out this patch and let me know if
it helps or not.
thanks,
greg k-h
# This is a BitKeeper generated patch for the followin
I lack understanding of usb slave side protocol a bit.
my question is that do I require to handle SOF ( start of frame)
events on usb slave side through a interrupt handler as we do on
HOST side.
one gentleman has given me a right pointer ..I just need bit more
explanation .
Best Regards,
As
anton wilson wrote:
> I'm having a problem where the kernel is freezing when the function
> sohci_unlink_urb is attempting to shedule_timeout(timeout). The exact point
> in the kerneL where it freezes is in add_timer(&timer) after the spinlock is
> locked.
That is, not in the USB code at all.
> -obj-$(CONFIG_VIDEO_DEV) +=3D videodev.o
> +obj-$(CONFIG_VIDEO_DEV) +=3D videodev.o tuner.o
That looks wrong. Tuner is only needed for some cards. Put the proper rules
in
---
This sf.net email is sponsored by:ThinkGeek
Stuff, things, and muc
23 matches
Mail list logo
