4 ms·

Sleep and hibernate have nothing to do with drivers. They are done via ACPI. ACPI is implemented by the device vendor, is part of BIOS/UEFI and is notoriously

Sleep and hibernate have nothing to do with drivers. They are done via ACPI. ACPI is implemented by the device vendor, is part of BIOS/UEFI and is notoriously buggy.

1996 6y ago
Some manufacturer selectively implement ACPI (ex: no S3 or S4, only S0 for connected standby) making things worse
Overdr0ne 6y ago
No. Linux drivers are supposed to implement runtime_pm callbacks. These are called based on the usage counter of those devices. ACPI is an Intel/microsoft standard for power state definition with spotty compliance. How and when you put those devices into whatever power state, ACPI or not is dictated by those callbacks. Bugs seem to most often occur when you turn off something when it is still being used cuz someone failed to claim it or released it too soon. Also asic bugs in their definitions of their power states.
- dyingkneepad 6y ago
  runtime_pm is generally for runtime suspend (Intel calls it s0ix) instead of S3 suspend. You can implement S3 suspend using the same callbacks as your runtime_pm callbacks, but you don't need to. The runtime_pm framework is for when applications are still running but the device goes to sleep. In S3 suspend first every single user space application freezes, then the drivers go to sleep. S3 is much easier to implement.
  - Overdr0ne 6y ago
    I think ideally all pm would be controlled by the runtime_pm and qos frameworks. You then don't need to define explicit power states like 'sleep' or 'suspend', you instead simply use what you need for a given performance spec and naturally use a minimum of power. I think that is the ultimate plan
    - dyingkneepad 6y ago
      It's not that simple. There's a lot of predicting the future when it comes to power management. When you put things to sleep in order to save power you add latency, because waking up the hardware and restoring its state takes a long time. It's all tradeoffs, and "use minimum power" is taking the slider and shifting it all the way to one side.
usr1106 6y ago
> Sleep and hibernate have nothing to do with drivers. That sounds like a brave statement to me. Without knowing many details I believe that drivers can block the system from hibernating when they don't cooperate correctly. I am absolutely sure during wakeup the driver needs to cooperate correctly. There are numerous cases that some device does no longer work correctly after wakeup. I doubt that ACPI alone can be blamed for all of the issues, even if I don't like the close source nature of ACPI. Is there any open source approach to ACPI? Not that I'd expect to work better right away. But you know whom to blame. In the worst case yourself for not starting to fix it.
_notreallyme_ 6y ago
Well, there is a driver for ACPI. I have the vague souvenir of Linus Torvalds calling BIOS/UEFI dev "monkeys on crack" or something along the line...
- raverbashing 6y ago
  Yes but on top of that Linus had a very "stern taking to" kernel developers who would fix it for one model but break it for others, so has made sure developers wouldn't break each others code
kodah 6y ago
> Sleep and hibernate have nothing to do with drivers. I think this is halfway accurate. Drivers are part of the problem and firmware is the other. Other folks in this thread have gone on to explain it better than I can, so I'll just point you to them. That said, I think things like the new firmware update manager that connects device creators to the Linux ecosystem so they can provide smooth and regular updates to users are pivotal to solving these kinds of problems. I've had less problems on PopOS due to this. Firmware updates have at times completely eradicated the more usual problems I experienced with Linux, which in an uneducated guess, probably boiled down to interoperability.
kinleyd 6y ago
I remember trying to set up a PVR and getting pretty far using mpv and at. The system worked as long as it was left on. rtcwake was the bridge that was too far: Upon waking, recording started but ACPI errors occurred soon after, culminating with ivtv reporting the encoder had died. I never got past that stage, but it was a worthy try - and I learned that some bugs ain't never going to be fixed. Edit: It was an Arch setup from about 5 years ago.
dyingkneepad 6y ago
Driver developer here. The sentences above are just plain wrong. Drivers have to implement callbacks for suspend. A driver needs to make sure it saves all of its state before the suspend, and then it needs to make sure it restores all of its state after resume. S3 suspend often kills the state of every register that was previously written.

Sleep and hibernate have nothing to do with drivers. They are done via ACPI. ACPI is implemented by the device vendor, is part of BIOS/UEFI and is notoriously buggy.

1996 6y ago

Some manufacturer selectively implement ACPI (ex: no S3 or S4, only S0 for connected standby) making things worse

Overdr0ne 6y ago

No. Linux drivers are supposed to implement runtime_pm callbacks. These are called based on the usage counter of those devices. ACPI is an Intel/microsoft standard for power state definition with spotty compliance. How and when you put those devices into whatever power state, ACPI or not is dictated by those callbacks. Bugs seem to most often occur when you turn off something when it is still being used cuz someone failed to claim it or released it too soon. Also asic bugs in their definitions of their power states.

dyingkneepad 6y ago
runtime_pm is generally for runtime suspend (Intel calls it s0ix) instead of S3 suspend. You can implement S3 suspend using the same callbacks as your runtime_pm callbacks, but you don't need to. The runtime_pm framework is for when applications are still running but the device goes to sleep. In S3 suspend first every single user space application freezes, then the drivers go to sleep. S3 is much easier to implement.
- Overdr0ne 6y ago
  I think ideally all pm would be controlled by the runtime_pm and qos frameworks. You then don't need to define explicit power states like 'sleep' or 'suspend', you instead simply use what you need for a given performance spec and naturally use a minimum of power. I think that is the ultimate plan
  - dyingkneepad 6y ago
    It's not that simple. There's a lot of predicting the future when it comes to power management. When you put things to sleep in order to save power you add latency, because waking up the hardware and restoring its state takes a long time. It's all tradeoffs, and "use minimum power" is taking the slider and shifting it all the way to one side.

usr1106 6y ago

> Sleep and hibernate have nothing to do with drivers. That sounds like a brave statement to me. Without knowing many details I believe that drivers can block the system from hibernating when they don't cooperate correctly. I am absolutely sure during wakeup the driver needs to cooperate correctly. There are numerous cases that some device does no longer work correctly after wakeup. I doubt that ACPI alone can be blamed for all of the issues, even if I don't like the close source nature of ACPI. Is there any open source approach to ACPI? Not that I'd expect to work better right away. But you know whom to blame. In the worst case yourself for not starting to fix it.

_notreallyme_ 6y ago

Well, there is a driver for ACPI. I have the vague souvenir of Linus Torvalds calling BIOS/UEFI dev "monkeys on crack" or something along the line...

raverbashing 6y ago
Yes but on top of that Linus had a very "stern taking to" kernel developers who would fix it for one model but break it for others, so has made sure developers wouldn't break each others code

kodah 6y ago

> Sleep and hibernate have nothing to do with drivers. I think this is halfway accurate. Drivers are part of the problem and firmware is the other. Other folks in this thread have gone on to explain it better than I can, so I'll just point you to them. That said, I think things like the new firmware update manager that connects device creators to the Linux ecosystem so they can provide smooth and regular updates to users are pivotal to solving these kinds of problems. I've had less problems on PopOS due to this. Firmware updates have at times completely eradicated the more usual problems I experienced with Linux, which in an uneducated guess, probably boiled down to interoperability.

kinleyd 6y ago

I remember trying to set up a PVR and getting pretty far using mpv and at. The system worked as long as it was left on. rtcwake was the bridge that was too far: Upon waking, recording started but ACPI errors occurred soon after, culminating with ivtv reporting the encoder had died. I never got past that stage, but it was a worthy try - and I learned that some bugs ain't never going to be fixed. Edit: It was an Arch setup from about 5 years ago.

dyingkneepad 6y ago

Driver developer here. The sentences above are just plain wrong. Drivers have to implement callbacks for suspend. A driver needs to make sure it saves all of its state before the suspend, and then it needs to make sure it restores all of its state after resume. S3 suspend often kills the state of every register that was previously written.