Hello Cédric,
On 7/25/23 9:08 PM, ttcoder@netcourrier.com wrote:
- Suspend/resume
The introduction of that feature in 23.02 triggered some "geek lust" in this aging geek, and now with 23.05 I got around to attempting system integration of suspend/resume in my stack.
In Qemu it seems to all work fine (after I realized the vesa and input driver need to be restarted, reading acpi_suspend.run more carefully). However on bare metal (admittely years old), S3-suspend works well, but at resume time, the screen remains black. I thought maybe if the video driver causes trouble, I can try the "back door" (vnc), to validate the concept that everything works except vesa, and confirm I need to revisit my integration of vesa_drv. So I tried to connect via VNC, but no go, coming back from suspend. Could be that the nic_driver needs to be restarted as well (I didn't handle that, I only restart vesa and ps2_drv currently).
I could persist, but this is not a feature I really need (just wanted it for "bragging rights" :^) so I'll probably wait for newer Genode releases, in case it's a matter of waiting for Genode upgrades. Very cool to have that feature almost at reach though.
currently, it is too early to use this feature productively. In principal all hardware must be re-initialized after resume, since they were powered off potentially and lost configuration. In the current state, the kernels (nova and hw) reinitialize the devices used by them (CPUs, lapic, ioapic, iommu (nova) and serial), but nothing more. The port of acpica does additional wakeup handling, but must also be considered non complete yet.
For Intel graphic devices we have a, in principal capable driver, to do the job, so intel_fb and intel_gpu works on some systems. By restarting them, they initialize the hardware again into a usable state.
In contrast, vesa_drv or boot_fb expects that someone (e.g. Bios/UEFI) did the job of setting up the hardware, which is not the case after ACPI resume (as far as I can tell). That means also, that for AMD or NVDIDA devices you will have to have "real" drivers, so that they can work after ACPI resume. So, AMD/NVDIDA cards are not what GenodeLabs is focusing on at all, beside some hobby interests/experiments of some of us. If this is a target hardware for you/someone, first the drivers need to written or ported ...
By restarting the network driver after resume, the hardware should be get back into a usable state, but I did not tried so far. It may happen that new code paths in the ported drivers get triggered, which needs to be implemented/inspected. Lucky, who gets a working serial interface after resume for doing the debugging job ...
So for now, I think you should consider this feature experimental, as you guessed already.
Cheers,
Alex.