Bug 1027465 - Apple bluetooth magic trackpad crashes system
Apple bluetooth magic trackpad crashes system
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
Unspecified Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
: 1031070 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2013-11-06 17:09 EST by Nicola
Modified: 2014-03-15 11:24 EDT (History)
19 users (show)

See Also:
Fixed In Version: kernel-3.13.6-100.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-03-10 02:50:18 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
One of the kernel oops (when generated) (3.91 KB, text/plain)
2013-11-06 17:09 EST, Nicola
no flags Details
another kernel backtrace from apple magic trackpad crash (31.01 KB, text/plain)
2013-11-12 05:48 EST, Ilkka Tengvall
no flags Details
lsusb -vs 4:2 - for usb bt dongle (10.73 KB, text/plain)
2013-11-12 05:52 EST, Ilkka Tengvall
no flags Details

  None (edit)
Description Nicola 2013-11-06 17:09:05 EST
Created attachment 820739 [details]
One of the kernel oops (when generated)

Description of problem:
Apple bluetooth magic trackpad crashes system.

Version-Release number of selected component (if applicable):
Fedora 19 and 18.

How reproducible:
Always, just start using it.

Steps to Reproduce:
1. Switch on trackpad
2. Start using it
3. Crashes within 1 minute

Actual results:
Kernel oops

Expected results:
Should work flawlessly as used to do in Fedora 17

Additional info:
Changed two boxes and two bluetooth dongles to no avail.
Concernes all kernel series 3.11 and original 3.9 of F19.
Comment 1 Nicola 2013-11-06 17:10:25 EST
Same behaviour with Fedora 19 and 18. Used to work flawlessly in Fedora 17.
Bluetooth dongle works with other devices like android phones.
Comment 2 Ilkka Tengvall 2013-11-12 05:48:40 EST
Created attachment 822828 [details]
another kernel backtrace from apple magic trackpad crash

I also experience this, it was so on f18 and is still so in up to date f19.

Here the latest kernel oops from it as attachment. I don't know if there is really anything useful in it, though. The point being, the mouse can be attached, it works for minute or so, and then bad things start to happen: kernel backtrace -> GUI stuck -> abrt starts acting like crazy -> system is unusable -> need to reboot.
Comment 3 Ilkka Tengvall 2013-11-12 05:52:21 EST
Created attachment 822830 [details]
lsusb -vs 4:2  - for usb bt dongle

here is some info about the bluetooth adapter which is used for mouse connection. I use that succesfully daily for apple keyboard. It's the mouse that kills it.
Comment 4 Ilkka Tengvall 2013-11-12 06:25:10 EST
I tried it the second time today, and now it totally paniced the kernel. The backtrace that I saw on screen was from tcp stack handling a packet got from network interrupt. So it seems totally unrelated. I will try some other bluetooth mouse to see if it's any mouse, or trackpad that kills the kernel.
Comment 5 Ilkka Tengvall 2013-11-12 06:26:31 EST
Comment 6 Ilkka Tengvall 2013-11-15 08:18:34 EST
I've been using now two days some other bt mouse with no problems. It's only apple magic trackpad that is able to crash the kernel.
Comment 7 Michele Baldessari 2013-11-17 09:29:12 EST
Weird. The traces seem to be quite non-bluetooth/apple related.
Nicola's traces seem to be radeon related:
[701588.593477]  [<ffffffffa00c3b2d>] ? radeon_fence_emit+0x2d/0xf0 [radeon]
[701588.593535]  [<ffffffff8164e6b2>] ? _raw_spin_lock+0x22/0x30
[701588.593544]  [<ffffffff8164b8b6>] __mutex_unlock_slowpath+0x16/0x40
[701588.593552]  [<ffffffff8164ae93>] ww_mutex_unlock+0x33/0x40
[701588.593575]  [<ffffffffa007159a>] ttm_eu_fence_buffer_objects+0x9a/0xf0 [ttm]
[701588.593623]  [<ffffffffa00dbd6f>] radeon_cs_parser_fini+0x16f/0x190 [radeon]
[701588.593669]  [<ffffffffa00dc776>] radeon_cs_ioctl+0x2f6/0xa30 [radeon]
[701588.593705]  [<ffffffffa0014142>] drm_ioctl+0x532/0x660 [drm]
[701588.593724]  [<ffffffff811a7ab0>] ? do_sync_read+0x80/0xb0
[701588.593736]  [<ffffffff811b9f6d>] do_vfs_ioctl+0x2dd/0x4b0
[701588.593746]  [<ffffffff811ba1c1>] SyS_ioctl+0x81/0xa0
[701588.593755]  [<ffffffff81656e99>] system_call_fastpath+0x16/0x1b

[701613.925260]  [<ffffffff8164b8b6>] __mutex_unlock_slowpath+0x16/0x40
[701613.925266]  [<ffffffff8164ae93>] ww_mutex_unlock+0x33/0x40
[701613.925287]  [<ffffffffa007159a>] ttm_eu_fence_buffer_objects+0x9a/0xf0 [ttm]
[701613.925333]  [<ffffffffa00dbd6f>] radeon_cs_parser_fini+0x16f/0x190 [radeon]
[701613.925373]  [<ffffffffa00dc776>] radeon_cs_ioctl+0x2f6/0xa30 [radeon]
[701613.925403]  [<ffffffffa0014142>] drm_ioctl+0x532/0x660 [drm]
[701613.925420]  [<ffffffff811a7ab0>] ? do_sync_read+0x80/0xb0
[701613.925429]  [<ffffffff811b9f6d>] do_vfs_ioctl+0x2dd/0x4b0
[701613.925436]  [<ffffffff811ba1c1>] SyS_ioctl+0x81/0xa0
[701613.925444]  [<ffffffff81656e99>] system_call_fastpath+0x16/0x1b

Ilkka's trace seem to hit in ext4:
[ 2242.711530]  [<ffffffff81647c7f>] dump_stack+0x45/0x56
[ 2242.711540]  [<ffffffff8106715d>] warn_slowpath_common+0x7d/0xa0
[ 2242.711547]  [<ffffffff8106723a>] warn_slowpath_null+0x1a/0x20
[ 2242.711554]  [<ffffffff8126e2a0>] start_this_handle+0x550/0x5a0
[ 2242.711562]  [<ffffffff811bac87>] ? poll_freewait+0x47/0xa0
[ 2242.711568]  [<ffffffff811bbd4e>] ? do_sys_poll+0x11e/0x560
[ 2242.711575]  [<ffffffff8118e1bc>] ? kmem_cache_alloc+0x1ac/0x210
[ 2242.711582]  [<ffffffff8126e490>] ? jbd2__journal_start+0x90/0x1e0
[ 2242.711589]  [<ffffffff8126e4f3>] jbd2__journal_start+0xf3/0x1e0
[ 2242.711598]  [<ffffffff81230239>] ? ext4_setattr+0x3c9/0x6a0
[ 2242.711606]  [<ffffffff81256359>] __ext4_journal_start_sb+0x69/0xe0
[ 2242.711614]  [<ffffffff81230239>] ext4_setattr+0x3c9/0x6a0
[ 2242.711622]  [<ffffffff811c2b58>] notify_change+0x1b8/0x340
[ 2242.711629]  [<ffffffff811a64eb>] do_truncate+0x6b/0xa0
[ 2242.711636]  [<ffffffff811a6164>] ? do_dentry_open+0x214/0x280
[ 2242.711644]  [<ffffffff811b6e27>] do_last+0x847/0xe00
[ 2242.711652]  [<ffffffff811b749b>] path_openat+

[ 2242.711660]  [<ffffffff811b813a>] do_filp_open+0x3a/0x90
[ 2242.711668]  [<ffffffff811c3e5d>] ? __alloc_fd+0x7d/0x110
[ 2242.711675]  [<ffffffff811a75de>] do_sys_open+0x12e/0x210
[ 2242.711682]  [<ffffffff811a76de>] SyS_open+0x1e/0x20
[ 2242.711690]  [<ffffffff81656e99>] system_call_fastpath+0x16/0x1b
[ 2242.711695] ---[ end trace 85b60c167f550b2d ]---

I'd say some corruption issues triggered by the corresponding bluetooth module...
Comment 8 Nicola 2013-11-17 17:01:39 EST
Even weirder, it has never been a radeon video card in any of
my boxes. 990FX chipset, cpu FX-8350, Nvidia video only. 
dmesg | grep -i radeon
lspci | grep -i radeon 
both return an empty set.

Btw, same behaviour with apple trackpad observer also on F20 beta with latest kernel 3.11.8.
Comment 9 Michele Baldessari 2013-11-17 18:02:20 EST
Odd indeed. Well one way to get a bit closer to the root of the issue
would be to capture a crash dump when the system crashes. More infos here:

With a dump we could probably investigate and understand a bit more.
Comment 10 Clarke Wixon 2013-11-19 18:50:07 EST
I'm experiencing this problem as well.  The Apple trackpad is a great piece of hardware, but getting it supported and KEEPING it supported has been a pain in the neck.

I haven't been in a troubleshooting mood lately, so I have just been using my old USB trackball for the last few weeks.  But if I recall correctly, I was seeing some messages in the system journal or dmesg about corrupted packets, very much like this:


I'll see if I can reproduce.  But when this first started, I deleted the trackpad (and Apple keyboard too) from Bluetooth Devices in Gnome, then attempted to re-add them without success.  I wasn't able to get them paired again.
Comment 11 Michele Baldessari 2013-12-01 06:42:58 EST
Seems the chromium guys had a similar issue:

They papered over the issue with:
Comment 12 Daniel Sjoholm 2013-12-12 07:28:17 EST
I'm experiencing this as well on fedora 18, however it happened (for me) in one of the recent kernel updates.
For example: kernel 3.10.4-100.fc18.x86_64 works flawlessly.

I can trigger the freeze/crash by pressing down on it.
If not actually pressing down on it then it can go for a while, sometimes indefinitely, before crashing.

As stated in another bug report (#1018066) which is filed against gnome-bluetooth:
"This happens for me too on Fedora 18. Complete system freeze a short while after my Magic Trackpad connects via bluetooth and I start using it.

Happened for me after I updated on Oct 24th after about a long month wait since last time. The only package I can identify as guilty from quickly skimming what was updated would be the kernel. I have however not tried to back down a version yet.

Running KDE without gnome-bluetooth installed.
Kernel: kernel-3.11.4-101.fc18.x86_64"
Comment 13 Michele Baldessari 2014-01-03 03:24:23 EST
So I have a vmcore from Daniel, which I am looking at. What I was wondering
was that different people on this BZ have different opinions as to which kernels
this used to work with.

Daniel: Works 3.10.4 - Broken 3.11.X
Nicola: Concernes all kernel series 3.11 and original 3.9 of F19 (so I assume it is broken on 3.9 as well)

So my question would be. Does it work 100% on 3.10.x and it broke 3.11.4?
Comment 14 Michele Baldessari 2014-01-04 09:35:47 EST
*** Bug 1031070 has been marked as a duplicate of this bug. ***
Comment 15 Daniel Sjoholm 2014-01-05 07:48:48 EST
Currently using 3.10.12 (the latest 3.10.x kernel I have at the moment), and have been for an hour or so, and the trackpad has not caused any issues.
Comment 16 Michele Baldessari 2014-01-07 06:27:56 EST
Thanks. Initial work to fix this is here:

It has not been included in any tree yet as the patch is still under discussion
Comment 17 Clarke Wixon 2014-01-07 13:48:15 EST
Michele, going back to your 2014-01-03 inquiry - my vague recollection adds to the apparent consensus that this bug started around 3.11.x (though I don't remember any issues with 3.9).

I think I started seeing it around October on Fedora 19, but at the time I was too busy with other matters to do any troubleshooting, so I just substituted my USB keyboard and trackball.

Bluetooth input on 3.11/3.12 has been ALL KINDS of troublesome for me.  The Apple keyboard also has been problematic (bug 1039738).  I'm hoping the cleanup here will help on that as well.
Comment 18 Ilkka Tengvall 2014-01-09 05:22:07 EST
I confirm that this still occurs on Fedora 20. The kernel crashed after few seconds usage.


Additional fun with the fruit products, the keyboard wont pair with F20 anymore, but that would be another story... ah, Clarke has made it to another story. I'll join.
Comment 19 Ergels Gaxhaj 2014-01-10 21:19:07 EST
I can confirm as well that this is also happening in F20. 

I am unable to pair my apple keyboard at all. I can pair the trackpad successfully but once I start using it for a few seconds my system freezes and i have to reboot.

I skipped F19 but in F18 it worked somewhat ok. It would disconnect every now and again and I would have to hit the power button on the trackpad and keyboard to pair it again. Also, once my laptop went into hibernate after bringing the system up they  would never pair again. It required a reboot.
Comment 20 Alex Markley 2014-01-14 01:52:16 EST
I also have been having this issue. It was stable for me in Fedora 18 until kernel updates broke Magic Trackpad support. The system would always crash shortly after pairing the Trackpad. I upgraded to Fedora 20 hoping that would fix it, but it did not.

When I found this bug report, I installed kernel-3.10.14-100.fc18.x86_64 onto my Fedora 20 system, and now Magic Trackpad support appears stable again.
Comment 21 Ergels Gaxhaj 2014-01-17 19:23:14 EST
Alex thanks. 

Your workaround worked. However, I had to take some additional steps to resolve the issue with the keyboard not pairing due to the error below. 

Running # sudo service bluetooth status  revealed the following error:

 "Agent replied with an error: org.freedesktop.DBus.Error.UnknownMethod, No such method 'DisplayPinCode'"

For those of you who get the same error follow the instructions on the links below. The second link is in Spanish but you should be able to follow along.
I have also posted instructions below if you cannot follow.

This will help with troubleshooting your Bluetooth service: 
This will help resolve the error above: http://misnotasdelinux.wordpress.com/2013/12/08/teclado-bluetooth-no-se-conecta-en-fedora-20/

1. enable source repositories in /etc/yum.repos.d/fedora.repo and fedora-updates.repo. I enabled both but only fedora.repo may be required.

2. # yumdownloads --source bluez

4. # cd ~/Downloads

5. # mkdir bluez

6. # cd bluez

7. # rpm2cpio ../bluez-5.13-1.fc20.src.rpm | cpio -idv

8. # sudo yum install git flex dbus-devel glib2-devel libcap-ng-devel libical-devel readline-devel systemd-devel cups cups-devel libtool autoconf automake

9. # rpmbuild --nodeps -bp ./bluez.spec

10. # cd ~/home/<user>/rpmbuild/BUILD/bluez-5.11/test

Power on keyboard to begin paring process.

Retrieve mac address.
11. # hcitool scan
 Scanning ...
 90:7F:61:8C:B0:9C Apple TouchPad Wireless Keyboard

Run and enter the pin at the end of the "DisplayPinCode" line.
12. # ./simple-agent hci0 90:7F:61:8C:B0:9C
 Agent registered
 DisplayPinCode (/org/bluez/hci0/dev_90_7F_61_8C_B0_9C, 680090)
 Device paired

13. # ./test-device trusted 90:7F:61:8C:B0:9C yes
Comment 22 Michele Baldessari 2014-01-20 15:56:06 EST
I've spun a test kernel with the patch from comment 16. As it has not yet made it upstream, some positive (or negative feedback) might help:

Can anyone test and report back please?
Comment 23 Clarke Wixon 2014-01-21 13:16:40 EST
Michele, thanks.  Partial success I guess:

At this point I have only been able to test it for about ten minutes, but so far, my system is crash-free on that test kernel from koji.  I have been moving the pointer around with the Apple trackpad, clicking, tapping, dragging, and two-finger scrolling without any problems at all.

Bluetooth still seems pretty brittle, though, as a subsequent attempt to scan for my keyboard caused BT to drop out entirely, with the Gnome BT wizard GUI advising that no adapter could be found.  The "airplane mode" indicator icon showed up in Gnome shell.

Turned airplane mode off, manually re-connected the trackpad by flicking the connection switch in the GUI, and the trackpad was working again.  No keyboard though!

I will do some more testing (repeatability, persistence after reboot, etc.), but that's all I have had time for today.
Comment 24 Clarke Wixon 2014-01-24 00:39:24 EST
The patched kernel (from comment 22) continues to work pretty well for me.  No oopses, uptime 2 days 13 hours with intermittent use.
Comment 25 Alex Markley 2014-01-27 13:32:52 EST
Sorry for taking so long to test this. I have installed the kernel from comment 22 and it's working great for me!

I have tested the Magic Trackpad now for several minutes, and it no longer appears to crash the system or generate kernel oops messages in the logs.

I have also tested an Apple Magic Mouse, Apple Wireless Keyboard, and a generic bluetooth keyboard. All are working as expected.

(However, as Clarke mentioned in comment 23, the Gnome bluetooth front end remains confused about keyboard pairing and PIN entry. It fails badly. I had to use bluedevil-wizard to pair the keyboards.)

Anyway, I am just super excited to have my trackpad working again with a modern kernel. :)
Comment 26 Ravikiran Rajagopal 2014-01-30 20:41:07 EST
The kernel from comment 22 fixes the issue for me as well. How does the patch get promoted to a released update?
Comment 27 Clarke Wixon 2014-02-05 15:59:26 EST
Let me revise my prior comments.  Sometimes it works, sometimes it doesn't.

Part of the time I will boot and log in, and it only takes a click on the trackpad to get it to reconnect and start working.  That's the best-case scenario.

Other times I will boot and log in, click on the trackpad, the bluetooth status icon will blink on and off, and I never get a connection.  When that happens, I get a slew of bluetooth error messages in dmesg that look like the following:

Bluetooth: hci0 ACL packet for unknown connection handle ##
Bluetooth: hci0 corrupted ACL packet

The "##" varies.

Is anyone else seeing this on the patched kernel?

Still, mercifully, no oopses.
Comment 28 Wilbert Sequeira 2014-02-06 00:33:34 EST

Newbie here, apologies in advance if your reaction is "Duh!". 

How can I go about installing that kernel from link 22.
Comment 29 Michele Baldessari 2014-02-06 17:42:51 EST
The patch that fixes the crash has finally received some positive feedback and
barring surprises should hit 3.14 (might be CCed to stable as well)
Comment 30 Lukáš Fryč 2014-02-13 04:04:45 EST
Hi Michele, I tried to download [1] the test kernel from Comment 22, but kojipkgs.fedoraproject.org responds with Forbidden (permission denied).

I assume there must be something wrong with permissions as other packaged can be downloaded with no problem.

[1] http://koji.fedoraproject.org/koji/taskinfo?taskID=6430930
Comment 31 Michele Baldessari 2014-02-13 11:06:18 EST
Hi Lukáš,

it was a scratch build and they expire after a while. The patch comes from
here for those interested:

It should shortly make it via the HID tree. Once that happens I'll report here.

Comment 32 Michele Baldessari 2014-02-25 08:34:17 EST
It now hit the linus tree:
commit a4b1b5877b514b276f0f31efe02388a9c2836728
Author: David Herrmann <dh.herrmann@gmail.com>
Date:   Thu Dec 19 12:09:32 2013 +0100

    HID: Bluetooth: hidp: make sure input buffers are big enough

$ git tag --contains a4b1b58
Comment 33 John Schmitt 2014-03-01 22:06:13 EST
How could I test this before 3.14 makes it to updates-testing?
Comment 34 Josh Boyer 2014-03-03 09:01:16 EST
Grab the rawhide kernels from koji or the rawhide nodebug repo.
Comment 35 Josh Boyer 2014-03-04 13:39:07 EST
I added this to F19/F20 in git.  Thanks much Michele!
Comment 36 Fedora Update System 2014-03-07 17:52:09 EST
kernel-3.13.6-100.fc19 has been submitted as an update for Fedora 19.
Comment 37 Fedora Update System 2014-03-07 17:53:28 EST
kernel-3.13.6-200.fc20 has been submitted as an update for Fedora 20.
Comment 38 Fedora Update System 2014-03-08 23:39:18 EST
Package kernel-3.13.6-100.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kernel-3.13.6-100.fc19'
as soon as you are able to, then reboot.
Please go to the following url:
then log in and leave karma (feedback).
Comment 39 Fedora Update System 2014-03-10 02:50:18 EDT
kernel-3.13.6-200.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 40 Fedora Update System 2014-03-15 11:24:11 EDT
kernel-3.13.6-100.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.