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.
Same behaviour with Fedora 19 and 18. Used to work flawlessly in Fedora 17. Bluetooth dongle works with other devices like android phones.
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.
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.
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.
bluez-libs-4.101-9.fc19.x86_64 bluez-cups-4.101-9.fc19.x86_64 bluez-libs-devel-4.101-9.fc19.x86_64 bluez-4.101-9.fc19.x86_64 kernel-3.11.7-200.fc19.x86_64
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.
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...
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 and 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.
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: https://fedoraproject.org/wiki/How_to_use_kdump_to_debug_kernel_crashes With a dump we could probably investigate and understand a bit more.
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: https://bugs.archlinux.org/task/37587 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.
Seems the chromium guys had a similar issue: http://code.google.com/p/chromium/issues/detail?id=242344 They papered over the issue with: http://www.spinics.net/lists/linux-bluetooth/msg15564.html
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"
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?
*** Bug 1031070 has been marked as a duplicate of this bug. ***
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.
Thanks. Initial work to fix this is here: http://www.spinics.net/lists/linux-bluetooth/msg41904.html It has not been included in any tree yet as the patch is still under discussion
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.
I confirm that this still occurs on Fedora 20. The kernel crashed after few seconds usage. kernel-3.12.6-300.fc20.x86_64 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.
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.
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.
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: http://virtuallyhyper.com/2012/09/setup-apple-wireless-keyboard-via-bluetooth-on-fedora-17/ 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 Extract 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
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: http://koji.fedoraproject.org/koji/taskinfo?taskID=6430928 Can anyone test and report back please?
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.
The patched kernel (from comment 22) continues to work pretty well for me. No oopses, uptime 2 days 13 hours with intermittent use.
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. :)
The kernel from comment 22 fixes the issue for me as well. How does the patch get promoted to a released update?
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.
Hello, Newbie here, apologies in advance if your reaction is "Duh!". How can I go about installing that kernel from link 22.
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)
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
Hi Lukáš, it was a scratch build and they expire after a while. The patch comes from here for those interested: http://www.spinics.net/lists/linux-bluetooth/msg41725.html It should shortly make it via the HID tree. Once that happens I'll report here. hth, Michele
It now hit the linus tree: commit a4b1b5877b514b276f0f31efe02388a9c2836728 Author: David Herrmann <dh.herrmann> Date: Thu Dec 19 12:09:32 2013 +0100 HID: Bluetooth: hidp: make sure input buffers are big enough $ git tag --contains a4b1b58 v3.14-rc4
How could I test this before 3.14 makes it to updates-testing?
Grab the rawhide kernels from koji or the rawhide nodebug repo.
I added this to F19/F20 in git. Thanks much Michele!
kernel-3.13.6-100.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/kernel-3.13.6-100.fc19
kernel-3.13.6-200.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/kernel-3.13.6-200.fc20
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: https://admin.fedoraproject.org/updates/FEDORA-2014-3651/kernel-3.13.6-100.fc19 then log in and leave karma (feedback).
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.
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.