Slashdot Mirror
SteamOS Has Dropped Support For Suspend
jones_supa writes: As pointed out by a Redditor, it seems that suspending the machine is not officially supported by SteamOS anymore. A SteamOS user opened a bug report due to his controllers being unresponsive after a suspend cycle. To this, a Valve engineer bluntly reported that "suspend is no longer supported". He further explained the issue by saying that given the state of hardware and software support throughout the graphics stack on Linux, the team didn't think that they could make the feature work reliably.
Suspend is such a complicated feature that touches every part of the stack. I've found it works about 50/50. Every now and then I try it and it works for a while until a kernel update breaks it, eventually I try again in a few months and it's working again. I wouldn't support it if I wanted to remain sane.
If I mod you up, it doesn't necessarily mean I agree with what you've said, sorry.
Suspend is a key feature, and energy costs more than ever. It's not acceptable not to suspend. Many people won't shut down, and if they can't suspend, they'll just leave the system on and turn off the display.
I hope they're at least using the lowest power states when at idle, and with a governor more intelligent than ondemand.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Considering the push for the "Year of the Linux Desktop" it's strange Ubuntu does not support hibernate and hasn't for years now. Hibernate is important, because unlike suspend it does not require power.
It's annoying to have the computer shutdown when it runs out of power instead of simply hibernating.
No.
This is a great example of how not to close a bug report.
Merely stating that the feature "is no longer supported" and closing the bug report without giving any further explanation is the wrong way of handling the situation.
If a user went to the trouble of submitting the ticket, then somebody associated with the project should at least put forth the small amount of effort it takes to explain why the bug is being closed without being properly resolved.
Providing some concrete information is just the sensible, courteous thing to do.
Uselessly vague "$FEATURE is no longer supported"-type replies do no good.
Sleep and Suspend are two different names for the same thing. Windows supports Hibernate, but it's often disabled by users to save hard drive space. Suspend/Sleep saves the current state of the system in RAM and powers off pretty much everything else (including the CPU) for quick resume. Hibernate copies the contents of RAM to the hard drive, and powers everything off. Resuming is slower, but it will survive a complete power outage.
I can tell you're lying, systemd-shill.
Swapfile, of course. Do you not know the basics of modern OS architecture?
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
Giving a proper explanation for why a bug is being closed is not "handholding".
It's professionalism, plain and simple.
Being a programmer doesn't mean that one's incapable of providing a technical justification for closing a bug ticket.
It doesn't even matter if the person who logged the bug is a customer or not.
If the bug ticket is closed, then a complete, technical explanation of why is the minimum that should be expected.
The person who opened the ticket, and anyone else reading it, regardless of whether they are or aren't affiliated with the project in question, should be provided with a full explanation as to why the bug was closed.
This will typically be well over one sentence in length.
So if someone is closing a bug ticket and their justification is only one or two sentences long, then they should realize right away that what they're providing is completely insufficient.
Technically, suspend is not the problem. The problem is resume. It doesn't probe and reattach the controllers to the same point in the device tree that they were in when the system was suspended. Since those are the device nodes that SteamOS has open at the time of the suspend, and they route to The Noplace(tm), the controllers become unresponsive.
This is a general problem in the Linux device model, and you can see problem in the device model poke their heads up in various places.
For example, if you plug in two USB keyboards, what you are going to see when you hit the caps lock key on one of them is that the caps get locked for both of them, but the LED indicating that the caps lock is on is only lit on the original keyboard. This is great fun, when you see the LED state on both keyboards relative to the caps lock state, when you bounce the caps lock key on the second keyboard.
Presumably, this was implemented this way in order to allow multihead operation, with the keyboards separately (and explicitly -- which they are not by default -- to separately running console instances. But it's indicative of deeper problems in the model.
The reattach operation should (in theory) be handled by the udev mechanism, which I'm told is subsumed in systemd; however, they've faithfully reproduced the problems in the original implementation in the replacement as well (so it actually doesn't matter which one SteamOS is using, so please don't argue about that crap).
There are two implementations that do work; however, they in fact work differently.
The first implementation is in Windows; it works by directly assigning the device descriptor based on the USB vendor and device ID. What this effectively means is that when you resume, everything gets the same descriptor (or a replacement) that it had going own. The keyboard "problem" is handled in Windows by making them "the same device" -- in other words, you caps lock on one keyboard, it does it on both, and you undo it, and it does it on both.
The second implementation is Mac OS X; it's handled by explicit enumeration order of USB bus devices, and the using the USB vendor and device ID *and* the enumeration position ("bus ID) to uniquely identify the device.
You'll also notice, if you look, that Linux has problems with keyboard internationalization and locale. This is most easily seen by using a locale specific keyboard, and having it not be recognized. Further, you'll notice that the character set differences are handled by tables in X and Weyland, and these are not the same as the console tables (i.e. the USB ID of the keys is not propagated through the full input stack, and there's a difference in operation between sending the events up through the console, vs. sending events up through the X Server). To fix this would require moving the HID key value translations into the kernel keyboard driver, rather than having it (mostly) in user space in all three instances (X, Weyland, console).
Finally, Apple is one of the few vendors that actually correctly fills out the USB device serial number field correctly, so it's hard to use that as a unique identifier (specifically, it makes it really hard to mask program all your controller chips, without adding a "burn the fusable links" step).
Further, they are also one of the few vendors that sets the locale field in their USB devices (most laptop vendors will get this right during manufacturing, by placing the value into the BIOS, since the laptop keyboard is actually matrix decoded by the EC via a grid hooked up to GPIO pins, and then the EC pretends it's an 8051 with a PS/2 interface for the keyboard to mux a PS/2 trackpad -- e.g. like a Synaptics -- to look like a standard PS/2 keyboard and mouse).
Apple handles for unrecognized keyboards by having you press "the key right of the left shift key" and "the key to the left of the right shift key", and then uses the key IDs. Not ure if they have a patent on it, but it's a lot more clever than what Linux or the BSDs do to
I don't disagree that a reasonable, well adjusted person should do exactly what you said. But that's not the description of many software engineers, and reality is this sort of report is exactly the same thing that would happen internally in a lot of projects - and in fact it effects the project exactly ZERO to be this succinct; the only real issue is customer perception.
If you want politeness, make all public bug reports go through company representatives. That's in fact what nearly ALL large software companies already do. Stream has tried to model their development/bug reporting more along the lines of Mozilla, or, in the ultimate example the Linux kernel - have you ever read LKML? If this post made you butt-hurt the LKML will rip you a new hole...
Am I the only one who hasn't had a suspend problem in years on any platform? The last time I can recall having suspend not work reliably was on a late '90s Pentium 2 running Windows 98.
I used to get high on life, but I developed a tolerance. Now I need something stronger.
For all the nitpickers, what he said is true. Suspend saves the system state in RAM, which means NOT in CPU registers, GPU registers, nor a myriad other hardware controller registers on devices and hubs all over the system bus. The RAM is left in a low-power, self-refresh mode. Resuming from suspend means powering up all those devices, reinitializing their control registers, and getting everything back in sync with the state that the OS *thought* it was in according to the state stored in RAM.
This process involves coordinated effort of many different layers of hardware drivers to reinitialize each part and restore it to a working state. Some annoying hardware also lacks a simple "load state from bit sequence" function, and instead needs its own convoluted state-machine to be run through multiple steps in the right order to reestablish the state it had before suspending. This is where things usually go comically wrong.
Hibernate suffers all of this plus a bit more. It also has to reinitialize the disk controllers, read the saved system state from disk into RAM, and then perform all this same state-recovery that resume-from-suspend does.
No, the bug simply shouldn't have been closed at all. "We know that it doesn't work right, here's a bunch of reasons why" simply means that this bug should have a bunch of other blocking bugs. Yes, it may not be fixed for a while, but that doesn't mean that it isn't a bug.
So I guess I should make a comment about how superior Windows is because this is an article about Linux OS issues. Then I can be like all the Linux fan boys who just have to comment in Windows articles on how they never have such such issues because they are running a Linux based OS.
I've never have suspend or hibernation issues while running Windows based OS. In fact, it's crazy how fast resume works on my Lenovo Z50-75 running Windows 10. I don't even worry about privacy issues because I turned that stuff off. It's was easy to get the help I needed right from Windows forums on the correct settings.
Instead of all the thousand different yet same Distros. How about all the Linux geeks get together, focus on a handful of Distros and prove to us why it's superior to Windows? Because issues like suspend and the various graphic driver bugs will continue to keep it from wide spread usage. Like it or not, Linux based Distros make up 1.6% of the desktop OS and it's because of problems not because it's better. Microsoft has continued to up their game on the desktop and Linux Distros will have to match them if they every want a chance at taking over.
The swap file is only virtual memory. Both Linux and Windows have a separate file for hibernation. In Windows it's hibernate.sys. If the swap file was in use and then the OS used it again to hold the dumped contents of RAM when hibernating, the existing swap data would be lost. Don't think of swap as a replaceable cache, think of it as slow RAM. It holds real data. Also, Windows has a hybrid Suspend To Disk feature which does a normal Sleep/Suspend then hibernates after some specified time (I've never seen Linux do that. Can it?).
I'm really annoyed at the other ACs that responded to your post. They took the time to rudely point out you were wrong but didn't go the extra tiny step to explain why. You don't appear to know the basics of modern OS architecture, so maybe what went around came around?
its not necessarily the ACPI, its the manufacturers implementation of it and their need to bodge it to make sure it works on windows.
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
Most of the time problems with suspend/hibernation are related to drivers which aren't properly initializing after the memory is restored. the thing with hardware is that the state of the hardware has to be restored after suspend/hibernation to the point that the driver expects as the state. So if a driver isn't capable of restoring that state, it will likely cause some sort of trouble.
Never underestimate the relief of true separation of Religion and State.
The last time Windows suspend didn't work reliably for me I was using Windows ME.
The last time Linux suspend didn't work reliably for me I was using Ubuntu 15.04.
Don't go touch wood, go throw your entire body on it and praise whoever you worship for you lucky and successful life. Suspend and hibernation support is a messy clusterfuck of standards which were never implemented correctly supported by device models that never considered going to sleep as a design consideration.
You got it half right, the problem on Linux is drivers or more precisely a driver stack that hasn't evolved since the days of Win9x. You can sit down and with basic math show that "let the devs handle it" just doesn't scale, even if you had ten times the amount of driver devs than Linux actually has they still wouldn't have enough hours in the day to fix all that gets pissed on when Torvalds and friends change a pointer.
I have taken XP drivers and ran them in Windows 7, taken XP X64 drivers and run them in 8.1 64bit, and until Linus fixes his mess of a driver stack so an OEM won't have to remake every driver when a new kernel comes out? Things are never gonna get any better which is why despite Windows 10 being nothing but spyware pretending to be an OS Linux will not gain even a single percentage point, not one.
The really sad part IMHO? I gave you a perfect test to rub in the dev's noses like rubbing a doggy nose in its poo, they say their driver model works? Show them the results of the Hairyfeet challenge and call 'em out on their bullshit. Instead I get called dirty names for actually expecting an OS to be able to update itself without destroying itself (gasp! shock!) and have FOSSies rush to defend them with classic memes like "its free you can't complain" or the ever hilarious "you should fix it" which is like saying you have a new car that can take on the new Mustang and when somebody asks to see it you hand 'em a pile of raw ore and say "here ya go, make it for me" LOL.
So take the challenge yourself, pick any of those "consumer friendly" distros and knock yourself out, then you will see why Linux doesn't gain any share and why I predict Valve will abandon SteamOS within 5 years, its because you can't build a strong house on a rotten foundation and the Linux driver model is rotten to the core.
ACs don't waste your time replying, your posts are never seen by me.
I don't even worry about privacy issues because I turned that stuff off.
You mean you think you turned that stuff off. I guess you haven't been reading Win10 forums (and /. and other places) in the last few days...
I've had hardware act screwy on Windows, too. Sometimes Windows will just refuse to sleep because a process prohibiting suspend did not exit like it should. Suspend works rather well on my present install of Ubuntu on my laptop, but I've had issues with it waking up.
Chewbacon
The Bible is like Wikipedia: written by a bunch of people and verifiable by questionable sources.
Hibernation never works for me and I am unwilling to debug it. Suspend works like a champ, though.
"So long and thanks for all the fish."
Nope, but it's his brother's fault: suspendd.
In Linux, suspend to disk really does write the contents of RAM to the swap partition.
From here:
Suspend part
~~~~~~~~~~~~
running system, user asks for suspend-to-disk
user processes are stopped
suspend(PMSG_FREEZE): devices are frozen so that they don't interfere
with state snapshot
state snapshot: copy of whole used memory is taken with interrupts disabled
resume(): devices are woken up so that we can write image to swap
write image to swap
suspend(PMSG_SUSPEND): suspend devices so that we can power off
turn the power off
Actually, Windows isn't perfect either. My home desktop will hang on attempts to suspend, shutdown, or reboot. No idea why.
My other windows systems are fine, and all my linux systems also suspend/resume without issue.
So anecdotes can be found everywhere. It has more to do with the firmware/hardware than anything else.
XML is like violence. If it doesn't solve the problem, use more.
Maybe because not every SteamOS install is on a Dell Precision workstation??? Just sayin.
Yes. If you don't want the topic coming back over and over again, you need provide an explanation for why you're closing the ticket. WONTFIX without an explanation is the equivalent to saying, "because I said so."
It's also lazy. Removing an expected feature because you didn't plan your product development well enough isn't acceptable. Set an appropriate milestone and fix the problem. Did you really not plan well enough to anticipate this being a problem?
If you want a vision of the future, imagine a youtube comments section scrolling - forever.