Date: Fri, 23 May 2014 20:33:17 +1000 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Kevin Oberman <rkoberman@gmail.com> Cc: Jan Henrik Sylvester <me@janh.de>, Hans Petter Selasky <hps@selasky.org>, Adrian Chadd <adrian@freebsd.org>, Stefan Ehmann <shoesoft@gmx.net>, "freebsd-mobile@freebsd.org" <freebsd-mobile@freebsd.org> Subject: Re: Thinkpad T410: resume broken Message-ID: <20140523193134.Q89611@sola.nimnet.asn.au> In-Reply-To: <CAN6yY1v3DW-0FDr=vx0tFBOWjw1wukV0VZfjrbbtZOxDuhWiqA@mail.gmail.com> References: <53762216.8020205@gmx.net> <CAJ-VmokswTyyfrwbcwzX6c07ui_aTzbJ=jTm_rGw0r824ChaTw@mail.gmail.com> <CAN6yY1t2Zcvy=yMXOqJozRQ-LDp%2BD74gWymrfcCRExuGvfcj=Q@mail.gmail.com> <537753F3.6000202@FreeBSD.org> <537CFB7C.60702@janh.de> <537CFCE4.2000300@selasky.org> <537D01F5.2050101@janh.de> <CAN6yY1v3DW-0FDr=vx0tFBOWjw1wukV0VZfjrbbtZOxDuhWiqA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[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@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140523193134.Q89611>