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

[Masanobu SAITOH <msaitoh%execsw.org@localhost>]

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)