Thinkpad T410: resume broken

Fri May 23 10:33:29 UTC 2014

[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.

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.