lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201106302025.04722.a.miskiewicz@gmail.com>
Date:	Thu, 30 Jun 2011 20:25:04 +0200
From:	Arkadiusz Miskiewicz <a.miskiewicz@...il.com>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Kernel development list <linux-kernel@...r.kernel.org>,
	USB list <linux-usb@...r.kernel.org>
Subject: Re: 3.0rc3-rc5: usb stops working after resume from suspend

On Thursday 30 of June 2011, Alan Stern wrote:
> On Thu, 30 Jun 2011, Arkadiusz Miskiewicz wrote:
> > > Actually bisection might end up being quicker.  This looks like a
> > > pretty tricky problem.  Maybe you should start a bisection while I look
> > > at this stuff; you'll probably reach an answer before I do!
> > 
> > Looks tricky indeed. There seem to be two related problems actually. I'm
> > bisecting between rc3 (good) and rc5 (bad).
> 
> These are separate problems, not related.

Ok.

> 
> > At 3.0.0-rc4-00059-g143e859 usb auto-suspend suspends my mouse usb port
> > after like 4 seconds when I don't move mouse. That's not a problem. The
> > problem is that resume takes like 1-2seconds and in that time mouse
> > cursor doesn't move when I move mouse of course.
> 
> For the record, the log you posted shows that autoresuming the mouse
> takes less than 60 ms.  If it seems longer, it may be that the mouse
> doesn't send a wakeup request as soon as you move it or press a
> button.

One new info. suspend/resume from ram is not needed. Fresh boot, I'm running 
on battery, plug power, unplug power and these weird thing start to happen 
with mouse unsuspend delay.

Unfortunately turns out that this behaviour is also seen on my rc3 but laptop 
has to run on battery. So not a regression.

Example (on 3.0.0-rc3-00205-gdd34739)

[ 1155.447146] hub 3-0:1.0: port 1, status 0103, change 0004, 12 Mb/s
[ 1165.970079] uhci_hcd 0000:00:1a.0: release dev 2 ep82-INT, period 2, phase 
1, 17 us
[ 1165.971071] uhci_hcd 0000:00:1a.0: release dev 2 ep81-INT, period 8, phase 
4, 17 us

mouse works but I don't move it, so it suspends

[ 1165.973074] usb 3-1: usb auto-suspend

now from this moment until...

[ 1167.988114] hub 3-0:1.0: hub_suspend
[ 1167.988132] usb usb3: bus auto-suspend
[ 1167.988138] usb usb3: suspend_rh
[ 1167.988169] uhci_hcd 0000:00:1a.0: uhci_pci_suspend
[ 1167.988191] uhci_hcd 0000:00:1a.0: PCI INT A disabled
[ 1167.988197] uhci_hcd 0000:00:1a.0: hcd_pci_runtime_suspend: 0
[ 1167.988351] uhci_hcd 0000:00:1a.0: power state changed by ACPI to D3

untill this moment every my mouse move causes nothing but after some delay it 
resumes

[ 1170.545790] uhci_hcd 0000:00:1a.0: power state changed by ACPI to D0
[ 1170.545801] uhci_hcd 0000:00:1a.0: power state changed by ACPI to D0
[ 1170.545946] uhci_hcd 0000:00:1a.0: power state changed by ACPI to D0
[ 1170.545954] uhci_hcd 0000:00:1a.0: power state changed by ACPI to D0
[ 1170.545971] uhci_hcd 0000:00:1a.0: PCI INT A -> GSI 20 (level, low) -> IRQ 
20
[ 1170.545986] uhci_hcd 0000:00:1a.0: setting latency timer to 64
[ 1170.545995] uhci_hcd 0000:00:1a.0: uhci_pci_resume
[ 1170.546041] uhci_hcd 0000:00:1a.0: hcd_pci_runtime_resume: 0
[ 1170.546052] usb usb3: usb wakeup-resume
[ 1170.546061] usb usb3: usb auto-resume
[ 1170.546066] usb usb3: wakeup_rh
[ 1170.588078] hub 3-0:1.0: hub_resume
[ 1170.588097] uhci_hcd 0000:00:1a.0: port 1 portsc 0095,01
[ 1170.588108] hub 3-0:1.0: port 1: status 0103 change 0004
[ 1170.588169] hub 3-0:1.0: state 7 ports 2 chg 0002 evt 0000
[ 1170.588188] uhci_hcd 0000:00:1a.0: port 1 portsc 0095,01
[ 1170.604114] usb 3-1: usb wakeup-resume
[ 1170.604133] usb 3-1: finish resume
[ 1170.607134] uhci_hcd 0000:00:1a.0: reserve dev 2 ep81-INT, period 8, phase 
4, 17 us
[ 1170.607150] uhci_hcd 0000:00:1a.0: reserve dev 2 ep82-INT, period 2, phase 
1, 17 us
[ 1170.607162] hub 3-0:1.0: resume on port 1, status 0
[ 1170.607169] hub 3-0:1.0: port 1, status 0103, change 0004, 12 Mb/s

and is working fine until another suspend.

Another example on the same kernel as above:

Jun 30 19:30:28 localhost kernel: [ 1344.451124] hub 3-0:1.0: port 1, status 
0103, change 0004, 12 Mb/s
Jun 30 19:30:33 localhost kernel: [ 1348.822094] uhci_hcd 0000:00:1a.0: 
release dev 2 ep82-INT, period 2, phase 1, 17 us
Jun 30 19:30:33 localhost kernel: [ 1348.823082] uhci_hcd 0000:00:1a.0: 
release dev 2 ep81-INT, period 8, phase 4, 17 us

mouse suspends

Jun 30 19:30:33 localhost kernel: [ 1348.825086] usb 3-1: usb auto-suspend

but I don't move it

Jun 30 19:30:35 localhost kernel: [ 1350.840096] hub 3-0:1.0: hub_suspend
Jun 30 19:30:35 localhost kernel: [ 1350.840113] usb usb3: bus auto-suspend
Jun 30 19:30:35 localhost kernel: [ 1350.840119] usb usb3: suspend_rh
Jun 30 19:30:35 localhost kernel: [ 1350.840150] uhci_hcd 0000:00:1a.0: 
uhci_pci_suspend
Jun 30 19:30:35 localhost kernel: [ 1350.840172] uhci_hcd 0000:00:1a.0: PCI 
INT A disabled
Jun 30 19:30:35 localhost kernel: [ 1350.840178] uhci_hcd 0000:00:1a.0: 
hcd_pci_runtime_suspend: 0

I wait for this to show:

Jun 30 19:30:35 localhost kernel: [ 1350.840332] uhci_hcd 0000:00:1a.0: power 
state changed by ACPI to D3

and then start moving mouse, after short while 

Jun 30 19:30:38 localhost kernel: [ 1354.037335] uhci_hcd 0000:00:1a.0: power 
state changed by ACPI to D0
Jun 30 19:30:38 localhost kernel: [ 1354.037346] uhci_hcd 0000:00:1a.0: power 
state changed by ACPI to D0
Jun 30 19:30:38 localhost kernel: [ 1354.037495] uhci_hcd 0000:00:1a.0: power 
state changed by ACPI to D0
Jun 30 19:30:38 localhost kernel: [ 1354.037504] uhci_hcd 0000:00:1a.0: power 
state changed by ACPI to D0
Jun 30 19:30:38 localhost kernel: [ 1354.037521] uhci_hcd 0000:00:1a.0: PCI 
INT A -> GSI 20 (level, low) -> IRQ 20
Jun 30 19:30:38 localhost kernel: [ 1354.037535] uhci_hcd 0000:00:1a.0: 
setting latency timer to 64
Jun 30 19:30:38 localhost kernel: [ 1354.037544] uhci_hcd 0000:00:1a.0: 
uhci_pci_resume
Jun 30 19:30:38 localhost kernel: [ 1354.037593] uhci_hcd 0000:00:1a.0: 
hcd_pci_runtime_resume: 0
Jun 30 19:30:38 localhost kernel: [ 1354.037604] usb usb3: usb wakeup-resume
Jun 30 19:30:38 localhost kernel: [ 1354.037612] usb usb3: usb auto-resume
Jun 30 19:30:38 localhost kernel: [ 1354.037618] usb usb3: wakeup_rh
Jun 30 19:30:38 localhost kernel: [ 1354.076034] hub 3-0:1.0: hub_resume
Jun 30 19:30:38 localhost kernel: [ 1354.076054] uhci_hcd 0000:00:1a.0: port 1 
portsc 0095,01
Jun 30 19:30:38 localhost kernel: [ 1354.076065] hub 3-0:1.0: port 1: status 
0103 change 0004
Jun 30 19:30:38 localhost kernel: [ 1354.076111] hub 3-0:1.0: state 7 ports 2 
chg 0002 evt 0000
Jun 30 19:30:38 localhost kernel: [ 1354.076130] uhci_hcd 0000:00:1a.0: port 1 
portsc 0095,01
Jun 30 19:30:38 localhost kernel: [ 1354.092045] usb 3-1: usb wakeup-resume
Jun 30 19:30:38 localhost kernel: [ 1354.092065] usb 3-1: finish resume
Jun 30 19:30:38 localhost kernel: [ 1354.095086] uhci_hcd 0000:00:1a.0: 
reserve dev 2 ep81-INT, period 8, phase 4, 17 us
Jun 30 19:30:38 localhost kernel: [ 1354.095101] uhci_hcd 0000:00:1a.0: 
reserve dev 2 ep82-INT, period 2, phase 1, 17 us
Jun 30 19:30:38 localhost kernel: [ 1354.095115] hub 3-0:1.0: resume on port 
1, status 0
Jun 30 19:30:38 localhost kernel: [ 1354.095122] hub 3-0:1.0: port 1, status 
0103, change 0004, 12 Mb/s

it is useable again until new suspend happens. So mouse recovers quicker but 
only after "power state changed by ACPI to D3" happens.

Summary: not a regression, unfortunately feature unusable with this mouse on 
this laptop.

> On the other hand, the log shows that the mouse does work properly
> following system suspend.  Part of the problem here seems to be the
> Logitech receiver; even 130 ms after the USB bus was reset, the
> receiver still had not reconnected itself electrically to the bus.
> 
> With 3.0-rc4 that's okay, because the receiver is rediscovered after
> the resume and it starts working again.  With 3.5-rc5 the rediscovery
> doesn't occur, apparently because the khubd thread is hung.
> 
> > With previous kernel (rc5) the problem become worse as I described in
> > previous emails.
> 
> And now you know why, more or less -- we still have to figure out the
> reason for the hang.  Probably something goes wrong when cdc-ether is
> unbound from the wireless device.

If cdc-ether is not loaded at all then usb works fine after resume from ram on 
rc5.

> It's not even clear that autosuspend is a problem.  Doesn't 3.0-rc3
> also autosuspend the mouse?

The problem with usb not working if cdc-ether is used happens when also  on 
external power and afaik autosuspend doesn't kick-in in such case, right?

> If not, have you compared the contents of
> /sys/bus/usb/devices/3-1/power/control under the various kernels?

It's auto.

> 
> The fact is, some mice are very slow and non-responsive while waking up
> from suspend.  There's not much we can do about that except to avoid
> autosuspending them -- which you do by making sure the power/control
> file contains "on".

I'll disable usb autosuspend - it's better when off than having to configure 
every usb device I plug in ;/

> Alan Stern

-- 
Arkadiusz Miƛkiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ