Bug 200938
| Summary: | service moused restart required after resume from suspend | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | Joseph Mingrone <jrm> | ||||
| Component: | usb | Assignee: | freebsd-usb (Nobody) <usb> | ||||
| Status: | Closed Overcome By Events | ||||||
| Severity: | Affects Many People | CC: | bahlgren, glebius, hps, hselasky, inoue.takashi, marcis.lielturks, matthew, pi, rainbow, rkoberman, swills, ted, usb | ||||
| Priority: | --- | Keywords: | patch, patch-ready | ||||
| Version: | 10.3-STABLE | Flags: | koobs:
mfc-stable10?
|
||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| See Also: |
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196678 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202854 |
||||||
| Attachments: |
|
||||||
|
Description
Joseph Mingrone
2015-06-17 19:15:37 UTC
I always had the trackpad disabled in the BIOS. Steve Wills noted that if he left the trackpad enabled in the BIOS, the problem goes away. I can confirm the same behaviour, i.e., with the trackpad disabled in BIOS so that only the pointing stick and discrete buttons work, the mouse doesn't work after resume. With the trackpad enabled in the BIOS, the mouse works after a resume. Are you using X.org? Is this a race in X11's devd backend? --HPS I am using X.org (xorg-server-1.14.7_5,1), but the problem occurs at the console as well when X isn't running. Here is a workaround / solution for anyone in a similar situation. Instead of disabling the trackpad in the BIOS add hw.psm.synaptics_support=1 to /boot/loader.conf and in add hw.psm.synaptics.touchpad_off=1 to /etc/sysctl.conf. Note that I've only just set this up and checked that the trackpad is indeed disabled and I've only done one suspend and resume to confirm the mouse (wihtout the trackpad) works again. I will update here if I see problems. Can confirm this works well as a workaround for me. This bug exists in 10.2 Release. I have this problem on my ThinkPad X61s which dose not have a touchpad. The synaptics workaround is not effectual. I've also tried "hint.psm.0.flags=" but it had no effect. Why? (BTW, I can use keyboard after resume. So, I tried "moused onerestart" but it didn't solve the problem. "/dev/psm0 is busy" I do not use either moused and hald. What should I restart?) Anyway, the present psm.c seems to have a serious bug and should be repaired. (In reply to Joseph Mingrone from comment #5) I can confirm, this works on X201 and X220 on FreeBSD 10.2-amd64. Thanks! See also https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202854 *** Bug 202854 has been marked as a duplicate of this bug. *** I can't say whether the psm flags are really still required. At some point in the past 4+ years I have had my T520 I was having an issue with the mouse freezing on resume. I was aware of the psm(4) flags that would force a reset as well as tickle the ThinkPoint(TM) itself and put it into loader.conf where it remains. It worked and my problems were gone. This was probably on FreeBSD8. I am running moused, no longer using hald (for X) and that has been the case for a while. I run with the touchpad off and have not tried enabling Synaptics support and then disabling the pad. That might work just fine. At least in the past I was unable to get a proper three button mouse unless I disabled it (plus I keep inadvertently moving the pointer and clicking things when it is enabled). If enabling Synaptics support and using it to disable the pad keeps the three-button working correctly and the pad, itself, dead, that would be fine. I agree that this is almost certainly a psm(4) bug, but I am nowhere near to being conversant enough with FreeBSD drivers to try debugging it myself. Last drivers I wrote were in assembly language for VMS. Wrote several of these including some really weird ones. I'll post an update when I have tried this.
Grrr! No joy at all.
I added hw.psm.synaptics_support=1 to /boot/loader.conf and restarted my system. I se no relevant messages, but there is no Synaptics support and the hw.psm.synaptics tree in sysctl is absent.
I do have hw.psm.trackpoint_support=1. Is that conflicting with the Synaptics support and keeping it from running? While I'd rather not, I'll try again without the trackpoint_support.
I can now confirm that on a T520 (contemporary and very similar to the X220) I am able to suspend and resume with both the trackpoint and the touchpad working and the touchpad can be disabled with no problems. I have removed the psm flags from loader.conf. Both TrackPoint and Synaptics support is in place and working. I have suspended and resumed repeatedly with no issues. Looks like the work around in comment #5 does the trick. Can someone (Kurt?) confirm that it works on the X220 and X201? Be sure that the touchpad is enabled in BIOS. That's why Synaptics support was not loading. (In reply to rkoberman from comment #12) Yes, it works, see comment #8. (In reply to Joseph Mingrone from comment #5) X61 on 10.2 RELEASE. Workaround ineffective. Here's what I've tried. Only fix is to `/etc/rc.d/moused restart` after resume. * hw.psm.synaptics.touchpad_off=1 #/etc/sysctl.conf * hw.psm.synaptics_support=1 #/boot/loader.conf * hint.psm.0.flags="0x6000" #/boot/devices.hints * /etc/rc.d/moused restart #/etc/rc.resume * /etc/rc.d/moused forcerestart #/etc/rc.resume I am running both moused and hald. I have disabled hald, however, and this had no effect. Since my previous comment I've updated from 10.2-RELEASE to 11.0-CURRENT. Since doing this, the issues related to moused needing a manual restart after resuming from suspend have gone away. I have yet to determine exactly which commit fixed this or what component it was but I will continue to dig through the commit logs to try to identify what might have changed in the last month or two to affect this. It looks like this has been fixed as of r284320. Created attachment 163699 [details]
r284320_stable-r291454.patch
this patch is the backport of r284320 to stable r291454.
fix the issue with touchpad disabled in the bios.
tested with T430s
This problem is still present in 10.3-BETA2. Any reason to not merge r284320? This bug still exists in FreeBSD 10.3-RELEASE-p4 #0: Sat May 28 12:23:44 UTC 2016 Assign committer of r284320 in HEAD Still reproducible in and needs MFC to stable/11 and stable/10 Already in stable/11 presumably, only stable/10 MFC is required Rui, you merged faulty r281441 to stable/10 without taking care of regression fix r284320. Please take care of the fix as well. Thanks! I don't have Thinkpads running stable/10, so I can't merge. Since you merged r281441, I presume you have. It would be great if r284320 could be merged to stable/10 now so it gets into 10.4! I've been running with it on stable/10 for a long time now on a Thinkpad X201 w/o issues, albeit with the trackpad disabled. If any additional testing is needed, I'd be happy to assist with that on my X201. batch change of PRs untouched in 2018 marked "in progress" back to open. Now that we (almost) have two 11.x releases, there is not point in fixing problem in stable/10. (In reply to Gleb Smirnoff from comment #25) 10.x isn't EoL just yet, so this is still an open issue! |