Re: ThinkPad - suspend-to-RAM intel-x86 issues and tests
On 2018/12/06 0:22, David Brownlee wrote: On Sat, 1 Dec 2018 at 01:27, SAITOH Masanobu wrote: Committed. Hi - is this worth pulling up into netbsd-8? Of course yes! I ran a quick test and my T420s suspends/resumes fine with a netbsd-8 kernel and no X11 running. x11 looks to have issues which seem resolved in current, but it feels like a worthwhile fix to have in -8. It needed two other small changes pulled up (git hashes from https://github.com/NetBSD/src) # 5fca1fb34425590e514f0d745f936998fded9c18 PCIE_HAS_LINKREGS # 3fe2d92356e154aef689fc05111ac422c89c0785 PCIE_HAS_ROOTREGS The above two changes were pulled up two days ago. # 2e6fa7a8bbdd4df652e4cfb605385ff915176cbe suspend/resume I'll send the pullup request today. Sample kernel at http://ftp.netbsd.org/pub/NetBSD/misc/abs/netbsd-8-amd64-pci-resume/netbsd.gz if anyone wants to give it a quick go. (Many thanks again to msaitoh@ for all the work in analysing and You're welcome and thank you. If your didn't find the MSI's change, we couldn't fix this problem. fixing this - its really nice to have some fully functional suspend/resume use cases (eg :T420s with external mouse :) David -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
Re: ThinkPad - suspend-to-RAM intel-x86 issues and tests
On Sat, 1 Dec 2018 at 01:27, SAITOH Masanobu wrote: > > Committed. > Hi - is this worth pulling up into netbsd-8? I ran a quick test and my T420s suspends/resumes fine with a netbsd-8 kernel and no X11 running. x11 looks to have issues which seem resolved in current, but it feels like a worthwhile fix to have in -8. It needed two other small changes pulled up (git hashes from https://github.com/NetBSD/src) # 5fca1fb34425590e514f0d745f936998fded9c18 PCIE_HAS_LINKREGS # 3fe2d92356e154aef689fc05111ac422c89c0785 PCIE_HAS_ROOTREGS # 2e6fa7a8bbdd4df652e4cfb605385ff915176cbe suspend/resume Sample kernel at http://ftp.netbsd.org/pub/NetBSD/misc/abs/netbsd-8-amd64-pci-resume/netbsd.gz if anyone wants to give it a quick go. (Many thanks again to msaitoh@ for all the work in analysing and fixing this - its really nice to have some fully functional suspend/resume use cases (eg :T420s with external mouse :) David
Re: ThinkPad - suspend-to-RAM intel-x86 issues and tests
Hi, David H. Gutteridge wrote: I have good news and bad news, and it's the same thing: I was hoping the Toshiba laptop had more parity with one of your laptops in terms of hardware, but unfortunately, it's a consumer model, an M40X with an Intel Dothan CPU, integrated 915GM graphics, a RealTek Ethernet card, Atheros WiFi, etc. It's similar to the X110: it has a bit of trouble on 8.0_STABLE resuming with the i915 DRM driver, but that's addressed in 8.99.26, where it resumes as reliably as my T420. (With the same caveats about restoring hardware state that are being discussed elsewhere in this thread: I haven't tried that patch on it yet.) well, you could try running the latest kernel there and see how it works! I think we can exclude the ethernet and WiFi cards as culprit for me, because I disabled them. Graphics should matter less, if it is on console with disabled DRM, right? There isn't really much left. I'll wait a day or two for releng to build the new kernel with the fixes and test again all the NetBSD ThinkPads again! Riccardo
Re: ThinkPad - suspend-to-RAM intel-x86 issues and tests
Committed. Thank you all! On 2018/12/01 7:17, David Brownlee wrote: > On Thu, 29 Nov 2018 at 06:15, Masanobu SAITOH wrote: >> >> On 2018/11/28 22:12, SAITOH Masanobu wrote: > http://ftp.netbsd.org/pub/NetBSD/misc/abs/acpi-suspend-resume/pcidump.pre > http://ftp.netbsd.org/pub/NetBSD/misc/abs/acpi-suspend-resume/pcidump.post The diff says we should save/restore MSI table. We also should save/restore some other registers. Give me one or two days to resolve the problem. >>> >>> Please try the following diff: >>> >>> http://www.netbsd.org/~msaitoh/pci-resume-20181118-0.dif >>> >>> Even if I use this change with Thinkpad X220, it doesn't recover from >>> suspend... >> >> But, my X61 survived from suspend with this patch! > > I can confirm a T420s, T430 and T530 all suspend and resume single > user or multiuser without X11 including disk and network fine with > this patch (excellent stuff!). > > X11 on T420s > - Suspend and resumes fine while in X or on console with X running in > another virtual console > - The display seems to reverts to a blank console on resume into which > you can type > - Switching vtys fixes the display > - The ThinkPad touchpoint stops working on resume (but an external USB > mouse is fine) > > X11 on T530 > - Panics on resume if X is running (even if I then switch to the console) > drm/i915: Resetting chip after gpu hang > ufm_fault(0x8a77a0c0, 0x0, 1) -> w > fatal page fault in supervisor mode > ... > at netbsd:fini_hash_table+0x88: movq 1 > > but this is awesome progress! > > Thanks > > David > > DAvid > -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
Re: ThinkPad - suspend-to-RAM intel-x86 issues and tests
On Thu, 29 Nov 2018 at 06:15, Masanobu SAITOH wrote: > > On 2018/11/28 22:12, SAITOH Masanobu wrote: > >>> http://ftp.netbsd.org/pub/NetBSD/misc/abs/acpi-suspend-resume/pcidump.pre > >>> http://ftp.netbsd.org/pub/NetBSD/misc/abs/acpi-suspend-resume/pcidump.post > >> > >> The diff says we should save/restore MSI table. > >> We also should save/restore some other registers. > >> > >> Give me one or two days to resolve the problem. > > > > Please try the following diff: > > > > http://www.netbsd.org/~msaitoh/pci-resume-20181118-0.dif > > > > Even if I use this change with Thinkpad X220, it doesn't recover from > > suspend... > > But, my X61 survived from suspend with this patch! I can confirm a T420s, T430 and T530 all suspend and resume single user or multiuser without X11 including disk and network fine with this patch (excellent stuff!). X11 on T420s - Suspend and resumes fine while in X or on console with X running in another virtual console - The display seems to reverts to a blank console on resume into which you can type - Switching vtys fixes the display - The ThinkPad touchpoint stops working on resume (but an external USB mouse is fine) X11 on T530 - Panics on resume if X is running (even if I then switch to the console) drm/i915: Resetting chip after gpu hang ufm_fault(0x8a77a0c0, 0x0, 1) -> w fatal page fault in supervisor mode ... at netbsd:fini_hash_table+0x88: movq 1 but this is awesome progress! Thanks David DAvid
Re: ThinkPad - suspend-to-RAM intel-x86 issues and tests
On Sat, 2018-11-24 at 18:33 +0100, Riccardo Mottola wrote: > On 11/21/18 6:57 AM, David H. Gutteridge wrote: > > I have access to a Toshiba Satellite Pro that's a roughly similar > > vintage to your T43; I'll see how it behaves when I have a chance. > > That would be interesting. Try it as-is, possibly with 8.0 and HEAD. If > it works fine, then try to disable audio, video and see if it helps. > > Of course I want to pinpoint which driver(s) cause me problems, so at > least I can open the correct bug (and "bug" some kind soul to fix it). > Right now the information is a little more than "it doesn't work for me > on several computers". I have good news and bad news, and it's the same thing: I was hoping the Toshiba laptop had more parity with one of your laptops in terms of hardware, but unfortunately, it's a consumer model, an M40X with an Intel Dothan CPU, integrated 915GM graphics, a RealTek Ethernet card, Atheros WiFi, etc. It's similar to the X110: it has a bit of trouble on 8.0_STABLE resuming with the i915 DRM driver, but that's addressed in 8.99.26, where it resumes as reliably as my T420. (With the same caveats about restoring hardware state that are being discussed elsewhere in this thread: I haven't tried that patch on it yet.) Dave
Re: ThinkPad - suspend-to-RAM intel-x86 issues and tests
On Thu, 2018-11-29 at 15:15 +0900, Masanobu SAITOH wrote: > On 2018/11/28 22:12, SAITOH Masanobu wrote: > > On 2018/11/28 14:18, Masanobu SAITOH wrote: > > > The diff says we should save/restore MSI table. > > > We also should save/restore some other registers. > > > > > > Give me one or two days to resolve the problem. > > > > Please try the following diff: > > > > http://www.netbsd.org/~msaitoh/pci-resume-20181118-0.dif > > > > Even if I use this change with Thinkpad X220, it doesn't recover from > > suspend... > > But, my X61 survived from suspend with this patch! With that patch, networking devices now function reliably on my T420 after wakeup. That's a big improvement, thanks! Dave
Re: ThinkPad - suspend-to-RAM intel-x86 issues and tests
On Thu, Nov 29, 2018 at 03:15:31PM +0900, Masanobu SAITOH wrote: > On 2018/11/28 22:12, SAITOH Masanobu wrote: > > But, my X61 survived from suspend with this patch! > My fujitsu lifebook S904 came back from suspend with this patch too! Thank you very much for this. -- Brett Lymn Let go, or be dragged - Zen proverb.
Re: ThinkPad - suspend-to-RAM intel-x86 issues and tests
On 2018/11/28 22:12, SAITOH Masanobu wrote: On 2018/11/28 14:18, Masanobu SAITOH wrote: Hi, David. On 2018/11/28 6:09, David Brownlee wrote: On Tue, 27 Nov 2018 at 18:10, David Brownlee wrote: On Tue, 27 Nov 2018 at 08: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 Date: Mon Oct 22 20:57:07 2018 + 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 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. Let me just install to a USB stick to give me a working filesystem from which to run pcidump after resume :-p Collecting a pre-suspend dump was easy, but getting post-resume turned out to be a little more involved :) - root on wd0 on ahcisata - times out on resume - root on sd0 on usb on xhci - times out on resume - root on sd0 on usb on uhci - loses the root filesystem mount point on resume - install image - doesn't have the libs to run pcictl - install image, then chroot to mfs with extracted base - suspends but video does not come back (no drm) - root on wd0, then chroot to mfs with extracted base, suspend & resume, then mount sd0 on usb on uhci to save data - \o/ After all that it occurred to me I could have probably run the suspend/resume with an older NetBSD version where MSI was not being used. Still, interesting puzzle to try, and useful technique to stash. Files for the ThinkPad T420s: http://ftp.netbsd.org/pub/NetBSD/misc/abs/acpi-suspend-resume/pcidump.pre http://ftp.netbsd.org/pub/NetBSD/misc/abs/acpi-suspend-resume/pcidump.post The diff says we should save/restore MSI table. We also should save/restore some other registers. Give me one or two days to resolve the problem. Please try the following diff: http://www.netbsd.org/~msaitoh/pci-resume-20181118-0.dif Even if I use this change with Thinkpad X220, it doesn't recover from suspend... But, my X61 survived from suspend with this patch! Thanks. Thanks for looking at this! David -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
Re: ThinkPad - suspend-to-RAM intel-x86 issues and tests
On 2018/11/28 14:18, Masanobu SAITOH wrote: > Hi, David. > > On 2018/11/28 6:09, David Brownlee wrote: >> On Tue, 27 Nov 2018 at 18:10, David Brownlee wrote: >>> >>> On Tue, 27 Nov 2018 at 08: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 > Date: Mon Oct 22 20:57:07 2018 + > > 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 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. >>> >>> Let me just install to a USB stick to give me a working filesystem >>> from which to run pcidump after resume :-p >> >> Collecting a pre-suspend dump was easy, but getting post-resume turned >> out to be a little more involved :) >> - root on wd0 on ahcisata - times out on resume >> - root on sd0 on usb on xhci - times out on resume >> - root on sd0 on usb on uhci - loses the root filesystem mount point on >> resume >> - install image - doesn't have the libs to run pcictl >> - install image, then chroot to mfs with extracted base - suspends but >> video does not come back (no drm) >> - root on wd0, then chroot to mfs with extracted base, suspend & >> resume, then mount sd0 on usb on uhci to save data - \o/ >> >> After all that it occurred to me I could have probably run the >> suspend/resume with an older NetBSD version where MSI was not being >> used. Still, interesting puzzle to try, and useful technique to stash. >> >> Files for the ThinkPad T420s: >> >> http://ftp.netbsd.org/pub/NetBSD/misc/abs/acpi-suspend-resume/pcidump.pre >> http://ftp.netbsd.org/pub/NetBSD/misc/abs/acpi-suspend-resume/pcidump.post > > The diff says we should save/restore MSI table. > We also should save/restore some other registers. > > Give me one or two days to resolve the problem. Please try the following diff: http://www.netbsd.org/~msaitoh/pci-resume-20181118-0.dif Even if I use this change with Thinkpad X220, it doesn't recover from suspend... > > Thanks. > > >> Thanks for looking at this! >> >> David > > > -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
Re: ThinkPad - suspend-to-RAM intel-x86 issues and tests
On Wed, 28 Nov 2018 at 02:20, David H. Gutteridge wrote: > > On Sat, 2018-11-24 at 22:47 +, David Brownlee wrote: > > On Sat, 24 Nov 2018 at 18:52, David H. Gutteridge > > wrote: > > > On Fri, 2018-11-23 at 21:42 +, David Brownlee wrote: > > > > 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 :/ > > That error definitely can mean just that, but it's notable that it's > not a case of the firmware file being absent or unloadable, as for me > it successfully loads on boot, it only gives that error on wakeup. Sorry - I was unclear. I took it to mean there was a problem with putting the firmware image into the device after loading it from disk :) Looking at iwn5000_load_firmware_section() the only way for it to fail is if iwn_nic_lock() fails, which calls /* Request exclusive access to NIC. */ IWN_SETBITS(sc, IWN_GP_CNTRL, IWN_GP_CNTRL_MAC_ACCESS_REQ); then spins for a little while to see if it gets the lock. So presumably the iwn is in an inconsistent state after resume. Its possible that whatever fixes are needed for ahcisata to restore more PCI state for MSI might help here (certainly they should help for the wm case), but if (more likely) they do not help then someone gets to poke at if_iwn.c :) David
Re: ThinkPad - suspend-to-RAM intel-x86 issues and tests
Hi, David. On 2018/11/28 6:09, David Brownlee wrote: On Tue, 27 Nov 2018 at 18:10, David Brownlee wrote: On Tue, 27 Nov 2018 at 08: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 Date: Mon Oct 22 20:57:07 2018 + 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 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. Let me just install to a USB stick to give me a working filesystem from which to run pcidump after resume :-p Collecting a pre-suspend dump was easy, but getting post-resume turned out to be a little more involved :) - root on wd0 on ahcisata - times out on resume - root on sd0 on usb on xhci - times out on resume - root on sd0 on usb on uhci - loses the root filesystem mount point on resume - install image - doesn't have the libs to run pcictl - install image, then chroot to mfs with extracted base - suspends but video does not come back (no drm) - root on wd0, then chroot to mfs with extracted base, suspend & resume, then mount sd0 on usb on uhci to save data - \o/ After all that it occurred to me I could have probably run the suspend/resume with an older NetBSD version where MSI was not being used. Still, interesting puzzle to try, and useful technique to stash. Files for the ThinkPad T420s: http://ftp.netbsd.org/pub/NetBSD/misc/abs/acpi-suspend-resume/pcidump.pre http://ftp.netbsd.org/pub/NetBSD/misc/abs/acpi-suspend-resume/pcidump.post The diff says we should save/restore MSI table. We also should save/restore some other registers. Give me one or two days to resolve the problem. Thanks. Thanks for looking at this! David -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
Re: ThinkPad - suspend-to-RAM intel-x86 issues and tests
On Sat, 2018-11-24 at 22:47 +, David Brownlee wrote: > On Sat, 24 Nov 2018 at 18:52, David H. Gutteridge > wrote: > > On Fri, 2018-11-23 at 21:42 +, David Brownlee wrote: > > > 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 :/ That error definitely can mean just that, but it's notable that it's not a case of the firmware file being absent or unloadable, as for me it successfully loads on boot, it only gives that error on wakeup. Dave
Re: ThinkPad - suspend-to-RAM intel-x86 issues and tests
On Tue, 2018-11-27 at 18:08 +, David Brownlee wrote: > On Sun, 25 Nov 2018 at 21: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 > > Date: Mon Oct 22 20:57:07 2018 + > > > > 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 > > So it turns out I'm as affective at off-by-one errors in git > bisect as I am in coding... :/ > > It turns out the commit with the issue was: > > commit 1628082c6b882d064bd5d77e5847c42b44b59fde (HEAD, refs/bisect/bad) > Author: jdolecek > Date: Mon Oct 22 21:04:53 2018 + > > enable MSI support where available > > M sys/dev/pci/ahcisata_pci.c > > Apologies... No worries, I don't have an siisata device on that laptop, so I figured it was ahcisata I needed to revert. I've done so, and tested, and, yes, backing that change set out gets my laptop resuming without disk errors again. Thanks for the work you've put into isolating this and getting the PCI config dumps! Dave
Re: ThinkPad - suspend-to-RAM intel-x86 issues and tests
On Tue, 27 Nov 2018 at 18:10, David Brownlee wrote: > > On Tue, 27 Nov 2018 at 08: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 > > > Date: Mon Oct 22 20:57:07 2018 + > > > > > > 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 > > 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. > > Let me just install to a USB stick to give me a working filesystem > from which to run pcidump after resume :-p Collecting a pre-suspend dump was easy, but getting post-resume turned out to be a little more involved :) - root on wd0 on ahcisata - times out on resume - root on sd0 on usb on xhci - times out on resume - root on sd0 on usb on uhci - loses the root filesystem mount point on resume - install image - doesn't have the libs to run pcictl - install image, then chroot to mfs with extracted base - suspends but video does not come back (no drm) - root on wd0, then chroot to mfs with extracted base, suspend & resume, then mount sd0 on usb on uhci to save data - \o/ After all that it occurred to me I could have probably run the suspend/resume with an older NetBSD version where MSI was not being used. Still, interesting puzzle to try, and useful technique to stash. Files for the ThinkPad T420s: http://ftp.netbsd.org/pub/NetBSD/misc/abs/acpi-suspend-resume/pcidump.pre http://ftp.netbsd.org/pub/NetBSD/misc/abs/acpi-suspend-resume/pcidump.post Thanks for looking at this! David
Re: ThinkPad - suspend-to-RAM intel-x86 issues and tests
On Tue, 27 Nov 2018 at 08: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 > > Date: Mon Oct 22 20:57:07 2018 + > > > > 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 > 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. Let me just install to a USB stick to give me a working filesystem from which to run pcidump after resume :-p David
Re: ThinkPad - suspend-to-RAM intel-x86 issues and tests
On Sun, 25 Nov 2018 at 21: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 > Date: Mon Oct 22 20:57:07 2018 + > > 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 So it turns out I'm as affective at off-by-one errors in git bisect as I am in coding... :/ It turns out the commit with the issue was: commit 1628082c6b882d064bd5d77e5847c42b44b59fde (HEAD, refs/bisect/bad) Author: jdolecek Date: Mon Oct 22 21:04:53 2018 + enable MSI support where available M sys/dev/pci/ahcisata_pci.c Apologies... David
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 Date: Mon Oct 22 20:57:07 2018 + 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 mailto:a...@absd.org>> wrote: On Sat, 24 Nov 2018 at 18:52, David H. Gutteridge mailto:da...@gutteridge.ca>> wrote: > > On Fri, 2018-11-23 at 21:42 +, 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 (msai...@execsw.org msai...@netbsd.org)
Re: ThinkPad - suspend-to-RAM intel-x86 issues and tests
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 Date: Mon Oct 22 20:57:07 2018 + 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 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 mailto:a...@absd.org>> wrote: On Sat, 24 Nov 2018 at 18:52, David H. Gutteridge mailto:da...@gutteridge.ca>> wrote: > > On Fri, 2018-11-23 at 21:42 +, 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 (msai...@execsw.org msai...@netbsd.org)
Re: ThinkPad - suspend-to-RAM intel-x86 issues and tests
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 Date: Mon Oct 22 20:57:07 2018 + 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 David On Sat, 24 Nov 2018 at 22:47, David Brownlee wrote: > On Sat, 24 Nov 2018 at 18:52, David H. Gutteridge > wrote: > > > > On Fri, 2018-11-23 at 21:42 +, 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 >
Re: ThinkPad - suspend-to-RAM intel-x86 issues and tests
On Sat, 24 Nov 2018 at 18:52, David H. Gutteridge wrote: > > On Fri, 2018-11-23 at 21:42 +, 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
Re: ThinkPad - suspend-to-RAM intel-x86 issues and tests
On Fri, 2018-11-23 at 21:42 +, 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..." > 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. (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). Dave
Re: ThinkPad - suspend-to-RAM intel-x86 issues and tests
Hi, On 11/21/18 6:57 AM, David H. Gutteridge wrote: True. What I can also say is that I tested the i386 port with it too (see kern/53658), and it worked too. I've also tested i386 with an LG X110 that I used to run NetBSD 5.x and then 7.x on. I could never get it to suspend. With 8.0, it doesn't resume successfully, because of an issue with the i915 DRM driver, but with the newer DRM code base that was pulled into HEAD, I've found 8.99.25 did successfully resume, so there may be hope. that is interesting, it means that your T420 works independently of the architecture, it means the derivers perform equally well in 32bit and 64bit, this is good news. Your LG thus did not work but now works with the newer DRM! Very good. so for you there has been progress and apparently the only issue was the DRM. For me, there must be something deeper, because once audio and video are disabled, I just test suspend when at the login prompt! Riccardo I have access to a Toshiba Satellite Pro that's a roughly similar vintage to your T43; I'll see how it behaves when I have a chance. That would be interesting. Try it as-is, possibly with 8.0 and HEAD. If it works fine, then try to disable audio, video and see if it helps. Of course I want to pinpoint which driver(s) cause me problems, so at least I can open the correct bug (and "bug" some kind soul to fix it). Right now the information is a little more than "it doesn't work for me on several computers".
Re: ThinkPad - suspend-to-RAM intel-x86 issues and tests
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 ..." 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" netbsd-8 Multi user no x11: - Suspends, keyboard *usually* non responsive on resume (but can switch virtual terminals) On Wed, 21 Nov 2018 at 05:57, David H. Gutteridge wrote: > > On Tue, 2018-11-20 at 16:25 +0100, Riccardo Mottola wrote: > > Hi David, > > > > David H. Gutteridge wrote: > > > FWIW, I'm able to get suspend and resume to work reliably on a > > > Lenovo > > > T420 with NetBSD-8.0_STABLE. (With 8.99.x, it doesn't work as > > > reliably > > > because the SATA driver seems to have issues after resumption which > > > don't occur with 8.0.) I didn't have to do anything of note to get > > > it > > > to work, it just does, assuming there's nothing extra attached. > > > (Read > > > on below.) > > > > The T420 is a lot newer and is amd64 instead of x86. > > True. What I can also say is that I tested the i386 port with it too > (see kern/53658), and it worked too. I've also tested i386 with an LG > X110 that I used to run NetBSD 5.x and then 7.x on. I could never get > it to suspend. With 8.0, it doesn't resume successfully, because of an > issue with the i915 DRM driver, but with the newer DRM code base that > was pulled into HEAD, I've found 8.99.25 did successfully resume, so > there may be hope. > > I have access to a Toshiba Satellite Pro that's a roughly similar > vintage to your T43; I'll see how it behaves when I have a chance. > > > > On the other hand, I cannot get it to work on a Lenovo x131e (the > > > AMD > > > CPU version, with Radeon graphics). With that machine, it resumes, > > > but > > > the display stays dark. (This behaviour is consistent with most > > > Linux > > > kernels I've tried as well, so there's something tricky about it.) > > > > Yes, I have this issue on the T43 with ATI graphics, however it often > > does work and come back (but takes several secons) it is unreliable, > > but > > the only ThinkPad I have NetBSD on which sometimes suspends/resumes > > correctly. > > > > Did you try disabling video in configure and then trying to > > suspend/resume after a clean boot? > > I haven't tried that yet, no. I'll add it to the list. > > > Christos suggested to me disabling video and audio (things in my > > experience cause issue too). > > I tried also fine-grained disabling based on dmesg devices. > > > > However, I went down to bare-bones, leaving just internal hard disk > > and > > keyboard - disabling everything which I could (but perhaps I missed > > something) and yet it fails! > > > > > One other thing to consider is whether you have anything extra > > > plugged > > > into the USB stack when you're trying to suspend. I've found having > > > pretty much anything plugged in (including a mouse) causes my T420 > > > to > > > fail to completely suspend. > > > > Indeed, I did all the test with a just clean-booted machine with no > > USB > > mouse, keybord, dongles or else. > > > > It did not help. > > Hopefully, we'll figure this out. > > Dave > >
Re: ThinkPad - suspend-to-RAM intel-x86 issues and tests
On Tue, 2018-11-20 at 16:25 +0100, Riccardo Mottola wrote: > Hi David, > > David H. Gutteridge wrote: > > FWIW, I'm able to get suspend and resume to work reliably on a > > Lenovo > > T420 with NetBSD-8.0_STABLE. (With 8.99.x, it doesn't work as > > reliably > > because the SATA driver seems to have issues after resumption which > > don't occur with 8.0.) I didn't have to do anything of note to get > > it > > to work, it just does, assuming there's nothing extra attached. > > (Read > > on below.) > > The T420 is a lot newer and is amd64 instead of x86. True. What I can also say is that I tested the i386 port with it too (see kern/53658), and it worked too. I've also tested i386 with an LG X110 that I used to run NetBSD 5.x and then 7.x on. I could never get it to suspend. With 8.0, it doesn't resume successfully, because of an issue with the i915 DRM driver, but with the newer DRM code base that was pulled into HEAD, I've found 8.99.25 did successfully resume, so there may be hope. I have access to a Toshiba Satellite Pro that's a roughly similar vintage to your T43; I'll see how it behaves when I have a chance. > > On the other hand, I cannot get it to work on a Lenovo x131e (the > > AMD > > CPU version, with Radeon graphics). With that machine, it resumes, > > but > > the display stays dark. (This behaviour is consistent with most > > Linux > > kernels I've tried as well, so there's something tricky about it.) > > Yes, I have this issue on the T43 with ATI graphics, however it often > does work and come back (but takes several secons) it is unreliable, > but > the only ThinkPad I have NetBSD on which sometimes suspends/resumes > correctly. > > Did you try disabling video in configure and then trying to > suspend/resume after a clean boot? I haven't tried that yet, no. I'll add it to the list. > Christos suggested to me disabling video and audio (things in my > experience cause issue too). > I tried also fine-grained disabling based on dmesg devices. > > However, I went down to bare-bones, leaving just internal hard disk > and > keyboard - disabling everything which I could (but perhaps I missed > something) and yet it fails! > > > One other thing to consider is whether you have anything extra > > plugged > > into the USB stack when you're trying to suspend. I've found having > > pretty much anything plugged in (including a mouse) causes my T420 > > to > > fail to completely suspend. > > Indeed, I did all the test with a just clean-booted machine with no > USB > mouse, keybord, dongles or else. > > It did not help. Hopefully, we'll figure this out. Dave
Re: ThinkPad - suspend-to-RAM intel-x86 issues and tests
On Tue, Nov 20, 2018 at 06:02:36PM +0100, Riccardo Mottola wrote: > Hi, > > m...@netbsd.org wrote: > > For general context, suspend does work on -current. I tried on an older > > amd64.http://netbsd.org/~maya/n4030-suspend > > (No driver disabled, but I tried from r/o root in an installer) > > > > Unfortunately my shinier machine is a pain to suspend. I might end up > > giving up. > > at least it works for somebody :) It works for me (mostly) also on my amd64 > Laptop. However, except for video issues, suspend works also on my T43, so > basically suspend works also on x86. > > I am confused that disabling drivers does not help. One of the few drivers I > did not disable (of course) are pci and ide! ANd I need a keyboard too for > minimal tests... > > Other possible suspects? > > Riccardo > > PS: Do the install CDs or netinst CD's have ACPI enabled? Or do we have some > sort of Live CD? Since using an USB key to boot proved not feasible to test > without isntalling, if I had a CD image, Ic ould try at least on one or two > devices more where I could even compare against another OS. I was using a USB image to suspend, I dropped to boot prompt and ran 'boot -s' to boot to single user without a mounted rw filesystem.
Re: ThinkPad - suspend-to-RAM intel-x86 issues and tests
Hi, m...@netbsd.org wrote: For general context, suspend does work on -current. I tried on an older amd64.http://netbsd.org/~maya/n4030-suspend (No driver disabled, but I tried from r/o root in an installer) Unfortunately my shinier machine is a pain to suspend. I might end up giving up. at least it works for somebody :) It works for me (mostly) also on my amd64 Laptop. However, except for video issues, suspend works also on my T43, so basically suspend works also on x86. I am confused that disabling drivers does not help. One of the few drivers I did not disable (of course) are pci and ide! ANd I need a keyboard too for minimal tests... Other possible suspects? Riccardo PS: Do the install CDs or netinst CD's have ACPI enabled? Or do we have some sort of Live CD? Since using an USB key to boot proved not feasible to test without isntalling, if I had a CD image, Ic ould try at least on one or two devices more where I could even compare against another OS.
Re: ThinkPad - suspend-to-RAM intel-x86 issues and tests
Hi David, David H. Gutteridge wrote: FWIW, I'm able to get suspend and resume to work reliably on a Lenovo T420 with NetBSD-8.0_STABLE. (With 8.99.x, it doesn't work as reliably because the SATA driver seems to have issues after resumption which don't occur with 8.0.) I didn't have to do anything of note to get it to work, it just does, assuming there's nothing extra attached. (Read on below.) The T420 is a lot newer and is amd64 instead of x86. On the other hand, I cannot get it to work on a Lenovo x131e (the AMD CPU version, with Radeon graphics). With that machine, it resumes, but the display stays dark. (This behaviour is consistent with most Linux kernels I've tried as well, so there's something tricky about it.) Yes, I have this issue on the T43 with ATI graphics, however it often does work and come back (but takes several secons) it is unreliable, but the only ThinkPad I have NetBSD on which sometimes suspends/resumes correctly. Did you try disabling video in configure and then trying to suspend/resume after a clean boot? Christos suggested to me disabling video and audio (things in my experience cause issue too). I tried also fine-grained disabling based on dmesg devices. However, I went down to bare-bones, leaving just internal hard disk and keyboard - disabling everything which I could (but perhaps I missed something) and yet it fails! One other thing to consider is whether you have anything extra plugged into the USB stack when you're trying to suspend. I've found having pretty much anything plugged in (including a mouse) causes my T420 to fail to completely suspend. Indeed, I did all the test with a just clean-booted machine with no USB mouse, keybord, dongles or else. It did not help. Riccardo
Re: ThinkPad - suspend-to-RAM intel-x86 issues and tests
On Tue, 20 Nov 2018, David H. Gutteridge wrote: FWIW, I'm able to get suspend and resume to work reliably on a Lenovo T420 with NetBSD-8.0_STABLE. (With 8.99.x, it doesn't work as reliably because the SATA driver seems to have issues after resumption which don't occur with 8.0.) Jaromir Dolocek did a lot of work on ahcisata recently. You might try to coordninate with him to see if his changes have affected the suspend and resume stuff. +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: ThinkPad - suspend-to-RAM intel-x86 issues and tests
On Wed, 14 Nov 2018, at 13:10:55 +0100, Riccardo Mottola wrote: >HI all, > >I take the discussion started on a similar thread on netbsd-users over here, >since it is still a "current" issue and to debug it I am using netbsd-GENERIV >kernels from RelEng. [...] > >the question is again.. suggestions on what to disable, if you have patch >suggestions, etc. FWIW, I'm able to get suspend and resume to work reliably on a Lenovo T420 with NetBSD-8.0_STABLE. (With 8.99.x, it doesn't work as reliably because the SATA driver seems to have issues after resumption which don't occur with 8.0.) I didn't have to do anything of note to get it to work, it just does, assuming there's nothing extra attached. (Read on below.) On the other hand, I cannot get it to work on a Lenovo x131e (the AMD CPU version, with Radeon graphics). With that machine, it resumes, but the display stays dark. (This behaviour is consistent with most Linux kernels I've tried as well, so there's something tricky about it.) One other thing to consider is whether you have anything extra plugged into the USB stack when you're trying to suspend. I've found having pretty much anything plugged in (including a mouse) causes my T420 to fail to completely suspend. Regards, Dave
Re: ThinkPad - suspend-to-RAM intel-x86 issues and tests
For general context, suspend does work on -current. I tried on an older amd64. http://netbsd.org/~maya/n4030-suspend (No driver disabled, but I tried from r/o root in an installer) Unfortunately my shinier machine is a pain to suspend. I might end up giving up.
