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.
Is systemd involved at all with these problems?
WONTFIX
No one has managed to make it work reliably on Windows either. I don't think I've ever encountered a laptop on which Suspend wasn't either a game of Russian Roulette, or a guaranteed way to require a restart.
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.
This half-assed reply from johnv-valve reminds me why I don't bother submitting issues for projects hosted on GitHub. I've seen that kind of useless reply, followed by an immediate closure of what's apparently a legitimate bug report, way too often within GitHub. While this can happen with other bug reporting systems, too, I think that there's something with the GitHub culture and mindset that really promotes such disrespectful handling of bugs. Maybe it's the total lack of accountability, coupled with the "social coding" concept. More traditional non-GitHub bug tracking systems were just about that: tracking bugs. But GitHub adds the "social" aspect to it, which ends up just being a way for the project leaders to go on power trips, which often involve treating mere users of the software like total shit.
But even disrespectful bug closures like that don't match up to the pathetic "code of conduct" controversy bullshit we saw recently. I've been involved with open source software development for a couple of decades. We didn't need bullshit "code of conducts" before this GitHub era, because our coding wasn't "social". We were writing open source software to solve real problems, or to make our lives easier. We weren't coding as a way to attract attention, or to see who had a bigger e-penis, or to treat others like shit just so we can feel like we have "power" over others. We just naturally treated one another with respect, so we didn't need some lengthy, goddamn list of rules governing each and every possible aspect of our social interactions! It's only now that the coding becomes secondary to the "social" that all this bullshit about "code of conducts" starts coming up, and it's really quite pathetic!
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.
...wake from suspend is a whole lot worse.
Tried getting my wireless logitech keyboard to wake up my ubuntu-installed intel NUC to wake from sleep, but I can't get it to work.
Logitech's Unifying receiver can wake from sleep on Windows out of the box, but ubuntu needs hacks and tweaks... of which I can't get to work.
Having to get out of the chair and lean over to hit the power button on the computer should not be a feature when there's a wireless keyboard on the couch.
READY.
PRINT ""+-0
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.
> Suspend/Sleep saves the current state of the system in RAM
Where is "the current state of the system" normally kept, if not in RAM?
Not really. Suspend just completely sucks everywhere.
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.
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
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.
Think of how we use video devices. Not just in Linux, in pretty much all current systems. In the name of "efficiency" we memory-map them, and we let the user process directly mess around with the internals of a hardware device.
This is the way a set-top video game box works, not a secure and reliable operating system.
Until the video is firewalled off from the user the way other components of the operating system are, it's not going to be safe, secure, or reliable. Obviously we'll need new hardware designs to make this work fast enough.
Bruce Perens.
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?
Then how does Android work so well?
Not really. Suspend just completely sucks everywhere.
Except Playstation 4 and Xbox One, and since SteamOS is for gaming consoles, that's all that matters.
For those who think a simple suspend is easy, go read one of Matthew Garrett's old posts about the mess. Here's an example:
http://www.advogato.org/articl...
Apparently it's much nicer now.
Ask me about repetitive DNA
Which is odd, Win98 was the last time I had a machine where Suspend worked properly.
-=This sig has nothing to do with my comment. Move along now=-
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.
I don't see why this has been modded down. Suspend/resume has worked fine on OSX since 10.1 for me at least. My experience with suspend/resume on Windows has been hit and miss, and I haven't tried in on Linux (I run Linux in VMs and on servers, not on desktops/notebooks). I've heard people complain about suspend/resume on Linux, but the other day I saw a friend of mine having no trouble with suspend/resume with Ubuntu on a Toshiba notebook.
Sleep and suspend, outside the white-box laptops, pretty much never worked for me on Windows (2000, XP, 7). That's at least 4 home-built PCs. First one I thought I have messed up with the parts. But for the later ones I have specifically looked for the the parts officially supported by Windows. And still no dice.
On Linux, it is historically hit and miss. On earliest systems, the sleep and suspend were not supported at all. Later, when Linux started warming up to the laptop support, it still generally didn't worked for me (but I also haven't specifically tried the distros which officially claimed to support the suspend). These days, Linux' sleep/suspend support (on Xubuntu) generally works for me without problems.
The last PC I have built, Windows fails to come out of the sleep/suspend. With hybrid suspend it takes ~5 minutes before Windows reverts to resume from hibernate and finally starts. The (X)Ubuntu 12.04 and 14.04 have no problem with the PC whatsoever: both sleep and suspend worked out-of-box without a hitch.
P.S. To the problem with the controllers SteamOS had, I can probably relate. In office I have several custom USB devices and corresponding applications which misbehave after suspend. The applications open the devices and keep them open. After suspend, it seems that Linux tries to "replug" the devices, but the device nodes are locked by the applications. Consequently, the kernel (or udev?) assigns to them new device nodes. Applications do not work, because devices have "disappeared". Restart of application doesn't help because the device nodes are not there. One has to stop the application, unplug the devices, replug the device and start application again. From perspective of the software developer, it is a rather underdeveloped area in Linux: detection and handling in application of coming out of the suspend. On Linux there is precisely zero ways to reliably detect that the system just came out out of the suspend. One has to resort to stupid unreliable hacks like the polling of CLOCK_BOOTTIME.
All hope abandon ye who enter here.
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.
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
I have suspend fail occasionally on my Lenovo notebook running debian 8 (systemd) and Win7. I have a desktop system with a Gigabyte motherboard, core i7 and suspend fails there too occasionally - same operating systems.
I have bad luck (or I'm too cheap). I think the Lenovo BIOS is the problem and I believe my SATA III controller is the problem on my desktop.
Cthulhu Saves.
No, modern OSes use a pagefile. Swapfiles went out with the PDP-11.
Except, you know, Windows. Or, if you configure it that way, Linux. Oh, wait, you're attempting to redefine terminology to satisfy yourself. Guess what? We call both of those things swap files now. And we swap pages out to the paging file.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Happens with Diablo UEE as well, basically the game thinks network has gone down so when it resumes it's in LAN mode. all you have to do in UEE is just to put it back to whatever mode you want.
One reason I forget it is that Windows misbehavior is so rampant that its just a drop in the bucket. I'm using Windows 10 right now, and I suppose I could see if the problems crop up with it. I guess it's probably a driver problem moreso than a sleep problem. Windows 10 keeps me busy with its own idiosyncracies that I am frequently submitting issues with the Feedback app.
Suspend support for a given set of hardware is really hit or miss.
i'd like the auto-update-and-reboot be a bit smarter and signal apps that an update reboot is occurring and then the apps save their state
Windows applications do get a restart notification. Bug the publishers of the applications that you use to register for and act on this notification. On the other hand, Microsoft is hypocritical about this, including with Windows several applications that do not save their state.
In theory, Windows is already designed this way. Only a few services require a restart. It's just that PC operating systems in general have become so big, and people on the other side of the Internet have become so malicious, that at least one update per month affects a critical system service.
A lot of the issues I've had with suspend have been with the Nvidia/ATI proprietary video drivers, especially when switching video modes, and beyond that with USB peripherals
Suspending worked fine, when resuming I'd often have peripherals missings (often unplugging/replugging worked OK for keyboards, but not so much on a laptop) and plenty of weird stuff would occur with the video drivers.
Anything before Vista didn't S3/S4 (sleep/hibernate) properly for me. Part of that is building my own machine, so there was more incompatibility than from a manufacturer who would have tested/tweaked the combination before release. But I dealt with several manufactured PC's before that time (belonging to other people) where I've had to say - this isn't going to work and disabled suspend.
https://www.kernel.org/doc/Doc...
Modern OSes use a pagefile, eh?
That seems to say exactly opposite.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
XP was hit or miss for me, and I didn't use Vista long enough to be able to say, but starting with 7, suspend/resume in Windows has been 100% solid for me.
Karma: Poor (Mostly affected by lame karma-joke sigs)
Mint on my Thinkpad wouldn't suspend properly. It suspended/slept properly most of the time, but occasionally it wouldn't. It was kinda like rolling a D20 every time I needed to take the laptop out anywhere.
If you were me, you'd be good lookin'. - six string samurai
This is one of the big reasons I switched to Mac a long time ago (Pre Windows 7). I got utterly fed up with Windows being unable to handle suspend/resume. I tried to go to Linux, but the amount of fiddling and script editing I needed to do to make it was was just absurd, and still wasn't guaranteed to work.
I am able to close the lid on my Macbook Pro to suspend, open it to resume, multiple times a day for weeks at a time without ever having to shut down or reboot. (Ocassionally it would die, at which point I would be livid because it would be so unexpected). Whether this is still true or not, I'm not sure, as I haven't needed to do this for a couple years now, but it was true for 10.5, 10.6 and 10.7.
It's depressing that that it sounds like things haven't improved at all on the Linux side... I don't want to go to back to Windows, especially considering all the privacy nightmares I've been reading lately about Windows 10, but I'm equally unhappy with the appliance-ification of computers that Apple is doing... I swear it seems like we're going full circle to go back to the 1980s.
One would have thought that by going the Apple route and focusing on a specific and limited set of hardware, Valve would be able to focus on making sure that that hardware works flawlessly. I believe there are several Linux-certified laptops that are supposed to have done this (I can't remember who at this point... Dell maybe?), but I have no experience with them so I can't say how successful they were.
But rambling aside... Being able to suspend and/or hibernate should be considered a standard feature in almost everything at this point, so a device that can't handle it just seems... sub-par, and makes you wonder what else they've screwed up, or if they're even competent enough to put out a decent product in the first place.
Pretty much everything network will shit itself on resume on any OS unless maybe you have a hardwired ethernet connection with a static IP and the device manufacturer/driver developer thought that case was worth supporting. Before I disabled sleep/suspend on it, my Windows 7 computer's wireless adapter would work for about 15 seconds out of suspend (long enough to load up a webpage) before either Windows or the driver thought "Uhoh! I just resumed! I better wipe my address and re-connect!" and stop working while the systray icon let me know it was connecting to the network I was just using. I assume that it worked for the first few seconds because the state was saved/restored correctly, and since nothing else uses my wireless network, it never had a problem with IP conflicts.
If I have been able to see further than others, it is because I bought a pair of binoculars.
Hey, you have the same bullshit criticism as last time, I have the same response, you presumably have the same lack of response. I'm going to be less polite here, because you're obviously trolling.
Linux does not need desktop marketshare, and having a closed driver model would be too great a price to pay. If that means trouble for Valve, too bad. However, the driver model actually has nothing to do with anything, and your predictions and your challenge are worthless. You do not have a clue what you are talking about. If the drivers are so terrible, how are there billions of Linux devices?
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
I love it when Microsoft takes "Shut Down" and turns it into "Kinda sorta hibernate" without relabeling it as such. From what I have observed, it has to reinitialize the disk controller to save the system state to disk, which on some controllers can take quite a long time. So your system sits there powered on with the screen off and you have no idea why it hasn't actually shut down yet. Almost as dumb as systems that default to "Sleep" when you press the power button.
Of course all of this is typical MS fashion where they would rather implement stuff like this to help startup times than debloat their OS. I have a Linux laptop that goes from bootloader to usable desktop in 10 seconds on an ancient mobile C2D, because it's not bloated. No "partial hibernate" trickery required.
Good thing it works on a few dozen machines. Just a few million to go.
Suspend CAN work flawlessly on both Windows and Linux.
It CAN be extremely flaky for some people. It's the luck of the draw whether someone can read the specs correctly when doing device firmware.
Please show me 1 laptop that has an issue installing Windows on it, and then I will buy your argument, because I don't believe you. Even MacBooks run Windows...
But thank you for proving my point: the Linux community is primarily filled with assholes.
I have never had Windows suspend work reliably on any laptop or any of my desktops so it is one of the first things I completely disable along with automatic updates. I consider it one of the many broken features which has never worked correctly.
I wonder if there was an automatic update that would have fixed your problems ;-)
I disabled automatic updates because they managed to destroy a system. I do the updates manually.
During a power outage the UPS signaled the computer to shutdown like normal but then it started doing its automatic update thing because of the shutdown which lasted longer than the UPS could keep the computer running. The result was a destroyed Windows installation.
So no, I no long use automatic updates.
During a power outage the UPS signaled the computer to shutdown like normal
Crappy UPS software problem. There are multiple documented ways of making Windows shutdown specifically without installing updates. There's also a group policy you can set that the default shutdown option becomes shutdown and not "install then shutdown".