If I try to queue bulk urbs to an endpoint (2.5, uhci-hcd),
I rapidly get
host controller process error. something bad happened
followed by
host controller halted. very bad.
In order to track down what went wrong, I would like to
know which TD caused the host controller to barf, which
QH it is in,
On Mon, Jun 02, 2003 at 11:36:03AM -0700, David Brownell wrote:
Here's the non-inlined doc for the gadget API.
Please merge to Linus' tree.
Applied, thanks.
greg k-h
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The
On Wed, Jun 04, 2003 at 10:59:48AM +0200, Oliver Neukum wrote:
Hi,
you should not drop errors.
Applied, thanks.
greg k-h
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet. Designed
On Wed, Jun 04, 2003 at 10:28:11AM +0200, Oliver Neukum wrote:
Hi Greg,
this cuts out old cruft.
Please apply.
Applied, thanks. But now there's a compiler warning :)
greg k-h
---
This SF.net email is sponsored by: Etnus, makers of
On Tue, Jun 03, 2003 at 07:23:35PM -0400, Ben Collins wrote:
Ben, it looks like your patch broke something for USB keyboards, any
idea?
Yep, my patch killed hid-input from scanning HID_OUTPUT_REPORT's. Fixed
with this patch for 2.5.70+bk. I'll send one for 2.4.x in a few minutes.
Applied,
On Iau, 2003-06-05 at 00:02, [EMAIL PROTECTED] wrote:
I did mention in one of the other postings that multiple drivers were not
precluded. It would be perfectly valid to register multiple drivers for the
same VID/PID combination.
This would be the exception, but it would certainly
On Thu, Jun 05, 2003 at 01:20:15AM -0700, Greg KH wrote:
On Tue, Jun 03, 2003 at 07:33:52PM -0400, Ben Collins wrote:
Greg, if this doesn't apply to your 2.4.x tree, could you please send me
an updated tarball of your tree?
Applied, minus the BUG_ON() part.
Thanks.
Do you still want a
Greg KH wrote:
On Sat, May 31, 2003 at 07:01:56PM -0400, David T Hollis wrote:
Here you are. Would be happy to see it included mainline.
A few comments. First off, I need a 2.5 version first before I can add
it to 2.4
You need to follow the coding style rules found at
Hi Alan!
Yes, you are right, I used kernel 2.4.20. The last days I tried to reproduce
the problem with 2.4.21-rc3 but I failed. It 2.4.21-rc3 seems to be fixed in
that version. :-)
But I have another problem also with 2.4.21-rc3. The data I transmit to the
device gets corrupt. If I copy clean,
Hi,james
Sorry for disturbing you!I send this mail to u as I know from internet that
you can help me.
I can't find any definition of usb_ctrlrequest in my Linux kernel-source-2.
4.18.I searched in internet,they say it is in usb.h,But I can't find any of
the definition.
So I wonder if it is
Oliver Neukum wrote:
Am Donnerstag, 5. Juni 2003 22:16 schrieb David Brownell:
In short, usb_set_configuration() now does what
it's supposed to do: it changes the device config,
and all usbcore state depending on it.
Way cool.
A few points.
1. We need a special function for devices that just
Alan Stern wrote:
David:
Jun 5 20:53:25 ventus kernel: usb-storage: Attempting to get CSW...
Jun 5 20:53:25 ventus kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
Jun 5 20:53:55 ventus kernel: usb-storage: usb_storage_command_abort called
Jun 5 20:53:55 ventus kernel:
On Wed, 4 Jun 2003, Daniele Bellucci wrote:
Hi,
i've found some usb_buffer_alloc with GFP_KERNEL on in a probe function (kernel
2.5.70).
Since probe isn't ever called in process context... is that correct?
You have that exactly backwards. probe() is _always_ called in process
context, in
I'm not sure if this is a good idea. The config routine was adapted from
data provided by using the usb snoopy program in Windows, and from the
info I got from STM on the STV0680. You have check each step in a
certain way when configuring that chip. Greg, please do not apply this
patch until I
This is good. And quite interesting. It illustrates a problem with the
current SCSI code as well as a problem with the USB drivers.
By the way, Andras, was the device plugged directly into your computer's
USB port or did you use an intermediate hub?
On Tue, 3 Jun 2003, Major A wrote:
Jun
By the way, Andras, was the device plugged directly into your computer's
USB port or did you use an intermediate hub?
It was plugged into a USB 2.0 hub, but behaviour is exactly the same
when it's plugged in directly (well, maybe there is less stuff in the
logs, I haven't tried). Let me know
http://www.cnxp.com
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
On Tue, 3 Jun 2003, Greg KH wrote:
On Tue, Jun 03, 2003 at 04:59:31PM -0400, Alan Stern wrote:
I've been told it's not a good idea to put transfer buffers on the stack,
as that's not DMA-able on some architectures. Nevertheless, it's done in
the USB core (well, I found one place in hub.c
Network Associates WebShield SMTP V4.5 MR1a on GLOUTOON detected virus W32/[EMAIL
PROTECTED]
in attachment approved.pif from [EMAIL PROTECTED] and it was
Deleted and Quarantined.
---
This SF.net email is sponsored by: Etnus, makers of
Alan Stern wrote:
On Wed, 4 Jun 2003, Daniele Bellucci wrote:
Hi,
i've found some usb_buffer_alloc with GFP_KERNEL on in a probe function (kernel
2.5.70).
Since probe isn't ever called in process context... is that correct?
You have that exactly backwards. probe() is _always_ called in
Oliver Neukum wrote:
Hi,
going through the drivers, it seems that there are drivers which legitimately
use usb_set_configuration. It seems that we have to deal with it.
Some drivers, cdc-acm, -ether, really take the whole device and try
all configurations.
We should remove cdc-ether.c now, 2.5
Alan Stern wrote:
Does this need to be cleaned up?
Yes. I thought we had fixed all of this in the past, did we miss
something?
I think some fixes didn't get merged, for various reasons;
discussion about cache-incoherent DMA derailed a few.
This should fix things. I added buffer space (4 bytes)
Oliver Neukum wrote:
3. Usbfs is a security problem and needs filtering of control requests.
You can use it to set a device to an occupied address thereby crashing
any device.
The issue is a general one with control requests. SET_ADDRESS is
an interesting example, where pre-filtering ought to
On 4 Jun 2003 at 9:31, David Brownell wrote:
Oliver Neukum wrote:
Hi,
going through the drivers, it seems that there are drivers which
legitimately use usb_set_configuration. It seems that we have to
deal with it.
Some drivers, cdc-acm, -ether, really take the whole device and
On Wed, 4 Jun 2003, David Brownell wrote:
Reads good, but some comments on the GET_STATUS requests:
- Those timeouts should be HZ * USB_CTRL_GET_TIMEOUT, these
are excessively short.
- Naming is problematic: usb_*() suggests they're generic
and exported, but they're not.
--- 1.17/drivers/usb/core/hub.h Mon Oct 7 16:26:34 2002
+++ edited/drivers/usb/core/hub.h Wed Jun 4 10:37:30 2003
@@ -175,6 +175,10 @@
/* buffer for urb ... 1 bit each for hub and children, rounded up */
charbuffer[(USB_MAXCHILDREN + 1 + 7) / 8];
Alan Stern wrote:
David:
I got three messages from you all at once on this topic; I'll try to reply
to them all together.
There was a bit too much email on that topic for me to
read it as it happened, so I caught up all at once ... :)
On Mon, 2 Jun 2003, David Brownell wrote:
I'm not really
As for cdc-acm, I don't think it should be doing that. The code
that chooses a configuration can reasonably change its mind, for
example if there was a choice and no driver could bind to that
initial selection ... I don't think probe() should be allowed
to change configurations.
To
Alan Stern wrote:
On Wed, 4 Jun 2003, David Brownell wrote:
Reads good, but some comments on the GET_STATUS requests:
- Those timeouts should be HZ * USB_CTRL_GET_TIMEOUT, these
are excessively short.
- Naming is problematic: usb_*() suggests they're generic
and exported, but they're
[EMAIL PROTECTED] wrote:
... I don't think probe() should be allowed
to change configurations.
To the contrary, probe() is the only component in the system that
actually understands a device configuration. The higher-level code
is just blindly flipping through a list looking for
On 4 Jun 2003 at 11:14, David Brownell wrote:
[EMAIL PROTECTED] wrote:
... I don't think probe() should be allowed
to change configurations.
To the contrary, probe() is the only component in the system that
actually understands a device configuration. The higher-level code
On Wed, 4 Jun 2003 [EMAIL PROTECTED] wrote:
The only information the core has is the vendor and product IDs.
This is certainly not sufficient to determine which of multiple
configurations should be used / activated.
No, it's not.
It is the responsibility of the driver to take control of
On Wed, 4 Jun 2003, Oliver Neukum wrote:
It seems to me that this union needs a cacheline of its own for
noncoherent architectures. The rest looks good.
Oliver:
I would appreciate it if you (or anyone else) could post or provide a
pointer to a good discussion that explains all the important
[EMAIL PROTECTED] wrote:
On 4 Jun 2003 at 11:14, David Brownell wrote:
[EMAIL PROTECTED] wrote:
... I don't think probe() should be allowed
to change configurations.
To the contrary, probe() is the only component in the system that
actually understands a device configuration. The
On 4 Jun 2003 at 14:50, Alan Stern wrote:
On Wed, 4 Jun 2003 [EMAIL PROTECTED] wrote:
The only information the core has is the vendor and product IDs.
This is certainly not sufficient to determine which of multiple
configurations should be used / activated.
No, it's not.
It is
Alan Stern wrote:
And does this also mean that it's effectively impossible to dynamically
allocate any region smaller than a cacheline?
Only on processors with DMA-incoherent caches.
Unfortunately the only way to see if you're compiling for
such a system is to use architecture-specific
On Wed, 4 Jun 2003 [EMAIL PROTECTED] wrote:
I think we differ in philosophy. It's nice to think in terms of
tailoring a system by tweaking files here and there and loading or
removing individual modules, but that's not reality. We don't have
offices filled with professional system
David:
You last message in this thread gave me a lot to think about. I will
reply to a few items in context, then discuss the rest separately.
On Wed, 4 Jun 2003, David Brownell wrote:
Have a look at the EZ-USB doc to see the details, which
I fudged a bit. It initiates re-enumeration, I
On 4 Jun 2003 at 19:29, Leigh Bassett wrote:
On 4 Jun 2003 at 19:29, Oliver Neukum wrote:
As for cdc-acm, I don't think it should be doing that. The code
that chooses a configuration can reasonably change its mind, for
example if there was a choice and no driver could bind to that
I notice that the transfer buffer for the status URB is also part of
struct usb_hub, hence not cacheline-aligned. I also notice that the
contents of the buffer are never used; when a status change event occurs
the driver probes all the ports and the hub itself.
Would it be safe to eliminate
Actually, I kind of agree with you. The sad fact is that no one has come
up with a really satisfactory way of simplifying system administration
tasks for the user. The approach of the more popular operating systems is
to present a nice-looking user interface which works fine most of the
Alan Stern said:
On Wed, 4 Jun 2003, David Brownell wrote:
Have a look at the EZ-USB doc to see the details, which
I fudged a bit. It initiates re-enumeration, I forget
exactly how, and clearly can't lose power since that'd
mean the firmware got lost. (It's all detailed in one
of the
As for cdc-acm, I don't think it should be doing that. The code
that chooses a configuration can reasonably change its mind, for
example if there was a choice and no driver could bind to that
initial selection ... I don't think probe() should be allowed
to change configurations.
Hi,
you always set the same configuration. This makes doing so quite pointless.
Regards
Oliver
Pardon the interruption, but I don't believe you can arbitrarily remove device
writes just because they appear to be redundant.
I have worked with many hardware devices which required
On Mer, 2003-06-04 at 23:19, [EMAIL PROTECTED] wrote:
A device may have several interfaces in its configurations. Which driver
shall decide? And who shall decide which driver is to decide?
A good example of a manufactured problem. In my proposal, there is only one
driver for a given
[EMAIL PROTECTED] wrote:
On 4 Jun 2003 at 11:14, David Brownell wrote:
[EMAIL PROTECTED] wrote:
... I don't think probe() should be allowed
to change configurations.
To the contrary, probe() is the only component in the system that
actually understands a device
On Mer, 2003-06-04 at 23:19, [EMAIL PROTECTED] wrote:
A device may have several interfaces in its configurations. Which driver
shall decide? And who shall decide which driver is to decide?
A good example of a manufactured problem. In my proposal, there is only one
driver for a given
Am Mittwoch, 4. Juni 2003 20:58 schrieb Alan Stern:
On Wed, 4 Jun 2003, Oliver Neukum wrote:
It seems to me that this union needs a cacheline of its own for
noncoherent architectures. The rest looks good.
Oliver:
I would appreciate it if you (or anyone else) could post or provide a
You're looking at the question from the inside out, as an OS
developer. I think you could benefit from a reverse perspective,
from the standpoint of the peripheral manufacturers and driver
developers. They have very different concerns.
Just some thoughts.
Quite sensible thoughts.
What
Am Donnerstag, 5. Juni 2003 00:26 schrieb [EMAIL PROTECTED]:
Hi,
you always set the same configuration. This makes doing so quite
pointless.
Regards
Oliver
Pardon the interruption, but I don't believe you can arbitrarily remove
device writes just because they appear to be
I like the configuration driver idea, though I submit it should be an
integral part of the device driver rather than a separate component.
This is just based on a question of system maintenance over time.
It's much easier if you have one file responsible for one device.
Likely it'd be
A device may have several interfaces in its configurations. Which driver
shall decide? And who shall decide which driver is to decide?
A good example of a manufactured problem. In my proposal, there is only
one driver for a given device, so your questions disappear.
The number of device
I'm running a 2.5.70 kernel (BK from a day or so ago) on my Apple
titanium G4 powerbook, and it seems that the system stops polling the
root hub registers when I suspend and resume the machine. The symptom
is that nothing happens when I plug in a USB device after resuming.
It's very annoying
A device may have several interfaces in its configurations. Which driver
shall decide? And who shall decide which driver is to decide?
A good example of a manufactured problem. In my proposal, there is only
one driver for a given device, so your questions disappear.
The number of
Here's a patch to fix a race condition in usbdevfs. The fix is in hub.c
but the race is related to usbdevfs.
The race goes like this:
Process 1 (khubd) Process 2 (mount)
usb_hub_port_connect_change()
hub-children[port] = dev
usb_new_device()
On Thu, Jun 05, 2003, Johannes Erdfelt [EMAIL PROTECTED] wrote:
Here's a patch to fix a race condition in usbdevfs. The fix is in hub.c
but the race is related to usbdevfs.
The race goes like this:
Process 1 (khubd) Process 2 (mount)
usb_hub_port_connect_change()
56 matches
Mail list logo
