On 20/07/14(Sun) 17:34, Mike Burns wrote:
> On 2014-07-19 16.43.30 +0200, Martin Pieuchot wrote:
> > On 13/07/14(Sun) 18:22, Mike Burns wrote:
> > > Thinkpad X1 Carbon with a touchscreen, running 5.5-stable. When I resume
> > > from suspend my Xorg.0.log is flooded with:
> > >
> > > (EE) ws: /dev/wsmouse1: read error Input/output error
> > >
> > > In my dmesg:
> > >
> > > wsmouse1: can't attach mux (error=5)
> >
> > I did a lot of work after 5.5 to prevent races like this one. Could you
> > try a snapshot and tell me if you still see this error during suspend-
> > resume?
>
> This race is indeed fixed in the snapshot from 18 July. Thanks!
>
> In this snapshot, the touchscreen no longer works at all. The only
> mention of wsmouse in dmesg is now:
>
> wsmouse0 at pms0 mux 0
>
> That is, no mention of wsmouse1.
That's why you don't see the error message: no device, no error (8
More seriously, can you plug external USB devices to your laptop and see
if they are correctly recognized? Do they attach to uhub2 or uhub3?
> After resume, my normal mouse no longer works.
Even if you restart X? Does it work after suspend/resume under
wsmoused(8)?
Could you also check if you have a "disable legacy" option in your BIOS
that would make your keyboard and mouse appear as USB devices once
toggled. Could you try that if it exists?
> Suspend/resume is much more erratic now, too: sometimes zzz(1) will
> immediately suspend and then pressing the power button will cause it to
> immediately resume - this is typically what happens the first time I
> suspend after booting. Other times it will blank the screen and spin the
> fans loudly instead of suspending. Once it seemed to suspend just fine,
> but instead of resuming it just spun the fans loudly. Just now the
> system suspended then immediately resumed by itself - interestingly, the
> mouse works fine when that happens.
If the systems immediately "resumes" by itself that means something
failed in the suspend path. Could you try the diff below and tell me
if you get more information?
> Here's an Xorg.0.log from a successful suspend:
> [...]
> [ 124.548] (II) AIGLX: Suspending AIGLX clients for VT switch
> [ 131.466] (II) AIGLX: Resuming AIGLX clients after VT switch
> [ 131.466] (II) intel(0): switch to mode 1600x900@60.0 on LVDS1 using pipe
> 0, position (0, 0), rotation normal, reflection none
> [ 131.479] (II) intel(0): EDID vendor "LGD", prod id 898
> [ 131.479] (II) intel(0): Printing DDC gathered Modelines:
> [ 131.479] (II) intel(0): Modeline "1600x900"x0.0 108.00 1600 1648 1680
> 1924 900 903 908 936 -hsync -vsync (56.1 kHz eP)
> [ 131.601] (EE) xf86OpenSerial: Cannot open device /dev/wsmouse
> Device busy.
> [ 131.601] (EE) ws: /dev/wsmouse: cannot open input device
> [ 131.601] (EE) ws: /dev/wsmouse: wsOpen failed Device busy
> [ 131.601] [dix] couldn't enable device 7
This might be the reason with you can't use your mouse after resume.
> Here's a dmesg from a successful suspend/resume:
>
>
> OpenBSD 5.6-beta (GENERIC.MP) #288: Fri Jul 18 19:04:06 MDT 2014
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
How many suspend resumes did you do?
> [...]
> uhub2 at uhub0 port 1 "Intel Rate Matching Hub" rev 2.00/0.00 addr 2
> ugen0 at uhub2 port 3 "Auth Biometric Coprocessor" rev 1.10/0.01 addr 3
> ugen1 at uhub2 port 4 "Broadcom Corp BCM20702A0" rev 2.00/1.12 addr 4
> uvideo0 at uhub2 port 6 configuration 1 interface 0 "SunplusIT INC.
> Integrated Camera" rev 2.00/36.22 addr 5
> video0 at uvideo0
> uhub3 at uhub1 port 1 "Intel Rate Matching Hub" rev 2.00/0.00 addr 2
> vscsi0 at root
> scsibus2 at vscsi0: 256 targets
> softraid0 at root
> scsibus3 at softraid0: 256 targets
> sd1 at scsibus3 targ 1 lun 0: <OPENBSD, SR CRYPTO, 005> SCSI2 0/direct fixed
> sd1: 227906MB, 512 bytes/sector, 466751982 sectors
> root on sd1a (a1a57dffe6790454.a) swap on sd1b dump on sd1b
>
> - here I suspended
>
> ugen0 detached
> ugen1 detached
> video0 detached
> uvideo0 detached
> uhub2 detached
> uhub0 detached
> uhub3 detached
> uhub1 detached
Here the resume "starts" from the USB point of view:
> uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
> uhub1 at usb1 "Intel EHCI root hub" rev 2.00/1.00 addr 1
>
> - here I resumed
>
> uhub2 at uhub0 port 1 "Intel Rate Matching Hub" rev 2.00/0.00 addr 2
> ugen0 at uhub2 port 3 "Auth Biometric Coprocessor" rev 1.10/0.01 addr 3
> ugen1 at uhub2 port 4 "Broadcom Corp BCM20702A0" rev 2.00/1.12 addr 4
> uvideo0 at uhub2 port 6 configuration 1 interface 0 "SunplusIT INC.
> Integrated Camera" rev 2.00/36.22 addr 5
> video0 at uvideo0
> uhub3 at uhub1 port 1 "Intel Rate Matching Hub" rev 2.00/0.00 addr 2
Here it looks like you suspended once again:
> ugen0 detached
> ugen1 detached
> video0 detached
> uvideo0 detached
> uhub2 detached
> uhub0 detached
> uhub3 detached
> uhub1 detached
And resumed:
> uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
> uhub1 at usb1 "Intel EHCI root hub" rev 2.00/1.00 addr 1
> uhub2 at uhub0 port 1 "Intel Rate Matching Hub" rev 2.00/0.00 addr 2
> ugen0 at uhub2 port 3 "Auth Biometric Coprocessor" rev 1.10/0.01 addr 3
> ugen1 at uhub2 port 4 "Broadcom Corp BCM20702A0" rev 2.00/1.12 addr 4
> uvideo0 at uhub2 port 6 configuration 1 interface 0 "SunplusIT INC.
> Integrated Camera" rev 2.00/36.22 addr 5
> video0 at uvideo0
> uhub3 at uhub1 port 1 "Intel Rate Matching Hub" rev 2.00/0.00 addr 2
Suspended once more...
> ugen0 detached
> ugen1 detached
> video0 detached
> uvideo0 detached
> uhub2 detached
> uhub0 detached
> uhub3 detached
> uhub1 detached
... and resumed:
> uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
> uhub1 at usb1 "Intel EHCI root hub" rev 2.00/1.00 addr 1
> uhub2 at uhub0 port 1 "Intel Rate Matching Hub" rev 2.00/0.00 addr 2
> ugen0 at uhub2 port 3 "Auth Biometric Coprocessor" rev 1.10/0.01 addr 3
> ugen1 at uhub2 port 4 "Broadcom Corp BCM20702A0" rev 2.00/1.12 addr 4
> uvideo0 at uhub2 port 6 configuration 1 interface 0 "SunplusIT INC.
> Integrated Camera" rev 2.00/36.22 addr 5
> video0 at uvideo0
> uhub3 at uhub1 port 1 "Intel Rate Matching Hub" rev 2.00/0.00 addr 2
>
>
> I do not have a useful dmesg from when suspend failed. Do you know what
> might be useful for debugging that?
Just try this diff that should prevent you from suspending in the first
case:
Index: ehci.c
===================================================================
RCS file: /home/ncvs/src/sys/dev/usb/ehci.c,v
retrieving revision 1.162
diff -u -p -r1.162 ehci.c
--- ehci.c 12 Jul 2014 20:13:48 -0000 1.162
+++ ehci.c 21 Jul 2014 13:41:16 -0000
@@ -1056,6 +1056,18 @@ ehci_activate(struct device *self, int a
ehci_reset(sc);
sc->sc_bus.use_polling--;
+
+ if (!TAILQ_EMPTY(&sc->sc_intrhead)) {
+ printf("%s: intr head not empty\n",
+ sc->sc_bus.bdev.dv_xname);
+ return (EINVAL);
+ }
+ if (sc->sc_intrxfer != NULL) {
+ printf("%s: root intr not null\n",
+ sc->sc_bus.bdev.dv_xname);
+ return (EINVAL);
+ }
+
break;
case DVACT_RESUME:
sc->sc_bus.use_polling++;
