Laptop/Computer: Toshiba Satellite Pro S300-S2503 (PSSBAU-004005) Linux Distro: Manjaro 0.8.13.0 Ascella --- Problem: During the suspend process the laptop does not suspend properly. I believe ACPI may be the problem... but I'm not too sure. What happens is once everything is suspended to RAM, the laptop does not go into the suspend state, leaving me with a blank screen and the laptop still fully powered on. The reason I think it's ACPI having the problem is because of this: -- Jul 06 13:46:09 ManjaroLinux kernel: ACPI Warning: SystemIO range 0x000000000000D828-0x000000000000D82F conflicts with OpRegion 0x000000000000D800-0x000000000000D83F (\_SB_.PCI0 Jul 06 13:46:09 ManjaroLinux kernel: ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver -- I have the "toshiba_acpi" module loaded during booting as well! This also occurs when attempting to hibernate the system, it does not shut down the system, it just leaves it at the state mentioned above.
Is there an old kernel that works?
(In reply to Aaron Lu from comment #1) > Is there an old kernel that works? New information, turns out the Laptop does enter it's sleep state, but only after 4-6 minutes has passed. I found logs in SYSTEMD that showed a similar timegap. -- Jul 07 19:51:17 ManjaroLinux systemd-sleep[1788]: Suspending system... Jul 07 19:57:02 ManjaroLinux kernel: PM: Syncing filesystems ... done. -- I'm not sure if it's the kernel or systemd that's having the issue. I've filed a bug report to systemd about the issue with the systemd log.
Most likely systemd, you can also test suspend-to-mem by: # echo mem > /sys/power/state See if it has a long delay using this way.
I got the long delay again.
Created attachment 182371 [details] Add some debug statements to check where the delay comes from Please apply this patch and do the "echo mem > " suspend again, then attach dmesg, thanks.
I saved the contents of the patch file as "firstpatch.patch" and I'm running patch -p1 -i /path/to/file/firstpatch.patch And it's giving me the error patch -p1 -i /home/drake/firstpatch.patch can't find file to patch at input line 5 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff --git a/kernel/power/main.c b/kernel/power/main.c |index 63d395b5df93..e026bcf8b1c4 100644 |--- a/kernel/power/main.c |+++ b/kernel/power/main.c -------------------------- File to Patch: What's wrong?
Where did you run the above "patch" command? At the root directory of the linux kernel source tree?
First at the home directory, then at the root of the filesystem. Guess I'll need to find the root of kernel source tree then?
First time ever doing a patch.
Did you download the kernel source tree? If not, I would suggest you use git to do this: $ cd $(HOME)/src $ git clone http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Okay, I've done all that and patched the source. I'm going to have to build this kernel now and run it on boot, don't I..?
I've uploaded the dmesg log and the journal log (look around line 5 in it).
Created attachment 182611 [details] Dmesg log when triggering echo mem > with patched kernel.
Created attachment 182621 [details] Journal Log when triggering the echo mem > with patched kernel.
From the dmesg, the system entered suspend state well, without any delay. Is it the case? From the journal log, it does have a delay, but I guess that is due to the journal service is stopped and only gets written after resume? Not sure about this, but we should use dmesg to decide timing instead of journal log which involves user space file system.
Well I've just updated Systemd to v222-1, Kernel has no updates yet (v4.1.2-1). Rebooted the computer and tried it again, both from terminal and Desktop Environment. Still no luck. Just waiting for the people at the Systemd Bug Reports to respond to me and see what they say.
We can't trust systemd's journal, I just did a test and saw the following log: $ journalctl -r ... ... Jul 21 11:18:56 localhost.localdomain kernel: PM: Entering mem sleep Jul 21 11:18:56 localhost.localdomain kernel: Freezing remaining freezable tasks ... (elapsed 0. Jul 21 11:18:56 localhost.localdomain kernel: Freezing user space processes ... (elapsed 0.002 s Jul 21 11:18:56 localhost.localdomain kernel: PM: Preparing system for mem sleep Jul 21 11:11:12 localhost.localdomain kernel: PM: Syncing filesystems ... done. ... ... I started the suspend around 11:11 and resumed it around 11:18, and the log shows the suspend part has a delay of 7 minutes while I actually had a very normal suspend. So let's forget the systemd journal log and simply use dmesg. Let me get this clear: do you always get the 4-6 minutes delay before the laptop is powered off when entering suspended state?
Hmmm, that is interesting.. Yes, that's correct. Last time I timed it, I got 5 minutes and 20 seconds. The thing is, I installed the Linux distro on an external Hard Drive. But! I've tested suspending on other machines using the external hard drive and they worked out perfectly. Took only a few seconds to enter it's suspended state. I've recently tested the memory on the laptop as well, using multiple tools, they all came up clean.
Do you have Windows? Can you please test suspend in Windows with your rexternal USB device attached?
Windows is on the Internal hard drive.. but sure.
Suspends in a few seconds like it should on Windows. External HDD was plugged in during testing.
As we discussed earlier, the systemd journal log's timestamp doesn't make much sense here, but since you do have the delay, I think it may be worth to do the following tests: 1 Use another USB drive to see if it has the same delay issue; 2 Install to the internal drive to see what happens.
any update?
(In reply to Aaron Lu from comment #23) > any update? I apologize for the lateness, the other USB drive has the same issue, I have yet to install Linux to the main internal drive. But I've been doing some experimenting and thinking, I've found that once I hit suspend, the USB Hard Drive is shut off completely, allowing me to take out the hard drive during the suspension process. So I don't have to wait 5 minutes for it to fully enter the sleep state. Since that's the case, I don't see it being as big as a problem as it was before. This laptop is very old and I don't see a reason why the developers will need to make adjustments to the kernel just to make this work as technically speaking, suspension does work "like it should" (aside from waiting 5 minutes to enter it's sleep state).
OK, then I'll mark it closed as WILL_NOT_FIX, thanks for the update!