Bug 1010410
Summary: | Bluetooth Mouse Inoperative After Wake From Sleep with 3.11.1-200.fc19.x86_64 | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Garry T. Williams <gtwilliams> |
Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> |
Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 19 | CC: | anotherjonathon, bugzilla, gansalmon, gbauman, hdegoede, itamar, jonathan, kernel-maint, madhu.chinakonda, mail, marcelo.barbosa, roger.k.wells, skottler |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2013-12-01 12:36:52 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Garry T. Williams
2013-09-20 17:41:23 UTC
Update to kernel-3.10.11-200.fc19.x86_64 did not fix the problem. I continue to use 3.10.11-200.fc19.x86_64, which does not exhibit the problem. Arg. That update that fails to fix is: 3.11.2-201.fc19.x86_64. Sorry for the typo. Hi, I'm a casual Fedora user myself but I registered just to link here what appears to be the same bug, found on my archlinux install: https://bbs.archlinux.org/viewtopic.php?pid=1336852 Hopefully it helps narrowing it down. Regards, G. Also a Fedora user. Same problem. It appeared at kernel 3.11. Same machine/hardware, Thinkpad X220, has run fedora 14, 16, 17, and 19 (up to 3.11) without this. I use gnome3 openbox, and kde. It is the same on all. HTH This generic problem (bluetooth mouse non-functional after suspend/resume) has occurred intermittently since about F14, likely for various reasons. I most recently experienced it on update from kernel-3.10.13-101.fc18.x86_64 to kernel-3.11.4-101.fc18.x86_64. A hack that had worked under a previous occurrence, switching to text console (ctrl-alt-f2) and back to graphical, did not work for this regression. I've since updated to F19 and kernel-3.11.6-200.fc19.x86_64 with no resolution. At this point, the only way I've found to regain use of the mouse is to toggle bluetooth off/on with the gnome bluetooth settings gui, put the mouse into discoverable mode, and turn the mouse connection back on in the gui. If the mouse connection is showing as "on" but is not working upon resume, the only resolution I've found is to halt and power cycle the system. My laptop, Thinkpad X220, has a switch that turns off both radios. Toggle them off and back on and the BT mouse comes back. I went through what is described in Comment 5 but this is quicker if it works for you. Thanks, Roger, but this hp dv6-1030us has a touch switch for bluetooth hardware on/off that doesn't work under Fedora. Very strange. If I use the "Bluetooth Settings" popup, behavior is as above. If I just toggle Bluetooth off and on using the top panel icon, then do the same with the mouse using the drill in from the same icon, I get the mouse back without having to go to discovery mode. I can't find any doc on what difference there might be in what is done under the hood under that scenario as compared to the "Bluetooth Settings" popup scenario. Gratuitous remarks: we have serious issues with Gnome 3, dbus, and kernel regression testing, and I'd dearly love to have my bluetooth command line stuff back so I could hack my way through this. Also: I don't know what Gnome is calling on the lid "suspend" event, but it appears not to be pm-suspend, as the hooks aren't called and the pm-suspend.log does not get written. Everything is just as broken with pm-suspend, but I can at least hack at the hooks for that. The problem persists at kernel 3.11.9-200.fc19.x86_64. I've still not been able to figure out how to do command line replication of the toggling scenario in comment 8, so the awkward gui toggling remains the only workaround found. *** This bug has been marked as a duplicate of bug 988481 *** |