FS#35944 - Bluetooth mouse initializes slowly with kernel 3.9.7
Attached to Project:
Arch Linux
Opened by Gene (GeneC) - Wednesday, 26 June 2013, 18:20 GMT
Last edited by Tobias Powalowski (tpowa) - Friday, 19 July 2013, 05:17 GMT
Opened by Gene (GeneC) - Wednesday, 26 June 2013, 18:20 GMT
Last edited by Tobias Powalowski (tpowa) - Friday, 19 July 2013, 05:17 GMT
|
Details
Description:
1) Fully updated from testing repo. As of a couple of days ago (around 3.9.7 kernel) I noticed that bluetooth mouse takes a few seconds to initialize - it used to be almost instant. 2) i.e. leave laptop till screen blanks etc. Come back and wiggle mouse - takes a few seconds before cursor wakes up - after that it works totally normally. ------------------------- linux 3.9.7 ---------------------------------------------------- 3) /var/log/errors.log has this: Jun 25 08:30:14 lap3 kernel: [312741.987038] Bluetooth: Wrong link type (-71) Jun 25 08:30:18 lap3 kernel: [312746.011670] hid-generic 0005:1532:0008.0033: unknown main item tag 0x0 /var/log/messages has this (from 1/2 hour earlier) Jun 25 07:53:42 lap3 bluetoothd[461]: bluetoothd[461]: Adapter /org/bluez/461/hci0 has been enabled Jun 25 07:53:42 lap3 bluetoothd[461]: bluetoothd[461]: Unknown command complete for opcode 19 Jun 25 07:53:42 lap3 bluetoothd[461]: Adapter /org/bluez/461/hci0 has been enabled Jun 25 07:53:42 lap3 bluetoothd[461]: Unknown command complete for opcode 19 ------------------------- linux 3.9.6 ---------------------------------------------------- 4) Reverting to kernel 3.9.6 problem goes away: /var/log/everything.log Jun 26 13:04:28 lap3 bluetoothd[457]: bluetoothd[457]: Unknown command complete for opcode 19 Jun 26 13:04:28 lap3 bluetoothd[457]: bluetoothd[457]: Adapter /org/bluez/457/hci0 has been enabled Jun 26 13:04:28 lap3 bluetoothd[457]: Adapter /org/bluez/457/hci0 has been enabled Jun 26 13:05:11 lap3 kernel: [ 56.137685] hid-generic 0005:1532:0008.0001: unknown main item tag 0x0 Jun 26 13:05:11 lap3 kernel: [ 56.137738] input: Pro|Click Mobile as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.4/1-1.4:1.0/bluetooth/hci0/hci0:11/input15 Jun 26 13:05:11 lap3 kernel: [ 56.138016] hid-generic 0005:1532:0008.0001: input,hidraw0: BLUETOOTH HID v1.0c Mouse [Pro|Click Mobile] on ec:55:f9:f1:44:99 /var/log/errors.log Jun 26 13:04:28 lap3 bluetoothd[457]: Unknown command complete for opcode 19 Jun 26 13:05:11 lap3 kernel: [ 56.137685] hid-generic 0005:1532:0008.0001: unknown main item tag 0x0 -------------------------------------------------------------------------------------------------------- Additional info: * package version(s) linux 3.9.7-1 kdebase-runtime 4.10.4-1 bluedevil 1.3.1-1 bluez-libs 5.5-3 bluez-utils 5.5-3 protocol stack bluez4 4.101-3 9 libbluedevil 1.9.3-2 A * config and/or log files etc. Steps to reproduce: |
This task depends upon
$ git log v3.9.6..v3.9.7 -- net/bluetooth
commit 15794d484f6404b4794867a0da892c01b20ccf24
Author: Johan Hedberg <johan.hedberg@intel.com>
Date: Wed May 29 09:51:29 2013 +0300
Bluetooth: Fix mgmt handling of power on failures
If hci_dev_open fails we need to ensure that the corresponding
mgmt_set_powered command gets an appropriate response. This patch fixes
the missing response by adding a new mgmt_set_powered_failed function
that's used to indicate a power on failure to mgmt. Since a situation
with the device being rfkilled may require special handling in user
space the patch uses a new dedicated mgmt status code for this.
commit 22b74ee1ace2536bb4889c33f1de932d2814376a
Author: Johan Hedberg <johan.hedberg@intel.com>
Date: Tue May 28 13:46:30 2013 +0300
Bluetooth: Fix missing length checks for L2CAP signalling PDUs
There has been code in place to check that the L2CAP length header
matches the amount of data received, but many PDU handlers have not been
checking that the data received actually matches that expected by the
specific PDU. This patch adds passing the length header to the specific
handler functions and ensures that those functions fail cleanly in the
case of an incorrect amount of data.
I almost sure that reverting one of this patches will fix the issue. Gene, if you have chance could you compile 3.9.7 with reverted patch and test it? If it confirms the commit introduced this regression then it should be reported to the author - "Johan Hedberg <johan.hedberg@intel.com>"
See the patch from maillist. cb3b3152b2f593 incorrectly returns -EPROTO result (EPROTO==71). You have "Wrong link type (-71)" message that is very similar to the mentioned issue. I believe the change from maillist will fix your issue.
No need to wait for something you can easily do by yourself. Don't worry compiling custom kernel is not that scaring as it sounds. Check this page https://wiki.archlinux.org/index.php/Kernels/Compilation/Arch_Build_System
You just need to pull patch from maillist and modify PKGBUILD.
I note the wiki on custom kernel is out of date on the Boot Loader section - info there is for grub 0.9 and arch now uses grub 2.
Same problem:
/var/log/errors.log
Jun 27 21:46:45 lap3 kernel: [ 19.133236] Bluetooth: Wrong link type (-71)
Jun 27 21:46:49 lap3 kernel: [ 23.160061] hid-generic 0005:1532:0008.0001: unknown main item tag 0x0
patch I used was this:
$ cat bluetooth-1.patch
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 4be6a26..68843a2 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -4333,7 +4333,7 @@ static inline int l2cap_information_rsp(struct l2cap_conn *conn,
struct l2cap_info_rsp *rsp = (struct l2cap_info_rsp *) data;
u16 type, result;
- if (cmd_len != sizeof(*rsp))
+ if (cmd_len < sizeof(*rsp))
return -EPROTO;
type = __le16_to_cpu(rsp->type);
Try to compile 3.9.7 with 2 bluetooth commits reverted - "15794d484f64" "22b74ee1ace25".
If it still does not work - then send the information to linux-bluetooth maillist http://vger.kernel.org/vger-lists.html#linux-bluetooth
$ git revert 22b74ee1ace25
$ git diff HEAD~2 > my_changes.diff
# now revert back to the original
$ git reset --hard v3.9.7
So I generate patches for bluetooth commits using:
$ git format-patch -1 15794d4
$ git format-patch -1 22b74ee
And sent it to you via mail. Like with previous patch you need to put it into your package folder and modify PKGBUILD (as you want to patch the linux sources before building it). Note that you need to use "patch -R .. < .." to *revert* commits - patches that I sent are forward commits.
In any case - try to revert "Fix-missing-length-checks-for-L2CAP-signal" it should fix your bug. After that report it to linux-bluetooth maillist.
I just switched to testing kernel 3.9.8 and looks same - the file src/patch-3.9.8 seems to have both of these BT patches in.
I may be missing something - if I hand apply the patches they go in fine - if I apply them in PKGBLD as first step of prepare then I get complaints when it applies the upstream patch - if I move the patch command below that then I get complaints for my patch line.
Some of the occurrences of the != vs < may be ok as they seem to be on exit where the != may be ok .. I have not read the code so I am not sure.
Anyway - I applied the mailing list patch to testing/3.9.8 and while I still do see similar errors.log the delay is not as noticable but still delayed. Which is odd as I didn't notice any BT changes from 3.9.7 yo 3.9.8
gene
> the file src/patch-3.9.8 seems to have both of these BT patches in.
No there are not there. I was able to build kernel with any of the patches.
I patches linux for you. See the PKGBUILD files in the attachement. Unpack it. Find "For Gene" comment, unpack patches one by one and build it. Starting from 0001-Bluetooth-Fix-missing-length-checks-for-L2CAP-signal.patch.
The please send results to linux-bluetooth maillist. It is better place to continue debugging the issue.
I will compile and test with patches you provided and report back
...
patching file tools/perf/scripts/python/net_dropmonitor.py
patching file kernel/printk.c
Hunk #1 succeeded at 61 with fuzz 2 (offset 3 lines).
patching file net/bluetooth/l2cap_core.c
Hunk #1 succeeded at 4221 (offset -112 lines).
patching file net/bluetooth/l2cap_core.c
Hunk #12 FAILED at 4185.
1 out of 15 hunks FAILED -- saving rejects to file net/bluetooth/l2cap_core.c.rej
==> ERROR: A failure occurred in prepare().
Aborting...
Test kernels with each 3 patches - you need to build kernel 3 times and check result 3 times.
I just switched to testing kernel 3.9.8 and looks same - the file src/patch-3.9.8 seems to have both of these BT patches in.
I may be missing something - if I hand apply the patches they go in fine - if I apply them in PKGBLD as first step of prepare then I get complaints when it applies the upstream patch - if I move the patch command below that then I get complaints for my patch line.
Some of the occurrences of the != vs < may be ok as they seem to be on exit where the != may be ok .. I have not read the code so I am not sure.
Anyway - I applied the mailing list patch to testing/3.9.8 and while I still do see similar errors.log the delay is not as noticable but still delayed. Which is odd as I didn't notice any BT changes from 3.9.7 yo 3.9.8
gene
I had tested 1 of 3 patches which did make the problem go away - and planned to test other 2 this weekend - however 3.10 is out and it doesn't have the problem - so I guess let's close this one out as fixed upstream