On Fri, Feb 15, 2002 at 09:59:13AM -0800, Greg KH wrote:
>
> Ok, in the whole "hub debounce problem" the problem where
> usb_port_status is on the stack and passed to the host controller was
> also brought up. Here's that patch split out of the debounce patch
> against 2.5.5-pre1 thanks to Marti
This is a merge of my previously mentioned change sets into your most
recent tree, fixing up the merge problem that happened in
drivers/usb/inode.c
Pull from: bk://linuxusb.bkbits.net/linus-2.5
drivers/usb/hub.c | 60 +
drivers/usb/inode
On Mon, Feb 18, 2002 at 09:19:35PM -0800, Greg KH wrote:
> --
> [EMAIL PROTECTED], 2002-02-18 21:01:19-08:00, [EMAIL PROTECTED]
> usbdevfs:
> - put back locks that I accidentally took out with the last merge.
>
> drivers/usb/inode.c |3 +++
> 1 files changed, 3 insertions(+)
#
On Mon, Feb 18, 2002 at 06:58:28PM -0500, Roland King wrote:
> 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.
>
> I have read the US
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.
I have read the USB spec several times now and see that there
are 4 sorts of endpoint and as
Hi
(Sorry Dave, I hit the wrong button)
Correct me if I am wrong, I'm a little new to this myself.
It seems to me that the distinction between interrupt transfers and bulk
transfers is somewhat artificial.
Despite advice to the contrary I find that a usb_bulk_msg seems to be able
to get a pack
Hmm.. What would happen if I try to send a URB with 0 data size ?
thanks
Vladimir Dergachev
On Mon, 18 Feb 2002, David Brownell wrote:
> Right now the only portable solution is rather awkward.
> That is:
>
> (a) make sure urb->interval is
Right now the only portable solution is rather awkward.
That is:
(a) make sure urb->interval is long enough that it's
probably not going to suffer interrupt/scheduling
latency problems (causing extra transfers), and
submit the URB
(b) have your completion handler signal the thread
Stupid question:
I have a device that has two interrupt endpoints - in and out.
During initialization I need to transfer two small packets to the devices.
The problem is that USB seems to keep transferring the last packet..
How do I stop this ? (usb_unlink_urb does not seem to help).
On Mon, Feb 18, 2002 at 12:39:57AM -0800, David Paschal wrote:
>
> The kernel in question is RedHat 7.2's 2.4.7-10,
Eric, this kernel is known to have problems. An updated kernel has be
available for quite some time, please get it.
thanks,
greg k-h
__
> I've seen similar issues firsthand on an SMP box. I think the reported EIP
> address tends to lie in non-USB parts of the kernel, such as various
> network drivers, but I don't know if that's always the case. I just know
Are they repeatable ?
> that it's triggered by doing a fair amount of
Hi. There seem to be kernel-panic issues in the USB subsystem when running
in SMP mode, specifically with printer-class devices, although I don't know
if printer.c is what's at fault. I'm forwarding the message from the
person who reported this to me; please reply-to-all with any information.
S
12 matches
Mail list logo
