Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: ThinkPad - suspend-to-RAM intel-x86 issues and tests



On 2018/11/27 17:27, Masanobu SAITOH wrote:
  Hi, David.

On 2018/11/26 6:11, David Brownlee wrote:
I've bisected the changes against the github src copy, and it looks like the suspend/resume issue is related to the following commit:

commit 0fe469276f49bf0dc003300e0b8a35a80b7b246d (HEAD)
Author: jdolecek <jdolecek%NetBSD.org@localhost>
Date:   Mon Oct 22 20:57:07 2018 +0000

     enable MSI support where available, blatantly copied from jmcneill's msk(4)

I tried building from HEAD with just that one commit reverted, and my T420s suspends and resumes again!

iwn0 is still non responsive after resume and wm0 will not pick up an IP via dhcpcd, but the disk responds :-p

  (Note that I'm not familiar with suspend/resume though...)

  Our pci_suspend()/pci_resume() copy only first 16 bytes of each PCI

s/16 bytes/64 bytes/

config space. Other OSes copy some other control registers and
MSI/MSI-X capability area.

  Could you dump all PCI config space both before and after suspend with:

     http://www.netbsd.org/~msaitoh/pcidump

and put the two output somewhere? Diffing the two output will teach
us what we have to do.

  Thanks in advance.


David

On Sat, 24 Nov 2018 at 22:47, David Brownlee <abs%absd.org@localhost <mailto:abs%absd.org@localhost>> wrote:

    On Sat, 24 Nov 2018 at 18:52, David H. Gutteridge <david%gutteridge.ca@localhost <mailto:david%gutteridge.ca@localhost>> wrote:
     >
     > On Fri, 2018-11-23 at 21:42 +0000, David Brownlee wrote:
     > > Another couple of data points in case it helps
     > >
     > > Tested on Thinkpad T420s and T530 with NetBSD/amd64 - both have
     > > similar behaviour
     > >
     > > 8.99.25 Single user:
     > > - Suspends and seems to resume but hangs on first disk access "wd0a:
     > > device timeout reading fsbn ..."
     >
     > Yes, I get that too. pgoyette@ suggested I follow up with jdolecek@
     > about it, but I haven't had time yet to look for more details. There
     > are a number of PRs that jdolecek@ was working on fixing that
     > reference "clearing WDCTL_RST failed for drive" in the dmesg. In my
     > case, I get that error on both 8.0_STABLE and 8.99.26 (after his
     > latest changes), but it seems like it's a red herring or there's more
     > to it, because 8 still resumes reliably regardless of that warning,
     > while HEAD behaves as you've seen. I just keep getting continuous
     > output with "wd0a: device timeout writing fsbn X of X..."

    I asked jdolecek@ if it might be worth bisecting to find out when the
    hang was introduced, and he replied it was.
    I've just started using the github copy of src. Mon Oct 22 2018 was "good"

     > > netbsd-8 Single user:
     > > - Suspend (hw.acpi.sleep.state=3) and resume appears to work reliably
     > > many times in a row
     > > - Booting multi user after suspend/resume: wireless iwn0 does not
     > > appear to work "iwn0: could not load firmware .text section"
     >
     > I see that too. I haven't looked into it yet, but wondered if it was
     > as simple as forcing it to reload its firmware after resumption.

    Mmm, the man page indicates "iwn0: could not load firmware .text
    section" is reported when it attempted to
    load the firmware from disk into the device but failed, so it may be a
    little more than that :/

     > (Actually, my iwn didn't work at all, originally, because it requires
     > a different firmware file than any that are distributed by NetBSD at
     > present, and needed an addition in the driver to target that firmware.
     > I made those changes in my tree and have been testing with them on
     > both 8 and HEAD.)
     >
     > > netbsd-8 Multi user no x11:
     > > - Suspends, keyboard *usually* non responsive on resume (but can
     > > switch virtual terminals)
     >
     > I've never had this problem, I've found my T420 consistently responsive
     > whether I'm at a console or have suspended with X running (typically
     > with an Xfce4 session). When it comes back, no issues there (aside from
     > iwn).

    Thats definitely encouraging!

    David





--
-----------------------------------------------
                SAITOH Masanobu (msaitoh%execsw.org@localhost
                                 msaitoh%netbsd.org@localhost)


Home | Main Index | Thread Index | Old Index