chestm007/linux_thermaltake_riing

Driver doesn't survive after suspend

Opened this issue · 2 comments

Hello,

I found another bug. Still with my ubuntu (Exactly KDE Neon, a 18.04 ubuntu with up to date KDE Plasma).

I accidentally clicked on "suspend" the other day. At the wake up of the PC, the managed thermaltake hardware woke up with default colors and fan settings. I tried to reload the driver, without success.
The weird thing is, the driver is still OK in systemd. But have no effect (tried to stress with stress-ng to see if the fan setting was OK, the CPU transformed into a temporary bacon cooking device, the temperatures said), same for the color settings.

I have actually no resolution for this actually. But a reboot led to a normal behaviour.

CPU transformed into a temporary bacon cooking device

TBH, i laughed and cried at the same time :)

I was actually waiting for this issue in all honesty - i don't use suspend on my machine so i had no idea how this would be handled... turns out, sadly my fears are right.

we're there any logs that might let us know what got borked by the suspend?

Since the controller does not know it is sleeping you have to threat it like initialization when booting the pc, so just send init bytes after you detect resume event from sleep/hibernation.

Or you could stop the service when going to sleep/hibernate and start it when resuming, that should force send the init bytes.