0a5c:201e [Lenovo ThinkPad X41] Bluetooth connections stalling

Bug #950413 reported by Ruokoton on 2012-03-08
38
This bug affects 7 people
Affects Status Importance Assigned to Milestone
Linux
Confirmed
Medium
linux (Ubuntu)
Medium
Unassigned

Bug Description

Description: Ubuntu precise (development branch)
Release: 12.04

bluez:
  Installed: 4.98-2ubuntu4
  Candidate: 4.98-2ubuntu4
  Version table:
 *** 4.98-2ubuntu4 0
        500 http://fi.archive.ubuntu.com/ubuntu/ precise/main i386 Packages
        100 /var/lib/dpkg/status

lsusb:
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 002: ID 0a5c:201e Broadcom Corp. IBM Integrated Bluetooth IV

All bluetooth connections seem to stall after certain period of time (seen from dmesg) - this alone makes file transfers, etc impossible, although there might be other problems too.

sudo l2ping -s300 D4:88:90:C2:8B:33
Ping: D4:88:90:C2:8B:33 from 00:14:A4:DC:21:08 (data size 300) ...
300 bytes from D4:88:90:C2:8B:33 id 0 time 58.62ms
300 bytes from D4:88:90:C2:8B:33 id 1 time 19.87ms
300 bytes from D4:88:90:C2:8B:33 id 2 time 18.92ms
300 bytes from D4:88:90:C2:8B:33 id 3 time 19.93ms
300 bytes from D4:88:90:C2:8B:33 id 4 time 29.36ms
300 bytes from D4:88:90:C2:8B:33 id 5 time 18.08ms
300 bytes from D4:88:90:C2:8B:33 id 6 time 15.73ms
300 bytes from D4:88:90:C2:8B:33 id 7 time 20.92ms
300 bytes from D4:88:90:C2:8B:33 id 8 time 17.88ms
300 bytes from D4:88:90:C2:8B:33 id 9 time 15.92ms
no response from D4:88:90:C2:8B:33: id 10
no response from D4:88:90:C2:8B:33: id 11
no response from D4:88:90:C2:8B:33: id 12
no response from D4:88:90:C2:8B:33: id 13
no response from D4:88:90:C2:8B:33: id 14
Recv failed: Software caused connection abort

dmesg:
[ 5787.352443] Bluetooth: hci0 link tx timeout
[ 5787.352453] Bluetooth: hci0 killing stalled connection D4:88:90:C2:8B:33

The connection will always stall after 10 rounds. The pinged device is Samsung Galaxy S phone. When the same is being pinged from another computer, also running Ubuntu, the connection stays stable until aborted.

Noticed exactly similar behavior reported here: https://bbs.archlinux.org/viewtopic.php?id=120488 - only common things are bluez and Broadcom bluetooth chip.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: bluez 4.98-2ubuntu4
ProcVersionSignature: Ubuntu 3.2.0-18.28-generic-pae 3.2.9
Uname: Linux 3.2.0-18-generic-pae i686
ApportVersion: 1.94.1-0ubuntu1
Architecture: i386
Date: Fri Mar 9 01:33:34 2012
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Alpha i386 (20120306)
InterestingModules: rfcomm bnep btusb bluetooth
MachineType: IBM 2525AP5
PccardctlIdent:
 Socket 0:
   no product info available
PccardctlStatus:
 Socket 0:
   no card
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-18-generic-pae root=UUID=24998e60-4dee-4c05-829d-2142350617ab ro quiet splash vt.handoff=7
SourcePackage: bluez
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 12/14/2006
dmi.bios.vendor: IBM
dmi.bios.version: 74ET64WW (2.09 )
dmi.board.name: 2525AP5
dmi.board.vendor: IBM
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: IBM
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnIBM:bvr74ET64WW(2.09):bd12/14/2006:svnIBM:pn2525AP5:pvrThinkPadX41:rvnIBM:rn2525AP5:rvrNotAvailable:cvnIBM:ct10:cvrNotAvailable:
dmi.product.name: 2525AP5
dmi.product.version: ThinkPad X41
dmi.sys.vendor: IBM
hciconfig:
 hci0: Type: BR/EDR Bus: USB
  BD Address: 00:14:A4:DC:21:08 ACL MTU: 377:10 SCO MTU: 64:8
  UP RUNNING PSCAN ISCAN
  RX bytes:61317 acl:410 sco:0 events:3834 errors:0
  TX bytes:34007 acl:350 sco:0 commands:3553 errors:0
mtime.conffile..etc.bluetooth.audio.conf: 2012-03-09T00:08:00.157148
mtime.conffile..etc.bluetooth.main.conf: 2012-03-09T00:23:05.617638
mtime.conffile..etc.dbus.1.system.d.bluetooth.conf: 2012-03-08T21:16:48.604399

Ruokoton (uborealis) wrote :
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in bluez (Ubuntu):
status: New → Confirmed

Data transmissions seem to timeout:

Mar 8 18:10:22 X41 bluetoothd[3737]: Discover: Connection timed out (110)
Mar 8 18:22:06 X41 kernel: [ 3399.348103] Bluetooth: hci0 link tx timeout
Mar 8 18:22:06 X41 kernel: [ 3399.348122] Bluetooth: hci0 killing stalled connection D4:88:90:C2:8B:33
Mar 8 18:22:06 X41 kernel: [ 3399.348165] Bluetooth: hci0 link tx timeout
Mar 8 18:22:06 X41 kernel: [ 3399.348176] Bluetooth: hci0 killing stalled connection D4:88:90:C2:8B:33
Mar 8 18:25:34 X41 kernel: [ 3607.476137] Bluetooth: hci0 link tx timeout
Mar 8 18:25:34 X41 kernel: [ 3607.476155] Bluetooth: hci0 killing stalled connection D4:88:90:C2:8B:33
Mar 8 18:25:34 X41 kernel: [ 3607.476211] Bluetooth: hci0 link tx timeout
Mar 8 18:25:34 X41 kernel: [ 3607.476223] Bluetooth: hci0 killing stalled connection D4:88:90:C2:8B:33

Reassigning to linux so it can be looked at at the driver level...

affects: bluez (Ubuntu) → linux (Ubuntu)
Changed in linux (Ubuntu):
status: Confirmed → New
Brad Figg (brad-figg) on 2012-04-16
Changed in linux (Ubuntu):
status: New → Confirmed

Thank you for taking the time to file a bug report on this issue.

However, given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

We have noted that there is a newer version of the development kernel than the one you last tested when this issue was found. Please test again with the newer kernel and indicate in the bug if this issue still exists or not.

You can update to the latest development kernel by simply running the following commands in a terminal window:

    sudo apt-get update
    sudo apt-get dist-upgrade

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

If you want this bot to quit automatically requesting kernel tests, add a tag named: bot-stop-nagging.

 Thank you for your help, we really do appreciate it.

Changed in linux (Ubuntu):
status: Confirmed → Incomplete
tags: added: kernel-request-3.2.0-23.36
Changed in linux (Ubuntu):
importance: Undecided → Medium

Tested with :

apt-cache policy linux-image-3.2.0-23-generic-pae
linux-image-3.2.0-23-generic-pae:
  Installed: 3.2.0-23.36
  Candidate: 3.2.0-23.36
  Version table:
 *** 3.2.0-23.36 0
        500 http://fi.archive.ubuntu.com/ubuntu/ precise/main i386 Packages
        100 /var/lib/dpkg/status

Behaviour same as before:

sudo l2ping -s300 D4:88:90:C2:8B:33
Ping: D4:88:90:C2:8B:33 from 00:14:A4:DC:21:08 (data size 300) ...
300 bytes from D4:88:90:C2:8B:33 id 0 time 16.56ms
300 bytes from D4:88:90:C2:8B:33 id 1 time 17.81ms
300 bytes from D4:88:90:C2:8B:33 id 2 time 17.85ms
300 bytes from D4:88:90:C2:8B:33 id 3 time 18.91ms
300 bytes from D4:88:90:C2:8B:33 id 4 time 19.90ms
300 bytes from D4:88:90:C2:8B:33 id 5 time 18.86ms
300 bytes from D4:88:90:C2:8B:33 id 6 time 19.83ms
300 bytes from D4:88:90:C2:8B:33 id 7 time 23.78ms
300 bytes from D4:88:90:C2:8B:33 id 8 time 18.89ms
300 bytes from D4:88:90:C2:8B:33 id 9 time 18.82ms
no response from D4:88:90:C2:8B:33: id 10
no response from D4:88:90:C2:8B:33: id 11

Changing status back to confirmed.

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Joseph Salisbury (jsalisbury) wrote :

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.4kernel[1] (Not a kernel in the daily directory). Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag(Only that one tag, please leave the other tags). This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text.

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4-rc3-precise/

tags: added: needs-upstream-testing
Changed in linux (Ubuntu):
status: Confirmed → Incomplete
Ruokoton (uborealis) wrote :

ruokoja@X41:~$ uname -r
3.4.0-030400rc3-generic-pae
ruokoja@X41:~$ sudo l2ping -s300 D4:88:90:C2:8B:33
[sudo] password for ruokoja:
Ping: D4:88:90:C2:8B:33 from 00:14:A4:DC:21:08 (data size 300) ...
300 bytes from D4:88:90:C2:8B:33 id 0 time 58.83ms
300 bytes from D4:88:90:C2:8B:33 id 1 time 21.27ms
300 bytes from D4:88:90:C2:8B:33 id 2 time 20.33ms
300 bytes from D4:88:90:C2:8B:33 id 3 time 20.30ms
300 bytes from D4:88:90:C2:8B:33 id 4 time 18.33ms
300 bytes from D4:88:90:C2:8B:33 id 5 time 20.32ms
300 bytes from D4:88:90:C2:8B:33 id 6 time 20.32ms
300 bytes from D4:88:90:C2:8B:33 id 7 time 19.32ms
300 bytes from D4:88:90:C2:8B:33 id 8 time 20.30ms
300 bytes from D4:88:90:C2:8B:33 id 9 time 19.37ms
no response from D4:88:90:C2:8B:33: id 10
no response from D4:88:90:C2:8B:33: id 11
...

Unfortunately the latest kernel didn't solve the problem. Should I post any logs done with it or can we assume the situation is the same as was during the 1st post?

tags: added: kernel-bug-exists-upstream
removed: needs-upstream-testing
Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Joseph Salisbury (jsalisbury) wrote :

This issue appears to be an upstream bug, since you tested the latest upstream kernel. Would it be possible for you to open an upstream bug report at bugzilla.kernel.org [1]? That will allow the upstream Developers to examine the issue, and may provide a quicker resolution to the bug.

If you are comfortable with opening a bug upstream, It would be great if you can report back the upstream bug number in this bug report. That will allow us to link this bug to the upstream report.

[1] https://wiki.ubuntu.com/Bugs/Upstream/kernel

Changed in linux (Ubuntu):
status: Confirmed → Triaged

I've just reported this upstream, since the bug is present in the latest mainline, and I could not find any upstream reports about this bug. The mantainers at the linux-bluetooth mailing list were already informed about this bug on April 2012, but I could not find any reply: http://permalink.gmane.org/gmane.linux.kernel/1279113 and http://www.spinics.net/lists/linux-bluetooth/msg23498.html So I reported this on the kernel.org bugzilla.

Changed in linux:
importance: Unknown → Medium
status: Unknown → Confirmed
Phil Pemberton (philpem) wrote :

@VittGam - Can you provide a link to the bug on the kernel Bugzilla?

I'm also seeing this issue on Quantal -

philpem@cheetah:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 12.10
Release: 12.10
Codename: quantal

philpem@cheetah:~$ sudo l2ping -s300 00:04:48:11:03:5C
Ping: 00:04:48:11:03:5C from 00:0B:0D:62:F5:50 (data size 300) ...
0 bytes from 00:04:48:11:03:5C id 0 time 39.78ms
0 bytes from 00:04:48:11:03:5C id 1 time 21.88ms
0 bytes from 00:04:48:11:03:5C id 2 time 20.50ms
0 bytes from 00:04:48:11:03:5C id 3 time 19.72ms
0 bytes from 00:04:48:11:03:5C id 4 time 20.03ms
0 bytes from 00:04:48:11:03:5C id 5 time 19.80ms
0 bytes from 00:04:48:11:03:5C id 6 time 19.92ms
0 bytes from 00:04:48:11:03:5C id 7 time 19.89ms
0 bytes from 00:04:48:11:03:5C id 8 time 20.39ms
0 bytes from 00:04:48:11:03:5C id 9 time 19.29ms
no response from 00:04:48:11:03:5C: id 10
no response from 00:04:48:11:03:5C: id 11
no response from 00:04:48:11:03:5C: id 12
no response from 00:04:48:11:03:5C: id 13
no response from 00:04:48:11:03:5C: id 14
Recv failed: Software caused connection abort

philpem@cheetah:~$ dmesg |tail
[23687.938626] usb 2-1.1.2: USB disconnect, device number 11
[23687.959165] usb 2-1.1.3: USB disconnect, device number 12
[23690.679189] usb 2-1.1: new full-speed USB device number 13 using ehci_hcd
[23690.794663] usb 2-1.1: New USB device found, idVendor=0a5c, idProduct=200a
[23690.794669] usb 2-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[23690.794672] usb 2-1.1: Product: BCM92035DGROM
[23690.794674] usb 2-1.1: Manufacturer: Broadcom
[23690.794677] usb 2-1.1: SerialNumber: 000B0D62F550
[24048.803235] Bluetooth: hci0 link tx timeout
[24048.803243] Bluetooth: hci0 killing stalled connection 00:04:48:11:03:5C

Of course, it is: https://bugzilla.kernel.org/show_bug.cgi?id=51221

The issue is that the device does not generate the Number of Completed Packets event (0x13) with the configuration sent by the Linux driver. A Windows XP virtual machine with USB pass-through on the same machine and adapter does not show the problem, even though I could not spot sensible differences with the Linux driver other than the maximum packet size while sniffing the usb bus with Wireshark. I've also tried to reproduce the exact packets sent by the WinXP driver in the Linux driver, but it didn't help. There must be something wrong with the USB protocol implementation in the adapter I think.

summary: - Bluetooth connections stalling
+ Bluetooth connections stalling with some Broadcom cards from year 2005

VittGam,

Do you know what would be the quick fix for this?

I need a quick fix for this and was wondering if just commenting out the call to __check_timeout() in hci_sched_acl_pkt() would do the trick as a quick and dirty fix?

ukungfu (varenorn) wrote :

VittGam,

Are you sure that the issue is to do with the non-generation of the Number of Completed Packets event?

The reason why I ask is because my Broadcom Corp. BCM2035 Bluetooth dongle (0a5c:200a) worked in kernel 2.6.22.5 (OpenSUSE 10.3) but not in the later kernel 3.7.10 (OpenSUSE 12.3).

Though there have been major changes to the source code in the net/bluetooth directory, one of the basics still remain - both have the function hci_event_packet() and both handle the HCI_EV_NUM_COMP_PKTS event by calling hci_num_comp_pkts_evt().

So this problem is possibly more subtle than just not having HCI_EV_NUM_COMP_PKTS being triggered?

ukungfu,

Some time ago I remember I tried to workaround this, l2ping did work but the connection was not reliable at all, since the card could not signal if its buffer was empty, so the driver would continue sending tx packets continuously even with the tx buffer full. At the moment I cannot find the testing tree I was using at the time, so I can't tell more for now...

After testing in an WinXP virtual machine and sniffing the USB traffic as in comment #11, I could conclude that the problem is not in the bluetooth stack but in the method/init parameters/something like that the btusb driver and/or the usb driver use to initialize the usb communication with the bluetooth card. The only sensible difference between the WinXP dump and the btusb dump was the maximum size of the usb packets sent and received on the wire. I also tried to manually replace the btusb initialization messages with the sniffed ones from WinXP, and it did not work.

(P.s. As a quick fix I'd suggest you to buy or borrow a $10 CSR dongle as I've done when I was in a hurry and needed bluetooth on this pc some time ago, this fixed the problem very well. ;)

And yes, the issue I could see while sniffing packets is that for some reason the card in the linux configuration does not generate the HCI_EV_NUM_COMP_PKTS when it should, nor anything in place of that (the dump's just silent).

Ruokoton, could you please confirm this issue exists with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ . If the issue remains, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Please do not test the daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.11-rc3

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

If you are unable to test the mainline kernel, please comment as to why specifically you were unable to test it and add the following tags:
kernel-unable-to-test-upstream
kernel-unable-to-test-upstream-VERSION-NUMBER

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

summary: - Bluetooth connections stalling with some Broadcom cards from year 2005
+ 0a5c:201e Bluetooth connections stalling
tags: added: bot-stop-nagging kernel-bug-exists-upstream-v3.4-rc3 latest-bios-2.09 needs-upstream-testing regression-potential
removed: kernel-bug-exists-upstream kernel-request-3.2.0-23.36
summary: - 0a5c:201e Bluetooth connections stalling
+ 0a5c:201e [Lenovo ThinkPad X41] Bluetooth connections stalling
Changed in linux (Ubuntu):
status: Triaged → Incomplete

apport information

tags: added: apport-collected raring
description: updated

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

Ruokoton (uborealis) on 2013-09-11
description: updated
Ruokoton (uborealis) on 2013-09-11
tags: added: kernel-bug-exists-upstream kernel-bug-exists-upstream3.9.0-030900
removed: needs-upstream-testing
tags: added: kernel-bug-exists-upstream-3.9.0-030900
removed: kernel-bug-exists-upstream3.9.0-030900
tags: added: kernel-bug-exists-upstream-v3.9 needs-upstream-testing
removed: kernel-bug-exists-upstream kernel-bug-exists-upstream-3.9.0-030900 kernel-bug-exists-upstream-v3.4-rc3
description: updated
Ruokoton (uborealis) wrote :

What'd be the next step? I understood that 3.9 is the mainline kernl version for 13.04 Ubuntu. Even further upstream?

Ruokoton (uborealis) wrote :

Behaviour with 3.9 kernel was unchanged.

Ping: 30:39:26:5D:16:38 from 00:14:A4:DC:21:08 (data size 300) ...
0 bytes from 30:39:26:5D:16:38 id 0 time 9.78ms
0 bytes from 30:39:26:5D:16:38 id 1 time 10.92ms
0 bytes from 30:39:26:5D:16:38 id 2 time 27.85ms
0 bytes from 30:39:26:5D:16:38 id 3 time 37.78ms
0 bytes from 30:39:26:5D:16:38 id 4 time 27.81ms
0 bytes from 30:39:26:5D:16:38 id 5 time 47.82ms
0 bytes from 30:39:26:5D:16:38 id 6 time 15.85ms
0 bytes from 30:39:26:5D:16:38 id 7 time 23.81ms
no response from 30:39:26:5D:16:38: id 8
no response from 30:39:26:5D:16:38: id 9
no response from 30:39:26:5D:16:38: id 10
no response from 30:39:26:5D:16:38: id 11
no response from 30:39:26:5D:16:38: id 12
Recv failed: Software caused connection abort

...and from dmesg:

[ 4282.450402] Bluetooth: hci0 link tx timeout
[ 4282.450420] Bluetooth: hci0 killing stalled connection 30:39:26:5d:16:38

Ruokoton, as per https://bugs.launchpad.net/ubuntu/+source/linux/+bug/950413/comments/16 the latest release is Saucy, and the latest mainline kernel v3.11.

Ruokoton (uborealis) wrote :

OK, I'll test with that then. Thanks for guidance.

gadLinux (gad-aguilardelgado) wrote :

I can confirm with latest kernel has same bug.

[116176.608967] hid-generic 0005:046D:B309.003F: input,hidraw2: BLUETOOTH HID v1.1b Mouse [Logitech diNovo Edge] on 00:10:60:af:02:19
[116221.665226] Bluetooth: hci0 link tx timeout
[116221.665239] Bluetooth: hci0 killing stalled connection 00:07:61:73:4f:76
[116223.100435] hid-generic 0005:046D:B309.0040: unknown main item tag 0x0
[116228.104906] input: Logitech diNovo Edge as /devices/pci0000:00/0000:00:12.0/usb3/3-3/3-3:1.0/bluetooth/hci0/hci0:7/input76
[116228.105262] hid-generic 0005:046D:B309.0040: input,hidraw2: BLUETOOTH HID v1.1b Mouse [Logitech diNovo Edge] on 00:10:60:af:02:19

Not the same model, but same problem.
Linux red1 3.11.0-15-generic #23-Ubuntu SMP Mon Dec 9 18:17:04 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
g

gadLinux, thank you for your comment. So your hardware may be tracked, could you please file a new report by executing the following in a terminal while booted into a Ubuntu repository kernel (not a mainline one) via:
ubuntu-bug linux

For more on this, please read the official Ubuntu documentation:
Ubuntu Bug Control and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue
Ubuntu Kernel Team: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

Thank you for your understanding.

Helpful bug reporting tips:
https://help.ubuntu.com/community/ReportingBugs

gadLinux (gad-aguilardelgado) wrote :

Hi Christopher, will try to do it but since I don't use this keyboard all time it will take me time to do it. Cause I have to switch environment.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.