Bug 4358

Summary: some fullspeed ISO IN transfers don't work on usb-2.0 hub (ehci_hcd)
Product: Drivers Reporter: Ruben Jenster (rjenster)
Component: USBAssignee: David Brownell (dbrownell)
Status: REJECTED DOCUMENTED    
Severity: normal CC: greg, nacc
Priority: P2    
Hardware: i386   
OS: Linux   
Kernel Version: 2.6.9, 2.6.10, 2.6.11 Subsystem:
Regression: --- Bisected commit-id:
Bug Depends on:    
Bug Blocks: 5089    
Attachments: karsten's split iso fixes
lspci.hub
lspci.nohub
lsusb.hub
lsusb.nohub
updated split iso fixes

Description Ruben Jenster 2005-03-17 08:31:22 UTC
Distribution:Gentoo    
Hardware Environment:AMD Athlon(tm) XP 2200+; Leadtek K7NCR-Pro (nforce2)  
Software Environment:  
Problem Description: When pluggin a bluetooth dongle directly to the usb-2.0  
connector of the mainboard it works perfecly. This also applies if the dongle  
will be attached to a usb 1.1 hub. But attaching the dongle to a usb-2.0 hub  
doesn't work.  
Steps to reproduce: plug in a usb bluetooth dongle into a usb-2.0 hub ( DLINK  
DUB-H4). This will lead to the following error:  
usb 3-3.1: new full speed USB device using ehci_hcd and address 5  
Bluetooth: Core ver 2.7  
NET: Registered protocol family 31  
Bluetooth: HCI device and connection manager initialized  
hci_usb: Unknown symbol hci_free_dev  
hci_usb: Unknown symbol hci_alloc_dev  
hci_usb: Unknown symbol hci_unregister_dev  
hci_usb: Unknown symbol hci_register_dev  
Bluetooth: HCI socket layer initialized  
Bluetooth: HCI USB driver ver 2.8  
usbcore: registered new driver hci_usb  
Bluetooth: L2CAP ver 2.7  
Bluetooth: L2CAP socket layer initialized  
Bluetooth: RFCOMM ver 1.5  
Bluetooth: RFCOMM socket layer initialized  
Bluetooth: RFCOMM TTY layer initialized  
hci_cmd_task: hci0 command tx timeout  
usb 3-3.1: USB disconnect, address 5  
usb 3-3.1: new full speed USB device using ehci_hcd and address 6  
hci_usb_isoc_rx_submit: hci0 isoc rx submit failed urb cdc6ee14 err -38  
hci_usb_isoc_rx_submit: hci0 isoc rx submit failed urb cdc6ee14 err -38  
  
When directly attached to the mainboard:  
usb 2-3: new full speed USB device using ohci_hcd and address 4
Comment 1 Nishanth Aravamudan 2005-03-18 11:36:26 UTC
Well, taking a quick look at that output: ehci_hcd is for usb 2.0 and ohci_hcd
is for usb 1.1. Which means that when the dongle works, it is connected as a 1.1
device. Are you sure all the hardware actually is usb 2.0 and not just usb 2.0
compliant? Does the Bluetooth layer come up with the successful connect? Full
output please.

lspci -vvv, lsusb -vvv with success and failure pleaes (as attachments).

Thanks,
Nish
Comment 2 Greg Kroah-Hartman 2005-03-21 23:29:09 UTC
Lots of odd devices do not work when plugged into a usb 2.0 hub, this is 
a known issue with the ehci driver, sorry.

I'll reassign it to David and let him decide if it's worth fixing one of these
days :)
Comment 3 David Brownell 2005-03-22 01:16:23 UTC
Created attachment 4768 [details]
karsten's split iso fixes

What do you mean, "one of these days"?	;)

First problem:	that kernel's not configured with support
for full speed ISO transactions in EHCI.  That's shown by
the particular "-38" (-ENOSYS) status code.  User error.

Second problem:  the reason that support is experimental
and not enabled by default is that there are some bugs in
it that I can't reproduce any more (but some others can).
Some recently posted patches may be able to help, if just
enabling that support in your kernel doesn't resolve this.

Karsten's patches are attached, at least the ones that seem
obviously correct.  He pointed out another issue, but his
patch there was wrong so I don't include it here.
Comment 4 Ruben Jenster 2005-03-22 07:50:04 UTC
I enabled full speed ISO transactions in EHCI. Other errorcode same problem.    
Also the patch doesn't help. Applied it against 2.6.12-rc1.  
Now I get the following error:  
   
sb 3-3.1: new full speed USB device using ehci_hcd and address 6   
ACPI: No ACPI bus support for 3-3.1   
ACPI: No ACPI bus support for 3-3.1:1.0   
ACPI: No ACPI bus support for 3-3.1:1.1   
ACPI: No ACPI bus support for 3-3.1:1.2   
hci_usb_isoc_rx_submit: hci0 isoc rx submit failed urb d2021414 err -12   
hci_usb_isoc_rx_submit: hci0 isoc rx submit failed urb d2021414 err -12   
   
As requested I added the output of lsusb and lspci. 
*.nohub -> dongle is direct attached to the mainboard (success) 
*.hub -> dongle is attached to the usb 2.0 hub (failure) 
Comment 5 Ruben Jenster 2005-03-22 07:51:19 UTC
Created attachment 4775 [details]
lspci.hub
Comment 6 Ruben Jenster 2005-03-22 07:52:03 UTC
Created attachment 4776 [details]
lspci.nohub
Comment 7 Ruben Jenster 2005-03-22 07:52:46 UTC
Created attachment 4777 [details]
lsusb.hub
Comment 8 Ruben Jenster 2005-03-22 07:53:18 UTC
Created attachment 4778 [details]
lsusb.nohub
Comment 9 Ruben Jenster 2005-03-22 08:05:53 UTC
Want to point to an message at gmane where someone has nearly the same problem: 
http://article.gmane.org/gmane.linux.bluez.user/6171/match=ehci 
Comment 10 David Brownell 2005-03-22 11:10:52 UTC
Created attachment 4779 [details]
updated split iso fixes

This is the same as the previous patch, except that it
resolves the "buf1" issue previously noted as unfixed.
Comment 11 Ruben Jenster 2005-03-22 11:56:43 UTC
Tried the second patch, but problem still exists. 
Can I help you out with some additional information / testing? 
Comment 12 Ruben Jenster 2005-03-22 11:58:32 UTC
Well the error looks somehow different: 
 
Bluetooth: L2CAP ver 2.7 
Bluetooth: L2CAP socket layer initialized 
hci_usb_isoc_rx_submit: hci0 isoc rx submit failed urb dc5c4a14 err -12 
hci_usb_isoc_rx_submit: hci0 isoc rx submit failed urb dc5c4a14 err -12 
Bluetooth: RFCOMM ver 1.5 
Bluetooth: RFCOMM socket layer initialized 
Bluetooth: RFCOMM TTY layer initialized 
 
Comment 13 David Brownell 2005-03-22 16:36:50 UTC
Let's see.  The GMANE report is also user error (didn't 
configure the necessary driver support). 
 
The "err -12" is "-ENOMEM".  Compile with CONFIG_USB_DEBUG 
and the kernel dmesg output should explain in more detail. 
Except for a few cases in sitd_urb_transaction() ... where 
either [a] kmalloc failed, or [b] neither the stream's own 
freelist nor the dma pool has enough free descriptors. 
 
I bet you're hitting the FIXME that's at the top of 
sitd_submit() in drivers/usb/host/ehci-sched.c ... if 
you're feeling brave, just comment out that "if" statement 
that fails all split IN transfers.  No guarantees that it 
will behave... 
 
Comment 14 Ruben Jenster 2005-03-22 19:59:10 UTC
OK,  commenting out that region works I can connect to my headset but no sound 
is transmitted. Seems that sco support is broken via the usb-2.0 hub. 
How can I fix that? 
  
hub 3-3:1.0: state 5 ports 4 chg 0000 evt 0002  
hub 3-3:1.0: port 1, status 0100, change 0001, 12 Mb/s  
usb 3-3.1: USB disconnect, address 5  
usb 3-3.1: usb_disable_device nuking all URBs  
usb 3-3.1: unlink qh1-0601/c4487200 start 0 [8/16 us]  
ehci_hcd 0000:00:02.2: shutdown urb c92e5b74 pipe 40408580 ep1in-intr  
ehci_hcd 0000:00:02.2: shutdown urb dea96454 pipe c0410580 ep2in-bulk  
ehci_hcd 0000:00:02.2: shutdown urb c63e7414 pipe 00418580 ep3in-iso  
ehci_hcd 0000:00:02.2: shutdown urb cf3bca14 pipe 00418580 ep3in-iso  
usb 3-3.1: unregistering interface 3-3.1:1.0  
usb 3-3.1:1.0: hotplug  
usb 3-3.1: unregistering interface 3-3.1:1.1  
usb 3-3.1:1.1: hotplug  
usb 3-3.1: unregistering interface 3-3.1:1.2  
usb 3-3.1:1.2: hotplug  
usb 3-3.1: unregistering device  
usb 3-3.1: hotplug  
hub 3-3:1.0: debounce: port 1: total 100ms stable 100ms status 0x100  
hub 3-3:1.0: state 5 ports 4 chg 0000 evt 0002  
hub 3-3:1.0: port 1, status 0101, change 0001, 12 Mb/s  
hub 3-3:1.0: debounce: port 1: total 100ms stable 100ms status 0x101  
hub 3-3:1.0: port 1 not reset yet, waiting 10ms  
usb 3-3.1: new full speed USB device using ehci_hcd and address 6  
hub 3-3:1.0: port 1 not reset yet, waiting 10ms  
usb 3-3.1: skipped 1 descriptor after interface  
usb 3-3.1: new device strings: Mfr=0, Product=0, SerialNumber=0  
usb 3-3.1: hotplug  
ACPI: No ACPI bus support for 3-3.1  
usb 3-3.1: adding 3-3.1:1.0 (config #1, interface 0)  
usb 3-3.1:1.0: hotplug  
hci_usb 3-3.1:1.0: usb_probe_interface  
hci_usb 3-3.1:1.0: usb_probe_interface - got id  
ACPI: No ACPI bus support for 3-3.1:1.0  
usb 3-3.1: adding 3-3.1:1.1 (config #1, interface 1)  
usb 3-3.1:1.1: hotplug  
ACPI: No ACPI bus support for 3-3.1:1.1  
usb 3-3.1: adding 3-3.1:1.2 (config #1, interface 2)  
usb 3-3.1:1.2: hotplug  
hci_usb 3-3.1:1.2: usb_probe_interface  
hci_usb 3-3.1:1.2: usb_probe_interface - got id  
ACPI: No ACPI bus support for 3-3.1:1.2  
usb 3-3.1: link qh1-0601/c4487200 start 0 [8/16 us]  
  
Comment 15 David Brownell 2005-04-04 13:19:20 UTC
I'd expect that isochronous OUT transfers (e.g. to speakers) 
should work in 2.6.12-rc2 through a transaction translator; 
please try this and let me know if it works. 
 
The IN transfers (e.g. from microphone) may not work yet 
for you. 
Comment 16 Ruben Jenster 2005-04-07 17:30:58 UTC
Sorry for delay. (Cause I use reiser4 and rc2-mm1 is not working I had to patch 
the kernel manually) 
It was worth the work. It's working now, even the mic.  
Yeah, no more crawling under the desk :-) 
 
Regards 
 
Ruben 
Comment 17 Ruben Jenster 2005-04-08 11:38:50 UTC
Sorry I have to reopen the bug.  
I recognized that when ehci_hcd is loaded the sco audio transfer still is not  
possible.  
 
When pluggin the usb bluetooth dongle direcly to the mainboard  
the hci_usb driver uses the ohci host, it doesn't matter that ehci_hcd is 
loaded. But when pluggin it to the usb hub and ehci_hcd is loaded hci_usb uses  
the ehci host. 
 
usb 1-3: new full speed USB device using ohci_hcd and address 13 
usb 1-3: USB disconnect, address 13 
 
usb 3-4.1: new full speed USB device using ehci_hcd and address 7 
usb 3-4.1: USB disconnect, address 7 
 
When unloading ehci_hcd before plugin the dongle to the usb hub the ohci host 
is used. It seems that I have accidentially unloaded ehci_hcd and then plugged  
in the dongle - therefore the success message.  
 
Comment 18 Andrew Morton 2005-05-25 16:12:52 UTC
It seems that we still have some bug here, but it's not clear what it is.

Could you please retest 2.6.12-rc5 and if it still has problems, attempt to
redescribe them?

Thanks.
Comment 19 David Brownell 2005-06-15 08:13:32 UTC
Full speed iso IN transfers are still not expected to work 
very well. 
 
Someone would have to contribute a patch ... meanwhile, 
do please remember you're complaining about a feature that's 
marked clearly as EXPERIMENTAL.   
Comment 20 David Brownell 2005-07-29 13:12:33 UTC
Changing the title to better reflect the root cause. 
 
Someone else is going to have to invest the time to 
fix this, but I have no problem with leaving a bug 
open to mark the fact that this particular EXPERIMENTAL 
code isn't yet ready to turn on by default. 
 
Comment 21 Marcus Better 2005-09-02 02:35:23 UTC
I can only confirm that this bug persists in Debian kernel 2.6.12-5 (which is 
based on mainline 2.6.12.5, I believe). 
 
Comment 22 Greg Kroah-Hartman 2006-03-06 10:38:03 UTC
Am just going to close it, as it is dealing with EXPERIMENTAL code at 
this stage...