Thinkpad T410: resume broken

Fri May 23 11:52:04 UTC 2014

Ian Smith <smithi at nimnet.asn.au> writes:

> [minus -current, not subscribed]
>
> On Thu, 22 May 2014 22:39:50 -0700, Kevin Oberman wrote:
>  > On Wed, May 21, 2014 at 12:43 PM, Jan Henrik Sylvester <me at janh.de> wrote:
>  > > On 05/21/2014 21:22, Hans Petter Selasky wrote:
>  > > > On 05/21/14 21:16, Jan Henrik Sylvester wrote:
>  > > >> Unfortunately, my USB mouse does not work anymore: After the first
>  > > >> resume, it took a few seconds until it worked again (the build in
>  > > >> touchpad was back immediately). After the second resume, it would not
>  > > >> work anymore at all, even after reconnecting it to a different EHCI
>  > > >> port. It does work at a XHCI, though, until the next resume. Anyhow,
>  > > >> this is obviously not related to the original problem.
>  > > >
>  > > > Hi,
>  > > >
>  > > > USB controller are being reset at resume, so I think this indicates a
>  > > > more fundamental PCI/BUS problem.
>  > >
>  > > Looking through dmesg, it seems that other USB devices (build-in) are
>  > > reappearing (Qualcomm Gobi 2000, Broadcom Bluetooth Device) after
>  > > resume, just not the mouse.
>
> More likely, just not anything using the external USB ports, if it's the 
> same issue that seems to be happening on (all?) X2xx, X4xx, X5xx and 
> someone mentioned a T320? - ie perhaps all modern(ish) Lenovo laptops.
>
> It's becoming clear to me that there are two distinct and probably 
> completely unrelated suspend/resume issues on these machines:
>
>  1) graphics issues, where most of the attention has been (rightly) 
>     focussed.  My X200 has older Intel i915, pre-KMS, and has NO video
>     issues on suspend/resume at all on stable/9, from console or X.
>
>  2) disappearance of external USB ports after sometimes the first and on 
>     others (such as my X200) the second resume.  This extends to there 
>     being no 5V on the connectors, which may or may not be the main 
>     problem.  It is seeming to be more likely a BIOS/ACPI issue, given
>     that USB (UCHI & EHCI here) is doing the right thing to wake them.

A peculiarity I noted on my X201 is that it does not seem to have any
USB 1.x controllers, only ehci 2.0, yet the man page says that "EHCI
controllers are peculiar in that they can only handle the USB 2.0
protocol".

I wonder if these boxes have some strange ohci or uhci controllers that
are not detected, or some kind of integrated 2.0/1.x controllers that
the ehci driver does not fully understand and therefore is causing the
resume issue?

(Yes, I also have the USB resume issue after a couple of resumes.)

Bengt

> Unless there really is some cross-relatedness, I'm very keen to see the 
> two issues disentangled.  I wrote to Hans Petter and Adrian about this 
> yesterday offlist; Adrian has confirmed he still has the no-USB problem 
> despite presumably having fixed the video one/s.
>
>  > > Are these lines likely related?
>  > >
>  > > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.PEG_:
>  > > AE_BAD_PARAMETER
>
> PEG_ is related to video I think.  I don't have one of these.
>
>  > > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP1:
>  > > AE_BAD_PARAMETER
>  > > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP2:
>  > > AE_BAD_PARAMETER
>  > > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP4:
>  > > AE_BAD_PARAMETER
>  > > pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP5:
>  > > AE_BAD_PARAMETER
>
> I expect these are likely to be your 4-in-1 card reader.  Note that 
> these messages appear on the suspend path, not the resume.  I'm not 
> sure, but suspect that this/these device/s just don't allow setting 
> power state D2, but it might take some ACPI debugging to track down, or 
> at least matching verbose pci boot messages with device capabilities.
>
> I haven't tried my multi-card reader at all, let alone after resume, but 
> if you have suitable cards you could test that, with verbose logging on?
>
> On mine, consistently, on the suspend path:
>
> May  7 18:36:26 x200 kernel: vga0: saving 4932 bytes of video state
> May  7 18:36:26 x200 kernel: vga0: saving color palette
> May 7 18:36:26 x200 kernel: pci0: failed to set ACPI power state D2 on
> \_SB_.PCI0.EXP0: AE_BAD_PARAMETER
> May 7 18:36:26 x200 kernel: pci0: failed to set ACPI power state D2 on
> \_SB_.PCI0.EXP1: AE_BAD_PARAMETER
> May 7 18:36:26 x200 kernel: pci0: failed to set ACPI power state D2 on
> \_SB_.PCI0.EXP2: AE_BAD_PARAMETER
> May 7 18:36:26 x200 kernel: pci0: failed to set ACPI power state D2 on
> \_SB_.PCI0.EXP3: AE_BAD_PARAMETER
>
> Then the resume path (I wish there was a message separating these as the 
> suspend timestamps are bogus at this point, those messages were stored):
>
> May  7 18:36:26 x200 kernel: em0: Link is up 100 Mbps Full Duplex
> May  7 18:36:26 x200 kernel: em0: link state changed to UP
> May  7 18:36:26 x200 kernel: acpi_lid0: run_prep cleaned up for \_SB_.LID_
> May  7 18:36:26 x200 kernel: acpi_button0: run_prep cleaned up for \_SB_.SLPB
> May  7 18:36:26 x200 kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.VID_
> May  7 18:36:26 x200 kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.IGBE
> May  7 18:36:26 x200 kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.USB3
> May  7 18:36:26 x200 kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.USB4
> May  7 18:36:26 x200 kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.USB5
> May  7 18:36:26 x200 kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.EHC1
> May  7 18:36:26 x200 kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.HDEF
> May  7 18:36:26 x200 kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.EXP0
> May  7 18:36:26 x200 kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.EXP1
> May  7 18:36:26 x200 kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.EXP2
> May  7 18:36:26 x200 kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.EXP3
> May  7 18:36:26 x200 kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.USB0
> May  7 18:36:26 x200 kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.USB1
> May  7 18:36:26 x200 kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.USB2
> May  7 18:36:26 x200 kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.EHC0
> May  7 18:36:26 x200 kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.LPC_
> May  7 18:36:26 x200 kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.SATA
> May  7 18:36:26 x200 kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.EXP0
> May  7 18:36:26 x200 kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.EXP1
> May  7 18:36:26 x200 kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.EXP2
> May  7 18:36:26 x200 kernel: pci0: set ACPI power state D0 on \_SB_.PCI0.EXP3
> May  7 18:36:26 x200 kernel: vga0: calling BIOS POST
>
> Note that EXP0 to EXP3 are here always reinitialised to power state D0 
> twice, but I don't know what that denotes .. perhaps some timing delay.
>
>  > > Thanks,
>  > > Jan Henrik
>  > 
>  > Could this be another face of the problems that requires kbdmux to keep the
>  > USB keyboard working correctly with vt(4)?
>
> I'm pretty sure by tis stage that video interaction issues are separate. 
> Leaving VESA out of my kernel only led to no video on console on resume, 
> and to repeat, I have NO video resume issues with my pre-kms i915.
>
> cheers, Ian
>
> PS I shouldn't even be writing this; I'm still suffering from the 'flu 
> while in the middle of moving house.  Back on deck next week sometime.
> _______________________________________________
> freebsd-mobile at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-mobile
> To unsubscribe, send any mail to "freebsd-mobile-unsubscribe at freebsd.org"