syslog is flooded with messages after connecting bluetooth usb dongle

[Chris Vigelius]

Whenever I insert my Bluetooth USB dongle, manufactured by Vivanco (Model 18031, FCC-ID NV6-CS8024), the syslog is flooded with messages

> hci_scodata_packet: hci0 SCO packet for unknown connection handle 0

There are about 500 of these messages generated EACH SECOND, causing a high load (and lots of wasted disk space) on my system (which is a Thinkpad R40 running dapper, but the same problem also exists in breezy). This happens also if the system is booted from dapper flight 5 live CD, so this is no configuration issue.

Since the Vivanco dongle is -at least here in Germany- sold in large volumes by retailers like Media Markt, and simply plugging it in causes the system load go up to 2 just for processing the log messages, therefore making the system slow and almost unusable, I believe this should be fixed with some priority.

I have also posted this to the development and users mailing list of the module in question (bluez), but to no avail (yet):

http://sourceforge.net/mailarchive/message.php?msg_id=15355967
http://sourceforge.net/mailarchive/message.php?msg_id=15335499

Note: the original reporter indicated the bug was in package 'linux-image-2.6.15-19-386'; however, that package was not published in Ubuntu.

[Matthew Lange (matthewlange)]

Set to Major based on potential impact, but still unconformed. Can we get anyone else who has had a similar experience?

[Manuel López-Ibáñez (manuellopezibanez)]

guessing package

[Alexander Heß (launchpad-alexanderhess)]

I have exactly the same problem with exactly the same dongle.

Running 2.6.15-25-386 (Dapper 6.06)

[Uwe Menges (uwe-menges)]

Same problem with the exactly same dongle.

lsusb: Bus 003 Device 004: ID 0400:080a National Semiconductor Corp.

Running 2.6.15-26-686 #1 SMP PREEMPT Fri Jul 7 19:48:22 UTC 2006 (dapper 6.06).

[Holger H. Wenner (h-wenner)]

I´m having the same problem.
My system: 2.6.15-27-386

lsusb:

Bus 001 Device 002: ID 0846:4240 NetGear, Inc. WG111 WiFi (v2)
Bus 001 Device 001: ID 0000:0000
Bus 002 Device 005: ID 0400:080a National Semiconductor Corp.
Bus 002 Device 004: ID 03f0:7204 Hewlett-Packard DeskJet 36xx
Bus 002 Device 003: ID 0c45:2060 Microdia
Bus 002 Device 002: ID 04b4:6560 Cypress Semiconductor Corp. CY7C65640 USB-2.0 "TetraHub"Bus 002 Device 001: ID 0000:0000

[Caroline Ford (secretlondon)]

Rejecting bug filed on Ubuntu, as bug filed under linux-source-2.6.15 has been fixed.

[Timo Aaltonen (tjaalton)]

Going through "Fix Committed" bugs that are old. What is the status of this one?

[Uwe Menges (uwe-menges)]

The bug still exists in 2.6.15-28-686.
It is mildened in the way that the syslog is no longer really flooded by a seemingly new printk feature, so syslog says now:

Mar 30 16:20:23 nx7000 kernel: [17180739.048000] Bluetooth: HCI USB driver ver 2.9
Mar 30 16:20:23 nx7000 kernel: [17180739.052000] usbcore: registered new driver hci_usb
Mar 30 16:20:28 nx7000 kernel: [17180744.080000] printk: 25040 messages suppressed.
Mar 30 16:20:33 nx7000 kernel: [17180749.076000] printk: 24999 messages suppressed.
Mar 30 16:20:38 nx7000 kernel: [17180754.076000] printk: 24999 messages suppressed.
Mar 30 16:20:40 nx7000 kernel: [17180756.292000] usb 3-1: USB disconnect, address 3

I don't understand why this bug is 'rejected' on Ubuntu just because it is fixed upstream, from my user's perspective the bug should be open unless it's really fixed for the "Ubuntu 6.06.1 LTS" users.

[mirshafie (mirshafie)]

I apparently have the same problem. I have a CNet CBD-120 Bluetooth V2.0 USB Adapter. My syslog and kern.log is flooded with this type of messages:

Jul 2 07:39:13 mirshafie kernel: [144467.293717] usb 7-4: clear tt 1 (9282) error -71

[DeusEx (boulevard-of-stars)]

Same problem here :

[ 449.245982] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
[ 449.246224] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
[ 449.255678] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
[ 449.255919] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
[ 449.256033] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
[ 449.265619] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
[ 449.265734] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
[ 449.265847] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
[ 449.265960] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
[ 449.275698] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
[ 449.275944] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
[ 449.276057] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
[ 449.285550] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
[ 449.285665] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
[ 449.285778] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92

Repeated many and many times (what i reported is just a part).

[Dave Pucknell (dave-pucknell-deactivatedaccount)]

Getting the same error.

>lsusb

Bus 001 Device 004: ID 0e5e:6622

>uname -a
Linux dave-laptop 2.6.22-9-generic #1 SMP Wed Aug 1 17:31:10 GMT 2007 i686 GNU/Linux

>dmesg
-----SNIP----
[37829.836000] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
[37829.836000] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
[37829.836000] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
[37829.844000] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
[37829.844000] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
----SNIP-----

[Sarangan Thuraisingham (tvsaru)]

This bug exists in feisty as well here is the output of the shell commands I ran

saru@amma:~$ lsusb
Bus 002 Device 001: ID 0000:0000
Bus 005 Device 001: ID 0000:0000
Bus 004 Device 001: ID 0000:0000
Bus 003 Device 004: ID 1131:1001 Integrated System Solution Corp. KY-BT100 Bluetooth Adapter
Bus 003 Device 001: ID 0000:0000
Bus 001 Device 002: ID 04b4:0001 Cypress Semiconductor Corp. Mouse
Bus 001 Device 001: ID 0000:0000
saru@amma:~$ dmesg|tail
[ 4451.717922] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
[ 4451.717934] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
[ 4451.717940] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
....... thousands of lines like this

But the card works as I can scan and find my mobile:
saru@amma:~$ hcitool scan
Scanning ...
        XX:XX:XX:XX:XX:XX Saru's Nokia N70

[DeusEx (boulevard-of-stars)]

Since the device works for everyone here, wouldnt be possible to manage on
the syslog daemon and configure it to ignore such messages? Does anyone know
how to do it? I think i found something like this somewhere, but can't
remember where.

[Uwe Menges (uwe-menges)]

I think filtering these messages would be possible using e.g. the syslog-ng logging daemon. But just filtering the log is no clean solution, as this would spend lots of CPU cycles on generating and filtering syslog messages.

As the upstream bug I filed (http://bugzilla.kernel.org/show_bug.cgi?id=6833) was fixed by just adding one line with the device's ID into the drivers/bluetooth/hci_usb.c source file, you could add the fix for your device and recompile the module.

As there seem to be lots of different devices affected, upstream/ubuntu/whoever could maintain an ever-growing list of IDs in the C source file, or upstream/ubuntu/whoever could maybe provide some means to extend such a blacklist without the need for recompilation of the module, e.g. by a /etc/modprobe.d/ or /sys/module/usbcore/ config file.

[Chuck Short (zulcss)]

For those who are still having this problem, can you attach the full output of lsusb -v. To this bug Ill see If I can get a fix in for gutsy.

Thanks
chuck

[DeusEx (boulevard-of-stars)]

Sorry, just read your message. Was on vacation ;-)

Attached you can find my lsusb -v
Thanks a lot

Il giorno lun, 06/08/2007 alle 14.30 +0000, Chuck Short ha scritto:
> For those who are still having this problem, can you attach the full
> output of lsusb -v. To this bug Ill see If I can get a fix in for gutsy.
>
> Thanks
> chuck
>

~$ sudo lsusb -v

Bus 003 Device 001: ID 0000:0000
Device Descriptor:
  bLength 18
  bDescriptorType 1
  bcdUSB 2.00
  bDeviceClass 9 Hub
  bDeviceSubClass 0 Unused
  bDeviceProtocol 1 Single TT
  bMaxPacketSize0 64
  idVendor 0x0000
  idProduct 0x0000
  bcdDevice 2.06
  iManufacturer 3 Linux 2.6.20-16-generic ehci_hcd
  iProduct 2 EHCI Host Controller
  iSerial 1 0000:00:02.2
  bNumConfigurations 1
  Configuration Descriptor:
    bLength 9
    bDescriptorType 2
    wTotalLength 25
    bNumInterfaces 1
    bConfigurationValue 1
    iConfiguration 0
    bmAttributes 0xe0
      Self Powered
      Remote Wakeup
    MaxPower 0mA
    Interface Descriptor:
      bLength 9
      bDescriptorType 4
      bInterfaceNumber 0
      bAlternateSetting 0
      bNumEndpoints 1
      bInterfaceClass 9 Hub
      bInterfaceSubClass 0 Unused
      bInterfaceProtocol 0 Full speed hub
      iInterface 0
      Endpoint Descriptor:
        bLength 7
        bDescriptorType 5
        bEndpointAddress 0x81 EP 1 IN
        bmAttributes 3
          Transfer Type Interrupt
          Synch Type None
          Usage Type Data
        wMaxPacketSize 0x0004 1x 4 bytes
        bInterval 12
Hub Descriptor:
  bLength 11
  bDescriptorType 41
  nNbrPorts 8
  wHubCharacteristic 0x000a
    No power switching (usb 1.0)
    Per-port overcurrent protection
    TT think time 8 FS bits
  bPwrOn2PwrGood 10 * 2 milli seconds
  bHubContrCurrent 0 milli Ampere
  DeviceRemovable 0x00 0x00
  PortPwrCtrlMask 0xff 0xff
 Hub Port Status:
   Port 1: 0000.0100 power
   Port 2: 0000.0100 power
   Port 3: 0000.0100 power
   Port 4: 0000.0100 power
   Port 5: 0000.0100 power
   Port 6: 0000.0000
   Port 7: 0000.0000
   Port 8: 0000.0000
Device Status: 0x0003
  Self Powered
  Remote Wakeup Enabled

Bus 002 Device 008: ID 1131:1001 Integrated System Solution Corp. KY-BT100 Bluetooth Adapter
Device Descriptor:
  bLength 18
  bDescriptorType 1
  bcdUSB 1.10
  bDeviceClass 224 Wireless
  bDeviceSubClass 1 Radio Frequency
  bDeviceProtocol 1 Bluetooth
  bMaxPacketSize0 16
  idVendor 0x1131 Integrated System Solution Corp.
  idProduct 0x1001 KY-BT100 Bluetooth Adapter
  bcdDevice 1.34
  iManufacturer 0
  iProduct 0
  iSerial 0
  bNumConfigurations 1
  Configuration Descriptor:
   ...

[japuzzo (japuzzo)]

have the same issue with:

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=7.04
DISTRIB_CODENAME=feisty
DISTRIB_DESCRIPTION="Ubuntu 7.04"
Kernel: 2.6.20-16-lowlatency
Platform: x86_64

dmesg is full of:
[107224.059239] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
[107224.059241] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
[107224.069222] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
[107224.069229] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
[107224.069232] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
[107224.069235] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92

sudo lsusb -v

Bus 002 Device 001: ID 0000:0000
Device Descriptor:
  bLength 18
  bDescriptorType 1
  bcdUSB 2.00
  bDeviceClass 9 Hub
  bDeviceSubClass 0 Unused
  bDeviceProtocol 1 Single TT
  bMaxPacketSize0 64
  idVendor 0x0000
  idProduct 0x0000
  bcdDevice 2.06
  iManufacturer 3 Linux 2.6.20-16-lowlatency ehci_hcd
  iProduct 2 EHCI Host Controller
  iSerial 1 0000:00:02.1
  bNumConfigurations 1
  Configuration Descriptor:
    bLength 9
    bDescriptorType 2
    wTotalLength 25
    bNumInterfaces 1
    bConfigurationValue 1
    iConfiguration 0
    bmAttributes 0xe0
      Self Powered
      Remote Wakeup
    MaxPower 0mA
    Interface Descriptor:
      bLength 9
      bDescriptorType 4
      bInterfaceNumber 0
      bAlternateSetting 0
      bNumEndpoints 1
      bInterfaceClass 9 Hub
      bInterfaceSubClass 0 Unused
      bInterfaceProtocol 0 Full speed hub
      iInterface 0
      Endpoint Descriptor:
        bLength 7
        bDescriptorType 5
        bEndpointAddress 0x81 EP 1 IN
        bmAttributes 3
          Transfer Type Interrupt
          Synch Type None
          Usage Type Data
        wMaxPacketSize 0x0004 1x 4 bytes
        bInterval 12
Hub Descriptor:
  bLength 11
  bDescriptorType 41
  nNbrPorts 10
  wHubCharacteristic 0x000a
    No power switching (usb 1.0)
    Per-port overcurrent protection
    TT think time 8 FS bits
  bPwrOn2PwrGood 10 * 2 milli seconds
  bHubContrCurrent 0 milli Ampere
  DeviceRemovable 0x00 0x00
  PortPwrCtrlMask 0xff 0xff
 Hub Port Status:
   Port 1: 0000.0100 power
   Port 2: 0000.0000
   Port 3: 0000.0100 power
   Port 4: 0000.0100 power
   Port 5: 0000.0100 power
   Port 6: 0000.0100 power
   Port 7: 0000.0100 power
   Port 8: 0000.0100 power
   Port 9: 0000.0100 power
   Port 10: 0000.0000
Device Status: 0x0003
  Self Powered
  Remote Wakeup Enabled

Bus 001 Device 006: ID 0e5e:6622
Device Descriptor:
  bLength 18
  bDescriptorType 1
  bcdUSB 1.10
  bDeviceClass 224 Wireless
  bDeviceSubClass 1 Radio F...

[Michał Straszak (mstraszak)]

I've just upgraded to gutsy and I'm still getting the same flooding messages as above. Any chances to fix it before the gutsy final version?
I don't attach lsusb -v, since it's the same device as japuzzo's one (0e5e:6622).

[rivode (bugs-launchpad-net-rivode)]

I have the same thing with 0e5e:6622 in gutsy. The output from lsusb is attached.

$ dmesg
[11193.473686] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
[11193.483659] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
[11193.483670] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
[11193.483673] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92

$ uname -srmo
Linux 2.6.22-14-386 i686 GNU/Linux

[Uwe Menges (uwe-menges)]

Somehow the upstream fix has not lead to progress in Ubuntu.

[quixote_arg (tulsidas)]

Linux mobigreg 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux

ID 1131:1001 Integrated System Solution Corp. KY-BT100 Bluetooth Adapter

attached lsusb -v

[Jonah Duckles (jonahd)]

Seeing the same problem.

Attached is my lsusb -v

uname -srmo
Linux 2.6.22-14-generic i686 GNU/Linux

dmesg |tail
[426929.428099] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
[426929.428102] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
[426929.438077] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92

[Passeli (passeli)]

I have same problem in gutsy, causing massive sized syslog and kern.log files.

uname -srmo
Linux 2.6.22-14-generic i686 GNU/Linux

dmesg |tail
[ 443.549732] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
[ 443.549735] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
[ 443.549738] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
[ 443.559712] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92

Manufacturer seems to be same Integrated System Solution Corp. But adapter type is ES-388 (from package). In the user manual is says for the type BT Dongle-IS1002N Horus Module.

[Passeli (passeli)]

I have same problem in gutsy, causing massive sized syslog and kern.log files.

uname -srmo
Linux 2.6.22-14-generic i686 GNU/Linux

dmesg |tail
[ 443.549732] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
[ 443.549735] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
[ 443.549738] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
[ 443.559712] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92

Manufacturer seems to be same Integrated System Solution Corp. But adapter type is ES-388 (from package). In the user manual is says for the type BT Dongle-IS1002N Horus Module.

[rivode (bugs-launchpad-net-rivode)]

These messages can be filtered out of syslog. The basic instructions are here:

http://www.giacintosblog.splinder.com/post/15040472/Ubuntu%3A+Palliativo+per+il+bug+

You need to install syslog-ng, and add to /etc/syslog-ng/syslog-ng.conf:

filter f_bluetooth_error {
    facility(kern) and match("hci_scodata_packet");
};

and change these lines:

filter f_auth { facility(auth, authpriv) and not filter(f_bluetooth_error); };
filter f_syslog { not facility(auth, authpriv) and not filter(f_bluetooth_error); };
filter f_kern { facility(kern) and not filter(f_bluetooth_error); };

It keeps the log lines out of /var/log, but they still show up with dmesg.

[Alex Tanner (habitaddict)]

I have the same problem with my "Blue Soleil" Bluetooth dongle (Vendor:Device = 0e5e:6622). I've found you can suppress generation of the messages by changing the "isoc" parameter passed to the "hci_usb" kernel module. Depending on distro, you might put "hci_usb isoc=<new value>" in '/etc/modules' or "options hci_usb isoc=<new value>". For me, "isoc=3" causes "connection handle 92" errors. This method can only be considered a workaround, as non-optimal "isoc" values may have undesirable effects on hardware. I think the problem would be best cured by the designers of the "hci_usb" module consigning the detection of "connection handle" errors to the debug mode of that module.

On my system, "modinfo hci_usb" shows, in the "description" field, that I am using "Bluetooth HCI USB driver ver 2.9". It is THIS version, not the kernel version that is important in this "bug", as "hci_usb" is spewing out messages to the syslog. Just for the record, my kernel version is 2.6.16.13

[Alex Tanner (habitaddict)]

Correction: In my last post, I meant to specify that the line "options hci_usb isoc=<new value>", if used, should be added to '/etc/modprobe.conf'.

[Alex Tanner (habitaddict)]

Here is the output of running "lsusb -v" on my machine, with the BlueSoleil USB bluetooth dongle (Vendor:Device 0e5e:6622) inserted.

[graz848 (c-graz)]

Same here. Gutsy 7.10, kernel 2.6.22-14-generic, dongle recognized as 0e5e:6622 (it is a phonix PHB410), and the syslog continues giving messages such as
[19325.944260] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
[19325.944265] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
[19325.944268] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
[19325.944271] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
[19325.954246] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
[19325.954251] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
[19325.954254] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
and so on and so on... until the usb dongle is unplugged.
Gnome doesn't show either the Bluetooth applet when the dongle is plugged in, like it does instead on my laptop. The bluetooth sending/receiving files and other services work as well anyway.
Hope in a fix soon.
Bye

[Bernt (bernt-hullen)]

Here the same problem with Linux ubuntu 2.6.24 (gutsy 7.10)
a short time after booting all is ok, but then
[ 487.936916] hci_scodata_packet: hci0 SCO packet for unknown connection handle 46
[ 487.936923] hci_scodata_packet: hci0 SCO packet for unknown connection handle 46
and so on.

[peabody (ebnasos)]

Here the same problem with Linux ubuntu 2.6.24 (gutsy 7.10)

How Can I fix it? When fix is gone???

[Emmet Hikory (persia)]

I've opened a task for this bug against the linux source package as the continued reports appear to indicate a continuing issue (as if the bug were actually Fix Released on 7th July 2007, it would be unlikely to affect users of Ubuntu 7.10. Please reclose if there is a patch fixing this that I do not find in the changelog, or redirect if this bug belongs to a different package.

[Leann Ogasawara (leannogasawara)]

Hi Guys,

I just need some clarification. It was stated "Here the same problem with Linux ubuntu 2.6.24 (gutsy 7.10)" but that would seem to be a contradiction. Gutsy 7.10 uses the 2.6.22 kernel. Hardy Heron 8.04 uses the 2.6.24 kernel. Care to post a correction as to what you are really running or are you indeed running the Hardy kernel from a Gutsy installation?

Regardless, if you could please verify this issue still exists in the latest Hardy Alpha release it would be much appreciated. You can download and try the new Hardy Heron Alpha release from http://cdimage.ubuntu.com/releases/hardy/ . General information regarding the release can also be found here: http://www.ubuntu.com/testing/ . You should be able to then test the new kernel via the LiveCD. If the issue still exists, per the kernel team's bug policy, can you please attach the following information. Please be sure to attach each file as a separate attachment.

* uname -a > uname-a.log
* cat /proc/version_signature > version.log
* dmesg > dmesg.log
* sudo lspci -vvnn > lspci-vvnn.log

For more information regarding the kernel team bug policy, please refer to https://wiki.ubuntu.com/KernelTeamBugPolicies . Thanks again and we appreciate your help and feedback.

[none (ubuntu-bugs-nullinfinity-deactivatedaccount)]

I have this problem on Hardy. Attaching the requested files, except for dmesg which only consists of thousands of lines saying

[ 503.613772] hci_scodata_packet: hci0 SCO packet for unknown connection handle 1

For a dmesg which includes the boot messages, see http://launchpadlibrarian.net/12235140/dmesg

[none (ubuntu-bugs-nullinfinity-deactivatedaccount)]

Link to (untested) patch that supposedly fixes the problem:

http://lkml.org/lkml/2008/2/27/105

Please note that Marcel Holtmann, the bluetooth maintainer, thinks this patch is correct.

[Brian Rogers (brian-rogers)]

I have this problem, and that patch just causes an OOPS for me when I try to play audio to my headset. I wasn't able to record the contents.

[none (ubuntu-bugs-nullinfinity-deactivatedaccount)]

Hmm. There's an alternate patch at http://thread.gmane.org/gmane.linux.bluez.user/13573/focus=13592

If Brian (or anyone else) could try that, it'd be much appreciated.

[Brian Rogers (brian-rogers)]

Same crash (as far as I can tell) with the new patch. Also, I should specify that I'm trying the patch on Hardy's 2.6.24 kernel in git. 2.6.22 did not have this problem for me.

[Brian Rogers (brian-rogers)]

I've bisected down to the bad commit between 2.6.22 and 2.6.24. It's this:

commit b6a0dc822497e1c0b9e8c4add270cc27fce48454
Author: Marcel Holtmann <email address hidden>
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 <email address hidden>

Before this commit, it works fine. After, I get the flood.

[Brian Rogers (brian-rogers)]

Reverting that commit in the latest Hardy kernel and fixing the conflicts gets me a working headset!

Meanwhile, the latest patch I tried crashes like the others: http://thread.gmane.org/gmane.linux.bluez.kernel/14

[Rick Richardson (rick-richardson)]

Same here.

hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
hci_scodata_packet: hci0 SCO packet for unknown connection handle 92

[none (ubuntu-bugs-nullinfinity-deactivatedaccount)]

Thank you for the testing, Brian. I guess dropping the eSCO support isn't ideal, but in my opinion it's better than having a non-working connection that floods the syslog. Brian, is there any chance you could attach a clean patch against the Hardy kernel?

[none (ubuntu-bugs-nullinfinity-deactivatedaccount)]

Related kernel.org bug: http://bugzilla.kernel.org/show_bug.cgi?id=9871

[Brian Rogers (brian-rogers)]

Here's a patch.

[peabody (ebnasos)]

How can i use this patch, help me please)

[none (ubuntu-bugs-nullinfinity-deactivatedaccount)]

From #bluez irc channel, talking to Brad Midgley, one of the bluez developers:

<bmidgley> johanbr: the audio patch I referred to is broken and needs reworking
[...]
<bmidgley> johanbr the last "resolution" i saw for this was reverting esco

... so it seems like the only solution available at present is to drop the esco support, i.e. exactly what Brian's patch above does.

[none (ubuntu-bugs-nullinfinity-deactivatedaccount)]

I've been told that the oops-causing patches mentioned above actually work on vanilla kernel.org kernels.

[Brian Rogers (brian-rogers)]

It does work on vanilla 2.6.24.3 in the sense that it doesn't crash the system, but it also occasionally generates white noise instead of the correct audio. If somebody thinks it's useful, I could bisect between the vanilla and hardy kernels to find what change in combination with the patch causes the oops.

But if the static issue doesn't get solved in time, I think the best option is to disable eSCO entirely. I have a one-line patch that does this, and it works on Hardy without crashing or causing static.

[Brian Rogers (brian-rogers)]

This is the patch that I'm using right now.

[Ben Collins (ben-collins)]

Please use the "Simpler patch" near the bottom (one-liner)

[Launchpad Janitor (janitor)]

This bug was fixed in the package linux - 2.6.24-13.23

---------------
linux (2.6.24-13.23) hardy; urgency=low

  [Alessio Igor Bogani]

  * rt: Updated configuration files

  [Ben Collins]

  * openvz: New custom flavour for OpenVZ
  * config: Disable IDE AMD driver in favor of PATA version
    - LP: #181561
  * config: Disable IDE VIA driver in favor of PATA version
    - LP: #181561
  * drivers/video: Restore gutsy backlight dimming behavior
    - LP: #205261
  * build/config: Enable CONFIG_CIFS_WEAK_PW_HASH
    - LP: #202445

  [Colin Ian King]

  * SAUCE: Add support for version 4 of Chelsio NICs in cxgb3 driver
    - LP: #201893

  [Kees Cook]

  * AppArmor: re-add missing "type" field in syslog reports.
    - LP: #202888
  * kvm: reset TSS on x86_64 to avoid ioperm bitmap corruption
    - LP: #144900

  [Stefan Bader]

  * USB: EHCI: add separate IAA watchdog timer
    - LP: #198619
  * SAUCE: Always use SCO protocol (disable eSCO support)
    - LP: #39414
  * PM: Introduce PM_EVENT_HIBERNATE callback state
    - LP: #201086

  [Tim Gardner]

  * Disable DRM suspend/resume on pre-915 Intel chips
    - LP: #207496
  * frame buffer regression - screen blank except for blinking cursor after fbcon
    vtswitch
    - LP: #201591

 -- Tim Gardner <email address hidden> Wed, 19 Mar 2008 10:05:05 -0400

[quixote_arg (tulsidas)]

problem persists on 2.6.24-14-generic

ID 1131:1001 Integrades System Solution Corp. KY-BT100 Bluetooth Adapter

On Sun, Mar 30, 2008 at 7:50 PM, Launchpad Bug Tracker
<email address hidden> wrote:
> This bug was fixed in the package linux - 2.6.24-13.23
>
> ---------------
> linux (2.6.24-13.23) hardy; urgency=low
>
> [Alessio Igor Bogani]
>
> * rt: Updated configuration files
>
> [Ben Collins]
>
> * openvz: New custom flavour for OpenVZ
> * config: Disable IDE AMD driver in favor of PATA version
> - LP: #181561
> * config: Disable IDE VIA driver in favor of PATA version
> - LP: #181561
> * drivers/video: Restore gutsy backlight dimming behavior
> - LP: #205261
> * build/config: Enable CONFIG_CIFS_WEAK_PW_HASH
> - LP: #202445
>
> [Colin Ian King]
>
> * SAUCE: Add support for version 4 of Chelsio NICs in cxgb3 driver
> - LP: #201893
>
> [Kees Cook]
>
> * AppArmor: re-add missing "type" field in syslog reports.
> - LP: #202888
> * kvm: reset TSS on x86_64 to avoid ioperm bitmap corruption
> - LP: #144900
>
> [Stefan Bader]
>
> * USB: EHCI: add separate IAA watchdog timer
> - LP: #198619
> * SAUCE: Always use SCO protocol (disable eSCO support)
> - LP: #39414
> * PM: Introduce PM_EVENT_HIBERNATE callback state
> - LP: #201086
>
> [Tim Gardner]
>
> * Disable DRM suspend/resume on pre-915 Intel chips
> - LP: #207496
> * frame buffer regression - screen blank except for blinking cursor after fbcon
> vtswitch
> - LP: #201591
>
> -- Tim Gardner <email address hidden> Wed, 19 Mar 2008 10:05:05
> -0400
>
> ** Changed in: linux (Ubuntu)
> Status: Fix Committed => Fix Released
>
>
>
> --
> syslog is flooded with messages after connecting bluetooth usb dongle
> https://bugs.launchpad.net/bugs/39414
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[MsTiFtS (mstifts)]

@quixote_arg: can't reproduce problem on 2.6.24-16-generic. My headset does still not work, but the syslog flood doesn't occur any more. Sometimes there are still single "SCO packet for unknown connection handle", but not several thousands per second(!) as I experienced before.

[quixote_arg (tulsidas)]

Still happening on 2.6.24-16-generic :(

lots of "hci_scodata_packet: hci0 SCO packet for unknown connection handle 92"

attached lsusb -v

thanks

On Fri, Apr 11, 2008 at 6:15 PM, MsTiFtS <email address hidden> wrote:
> @quixote_arg: can't reproduce problem on 2.6.24-16-generic. My headset
> does still not work, but the syslog flood doesn't occur any more.
> Sometimes there are still single "SCO packet for unknown connection
> handle", but not several thousands per second(!) as I experienced
> before.

[none (ubuntu-bugs-nullinfinity-deactivatedaccount)]

With 2.6.24-16-generic, my Motorola H300 works fine. I suspect that those of you who still have problems may be experiencing something similar to http://bugzilla.kernel.org/show_bug.cgi?id=6833 .

[SebastienBarthelemy (barthelemy)]

I have the same problem with hardy heron and
 - bluez-utils version 3.26-0ubuntu6.
 - linux 2.6.24-18-generic
 - Motorola H500 headset (SCO)
 - my dell latitude integrated bluetooth

When I associate the headset and try it
mplayer -ao alsa:device=bluetooth "/usr/share/example-content/ubuntu Sax.ogg"

It does _not_ work (no sound), and syslog is flooded by
 thinbox kernel: [ 5830.621543] hci_scodata_packet: hci0 SCO packet for unknown connection handle 46
messages
When I ctrl+c mplayer, I can hear a "biip"

Here are some details

$ cat ~/.asoundrc
pcm.bluetooth {
   type bluetooth
   device 00:19:1F:33:7E:58
}

$ lsusb
Bus 001 Device 008: ID 413c:8103 Dell Computer Corp. Wireless 350 Bluetooth

/var/log/syslog:

Jun 7 09:44:10 thinbox NetworkManager: <debug> [1212824650.290425] nm_hal_device_added(): New device added (hal udi is '/org/freedesktop/Hal/devices/bluetooth_acl_191f337e58').
Jun 7 09:44:10 thinbox hcid[5466]: link_key_request (sba=00:16:41:91:54:6F, dba=00:19:1F:33:7E:58)
Jun 7 09:44:10 thinbox hcid[5466]: pin_code_request (sba=00:16:41:91:54:6F, dba=00:19:1F:33:7E:58)
Jun 7 09:44:25 thinbox hcid[5466]: link_key_notify (sba=00:16:41:91:54:6F, dba=00:19:1F:33:7E:58)
Jun 7 09:44:26 thinbox NetworkManager: <debug> [1212824666.400180] nm_hal_device_removed(): Device removed (hal udi is '/org/freedesktop/Hal/devices/bluetooth_acl_191f337e58').
Jun 7 09:44:26 thinbox NetworkManager: <debug> [1212824666.850472] nm_hal_device_added(): New device added (hal udi is '/org/freedesktop/Hal/devices/bluetooth_acl_191f337e58').
Jun 7 09:44:26 thinbox hcid[5466]: link_key_request (sba=00:16:41:91:54:6F, dba=00:19:1F:33:7E:58)
Jun 7 09:44:27 thinbox audio[5474]: Requesting authorization for device 00:19:1F:33:7E:58, UUID 00001112-0000-1000-8000-00805F9B34FB
Jun 7 09:44:27 thinbox audio[5474]: State changed /org/bluez/audio/device0: HEADSET_STATE_DISCONNECTED -> HEADSET_STATE_CONNECT_IN_PROGRESS
Jun 7 09:44:27 thinbox audio[5474]: State changed /org/bluez/audio/device0: HEADSET_STATE_CONNECT_IN_PROGRESS -> HEADSET_STATE_CONNECTED
Jun 7 09:44:27 thinbox audio[5474]: Accepted headset connection from 00:19:1F:33:7E:58 for /org/bluez/audio/device0
Jun 7 09:44:27 thinbox hcid[5466]: link_key_notify (sba=00:16:41:91:54:6F, dba=00:19:1F:33:7E:58)
Jun 7 09:49:12 thinbox audio[5474]: Accepted new client connection on unix socket (fd=10)
Jun 7 09:49:12 thinbox audio[5474]: Audio API: received BT_GETCAPABILITIES_REQ
Jun 7 09:49:12 thinbox audio[5474]: Audio API: sending BT_GETCAPABILITIES_RSP
Jun 7 09:49:12 thinbox audio[5474]: Audio API: received BT_SETCONFIGURATION_REQ
Jun 7 09:49:12 thinbox audio[5474]: config sco - device = 00:19:1F:33:7E:58 access_mode = 2
Jun 7 09:49:12 thinbox kernel: [ 5829.326791] Bluetooth: SCO (Voice Link) ver 0.6
Jun 7 09:49:12 thinbox kernel: [ 5829.326799] Bluetooth: SCO socket layer initialized
Jun 7 09:49:12 thinbox audio[5474]: State changed /org/bluez/audio/device0: HEADSET_STATE_CONNECTED -> HEADSET_STATE_PLAY_IN_PROGRESS
Jun 7 09:49:12 thinbox NetworkManager: <debug> [1212824952.681155] nm_hal_device_added(): New device added (hal udi is '/org/freedesktop/Hal/devices/bluetooth_acl_ffffffffffffffff')...

[Brian Murray (brian-murray)]

The bug task without a package is not valid so I'm setting its status to Invalid.

[Thomas Wihl (thomas-wihl)]

Having the same problem with my stick:
ID 1131:1001 Integrated System Solution Corp. KY-BT100 Bluetooth Adapter

Adding HCI_BROKEN_ISOC to hci_usb.c worked for me as well:
 { USB_DEVICE(0x1131, 0x1001), .driver_info = HCI_RESET | HCI_BROKEN_ISOC },

Using Ubuntu 8.04 and kernel 2.6.24-19-generic #1 SMP Wed Jun 18 14:43:41 UTC 2008 i686 GNU/Linux

[ssr (sada007)]

Reverting eSCO worked for me.
Always reconnect from BT Headset for reliable connection before using aplay or skype dialing.

[civility (lordjunkyard)]

Same continuing issue on 2 different Ubuntu boxes:

$ dmesg | grep hci0
Thousands of,,
[13231.381436] hci_scodata_packet: hci0 SCO packet for unknown connection handle 92

$ uname -srmo
Linux 2.6.24-23-generic i686 GNU/Linux

$ lsusb
...
Bus 003 Device 006: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
..

$ sudo lsub -v

Bus 006 Device 001: ID 0000:0000
Device Descriptor:
  bLength 18
  bDescriptorType 1
  bcdUSB 2.00
  bDeviceClass 9 Hub
  bDeviceSubClass 0 Unused
  bDeviceProtocol 1 Single TT
  bMaxPacketSize0 64
  idVendor 0x0000
  idProduct 0x0000
  bcdDevice 2.06
  iManufacturer 3 Linux 2.6.24-23-generic ehci_hcd
  iProduct 2 EHCI Host Controller
  iSerial 1 0000:00:1a.7
  bNumConfigurations 1
  Configuration Descriptor:
    bLength 9
    bDescriptorType 2
    wTotalLength 25
    bNumInterfaces 1
    bConfigurationValue 1
    iConfiguration 0
    bmAttributes 0xe0
      Self Powered
      Remote Wakeup
    MaxPower 0mA
    Interface Descriptor:
      bLength 9
      bDescriptorType 4
      bInterfaceNumber 0
      bAlternateSetting 0
      bNumEndpoints 1
      bInterfaceClass 9 Hub
      bInterfaceSubClass 0 Unused
      bInterfaceProtocol 0 Full speed (or root) hub
      iInterface 0
      Endpoint Descriptor:
        bLength 7
        bDescriptorType 5
        bEndpointAddress 0x81 EP 1 IN
        bmAttributes 3
          Transfer Type Interrupt
          Synch Type None
          Usage Type Data
        wMaxPacketSize 0x0004 1x 4 bytes
        bInterval 12
Hub Descriptor:
  bLength 9
  bDescriptorType 41
  nNbrPorts 4
  wHubCharacteristic 0x000a
    No power switching (usb 1.0)
    Per-port overcurrent protection
    TT think time 8 FS bits
  bPwrOn2PwrGood 10 * 2 milli seconds
  bHubContrCurrent 0 milli Ampere
  DeviceRemovable 0x00
  PortPwrCtrlMask 0xff
 Hub Port Status:
   Port 1: 0000.0100 power
   Port 2: 0000.0100 power
   Port 3: 0000.0100 power
   Port 4: 0000.0100 power
Device Status: 0x0003
  Self Powered
  Remote Wakeup Enabled

Bus 007 Device 002: ID 04f2:b016 Chicony Electronics Co., Ltd
Device Descriptor:
  bLength 18
  bDescriptorType 1
  bcdUSB 2.00
  bDeviceClass 239 Miscellaneous Device
  bDeviceSubClass 2 ?
  bDeviceProtocol 1 Interface Association
  bMaxPacketSize0 64
  idVendor 0x04f2 Chicony Electronics Co., Ltd
  idProduct 0xb016
  bcdDevice 6.04
  iManufacturer 2 Chicony Electronics Co., Ltd.
  iProduct 1 HP Webcam
  iSerial 3 SN0001
  bNumConfigurations 1
  Configuration Descriptor:
    bLength 9
    bDescriptorType 2
    wTotalLength 543
    bNumInterfac...

[RobPower (robpwr)]

Same problem on Hardy 64 bit, kernel 2.6.24-24
Attached is the lsusb -v output (I selected only the part related to the interested device (0a12:0001 - Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)).

[sles (slesru)]

The same problem with
Bus 001 Device 007: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
on
 2.6.24-24-generic #1 SMP Wed Apr 15 15:11:35 UTC 2009 x86_64 GNU/Linux

Still no solution?

[sles (slesru)]

I changed hci_usb.c to

     { USB_DEVICE(0x0a12, 0x0001), .driver_info = HCI_CSR | HCI_BROKEN_ISOC},

so now there is no
hci_scodata_packet: hci0 SCO packet for unknown connection handle 92
messages

But when I try to pair with my wm5 phone ubuntu crashes.

[Michał Gołębiowski-Owczarek (mgol)]

I can confirm it. I use Hardy, my device is (obtained via lsusb):
Bus 001 Device 006: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
I'll attach my system information.

[Michał Gołębiowski-Owczarek (mgol)]

OK, I don't know if this bug report should be touched any longer as it is closed. I reported another one:
https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/386736