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

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 :)

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.

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) 

Created attachment 4775 [details]
lspci.hub

Created attachment 4776 [details]
lspci.nohub

Created attachment 4777 [details]
lsusb.hub

Created attachment 4778 [details]
lsusb.nohub

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 

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.

Tried the second patch, but problem still exists. 
Can I help you out with some additional information / testing? 

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 
 

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... 
 

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]  
  

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. 

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 

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.  
 

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.

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.   

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. 
 

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). 
 

Am just going to close it, as it is dealing with EXPERIMENTAL code at 
this stage...