public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Meyer <thomas@m3y3r.de>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Jiri Kosina <jkosina@suse.cz>, "Rafael J. Wysocki" <rjw@sisk.pl>,
	Frans Pop <elendil@planet.nl>,
	linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org
Subject: Re: 2.6.30: suspend-to-ram, second s2r wakes up immediately
Date: Mon, 29 Jun 2009 20:13:06 +0200	[thread overview]
Message-ID: <1246299186.15821.19.camel@localhost> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0906171816280.23010-100000@iolanthe.rowland.org>

Am Mittwoch, den 17.06.2009, 18:53 -0400 schrieb Alan Stern: 
> On Wed, 17 Jun 2009, Thomas Meyer wrote:
> 
> > > Can you run the test again, this time with no extraneous USB devices 
> > > plugged in?  (That includes hubs.)  And before starting the test, 
> > > collect the contents of /sys/kernel/debug/usb/devices (you'll probably 
> > > have to mount /sys/kernel/debug first).
> > 
> > Sure. Rearranging the usb devices and removing some hubs makes the
> > problem go away in most cases...
> > 
> > This device combination seems to show the immediate wake up behaviour:
> 
> These logs are much better.  The ideal would be to have no I/O from 
> the mouse or keyboard.  (Which means you'd have to use a PS/2 keyboard 
> or a network login to initiate the test...)
> 
> Or no I/O from the network device.  What happens if you ifconfig it
> down before starting the test?

Same result. booting without the network device attached the problem
still occur.

> 
> > Here /proc/bus/usb/devices:
> > 
> > T:  Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 45 Spd=480 MxCh= 0
> > D:  Ver= 2.00 Cls=02(comm.) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
> > P:  Vendor=0411 ProdID=00bc Rev= 0.06
> > S:  Manufacturer=Broadcom
> > S:  Product=WLI-U2-KG125S
> > S:  SerialNumber=8057
> > C:* #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=500mA
> > I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=ff Driver=rndis_wlan
> > E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
> > I:* If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_wlan
> > E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> > E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=125us
> 
> If you unplug the Broadcom device from this reduced configuration, do 
> the immediate resumes still happen?

Yes.

> 
> > T:  Bus=01 Lev=01 Prnt=01 Port=05 Cnt=02 Dev#= 47 Spd=480 MxCh= 4
> > D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=02 MxPS=64 #Cfgs=  1
> > P:  Vendor=04b4 ProdID=6560 Rev= 0.09
> > C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=100mA
> > I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=01 Driver=hub
> > E:  Ad=81(I) Atr=03(Int.) MxPS=   1 Ivl=256ms
> > I:* If#= 0 Alt= 1 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=02 Driver=hub
> > E:  Ad=81(I) Atr=03(Int.) MxPS=   1 Ivl=256ms
> 
> This a separate (not built into the keyboard) powered hub, right?

Yes. And this thing seems to be responsible for the instant resume. Not
using a USB 2.0 hub, than the problem doesn't occur any more!

> 
> > T:  Bus=01 Lev=02 Prnt=47 Port=01 Cnt=01 Dev#= 48 Spd=1.5 MxCh= 0
> > D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
> > P:  Vendor=413c ProdID=2003 Rev= 1.00
> > S:  Manufacturer=DELL
> > S:  Product=DELL USB Keyboard
> > C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=100mA
> > I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=01 Driver=usbhid
> > E:  Ad=81(I) Atr=03(Int.) MxPS=   8 Ivl=10ms
> > I:* If#= 1 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=00 Prot=00 Driver=usbhid
> > E:  Ad=82(I) Atr=03(Int.) MxPS=   8 Ivl=10ms
> 
> If you unplug the keyboard but leave the mouse attached, do you still 
> get the immediate resumes?

Yes. But not using a USB 2.0 hub, the problem goes away.

> 
> > T:  Bus=01 Lev=02 Prnt=47 Port=02 Cnt=02 Dev#= 49 Spd=1.5 MxCh= 0
> > D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
> > P:  Vendor=045e ProdID=0029 Rev= 1.08
> > S:  Manufacturer=Microsoft
> > S:  Product=Microsoft IntelliMouse® Optical
> > C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA
> > I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=02 Driver=usbhid
> > E:  Ad=81(I) Atr=03(Int.) MxPS=   4 Ivl=10ms
> > 
> > Fail log:
> 
> > success with above setup (re-plugging mouse, then suspend to ram works):
> 
> No other changes, just unplugging and replugging the mouse?  Do you
> think this was responsible for the success or was it only a
> coincidence? If you leave the mouse unplugged, does suspend work 100%
> of the time?

I guess the USB 2.0 hub does something differently than expected?!
Hardware bug or linux bug? (But re-plugging the mouse into the USB 2.0
hub, makes resume work again! Strange, mhh?)

> 
> I won't go into details about the log data.  A few things stand out:
> 
> 	There was no remote wakeup request from either the mouse
> 	or the keyboard.
> 
> 	Your EHCI controller showed an overcurrent condition on
> 	ports 1 and 2 after the resume.  But this showed up in
> 	both logs, so it probably wasn't the cause.
> 
> 	The EHCI controller showed that it had received wakeup
> 	events on both ports: the one connected to the Broadcom
> 	and the one connected to the hub.  That's very suspicious,
> 	but it also occurred in both logs.
> 
> 	Neither log shows the mouse being resumed.  But it must
> 	have been, because the "success" log shows data transfers
> 	from the mouse later on.  This may indicate that the usbmon
> 	buffer is getting filled up.  You can check this by looking
> 	in usbmon's 0s or 1s file.
> 
> 	The rndis_wlan driver didn't behave very well during suspend.
> 	It tried to carry out several transfers to the device while
> 	the device was suspended, which it shouldn't have done.
> 	The transfers all failed, of course.  The same thing happened
> 	in both logs.
> 
> In short, I don't see any significant difference to explain why you
> sometimes get an immediate resume.  More testing is needed, especially
> to make sure that the earlier results weren't just random coincidences.  
> And of course, the answer to the questions above will help.

My current working setup involves no USB 2.0 hub and it's:

T:  Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh=10
B:  Alloc= 39/900 us ( 4%), #Int=  3, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=1d6b ProdID=0001 Rev= 2.06
S:  Manufacturer=Linux 2.6.30 ohci_hcd
S:  Product=OHCI Host Controller
S:  SerialNumber=0000:00:02.0
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms

T:  Bus=02 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#=  4 Spd=1.5 MxCh= 0
D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=413c ProdID=2003 Rev= 1.00
S:  Manufacturer=DELL
S:  Product=DELL USB Keyboard
C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=01 Driver=usbhid
E:  Ad=81(I) Atr=03(Int.) MxPS=   8 Ivl=10ms
I:* If#= 1 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=00 Prot=00 Driver=usbhid
E:  Ad=82(I) Atr=03(Int.) MxPS=   8 Ivl=10ms

T:  Bus=02 Lev=01 Prnt=01 Port=05 Cnt=02 Dev#=  5 Spd=1.5 MxCh= 0
D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=045e ProdID=0029 Rev= 1.08
S:  Manufacturer=Microsoft
S:  Product=Microsoft IntelliMouse® Optical
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=02 Driver=usbhid
E:  Ad=81(I) Atr=03(Int.) MxPS=   4 Ivl=10ms

T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=480 MxCh=10
B:  Alloc=  0/800 us ( 0%), #Int=  1, #Iso=  0
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=1d6b ProdID=0002 Rev= 2.06
S:  Manufacturer=Linux 2.6.30 ehci_hcd
S:  Product=EHCI Host Controller
S:  SerialNumber=0000:00:02.1
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   4 Ivl=256ms

T:  Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 23 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=02(comm.) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=0411 ProdID=00bc Rev= 0.06
S:  Manufacturer=Broadcom
S:  Product=WLI-U2-KG125S
S:  SerialNumber=8057
C:* #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=ff Driver=rndis_wlan
E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_wlan
E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=125us

greetings
thomas



  reply	other threads:[~2009-06-29 18:13 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-14 16:13 2.6.30: suspend-to-ram, second s2r wakes up immediately Thomas Meyer
2009-06-14 16:28 ` Rafael J. Wysocki
2009-06-14 16:44   ` Thomas Meyer
2009-06-14 17:01     ` Rafael J. Wysocki
2009-06-14 18:31       ` Frans Pop
2009-06-14 18:57         ` Rafael J. Wysocki
2009-06-15 15:37           ` Thomas Meyer
2009-06-14 19:07         ` Thomas Meyer
2009-06-14 19:29           ` Rafael J. Wysocki
2009-06-14 20:44             ` Alan Stern
2009-06-14 20:50             ` Jiri Kosina
2009-06-15 16:29               ` Thomas Meyer
2009-06-16  8:15                 ` Jiri Kosina
2009-06-16 17:13                   ` Thomas Meyer
2009-06-16 14:26                 ` Alan Stern
2009-06-16 17:47                   ` Thomas Meyer
2009-06-16 18:50                     ` Alan Stern
2009-06-17 21:50                       ` Thomas Meyer
2009-06-17 22:24                         ` Frans Pop
2009-06-29 17:30                           ` Thomas Meyer
2009-06-17 22:53                         ` Alan Stern
2009-06-29 18:13                           ` Thomas Meyer [this message]
2009-06-29 20:16                             ` Alan Stern

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1246299186.15821.19.camel@localhost \
    --to=thomas@m3y3r.de \
    --cc=elendil@planet.nl \
    --cc=jkosina@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=rjw@sisk.pl \
    --cc=stern@rowland.harvard.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox