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
Task Type Bug Report
Category Kernel
Status Closed
Assigned To No-one
Architecture x86_64
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

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

Closed by  Tobias Powalowski (tpowa)
Friday, 19 July 2013, 05:17 GMT
Reason for closing:  Fixed
Comment by Anatol Pomozov (anatolik) - Wednesday, 26 June 2013, 19:17 GMT
"Bluetooth: Wrong link type" indicates that message comes from net/bluetooth sources. I checked patches that were submit there:

$ 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>"
Comment by Anatol Pomozov (anatolik) - Wednesday, 26 June 2013, 20:17 GMT
There is also a patch (not merged upstream/stable yet) that fixes a regression in cb3b3152b2f593 ("Bluetooth: Fix missing length checks for L2CAP signalling PDUs") http://www.spinics.net/lists/linux-bluetooth/msg36466.html

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.
Comment by Gene (GeneC) - Thursday, 27 June 2013, 01:33 GMT
I wonder if the arch maintainer would mind building a patched kernel which I'd happily test?
Comment by Anatol Pomozov (anatolik) - Thursday, 27 June 2013, 03:43 GMT
Hi Gene.

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.
Comment by Gene (GeneC) - Thursday, 27 June 2013, 04:39 GMT
Ok looks simple enough - I'll try do it tomorrow.
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.
Comment by Gene (GeneC) - Friday, 28 June 2013, 01:50 GMT
Built custom kernel - no problem at all. Updated grub.cfg using grub-mkconfig. Booted new kernel fine.

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);
Comment by Anatol Pomozov (anatolik) - Friday, 28 June 2013, 02:56 GMT
Make sure that you added "patch < bluetooth-1.patch" to PKGBUILD.

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
Comment by Gene (GeneC) - Friday, 28 June 2013, 03:01 GMT
Thanks - For the git impaired - can you provide a quick howto for me on how i revert those commits?
Comment by Anatol Pomozov (anatolik) - Friday, 28 June 2013, 03:20 GMT
$ git revert 15794d484f64
$ git revert 22b74ee1ace25
$ git diff HEAD~2 > my_changes.diff

# now revert back to the original
$ git reset --hard v3.9.7
Comment by Gene (GeneC) - Friday, 28 June 2013, 12:29 GMT
Need a little more help on this. I imagine I first need to set up a git repo based on linus repo. Then I need to vary the above to get teh diff based on 3.9.7 - then i apply the diff to arch build?
Comment by Anatol Pomozov (anatolik) - Friday, 28 June 2013, 14:17 GMT
Actually you need "stable" linux repo. Linus manages upstream (aka HEAD) linux, and Greg Hartman handles "stable" one. Here is the stable URL git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git

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.
Comment by Anatol Pomozov (anatolik) - Friday, 28 June 2013, 15:59 GMT
Actually I can attach the patches to this bug.
Comment by Anatol Pomozov (anatolik) - Friday, 28 June 2013, 16:02 GMT
Another thing I noticed is that "cmd_len != sizeof(*rsp)" appears in the 0001-Bluetooth-Fix-missing-length-checks-for-L2CAP-signal.patch 4 times. But the maillist patch fixed only one of them.

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.
Comment by Gene (GeneC) - Saturday, 29 June 2013, 19:34 GMT
Patches don't apply cleanly - get prompt if want to revert - looks like they are already in the Arch package upstream patch.
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
Comment by Anatol Pomozov (anatolik) - Saturday, 29 June 2013, 22:13 GMT
Are you talking about this message "The next patch would create the file arch/powerpc/include/uapi/asm/tm.h,"? It looks like a 'makepkg' limitation that breaks 'prepare()' stage if patch adds a file (it worth filing a separate bug). Try to remove "src" and "pkg" directories and rebuild package again.

> 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.
Comment by Gene (GeneC) - Sunday, 30 June 2013, 00:46 GMT
Thanks for making this easy for me - and yes .../tm.h message.
I will compile and test with patches you provided and report back

Comment by Gene (GeneC) - Sunday, 30 June 2013, 00:48 GMT
Sigh ... I get this now:
...
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...
Comment by Anatol Pomozov (anatolik) - Sunday, 30 June 2013, 01:20 GMT
You should enable ONLY ONE of the 3 patches. One of the patches reverts the whole bluetooth change, another patch fixes bug in that change - it is not a surprise that they conflict each other.

Test kernels with each 3 patches - you need to build kernel 3 times and check result 3 times.
Comment by Gene (GeneC) - Friday, 05 July 2013, 18:52 GMT
Patches don't apply cleanly - get prompt if want to revert - looks like they are already in the Arch package upstream patch.
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
Comment by Gene (GeneC) - Friday, 05 July 2013, 18:57 GMT
Sorry for double post - restarted browser and I messed up.

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

Loading...