Date: Sun, 24 Apr 2016 22:48:19 +1000 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Michael Freisinger <freisingermichael@gmail.com> Cc: freebsd-acpi@freebsd.org Subject: Re: Suspend to RAM problem Message-ID: <20160424220323.O78284@sola.nimnet.asn.au> In-Reply-To: <CALYPBdtrCdVXAz_kWN-uWMyZywZnZ_LhFE23cEodjJ1qq%2BkPtg@mail.gmail.com> References: <CALYPBdvEWZh3oGqYvgr9k5j_nGt-iNfVP0ovRD6at1KY8Xd7Zg@mail.gmail.com> <20160422191822.D49078@sola.nimnet.asn.au> <CALYPBdtrCdVXAz_kWN-uWMyZywZnZ_LhFE23cEodjJ1qq%2BkPtg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 23 Apr 2016 00:42:11 +0200, Michael Freisinger wrote: > Hi Ian, > Thank you very much for your answer. I think you need advice from someone more conversant with FreeBSD 10.x .. I'm still running 9.3 until the broken loadavgs issue gets fixed, but that's another story. I booted a 10.3 memstick in LiveCD mode for some tests tonight though .. > > Since it's based on 10.3, I'd suggest booting from a 10.3 CD or memstick > > in "Live CD" mode and testing suspend / resume from there, just to rule > > out any possible differences with the FreeNAS configuration? If this > > problem then persists, people can test against a more familiar baseline. > > I tested my system with the Live CD mode. The result is the following: > After the command acpiconf -s 3 command the system is starting to suspend. > At least I think it is, because there are some suspend messages (very less > than with freenas). You'll see a lot more of those having booted verbose, see below. > After that the display signal stops and the power button of my system > is blinking. This state is stable. Sounds right. > Then I sent a WOL-Package or press the power button and the blinking > stops and it seemed that the system is resuming. However the display > doesn't get a signal. So I have to do a hard reset to see anything. > After this the system is booting normally, of course. There's been a lot about missing video on resume, but I thought most of that had been resolved by now. Hopefully somebody can advise? > I have to mention that I booted the Live CD from an USB stick. > Perhaps the USB devices are not available directly after resuming, so > the boot device is not available (I heard about this problem from > another user). I was going to say that I thought it would have been running from a memory filesystem in that mode, or that resuming from USB disks as root fs might have been fixed, but no, that's right, and while it seems to come back and you can eg 'ls -l /' ok, trying to read any file fails, and some userland utilities work, while some fail. > Finally I think my system supports the s3 mode correctly, so probably > the freenas configuration is the reason for my problem. Possibly, though you'll want to get the no video on resume issue sorted. > > Have you tried it without (from your sysctl hw.acpi) > > hw.acpi.handle_reboot: 1 ? > > I think I don't understand your proposal right. Should I set > hw.acpi.handle_reboot to 0? Where can I do this? Actually hw.acpi.handle_reboot=0 is the default, so maybe FreeNAS set that to 1? In which case, that might be (part of?) the problem there? Generally, most sysctls can be set while running except loader tunables. % sysctl -d hw.acpi.handle_reboot hw.acpi.handle_reboot: Use ACPI Reset Register to reboot But I don't know what that really means :) > Have you tried with the advice from (online) section 11.13.2.2, namely: > > # sysctl debug.bootverbose=1 > > # sysctl debug.acpi.suspend_bounce=1 > > # acpiconf -s 3 > > The first and the second command work fine (the value are set to 1). > However when I enter the acpiconf command the behavior is unchanged (the > system is starting the suspend process and restarts directly). Did I do > something wrong? No, that's what's supposed to happen .. everything in the suspend/resume path occurs except the actual suspend. I don't know if anything useful would turn up in dmesg (or in /var/log/messages, which is about the same thing, with timestamps). /var is on an md filesystem, so it's rw. > If nothing more informative turns up soon, you might want to add or > > point to a dmesg from booting in verbose mode. From what's there now, I > > don't know whether these may be significant? > > > ACPI Error: [\134_SB_.PCI0.XHC_.RHUB.HS11] Namespace lookup failure, > > AE_NOT_FOUND (20150515/dswload-219) > > ACPI Exception: AE_NOT_FOUND, During name lookup/catalog > > (20150515/psobject-233) > > > > Could you tell me the necessary commands to do this? On booting from the memstick, hit space on the FreeBSD boot menu (to stop the countdown) then select 'configure boot options' and set verbose booting on. Then backspace to the menu and hit enter to boot. Dominic asked if you could ssh in. I tried 'service sshd onestart' after booting but sshd needs to write its initial keys but can't to the readonly / fs, so fails to start. I don't know a workaround for that. What I do is mount (rw) a small partition I have for such purposes on the HD, so I can write dmesg, sysctl -a and other stuff to the HD for later inspection. You could instead mount another USB stick for that, though best unount it before trying suspend. I did 'dmesg >/thatdisk/dmesg.presuspend' which wrote the full verbose dmesg, and then after suspend/resume - despite that I couldn't do much locally anymore - 'dmesg >/thatdisk/dmesg.postsuspend' worked, including the extra suspend/resume messages. But that won't help you, after suspend, unless you get your screen back. I hope someone can help out with that. Again, verbose dmesg may assist. cheers, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160424220323.O78284>