If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
Announcement
Collapse
No announcement yet.
Ubuntu 18.04's Automatic Suspend Shows Linux Suspend Can Still Be An Issue In 2018
The Plasma issue is Nvidia only as their driver simply doesn't consider VRAM data to be non volatile.
I just tested it again some minutes ago with drm-next-4.17-wip and legacy DC (new DC doesn't work properly for me yet with DL-DVI) and suspend and turning off display via DPMS were working totally fine.
OK, but how should I know you were talking about Plasma? There was just no mention of Plasma either in the article or the comment I was replying to.
When I can find a deb of drm-next-4.17-wip or amd-staging-drm-next (4.17-rc1 should only be 3 weeks from now), I will check this. Hopefully it will fix this long pending issue.
It probably is. ACPI has been a headache from day one for anyone other than Microsoft (and probably even them from time to time). The reason is the specification is only partly defined, and the rest is up to the OEMs who generally won't play nice with anyone other than Microsoft. With the number of hardware and firmware bugs out there in race-to-the-bottom consumer market (yes this includes the gamer market too), you can probably imagine how many different implementations, bugs, and general brokenness in ACPI with just the desktop systems let alone the laptops where the problem is MUCH worse! You don't normally see these with Windows because the vendor specific drivers hide user visible problems. We see them in the open source world because, well, for one it's open development, and the other is that we get caught by all the "gotchas" the OEMs cover up with their in house drivers and otherwise hide behind NDA for documentation.
Given the state of ACPI, I'm puzzled why Canonical thinks this is a good move.
It probably is. ACPI has been a headache from day one for anyone other than Microsoft (and probably even them from time to time). The reason is the specification is only partly defined, and the rest is up to the OEMs who generally won't play nice with anyone other than Microsoft. With the number of hardware and firmware bugs out there in race-to-the-bottom consumer market (yes this includes the gamer market too), you can probably imagine how many different implementations, bugs, and general brokenness in ACPI with just the desktop systems let alone the laptops where the problem is MUCH worse! You don't normally see these with Windows because the vendor specific drivers hide user visible problems. We see them in the open source world because, well, for one it's open development, and the other is that we get caught by all the "gotchas" the OEMs cover up with their in house drivers and otherwise hide behind NDA for documentation.
Given the state of ACPI, I'm puzzled why Canonical thinks this is a good move.
FWTS program could help also to make the bios/uefi better?
Maybe not suspend and I indeed think it's more kernel or driver related. But for anything else related to screen handling as explained above, it's a complete disappointment.
In 12 years of Linux, I've never experienced that with any other DE (than Gnome 3).
It's also amdgpu. Hence why I don't think it's specific to nvidia. Either both drivers are half baked or there's a different reason...
The whole area. There is nobody specifically to blame. My laptop still simply blacks out with a new install, until I remember I have to hack into the boot process and enter "nomodeset" in the strangest way possible.
WTF, are Ubuntu's developers stupider than I thought?
Can't they just stop with these "We are smarter than the user and we're turning on things by default for him/her" ?
I bet that after a year or so a lot of users with normal hard disks (not SSDs) will complain that their hard drives died of all these on/off power cycles.
Now I can't ever recommend Linux Mint, which is based on Ubuntu, to my friends because of this crap.
And I thought that the worst thing in Ubuntu 18.04 is the introduction of spyware (data collection), and now I hear about this...
I can't even decide which is worst.
Automatic system suspend may actually be highly beneficial to some (all?) Western Digital HDDs. There's a bug where the load cycle count on WD drives on Linux will be significantly higher: https://wiki.manjaro.org/index.php?t...ve_Fix_-_Linux
Of course running those commands to fix the problem would be best. Luckily there's choices.
I'm also pretty sure most HDDs have a suspend feature in the firmware that's enabled automatically too.
You're also free to toggle the suspend setting on all popular operating systems, including Ubuntu. I'd argue that suspend on Linux works well for most people, but considering 18.04 isn't released yet, now would be a pretty good time to test it out and provide feedback instead of just shouting the usual "boo Ubuntu/Canonical" line blindly.
FWTS program could help also to make better the bios/uefi?
I'm not sure what you're asking here. Is there a program that can make this better or if it's better to fix this in firmware?
The problem is the ACPI standard was designed to be vague and incomplete. You can thank Intel and Microsoft for that. At the time it was first introduced back in the mid to late 90s, many were pointing out that such a poorly designed standard would cause more problems than the existing one, APM. Fast forward till today and there are many problems broken power management implementations are causing users of both Windows and FOSS solutions. Sometimes these OEM implementations are so broken they won't even work properly in Windows let alone Linux or BSD! I once had a Gigabyte ATX board that wouldn't properly sleep even under Windows. The state would be subtly corrupted on wake up requiring a full reboot anyway.
There's very little Linux, OpenBSD, FreeBSD, et al can do about it other than what's already being done - reverse engineering the quirks and bugs and advocating for transparency.
Hey. Looks like the automatic suspend as default thing might be rooted in GNOME 3.28. my desktop updated from 3.26 today, and it just suspended on its own.
I checked settings, auto suspend after 20 minutes was set. I know it was off before.
It's also amdgpu. Hence why I don't think it's specific to nvidia. Either both drivers are half baked or there's a different reason...
Strange, do you have an intel mainboard? I'm on a Ryzen system using the amdgpu driver in Gnome. Suspend and that stuff works fine hete. You need a recent kernel and possibly the out-of-tree kernel module (dkms) provided by amd.
Comment