Bug 9871
| Summary: | hci0 SCO packet for unknown connection handle 1 | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Adam Szalkowski (adam) |
| Component: | Network | Assignee: | Marcel Holtmann (marcel) |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | normal | CC: | akpm, alan, brian, brian, cavedon, diazluis+kernel, hidave.darkstar, johan.hedberg, kernel, n.laradji, someone |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.31 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Attachments: |
Full hcidump
syslog output New hcidump hcidump -X -V against comment #10 |
||
|
Description
Adam Szalkowski
2008-02-01 11:30:17 UTC
Created attachment 14677 [details]
Full hcidump
Created attachment 14678 [details]
syslog output
Marcel, this is a fairly recent regression. Having the "hcidump -X -V" would help a lot. Otherwise I have to decide the event content by hand which I not fancy at all. Created attachment 14679 [details]
New hcidump
I have this problem and bisected it back to the following: commit b6a0dc822497e1c0b9e8c4add270cc27fce48454 Author: Marcel Holtmann <marcel@holtmann.org> Date: Sat Oct 20 14:55:10 2007 +0200 [Bluetooth] Add support for handling simple eSCO links With the Bluetooth 1.2 specification the Extended SCO feature for better audio connections was introduced. So far the Bluetooth core wasn't able to handle any eSCO connections correctly. This patch adds simple eSCO support while keeping backward compatibility with older devices. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Reverting this patch gets things working. My commit introduces a regression and we are currently figuring out how to fix it. We do have a full patch that restores full eSCO handling, but some have seen oopses with it. As an alternative we are going with a one-line fix that will default to SCO while leaving the full eSCO infrastructure in place. Actually, when I tried that patch with a vanilla kernel, I was never able to reproduce the oops. I only got that when I used the patch on the Ubuntu Hardy kernel. But there was another problem. With that patch applied, I would frequently (but not always) get loud static instead of the correct audio. With eSCO completely disabled, I never get that static problem. Hi,
i seem to getting same issue:
>SCO Data: handle 45 flags 0x00 dlen 48.
>SCO Data: handle 45 flags 0x00 dlen 48.
>SCO Data: handle 45 flags 0x00 dlen 48.
i didn't really understand, what patch to apply !. i am using bluez 4.32.
kindly let me know.
thanks
I now tried with 2.6.21 kernel and bluez 4.25. i get flood of >SCO messages when i do headset.Play. i have attached the hcidump -X -V. any pointers about which way should i go, or try new combination. would be great as i am stuck. if i call aplay or arecord. i get error in bluetoothd. (this is irrespective of whether i call headset.play or not) Accepted new client connection on unix socket (fd=25) Audio API: BT_REQUEST <- BT_GET_CAPABILITIES Invalid message: length mismatch. thanks. Created attachment 20530 [details] hcidump -X -V against comment #10 Against comment #10 flood of SCO i get 45 and 46 handle error like: " hci_scodata_packet: hci0 SCO packet for unknown connection handle 45 " with disable_esco=1 i hear the headset beep, but then i get silence... Ubuntu 2.6.27-11-generic I also experience this message: [146784.785660] hci_scodata_packet: hci0 SCO packet for unknown connection handle 0 [146784.793077] hci_scodata_packet: hci0 SCO packet for unknown connection handle 0 [146784.800516] hci_scodata_packet: hci0 SCO packet for unknown connection handle 0 [146784.807918] hci_scodata_packet: hci0 SCO packet for unknown connection handle 0 [146784.815363] hci_scodata_packet: hci0 SCO packet for unknown connection handle 0 [146784.822767] hci_scodata_packet: hci0 SCO packet for unknown connection handle 0 [146784.830172] hci_scodata_packet: hci0 SCO packet for unknown connection handle 0 on Ubuntu's Karmic kernel 2.6.31-17-generic. I also experience what seems to be a functioning headset with the exception that I don't hear anything in it except the beep when the audio stream stops. *** Bug 10270 has been marked as a duplicate of this bug. *** |