Recently I started having Xorg crash while using firefox. This is f34 in a libvirt kvm, host (also f34) uses internal i915 video. Kernel is 5.12.14-300.fc34.x86_64 but saw this with earlier 5.12.12/13 kernels.
an example crash: ================= ### note: many repeats of the following line precede the crash ### Jul 9 16:28:47 e4 kernel: f 4026531864#104645: failed to wait on release 24 after spincount 301 Jul 9 16:28:47 e4 kernel: [TTM] Buffer eviction failed Jul 9 16:28:47 e4 kernel: qxl 0000:00:01.0: object_init failed for (458752, 0x00000001) Jul 9 16:28:47 e4 kernel: [drm:qxl_gem_object_create [qxl]] *ERROR* Failed to allocate GEM object (454760, 1, 4096, -12) Jul 9 16:28:47 e4 kernel: [drm:qxl_alloc_ioctl [qxl]] *ERROR* qxl_alloc_ioctl: failed to create gem ret=-12 Jul 9 16:28:47 e4 kernel: kauditd_printk_skb: 16 callbacks suppressed Jul 9 16:28:47 e4 kernel: audit: type=1701 audit(1625812127.806:325): auid=4294967295 uid=0 gid=0 ses=4294967295 subj=kernel pid=1035 comm="Xorg" exe="/usr/libexec/Xorg" sig=6 res=1 Jul 9 16:28:47 e4 audit[1035]: ANOM_ABEND auid=4294967295 uid=0 gid=0 ses=4294967295 subj=kernel pid=1035 comm="Xorg" exe="/usr/libexec/Xorg" sig=6 res=1 Jul 9 16:28:48 e4 systemd[1]: Created slice system-systemd\x2dcoredump.slice. Jul 9 16:28:48 e4 audit: BPF prog-id=49 op=LOAD Jul 9 16:28:48 e4 kernel: audit: type=1334 audit(1625812128.526:326): prog-id=49 op=LOAD Jul 9 16:28:48 e4 audit: BPF prog-id=50 op=LOAD Jul 9 16:28:48 e4 audit: BPF prog-id=51 op=LOAD Jul 9 16:28:48 e4 kernel: audit: type=1334 audit(1625812128.528:327): prog-id=50 op=LOAD Jul 9 16:28:48 e4 kernel: audit: type=1334 audit(1625812128.528:328): prog-id=51 op=LOAD Jul 9 16:28:48 e4 systemd[1]: Started Process Core Dump (PID 134753/UID 0). Jul 9 16:28:48 e4 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-coredump@0-134753-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Jul 9 16:28:48 e4 kernel: audit: type=1130 audit(1625812128.593:329): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-coredump@0-134753-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Jul 9 16:28:52 e4 systemd-coredump[134754]: Process 1035 (Xorg) of user 0 dumped core.
Stack trace of thread 1035: #0 0x00007f3c01fda2a2 n/a (libc.so.6 + 0x3d2a2) #1 0x00007f3c01fc38a4 n/a (libc.so.6 + 0x268a4) #2 0x00005595780f7170 OsAbort (Xorg + 0x1ba170) #3 0x00005595780ff446 FatalError (Xorg + 0x1c2446) #4 0x00005595780f5d3a OsSigHandler (Xorg + 0x1b8d3a) #5 0x00007f3c0217fa20 __restore_rt (libpthread.so.0 + 0x13a20) #6 0x00007f3c01716a35 qxl_image_create (qxl_drv.so + 0x8a35) #7 0x00007f3c01716e66 qxl_surface_put_image_for_reals (qxl_drv.so + 0x8e66) #8 0x00007f3c01723350 uxa_copy_n_to_n (qxl_drv.so + 0x15350) #9 0x00005595780d475b miCopyRegion (Xorg + 0x19775b) #10 0x00005595780d735c miDoCopy (Xorg + 0x19a35c) #11 0x00007f3c01723552 uxa_copy_area (qxl_drv.so + 0x15552) #12 0x00005595780831e9 damageCopyArea (Xorg + 0x1461e9) #13 0x0000559577f964af ProcCopyArea (Xorg + 0x594af) #14 0x0000559577f862d7 main (Xorg + 0x492d7) #15 0x00007f3c01fc4b75 n/a (libc.so.6 + 0x27b75) #16 0x0000559577f8667e _start (Xorg + 0x4967e)
Stack trace of thread 1038: #0 0x00007f3c02181a8a __futex_abstimed_wait_common64 (libpthread.so.0 + 0x15a8a) #1 0x00007f3c0217b2c0 pthread_cond_wait (libpthread.so.0 + 0xf2c0) #2 0x00007f3bfc296c43 thread_function (swrast_dri.so + 0x7b8c43) #3 0x00007f3bfc29653b impl_thrd_routine (swrast_dri.so + 0x7b853b) #4 0x00007f3c02175299 start_thread (libpthread.so.0 + 0x9299) #5 0x00007f3c0209d353 n/a (libc.so.6 + 0x100353)
Stack trace of thread 1040: #0 0x00007f3c02181a8a __futex_abstimed_wait_common64 (libpthread.so.0 + 0x15a8a) #1 0x00007f3c0217b2c0 pthread_cond_wait (libpthread.so.0 + 0xf2c0) #2 0x00007f3bfc293edb lp_cs_tpool_worker (swrast_dri.so + 0x7b5edb) #3 0x00007f3bfc293e5b impl_thrd_routine (swrast_dri.so + 0x7b5e5b) #4 0x00007f3c02175299 start_thread (libpthread.so.0 + 0x9299) #5 0x00007f3c0209d353 n/a (libc.so.6 + 0x100353)
Stack trace of thread 1042: #0 0x00007f3c02181a8a __futex_abstimed_wait_common64 (libpthread.so.0 + 0x15a8a) #1 0x00007f3c0217b2c0 pthread_cond_wait (libpthread.so.0 + 0xf2c0) #2 0x00007f3bfbc960db util_queue_thread_func (swrast_dri.so + 0x1b80db) #3 0x00007f3bfbc95b9b impl_thrd_routine (swrast_dri.so + 0x1b7b9b) #4 0x00007f3c02175299 start_thread (libpthread.so.0 + 0x9299) #5 0x00007f3c0209d353 n/a (libc.so.6 + 0x100353)
Stack trace of thread 1044: #0 0x00007f3c02181a8a __futex_abstimed_wait_common64 (libpthread.so.0 + 0x15a8a) #1 0x00007f3c0217b2c0 pthread_cond_wait (libpthread.so.0 + 0xf2c0) #2 0x00007f3bfbc960db util_queue_thread_func (swrast_dri.so + 0x1b80db) #3 0x00007f3bfbc95b9b impl_thrd_routine (swrast_dri.so + 0x1b7b9b) #4 0x00007f3c02175299 start_thread (libpthread.so.0 + 0x9299) #5 0x00007f3c0209d353 n/a (libc.so.6 + 0x100353)
Stack trace of thread 1048: #0 0x00007f3c0209d69e n/a (libc.so.6 + 0x10069e) #1 0x00005595780f8c28 ospoll_wait (Xorg + 0x1bbc28) #2 0x00005595780f8d90 InputThreadDoWork (Xorg + 0x1bbd90) #3 0x00007f3c02175299 start_thread (libpthread.so.0 + 0x9299) #4 0x00007f3c0209d353 n/a (libc.so.6 + 0x100353)
Stack trace of thread 1041: #0 0x00007f3c02181a8a __futex_abstimed_wait_common64 (libpthread.so.0 + 0x15a8a) #1 0x00007f3c0217b2c0 pthread_cond_wait (libpthread.so.0 + 0xf2c0) #2 0x00007f3bfc293edb lp_cs_tpool_worker (swrast_dri.so + 0x7b5edb) #3 0x00007f3bfc293e5b impl_thrd_routine (swrast_dri.so + 0x7b5e5b) #4 0x00007f3c02175299 start_thread (libpthread.so.0 + 0x9299) #5 0x00007f3c0209d353 n/a (libc.so.6 + 0x100353)
Stack trace of thread 1039: #0 0x00007f3c02181a8a __futex_abstimed_wait_common64 (libpthread.so.0 + 0x15a8a) #1 0x00007f3c0217b2c0 pthread_cond_wait (libpthread.so.0 + 0xf2c0) #2 0x00007f3bfc296c43 thread_function (swrast_dri.so + 0x7b8c43) #3 0x00007f3bfc29653b impl_thrd_routine (swrast_dri.so + 0x7b853b) #4 0x00007f3c02175299 start_thread (libpthread.so.0 + 0x9299) #5 0x00007f3c0209d353 n/a (libc.so.6 + 0x100353)
Stack trace of thread 1043: #0 0x00007f3c02181a8a __futex_abstimed_wait_common64 (libpthread.so.0 + 0x15a8a) #1 0x00007f3c0217b2c0 pthread_cond_wait (libpthread.so.0 + 0xf2c0) #2 0x00007f3bfbc960db util_queue_thread_func (swrast_dri.so + 0x1b80db) #3 0x00007f3bfbc95b9b impl_thrd_routine (swrast_dri.so + 0x1b7b9b) #4 0x00007f3c02175299 start_thread (libpthread.so.0 + 0x9299) #5 0x00007f3c0209d353 n/a (libc.so.6 + 0x100353)
Stack trace of thread 1045: #0 0x00007f3c02181a8a __futex_abstimed_wait_common64 (libpthread.so.0 + 0x15a8a) #1 0x00007f3c0217b2c0 pthread_cond_wait (libpthread.so.0 + 0xf2c0) #2 0x00007f3bfbc960db util_queue_thread_func (swrast_dri.so + 0x1b80db) #3 0x00007f3bfbc95b9b impl_thrd_routine (swrast_dri.so + 0x1b7b9b) #4 0x00007f3c02175299 start_thread (libpthread.so.0 + 0x9299) #5 0x00007f3c0209d353 n/a (libc.so.6 + 0x100353)
Xorg log has this: ================== [ 25259.974] (EE) qxl(0): error doing QXL_ALLOC [ 25259.974] (EE) [ 25259.974] (EE) Backtrace: [ 25260.034] (EE) 0: /usr/libexec/Xorg (OsLookupColor+0x139) [0x555f449f7cd9] [ 25260.100] (EE) 1: /lib64/libpthread.so.0 (funlockfile+0x60) [0x7eff83c1ea20] [ 25260.137] (EE) unw_get_proc_name failed: no unwind info found [-10] [ 25260.137] (EE) 2: /usr/lib64/xorg/modules/drivers/qxl_drv.so (?+0x0) [0x7eff831b5a35] [ 25260.137] (EE) unw_get_proc_name failed: no unwind info found [-10] [ 25260.138] (EE) 3: /usr/lib64/xorg/modules/drivers/qxl_drv.so (?+0x0) [0x7eff831b5e66] [ 25260.139] (EE) unw_get_proc_name failed: no unwind info found [-10] [ 25260.139] (EE) 4: /usr/lib64/xorg/modules/drivers/qxl_drv.so (?+0x0) [0x7eff831c2350] [ 25260.140] (EE) 5: /usr/libexec/Xorg (miCopyRegion+0x9b) [0x555f449d675b] [ 25260.141] (EE) 6: /usr/libexec/Xorg (miDoCopy+0x43c) [0x555f449d935c] [ 25260.141] (EE) unw_get_proc_name failed: no unwind info found [-10] [ 25260.142] (EE) 7: /usr/lib64/xorg/modules/drivers/qxl_drv.so (?+0x0) [0x7eff831c2552] [ 25260.142] (EE) 8: /usr/libexec/Xorg (DamageDamageRegion+0x1a39) [0x555f449851e9] [ 25260.143] (EE) 9: /usr/libexec/Xorg (SendGraphicsExpose+0x2bf) [0x555f448984af] [ 25260.143] (EE) 10: /usr/libexec/Xorg (miPutImage+0x1591) [0x555f448882d7] [ 25260.145] (EE) 11: /lib64/libc.so.6 (__libc_start_main+0xd5) [0x7eff83a63b75] [ 25260.145] (EE) 12: /usr/libexec/Xorg (_start+0x2e) [0x555f4488867e] [ 25260.145] (EE) [ 25260.146] (EE) Segmentation fault at address 0x0
On 10/07/2021 08:44, Eyal Lebedinsky wrote:
Recently I started having Xorg crash while using firefox. This is f34 in a libvirt kvm, host (also f34) uses internal i915 video. Kernel is 5.12.14-300.fc34.x86_64 but saw this with earlier 5.12.12/13 kernels.
I've not seen any crashes on my VM. Host is F34 and multiple guests, including F34 guests.
As a test, have you tried changing your guest video from QXL to Virtio?
On 10/07/2021 10.56, Ed Greshko wrote:
On 10/07/2021 08:44, Eyal Lebedinsky wrote:
Recently I started having Xorg crash while using firefox. This is f34 in a libvirt kvm, host (also f34) uses internal i915 video. Kernel is 5.12.14-300.fc34.x86_64 but saw this with earlier 5.12.12/13 kernels.
I've not seen any crashes on my VM. Host is F34 and multiple guests, including F34 guests.
As a test, have you tried changing your guest video from QXL to Virtio?
Worth a try. I am now running with Virtio video. Audio sync is a bit out...
Interestingly: I tried to change back to QXL for comparo but LXD could not start, X repeatedly terminated with [ 43.747] resizing primary to 3840x2160 [ 43.747] primary is 0x5640e09faa30 [ 43.747] (EE) qxl(0): failed to set mode: Cannot allocate memory(EE) I will deal with this later.
On 10/07/2021 19:09, Eyal Lebedinsky wrote:
On 10/07/2021 10.56, Ed Greshko wrote:
On 10/07/2021 08:44, Eyal Lebedinsky wrote:
Recently I started having Xorg crash while using firefox. This is f34 in a libvirt kvm, host (also f34) uses internal i915 video. Kernel is 5.12.14-300.fc34.x86_64 but saw this with earlier 5.12.12/13 kernels.
I've not seen any crashes on my VM. Host is F34 and multiple guests, including F34 guests.
As a test, have you tried changing your guest video from QXL to Virtio?
Worth a try. I am now running with Virtio video. Audio sync is a bit out...
Interestingly: I tried to change back to QXL for comparo but LXD could not start, X repeatedly terminated with [ 43.747] resizing primary to 3840x2160 [ 43.747] primary is 0x5640e09faa30 [ 43.747] (EE) qxl(0): failed to set mode: Cannot allocate memory(EE) I will deal with this later.
Is your host running low on memory?
On 11/07/2021 10.22, Ed Greshko wrote:
On 10/07/2021 19:09, Eyal Lebedinsky wrote:
On 10/07/2021 10.56, Ed Greshko wrote:
On 10/07/2021 08:44, Eyal Lebedinsky wrote:
Recently I started having Xorg crash while using firefox. This is f34 in a libvirt kvm, host (also f34) uses internal i915 video. Kernel is 5.12.14-300.fc34.x86_64 but saw this with earlier 5.12.12/13 kernels.
I've not seen any crashes on my VM. Host is F34 and multiple guests, including F34 guests.
As a test, have you tried changing your guest video from QXL to Virtio?
Worth a try. I am now running with Virtio video. Audio sync is a bit out...
Interestingly: I tried to change back to QXL for comparo but LXD could not start, X repeatedly terminated with [ 43.747] resizing primary to 3840x2160 [ 43.747] primary is 0x5640e09faa30 [ 43.747] (EE) qxl(0): failed to set mode: Cannot allocate memory(EE) I will deal with this later.
Is your host running low on memory?
I do not think so. I changed back to QXL and LXDM failed in a loop, at that point I did this on the host:
$ free total used free shared buff/cache available Mem: 32734592 3232096 7343812 246400 22158684 28782264 Swap: 16777212 1064704 15712508
The guest is configured with 8GB memory.
[later] I had a very vague memory that I needed to fiddle with the domain xml file. I restored /etc/libvirt/qemu/e4.xml from backup and compared and sure it was different.
I used $ sudo virsh edit e4 and set the <video> stanza to say <model type='qxl' ram='131072' vram='131072' vgamem='32768' heads='1' primary='yes'/> where it originally said <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1' primary='yes'/> Now lxdm starts OK.
Audio sync still bad. Video barely keeps up. Probably similar to virtio mode.
I will run this way until I get an Xorg crash, then switch to virtio to see if it is better.
On 11/07/2021 16:19, Eyal Lebedinsky wrote:
On 11/07/2021 10.22, Ed Greshko wrote:
On 10/07/2021 19:09, Eyal Lebedinsky wrote:
On 10/07/2021 10.56, Ed Greshko wrote:
On 10/07/2021 08:44, Eyal Lebedinsky wrote:
Recently I started having Xorg crash while using firefox. This is f34 in a libvirt kvm, host (also f34) uses internal i915 video. Kernel is 5.12.14-300.fc34.x86_64 but saw this with earlier 5.12.12/13 kernels.
I've not seen any crashes on my VM. Host is F34 and multiple guests, including F34 guests.
As a test, have you tried changing your guest video from QXL to Virtio?
Worth a try. I am now running with Virtio video. Audio sync is a bit out...
Interestingly: I tried to change back to QXL for comparo but LXD could not start, X repeatedly terminated with [ 43.747] resizing primary to 3840x2160 [ 43.747] primary is 0x5640e09faa30 [ 43.747] (EE) qxl(0): failed to set mode: Cannot allocate memory(EE) I will deal with this later.
Is your host running low on memory?
I do not think so. I changed back to QXL and LXDM failed in a loop, at that point I did this on the host:
$ free total used free shared buff/cache available Mem: 32734592 3232096 7343812 246400 22158684 28782264 Swap: 16777212 1064704 15712508
The guest is configured with 8GB memory.
[later] I had a very vague memory that I needed to fiddle with the domain xml file. I restored /etc/libvirt/qemu/e4.xml from backup and compared and sure it was different.
I used $ sudo virsh edit e4 and set the <video> stanza to say <model type='qxl' ram='131072' vram='131072' vgamem='32768' heads='1' primary='yes'/> where it originally said <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1' primary='yes'/> Now lxdm starts OK.
Audio sync still bad. Video barely keeps up. Probably similar to virtio mode.
I will run this way until I get an Xorg crash, then switch to virtio to see if it is better.
OK.... I forgot to ask. This is F34 installed from what Live Image?
I don't use VM's with audio. I don't know if it is my slow HW or what, but I never got it to work well with pulseaudio and I've not even given pipewire a try with VM's. I had the same disappointing issues using VirtualBox as well.
On 11/07/2021 20.14, Ed Greshko wrote:
On 11/07/2021 16:19, Eyal Lebedinsky wrote:
On 11/07/2021 10.22, Ed Greshko wrote:
On 10/07/2021 19:09, Eyal Lebedinsky wrote:
On 10/07/2021 10.56, Ed Greshko wrote:
On 10/07/2021 08:44, Eyal Lebedinsky wrote:
Recently I started having Xorg crash while using firefox. This is f34 in a libvirt kvm, host (also f34) uses internal i915 video. Kernel is 5.12.14-300.fc34.x86_64 but saw this with earlier 5.12.12/13 kernels.
I've not seen any crashes on my VM. Host is F34 and multiple guests, including F34 guests.
As a test, have you tried changing your guest video from QXL to Virtio?
Worth a try. I am now running with Virtio video. Audio sync is a bit out...
Interestingly: I tried to change back to QXL for comparo but LXD could not start, X repeatedly terminated with [ 43.747] resizing primary to 3840x2160 [ 43.747] primary is 0x5640e09faa30 [ 43.747] (EE) qxl(0): failed to set mode: Cannot allocate memory(EE) I will deal with this later.
Is your host running low on memory?
I do not think so. I changed back to QXL and LXDM failed in a loop, at that point I did this on the host:
$ free total used free shared buff/cache available Mem: 32734592 3232096 7343812 246400 22158684 28782264 Swap: 16777212 1064704 15712508
The guest is configured with 8GB memory.
[later] I had a very vague memory that I needed to fiddle with the domain xml file. I restored /etc/libvirt/qemu/e4.xml from backup and compared and sure it was different.
I used $ sudo virsh edit e4 and set the <video> stanza to say <model type='qxl' ram='131072' vram='131072' vgamem='32768' heads='1' primary='yes'/> where it originally said <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1' primary='yes'/> Now lxdm starts OK.
Audio sync still bad. Video barely keeps up. Probably similar to virtio mode.
I will run this way until I get an Xorg crash, then switch to virtio to see if it is better.
OK.... I forgot to ask. This is F34 installed from what Live Image?
This system was installed too many years ago to remember and upgraded every year.
I don't use VM's with audio. I don't know if it is my slow HW or what, but I never got it to work well with pulseaudio and I've not even given pipewire a try with VM's. I had the same disappointing issues using VirtualBox as well.
On 11/07/2021 18:17, Eyal Lebedinsky wrote:
On 11/07/2021 20.14, Ed Greshko wrote:
On 11/07/2021 16:19, Eyal Lebedinsky wrote:
On 11/07/2021 10.22, Ed Greshko wrote:
On 10/07/2021 19:09, Eyal Lebedinsky wrote:
On 10/07/2021 10.56, Ed Greshko wrote:
On 10/07/2021 08:44, Eyal Lebedinsky wrote: > Recently I started having Xorg crash while using firefox. > This is f34 in a libvirt kvm, host (also f34) uses internal i915 video. > Kernel is 5.12.14-300.fc34.x86_64 but saw this with earlier 5.12.12/13 kernels.
I've not seen any crashes on my VM. Host is F34 and multiple guests, including F34 guests.
As a test, have you tried changing your guest video from QXL to Virtio?
Worth a try. I am now running with Virtio video. Audio sync is a bit out...
Interestingly: I tried to change back to QXL for comparo but LXD could not start, X repeatedly terminated with [ 43.747] resizing primary to 3840x2160 [ 43.747] primary is 0x5640e09faa30 [ 43.747] (EE) qxl(0): failed to set mode: Cannot allocate memory(EE) I will deal with this later.
Is your host running low on memory?
I do not think so. I changed back to QXL and LXDM failed in a loop, at that point I did this on the host:
$ free total used free shared buff/cache available Mem: 32734592 3232096 7343812 246400 22158684 28782264 Swap: 16777212 1064704 15712508
The guest is configured with 8GB memory.
[later] I had a very vague memory that I needed to fiddle with the domain xml file. I restored /etc/libvirt/qemu/e4.xml from backup and compared and sure it was different.
I used $ sudo virsh edit e4 and set the <video> stanza to say <model type='qxl' ram='131072' vram='131072' vgamem='32768' heads='1' primary='yes'/> where it originally said <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1' primary='yes'/> Now lxdm starts OK.
Audio sync still bad. Video barely keeps up. Probably similar to virtio mode.
I will run this way until I get an Xorg crash, then switch to virtio to see if it is better.
OK.... I forgot to ask. This is F34 installed from what Live Image?
This system was installed too many years ago to remember and upgraded every year.
I see. What desktop and display manager?
On 11/07/2021 20.18, Ed Greshko wrote:
On 11/07/2021 18:17, Eyal Lebedinsky wrote:
On 11/07/2021 20.14, Ed Greshko wrote:
On 11/07/2021 16:19, Eyal Lebedinsky wrote:
On 11/07/2021 10.22, Ed Greshko wrote:
On 10/07/2021 19:09, Eyal Lebedinsky wrote:
On 10/07/2021 10.56, Ed Greshko wrote: > On 10/07/2021 08:44, Eyal Lebedinsky wrote: >> Recently I started having Xorg crash while using firefox. >> This is f34 in a libvirt kvm, host (also f34) uses internal i915 video. >> Kernel is 5.12.14-300.fc34.x86_64 but saw this with earlier 5.12.12/13 kernels. > > I've not seen any crashes on my VM. Host is F34 and multiple guests, including F34 guests. > > As a test, have you tried changing your guest video from QXL to Virtio?
Worth a try. I am now running with Virtio video. Audio sync is a bit out...
Interestingly: I tried to change back to QXL for comparo but LXD could not start, X repeatedly terminated with [ 43.747] resizing primary to 3840x2160 [ 43.747] primary is 0x5640e09faa30 [ 43.747] (EE) qxl(0): failed to set mode: Cannot allocate memory(EE) I will deal with this later.
Is your host running low on memory?
I do not think so. I changed back to QXL and LXDM failed in a loop, at that point I did this on the host:
$ free total used free shared buff/cache available Mem: 32734592 3232096 7343812 246400 22158684 28782264 Swap: 16777212 1064704 15712508
The guest is configured with 8GB memory.
[later] I had a very vague memory that I needed to fiddle with the domain xml file. I restored /etc/libvirt/qemu/e4.xml from backup and compared and sure it was different.
I used $ sudo virsh edit e4 and set the <video> stanza to say <model type='qxl' ram='131072' vram='131072' vgamem='32768' heads='1' primary='yes'/> where it originally said <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1' primary='yes'/> Now lxdm starts OK.
Audio sync still bad. Video barely keeps up. Probably similar to virtio mode.
I will run this way until I get an Xorg crash, then switch to virtio to see if it is better.
OK.... I forgot to ask. This is F34 installed from what Live Image?
This system was installed too many years ago to remember and upgraded every year.
I see. What desktop and display manager?
xfce4 xfwm4
On 11/07/2021 18:22, Eyal Lebedinsky wrote:
On 11/07/2021 20.18, Ed Greshko wrote:
On 11/07/2021 18:17, Eyal Lebedinsky wrote:
On 11/07/2021 20.14, Ed Greshko wrote:
On 11/07/2021 16:19, Eyal Lebedinsky wrote:
On 11/07/2021 10.22, Ed Greshko wrote:
On 10/07/2021 19:09, Eyal Lebedinsky wrote: > > On 10/07/2021 10.56, Ed Greshko wrote: >> On 10/07/2021 08:44, Eyal Lebedinsky wrote: >>> Recently I started having Xorg crash while using firefox. >>> This is f34 in a libvirt kvm, host (also f34) uses internal i915 video. >>> Kernel is 5.12.14-300.fc34.x86_64 but saw this with earlier 5.12.12/13 kernels. >> >> I've not seen any crashes on my VM. Host is F34 and multiple guests, including F34 guests. >> >> As a test, have you tried changing your guest video from QXL to Virtio? > > Worth a try. I am now running with Virtio video. Audio sync is a bit out... > > Interestingly: I tried to change back to QXL for comparo but LXD could not start, > X repeatedly terminated with > [ 43.747] resizing primary to 3840x2160 > [ 43.747] primary is 0x5640e09faa30 > [ 43.747] (EE) qxl(0): failed to set mode: Cannot allocate memory(EE) > I will deal with this later. >
Is your host running low on memory?
I do not think so. I changed back to QXL and LXDM failed in a loop, at that point I did this on the host:
$ free total used free shared buff/cache available Mem: 32734592 3232096 7343812 246400 22158684 28782264 Swap: 16777212 1064704 15712508
The guest is configured with 8GB memory.
[later] I had a very vague memory that I needed to fiddle with the domain xml file. I restored /etc/libvirt/qemu/e4.xml from backup and compared and sure it was different.
I used $ sudo virsh edit e4 and set the <video> stanza to say <model type='qxl' ram='131072' vram='131072' vgamem='32768' heads='1' primary='yes'/> where it originally said <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1' primary='yes'/> Now lxdm starts OK.
Audio sync still bad. Video barely keeps up. Probably similar to virtio mode.
I will run this way until I get an Xorg crash, then switch to virtio to see if it is better.
OK.... I forgot to ask. This is F34 installed from what Live Image?
This system was installed too many years ago to remember and upgraded every year.
I see. What desktop and display manager?
xfce4 xfwm4
Oh, I can't seem to find xfwm4 display manager available for F34.
What is the outupt of
systemctl status display-manager
On 11/07/2021 18:51, Ed Greshko wrote:
Oh, I can't seem to find xfwm4 display manager available for F34.
What is the outupt of
systemctl status display-manager
Never mind....
If one logs in from multi-user mode and does startxfce you get that window manager.
On 11/07/2021 18:14, Ed Greshko wrote:
I don't use VM's with audio. I don't know if it is my slow HW or what, but I never got it to work well with pulseaudio and I've not even given pipewire a try with VM's. I had the same disappointing issues using VirtualBox as well.
FWIW, I just started Xfce with xfwm4 and using firefox played a live-stream of Taiwan News on YouTube and the audio/video sync was good fine. I also stream a John Oliver Last Week Tonight segment and it was also good. The video was 16 minutes long and lips/audio were 99% fine. A little blip here and there but is recovered. Surprised the heck out of me. :-)
-
Ed Greshko -
Eyal Lebedinsky