Hi,
I'm running sculpt-20.02.img on QEMU and I wonder if the only way to shutdown sculpt is to kill QEMU?
Is it the same for real HW (e.g. to push the reset button)?
I'm sure it is somewhere in the documentation but I've failed to find it.
Best regards,
S.P.
Hello,
On 16.04.20 09:23, Shlomo Pongratz wrote:
I'm running sculpt-20.02.img on QEMU and I wonder if the only way to shutdown sculpt is to kill QEMU?
Is it the same for real HW (e.g. to push the reset button)?
I'm sure it is somewhere in the documentation but I've failed to find it.
I wonder, why would you ever want to shut down a running Sculpt system? ;-)
Joking aside, the answer to your question is currently not very compelling:
There is a way to power off the system once you deploy an ACPI driver. Please check out the depot of alex-ab for the corresponding component (System -> ACPI-CA). The component reports various ACPI information (aggregated in the report fs once the component is running) and also watches the system state as defined in /config/system. When changing the content to '<system state="poweroff"/>', the ACPI-CA driver will power off your machine.
That said, this raw mechanism is not a proper shutdown procedure. In particular, it does not imply the writing-back of data cached in a file-system server. This problem calls for an architectural answer, which is on our road map [1] for the 20.11 release (the item "Sculpt: component lifetime management, shutdown protocol").
[1] https://genode.org/about/road-map
Until then, the usual procedure is to manually shut down VMs and applications, wait a few seconds (cached file-system data is written back every 10 seconds), and turn off the machine manually (or via the ACPI-CA mechanism).
Cheers Norman
Hello, Can I ask two quick related questions?
Until then, the usual procedure is to manually shut down VMs and applications, wait a few seconds (cached file-system data is written back every 10 seconds), and turn off the machine manually (or via the ACPI-CA mechanism).
1) I have been using Sculpt on real hardware. What I do for shutdown is to open "Storage" under "Components" and de-select "Use" on my primary "GENODE*" partition. I assumed that this would cause any pending file operations to complete, similar to a UNIX "sudo umount". Is that right?
2) Sometimes I do feel the need to reboot Sculpt, but potentially this is not completely necessary if there were a way to restart certain services. Is it possible to restart internal components? Most common culprits for me would be usb_drv, and the depot-related components. Ideally this could be done without the runtime system killing my VMs, but I suspect that's asking too much.
Regards, Colin
Hi Colin,
- I have been using Sculpt on real hardware. What I do for shutdown is
to open "Storage" under "Components" and de-select "Use" on my primary "GENODE*" partition. I assumed that this would cause any pending file operations to complete, similar to a UNIX "sudo umount". Is that right?
Unfortunately not. By "unusing" the Sculpt partition, you are immediately wiping out all components without mercy. You probably have been lucky because the file-system's cache is quite small and the file system writes back data periodically.
- Sometimes I do feel the need to reboot Sculpt, but potentially this
is not completely necessary if there were a way to restart certain services. Is it possible to restart internal components? Most common culprits for me would be usb_drv, and the depot-related components. Ideally this could be done without the runtime system killing my VMs, but I suspect that's asking too much.
The USB driver and the depot components are strict dependencies. If restarted, a dependent VM would be implicitly restarted as well. For example, even though you can in fact force the restart of the USB driver by editing a 'version' attribute in USB driver's <start> node in /config/drivers, this is not helpful because all dependent components (including Sculpt's leitzentrale) would be affected. Better don't do this! ;-)
We actually plan to make drivers for network, wifi, framebuffer, and audio restartable, which will generally become possible because those particular drivers do not encapsulate much state. But bus drivers (like USB) or storage drivers contain complex state that would go lost upon restart. So those components must ultimately become infallible.
You can help us with that. I encourage you to report any problems that you experience with those low-level components, if possible.
Cheers Norman
Norman,
particular drivers do not encapsulate much state. But bus drivers (like
USB) or storage drivers contain complex state that would go lost upon restart. So those components must ultimately become infallible.
You can help us with that. I encourage you to report any problems that you experience with those low-level components, if possible.
I see. My problem is not so much with usb_drv but with a particular device (my wifi dongle that's passed to the VM). After VM shutdown the USB state becomes corrupted somehow, and requires a hard reset by manually detaching the device, which is a pain. I hope to find some way to issue a reset in SW, but USB seems not to make that easy. Under linux one can, for example, detach the PCI connection for the host controller (e.g. xhci controller, ehci controller), and then rescan the PCI bus but it has to be done with caution because you lose the keyboard and mouse access during the reset period prior to the rescan unless you have a backup input device. There are also ways to cycle per-port power on some hubs, although I have not figured them out. They are I believe difficult but possible to control in linux, I think it may not even be possible under Sculpt right now?
Colin
It seems like it would still be good to make the USB driver restartable, and have the ability to do simulate disconnecting then reconnecting individual devices as well.
On Fri, Apr 17, 2020, 9:07 AM Norman Feske norman.feske@genode-labs.com wrote:
Hi Colin,
- I have been using Sculpt on real hardware. What I do for shutdown is
to open "Storage" under "Components" and de-select "Use" on my primary "GENODE*" partition. I assumed that this would cause any pending file operations to complete, similar to a UNIX "sudo umount". Is that right?
Unfortunately not. By "unusing" the Sculpt partition, you are immediately wiping out all components without mercy. You probably have been lucky because the file-system's cache is quite small and the file system writes back data periodically.
- Sometimes I do feel the need to reboot Sculpt, but potentially this
is not completely necessary if there were a way to restart certain services. Is it possible to restart internal components? Most common culprits for me would be usb_drv, and the depot-related components. Ideally this could be done without the runtime system killing my VMs, but I suspect that's asking too much.
The USB driver and the depot components are strict dependencies. If restarted, a dependent VM would be implicitly restarted as well. For example, even though you can in fact force the restart of the USB driver by editing a 'version' attribute in USB driver's <start> node in /config/drivers, this is not helpful because all dependent components (including Sculpt's leitzentrale) would be affected. Better don't do this! ;-)
We actually plan to make drivers for network, wifi, framebuffer, and audio restartable, which will generally become possible because those particular drivers do not encapsulate much state. But bus drivers (like USB) or storage drivers contain complex state that would go lost upon restart. So those components must ultimately become infallible.
You can help us with that. I encourage you to report any problems that you experience with those low-level components, if possible.
Cheers Norman
-- Dr.-Ing. Norman Feske Genode Labs
https://www.genode-labs.com · https://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
-
Colin Parker -
Nobody III -
Norman Feske -
Shlomo Pongratz