Mageia Forum

Und schon wieder ein komisches Problem: Ich habe hier eine Cauldron-VM unter qemu mit qxl-Grafik. Wenn ich versuche eine lxqt-session zu starten, beendet sich qemu mit folgender Meldung:

Code: Alles auswählen

qemu-system-x86_64: hw/display/qxl.c:1135: qxl_check_state: Assertion `!spice_display_running || ((&ram->cmd_ring)->cons == (&ram->cmd_ring)->prod)' failed.

Andere DEs (plasma, xfce, lxde) funktionieren ohne Probleme, lxqt geht auch mit std-vga oder vmware, scheint also ein Problem mit der Kombination aus qxl und lxqt zu sein. Ich bekomme die Session zum Laufen, wenn ich vorher das lxqt-panel in /usr/bin umbenenne, sodaß das Panel nicht automatisch gestartet wird. Der nachträgliche Start von lxqt-panel funktioniert manchmal, manchmal auch nicht und das ganze System schmiert wieder ab, Log-Einträge in dmesg, journal, .xsession-errors sind nicht zu erkennen (getestet mit mehreren shells per ssh auf das Gastsystem). Hat noch jemand eine Idee, wie man das Problem sonst noch eingrenzen könnte?

Wie genau startest du denn die lxqt-session ?

Könnte sein dass hier ein Patch für qemu fehlt, kannst du mal die komplette Befehlszeile posten die du zum Starten der VM nutzt? Und der qemu-Host, ist das mga5 oder auch Cauldron?

doktor5000 hat geschrieben:Wie genau startest du denn die lxqt-session ?

Ganz normal über den sddm

Der qemu-host ist entweder Cauldron oder Arch, macht aber bei dem Problem keinen Unterschied, gestartet unter Arch per:

Code: Alles auswählen

LC_ALL=C SDL_VIDEO_X11_DGAMOUSE=0 qemu-system-x86_64 -enable-kvm -smp 2 -m 2048 -usbdevice tablet -soundhw hda -monitor stdio -net nic,macaddr=00:16:3e:f4:ed:e2,model=virtio -net bridge,br=xenbr0 -drive file=cauldron.img,if=virtio,cache=none -pflash ovmf/OVMF.fd  -device qxl-vga -spice port=5930,disable-ticketing,streaming-video=off -device virtio-serial-pci -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 -chardev spicevmc,id=spicechannel0,name=vdagent


bzw. unter Cauldron mit

Code: Alles auswählen

LC_ALL=C SDL_VIDEO_X11_DGAMOUSE=0 qemu-kvm -enable-kvm -smp 2 -m 2048 -usbdevice tablet -soundhw hda -monitor stdio -net nic,macaddr=00:16:3e:f4:ed:e2,model=virtio -net bridge,br=xenbr0 -drive file=cauldron.img,if=virtio,cache=none -pflash ovmf/OVMF.fd  -device qxl-vga -spice port=5930,disable-ticketing,streaming-video=off -device virtio-serial-pci -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 -chardev spicevmc,id=spicechannel0,name=vdagent

Welche qemu-Version jeweils? Unter Cauldron vermutlich 2.5, unter Arch auch?

Ich würde das an deiner Stelle upstream melden unter https://bugs.launchpad.net/qemu

Ggf. qemu unter gdb laufen lassen, und dann Backtrace-Informationen sammeln wenn qemu abschmiert.
Siehe auch https://wiki.mageia.org/en/Debugging_software_crashes

Ja, Cauldron ist 2.5 unter Arch 2.4

Code: Alles auswählen

[root@lenovo:~]# pacman -Qi qemu
Name                 : qemu
Version              : 2.4.1-2

Ich bin allerdings nicht überzeugt davon, daß das ein Upstream-Problem ist, LXQT unter Arch z.B. läuft ohne Probleme, sieht für mich eher nach einem Problem bei Mageia und LXQT aus. Außerdem stellt sich mir dann noch die Frage, wer denn eigentlich "upstream" ist, qemu? spice? lxqt?

Verstehe ich net ganz. Du meintest doch qemu beendet sich und qemu-Hosts sind Cauldron und Arch, und das Problem tritt bei beiden auf?
Jetzt aber doch nur unter Mageia oder wie? Verstehe ich net so ganz.

Und warum wäre es deiner Meinung nach ein Problem von LXQt, wenn der eingesetzte Hypervisor für das OS bei der Ausführung von z.B. LXQt abschmiert?
Das ist doch ein Problem des Hypervisors ... und da wäre upstream qemu, weshalb ich das bereits verlinkt hab.
Für spice wäre das https://bugs.freedesktop.org/enter_bug. ... duct=Spice

Aber erläuter mir bitte erstmal wie du das meinst. vielleicht hab ich da irgendwas net richtig verstanden.

doktor5000 hat geschrieben:Verstehe ich net ganz. Du meintest doch qemu beendet sich und qemu-Hosts sind Cauldron und Arch, und das Problem tritt bei beiden auf?
Jetzt aber doch nur unter Mageia oder wie? Verstehe ich net so ganz.

Das Problem tritt nur beim Mageia-LXQT-Gast auf, unabhängig vom Host-System, der Arch-LXQT-Gast funktioniert sowohl unter dem Cauldron-Host als auch dem Arch-Host ohne Probleme, deshalb ja auch meine Vermutung, daß es etwas mit dem Mageia-LXQT im Gastysystem zu tun hat. Und wie ich schon schrieb, das Problem wird im Mageia-Gast von lxqt-panel ausgelöst, ohne das Panel kann man die Session normal starten.

Aber qemu stürzt beim Ausführen des Mageia LXQT-Gastes ab, oder nicht?

doktor5000 hat geschrieben:Aber qemu stürzt beim Ausführen des Mageia LXQT-Gastes ab, oder nicht?

Ja, und das sowohl unter Mageia als auch Arch als Host-System.
Ein Arch-LXQT-Gast funktioniert aber unter beiden Host-Systemen ohne Probleme, also gehe ich davon aus, das das Problem vom Mageia LXQT-Gast kommt, ich hoffe, daß ist jetzt verständlicher.

Also so wie ich gesagt hatte. Bitte den Fehler bei qemu melden, qemu stürzt schließlich ab.
Woher das Problem auch kommen mag, man kann ja keinen permanenten Fix in lxqt einbauen, damit qemu nicht abstürzt, wenn es mit einem bestimmten Video-Treiber benutzt wird.

Falls du für die Zwischenzeit einen Patch für lxqt-panel hast, um das Problem zu umgehen, natürlich immer her damit.