Feedback on 23.05

[Alexander Boettcher]

Hello Cédric,

On 7/25/23 9:08 PM, ttcoder at netcourrier.com wrote:
> 1) 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.

-- 
Alexander Boettcher
Genode Labs

https://www.genodians.org - https://www.genode.org