Bug 200938 - service moused restart required after resume from suspend
Summary: service moused restart required after resume from suspend
Status: Closed Overcome By Events
Alias: None
Product: Base System
Classification: Unclassified
Component: usb (show other bugs)
Version: 10.3-STABLE
Hardware: Any Any
: --- Affects Many People
Assignee: freebsd-usb (Nobody)
URL:
Keywords: patch, patch-ready
: 202854 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-06-17 19:15 UTC by Joseph Mingrone
Modified: 2018-05-24 08:16 UTC (History)
13 users (show)

See Also:
koobs: mfc-stable10?


Attachments
r284320_stable-r291454.patch (7.98 KB, patch)
2015-12-01 08:24 UTC, rainbow
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Joseph Mingrone freebsd_committer freebsd_triage 2015-06-17 19:15:37 UTC
After an upgrade from 10-STABLE (synced a few months ago) to 10-STABLE
r281907 (Thu Apr 23) the psm mouse (pointing stick on a Lenovo X220) no longer works after a resume.  At BSDCan there were a number of X220s and others had the same problem when running CURRENT.  The problems occur in both X and at the console.

The dmesg output after putting debug.psm.loglevel=2 in /boot/loader.conf is pasted below.

There are similar PRs, but I think this one is different since the mouse was working after those reports and only broke in the last few months and none of the referenced hints in /boot/loader.conf work in this case.

Adding service moused restart to rc.resume doesn't help.  Only running it from a shell prompt after the resume works.

May  1 21:50:30 phe devd: Executing '/etc/rc.suspend acpi 0x03'
May  1 21:50:30 phe acpi: suspend at 20150501 21:50:30
May  1 21:50:33 phe kernel: uhub0: at usbus0, port 1, addr 1 (disconnected)
May  1 21:50:33 phe kernel: ugen0.2: <vendor 0x8087> at usbus0 (disconnected)
May  1 21:50:33 phe kernel: uhub2: at uhub0, port 1, addr 2 (disconnected)
May  1 21:50:33 phe kernel: ugen0.3: <Chicony Electronics Co., Ltd.> at usbus0 (disconnected)
May  1 21:50:47 phe kernel: uhub1: at usbus1, port 1, addr 1 (disconnected)
May  1 21:50:47 phe kernel: ugen1.2: <vendor 0x8087> at usbus1 (disconnected)
May  1 21:50:47 phe kernel: uhub3: at uhub1, port 1, addr 2 (disconnected)
May  1 21:50:47 phe kernel: pci0: failed to set ACPI power state D2 on \_SB_.PCI0.EXP1: AE_BAD_PARAMETER
May  1 21:50:47 phe kernel: pci0: failed to set ACPI power state D2 on \_SB_.PCI0.EXP2: AE_BAD_PARAMETER
May  1 21:50:47 phe kernel: pci0: failed to set ACPI power state D2 on \_SB_.PCI0.EXP4: AE_BAD_PARAMETER
May  1 21:50:47 phe kernel: pci0: failed to set ACPI power state D2 on \_SB_.PCI0.EXP5: AE_BAD_PARAMETER
May  1 21:50:47 phe kernel: acpi0: cleared fixed power button status
May  1 21:50:47 phe kernel: info: [drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp on
May  1 21:50:47 phe kernel: error: [drm:pid1253:intel_lvds_enable] *ERROR* timed out waiting for panel to power off
May  1 21:50:47 phe kernel: em0: link state changed to DOWN
May  1 21:50:47 phe kernel: psm0: system resume hook called.
May  1 21:50:47 phe kernel: psm0: current command byte: 0047 (reinitialize).
May  1 21:50:47 phe kernel: psm: DISABLE_DEV return code:00fa
May  1 21:50:47 phe kernel: psm: ENABLE_DEV return code:00fa
May  1 21:50:47 phe kernel: psm: DISABLE_DEV return code:00fa
May  1 21:50:47 phe kernel: psm: SET_SAMPLING_RATE (100) 00fa
May  1 21:50:47 phe kernel: psm: SET_RESOLUTION (2) 00fa
May  1 21:50:47 phe kernel: psm: SET_SCALING11 return code:00fa
May  1 21:50:47 phe kernel: psm: SET_STREAM_MODE return code:00fa
May  1 21:50:47 phe kernel: psm: SEND_AUX_DEV_STATUS return code:00fa
May  1 21:50:47 phe kernel: psm: status 00 02 64
May  1 21:50:47 phe kernel: psm: ENABLE_DEV return code:00fa
May  1 21:50:47 phe kernel: psm: SEND_AUX_DEV_STATUS return code:00fa
May  1 21:50:47 phe kernel: psm: status 20 02 64
May  1 21:50:47 phe kernel: psm0: system resume hook exiting.
May  1 21:50:47 phe kernel: uhub0: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus1
May  1 21:50:47 phe kernel: uhub1: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus0
May  1 21:50:47 phe devd: Executing '/etc/rc.resume acpi 0x03'
May  1 21:50:47 phe acpi: resumed at 20150501 21:50:47
May  1 21:50:48 phe kernel: em0: link state changed to UP
May  1 21:50:48 phe devd: Executing '/etc/rc.d/dhclient quietstart em0'
May  1 21:50:48 phe kernel: uhub1: 3 ports with 3 removable, self powered
May  1 21:50:48 phe kernel: uhub0: 3 ports with 3 removable, self powered
May  1 21:50:49 phe kernel: ugen0.2: <vendor 0x8087> at usbus0
May  1 21:50:49 phe kernel: uhub2: <vendor 0x8087 product 0x0024, class 9/0, rev 2.00/0.00, addr 2> on usbus0
May  1 21:50:49 phe kernel: ugen1.2: <vendor 0x8087> at usbus1
May  1 21:50:49 phe kernel: uhub3: <vendor 0x8087 product 0x0024, class 9/0, rev 2.00/0.00, addr 2> on usbus1
May  1 21:50:50 phe kernel: uhub2: 6 ports with 6 removable, self powered
May  1 21:50:51 phe kernel: uhub3: 8 ports with 8 removable, self powered
May  1 21:50:51 phe kernel: ugen0.3: <Chicony Electronics Co., Ltd.> at usbus0
May  1 21:50:51 phe devd: Executing '/usr/local/etc/rc.d/webcamd start ugen0.3'
May  1 21:50:51 phe devd: Executing '/usr/local/etc/rc.d/webcamd start ugen0.3'
May  1 21:50:51 phe devd: Executing 'logger Unknown USB device: vendor 0x04f2 product 0xb217 bus uhub2'
May  1 21:50:51 phe root: Unknown USB device: vendor 0x04f2 product 0xb217 bus uhub2
May  1 21:50:51 phe devd: Executing 'logger Unknown USB device: vendor 0x04f2 product 0xb217 bus uhub2'
May  1 21:50:51 phe root: Unknown USB device: vendor 0x04f2 product 0xb217 bus uhub2
May  1 21:50:51 phe devd: Executing 'logger Unknown USB device: vendor 0x04f2 product 0xb217 bus uhub2'
May  1 21:50:51 phe root: Unknown USB device: vendor 0x04f2 product 0xb217 bus uhub2
May  1 21:50:51 phe dhclient: New IP Address (em0): 192.168.2.2
May  1 21:50:51 phe dhclient: New Subnet Mask (em0): 255.255.255.0
May  1 21:50:51 phe dhclient: New Broadcast Address (em0): 192.168.2.255
May  1 21:50:51 phe dhclient: New Routers (em0): 192.168.2.1

Restart moused:

May  1 21:51:08 phe kernel: psm: DISABLE_DEV return code:00fa
May  1 21:51:08 phe kernel: psm: SEND_AUX_DEV_STATUS return code:00fa
May  1 21:51:08 phe kernel: psm: status 00 02 64
May  1 21:51:09 phe kernel: psm: ENABLE_DEV return code:00fa
May  1 21:51:09 phe kernel: psm: SEND_AUX_DEV_STATUS return code:00fa
May  1 21:51:09 phe kernel: psm: status 20 02 64
May  1 21:51:09 phe kernel: psm: SET_SAMPLING_RATE (100) 00fa
May  1 21:51:09 phe kernel: psm: SET_RESOLUTION (2) 00fa
May  1 21:51:09 phe kernel: psm: SET_SCALING11 return code:00fa
May  1 21:51:09 phe kernel: psm: SEND_AUX_DEV_STATUS return code:00fa
May  1 21:51:09 phe kernel: psm: status 20 02 64
May  1 21:51:09 phe kernel: psmintr: Sync bytes now 00c0,00c0
May 1 21:51:57 phe kernel: error: [drm:pid1498:gen6_sanitize_pm] *ERROR* Power
management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1a000000, was 12060000
May 1 21:53:54 phe kernel: error: [drm:pid1498:gen6_sanitize_pm] *ERROR* Power
management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1a0d0000, was 1a000000
Comment 1 Joseph Mingrone freebsd_committer freebsd_triage 2015-06-17 19:53:28 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.
Comment 2 Hans Petter Selasky freebsd_committer freebsd_triage 2015-06-17 20:59:32 UTC
Are you using X.org? Is this a race in X11's devd backend?

--HPS
Comment 3 Joseph Mingrone freebsd_committer freebsd_triage 2015-06-17 21:02:43 UTC
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.
Comment 4 Hans Petter Selasky freebsd_committer freebsd_triage 2015-06-17 21:03:37 UTC
See:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196678

--HPS
Comment 5 Joseph Mingrone freebsd_committer freebsd_triage 2015-08-24 17:46:06 UTC
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.
Comment 6 Steve Wills freebsd_committer freebsd_triage 2015-08-30 18:02:41 UTC
Can confirm this works well as a workaround for me.
Comment 7 Taka 2015-09-02 06:29:10 UTC
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.
Comment 8 Kurt Jaeger freebsd_committer freebsd_triage 2015-09-03 17:43:56 UTC
(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
Comment 9 Kurt Jaeger freebsd_committer freebsd_triage 2015-09-03 17:44:47 UTC
*** Bug 202854 has been marked as a duplicate of this bug. ***
Comment 10 rkoberman 2015-09-03 18:42:08 UTC
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.
Comment 11 rkoberman 2015-09-03 22:45:01 UTC
    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.
Comment 12 rkoberman 2015-09-03 23:33:54 UTC
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.
Comment 13 Kurt Jaeger freebsd_committer freebsd_triage 2015-09-04 04:21:24 UTC
(In reply to rkoberman from comment #12)
Yes, it works, see comment #8.
Comment 14 Ted W. 2015-09-26 22:41:21 UTC
(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.
Comment 15 Ted W. 2015-10-28 05:10:09 UTC
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.
Comment 16 Ted W. 2015-10-28 05:19:16 UTC
It looks like this has been fixed as of r284320.
Comment 17 rainbow 2015-12-01 08:24:56 UTC
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
Comment 18 Bengt Ahlgren 2016-02-18 09:45:11 UTC
This problem is still present in 10.3-BETA2. Any reason to not merge r284320?
Comment 19 Taka 2016-06-06 11:00:01 UTC
This bug still exists in FreeBSD 10.3-RELEASE-p4 #0: Sat May 28 12:23:44 UTC 2016
Comment 20 Kubilay Kocak freebsd_committer freebsd_triage 2016-07-08 12:27:15 UTC
Assign committer of r284320 in HEAD

Still reproducible in and needs MFC to stable/11 and stable/10
Comment 21 Kubilay Kocak freebsd_committer freebsd_triage 2016-07-08 12:29:24 UTC
Already in stable/11 presumably, only stable/10 MFC is required
Comment 22 Gleb Smirnoff freebsd_committer freebsd_triage 2017-01-02 21:25:59 UTC
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.
Comment 23 Bengt Ahlgren 2017-07-12 16:30:13 UTC
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.
Comment 24 Eitan Adler freebsd_committer freebsd_triage 2018-05-23 10:28:06 UTC
batch change of PRs untouched in 2018 marked "in progress" back to open.
Comment 25 Gleb Smirnoff freebsd_committer freebsd_triage 2018-05-23 16:04:29 UTC
Now that we (almost) have two 11.x releases, there is not point in fixing problem in stable/10.
Comment 26 Bengt Ahlgren 2018-05-24 08:16:21 UTC
(In reply to Gleb Smirnoff from comment #25)
10.x isn't EoL just yet, so this is still an open issue!