You are not logged in.

#1 2022-08-26 16:15:39

MarcoIs
Member
Registered: 2021-10-21
Posts: 6

qemu nvida 390xx OpenGL XOrg X-Server docker

Hello,

I try to start a machine via qemu inside a ubuntu-docker container as follows

/usr/bin/qemu-system-arm  -drive id=disk1,file=/mnt/qemu_images/qemu-vguser-id.img,if=none,format=raw -device virtio-blk-device,drive=disk1 -drive id=disk0,file=/mnt/qemu_images/rootfs.ext4,if=none,format=raw -device virtio-blk-device,drive=disk0 -device virtio-gpu-gl-pci,edid=on,xres=1024,yres=600 -display gtk,gl=on -cpu cortex-a7 -smp cpus=4 -m 2048  -machine virt,highmem=off  -kernel /mnt/qemu_images/zImage-4.9.88-initrd 

this works fine in the past. I received  the gui via xorg-X-Server DISPLAY.
After a system update I get now the following error:

runqemu - ERROR - Failed to run qemu: libEGL warning: DRI2: failed to authenticate

(qemu-system-arm:69): Gdk-ERROR **: 17:25:23.201: The program 'qemu-system-arm' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadRequest (invalid request code or no such operation)'.
  (Details: serial 147 error_code 1 request_code 153 (unknown) minor_code 1)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

Without OpenGl Support, the machine is booting in the docker-container. Trying the command above with gl=on native on archLinux will open a gui with e.g. the brower content 0.o. With gl=off (OpenGL = off) the machine also starts on archlinux native.

Im currently running on 5.18.16-arch1-1 with nvida-390-xxx / nvida-390-xxx-utils legacy driver and an xorg-xserver+dwm display manager.

When I try to launch a openGL test application like glxgears this works fine.


The /var/log/Xorg.0.log does not have any errors.
journalctl collects a coredump only when starting from inside the docker container

systemd-coredump[..]: [...] Process 4711 (qemu-system-arm) of user 0 dumped core.
  Module /usr/bin/qemu-system-arm with build-id e278ca886198074cb867d9d5d158a6f603e942a6
....
....
....
Stack trace of thread 82:
#0  0x0000d494979cc295 n/a (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6 + 0x58223)
#1  0x0000a59497a1e654 n/a (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6400.6 + 0xaa673)
ELF object binary architecture: AMD x86-64

Im not shure if the error above comes from the xserver or from shared libraries (or both)


glxinfo from inside the container

root@docker # glxinfo | grep -i opengl
OpenGL vendor string: Mesa/X.org
OpenGL renderer string: llvmpipe (LLVM 12.0.0, 128 bits)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 21.2.6
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.1 Mesa 21.2.6
OpenGL shading language version string: 1.40
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 21.2.6
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
OpenGL ES profile extensions:

glxinfo from archlinux

user@archlinux # glxinfo | grep -i opengl
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: Quadro 4000/PCIe/SSE2
OpenGL core profile version string: 4.6.0 NVIDIA 390.154
OpenGL core profile shading language version string: 4.60 NVIDIA
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 4.6.0 NVIDIA 390.154
OpenGL shading language version string: 4.60 NVIDIA
OpenGL context flags: (none)
OpenGL profile mask: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.2 NVIDIA 390.154
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
OpenGL ES profile extensions:

Is there someone who can support me?

Offline

#2 2022-08-27 11:30:50

Lone_Wolf
Administrator
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 15,276

Re: qemu nvida 390xx OpenGL XOrg X-Server docker

This sounds .. confusing .

I have the impression your setup is like this :
host - something else (docker?) - guest qemu VM

What OS is used on the host ?
Is the host bare metal or not ?
Why is there something between host and guest ?


Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.

clean chroot building not flexible enough ?
Try clean chroot manager by graysky

Offline

#3 2022-08-29 07:45:31

MarcoIs
Member
Registered: 2021-10-21
Posts: 6

Re: qemu nvida 390xx OpenGL XOrg X-Server docker

Hello Leon,

yes the setup is

archlinux --> docker-ubuntu -->  qemu.

but also archlinux --> qemu  doeas not work.

In short: Do you know how I can solve the error below? In my impression the problem its somewhere between Archlinux  5.18.16-arch1-1 with nvida-390-xxx and X-Server.


runqemu - ERROR - Failed to run qemu: libEGL warning: DRI2: failed to authenticate

(qemu-system-arm:69): Gdk-ERROR **: 17:25:23.201: The program 'qemu-system-arm' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadRequest (invalid request code or no such operation)'.
  (Details: serial 147 error_code 1 request_code 153 (unknown) minor_code 1)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

Offline

#4 2022-08-29 09:35:31

Lone_Wolf
Administrator
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 15,276

Re: qemu nvida 390xx OpenGL XOrg X-Server docker

Here's the command starting the VM broken down for readability :

/usr/bin/qemu-system-arm  \
    -drive id=disk1,file=/mnt/qemu_images/qemu-vguser-id.img,if=none,format=raw \
    -device virtio-blk-device,drive=disk1 -drive id=disk0,file=/mnt/qemu_images/rootfs.ext4,if=none,format=raw \
    -device virtio-blk-device,drive=disk0 \
    -device virtio-gpu-gl-pci,edid=on,xres=1024,yres=600 \
    -display gtk,gl=on \
    -cpu cortex-a7 \
    -smp cpus=4 -m 2048  \
    -machine virt,highmem=off  \
    -kernel /mnt/qemu_images/zImage-4.9.88-initrd

You're using virtio-gpu-gl graphics . That does support 2 modes with OpenGL support : gtk & sdl
Does it help if you use -display sdl,gl=on ?
If not, the issue is likely in the guest OS.

I know little about archlinux-arm and this forum is for archlinux x86_64 only.

Are you also running an archlinux x86_64 guest and does it have the same issue ?


Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.

clean chroot building not flexible enough ?
Try clean chroot manager by graysky

Offline

#5 2022-08-30 09:35:27

MarcoIs
Member
Registered: 2021-10-21
Posts: 6

Re: qemu nvida 390xx OpenGL XOrg X-Server docker

Hello Wolf.

It is a host related problem of my x86_64 archlinux system. There is no  archlinux-arm  in the game.  Inside docker is running an ubuntu system and the qemu is starting a yocto-poky linux on an  archarm64 cpu.  The setup was running in the past. The Error above pops up since a system+kernal update of my  x86_64 archlinux host system.

Sorry I skipped the information about sdl mode: The sdl+gl=on mode was and is still working. The problem relates only to gtk+gl=on. I'm not shure but It could be a broken shared library. I get no error log in the xorg.log. But the systemd-coredump in the journalctl point to libglib (wich results in gtk)(see above). libglib is up-to-date and I have no idea how to debug it further.

Offline

#6 2022-08-30 10:18:37

Lone_Wolf
Administrator
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 15,276

Re: qemu nvida 390xx OpenGL XOrg X-Server docker

The error message is of a type that often occurs when there's something wrong with the videodriver .

Are you using the dkms variant of the nvidia-390xx packages ?
Do you have the 32-bit versions installed ?

Is the host running X when the VM is started ?

Please post the output of

$ lspci -k
$ pacman -Qs nvidia

Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.

clean chroot building not flexible enough ?
Try clean chroot manager by graysky

Offline

#7 2022-09-02 07:25:30

MarcoIs
Member
Registered: 2021-10-21
Posts: 6

Re: qemu nvida 390xx OpenGL XOrg X-Server docker

Hello Wolf. Sorry for the late response

VGA compatible controller: NVIDIA Corporation GF100GL [Quadro 4000] (rev a3)
and 
vidia-390xx-dkms 390.154-1

Yes X server is running. Im using an DWM window-manager with an Xorg - X-Server.

 xhost + 

is allowing access. My /etc/X11/xorg.conf is empty.

 lspci
00:00.0 Host bridge: Intel Corporation 5400 Chipset Memory Controller Hub (rev 20)
00:01.0 PCI bridge: Intel Corporation 5400 Chipset PCI Express Port 1 (rev 20)
00:05.0 PCI bridge: Intel Corporation 5400 Chipset PCI Express Port 5 (rev 20)
00:09.0 PCI bridge: Intel Corporation 5400 Chipset PCI Express Port 9 (rev 20)
00:10.0 Host bridge: Intel Corporation 5400 Chipset FSB Registers (rev 20)
00:10.1 Host bridge: Intel Corporation 5400 Chipset FSB Registers (rev 20)
00:10.2 Host bridge: Intel Corporation 5400 Chipset FSB Registers (rev 20)
00:10.3 Host bridge: Intel Corporation 5400 Chipset FSB Registers (rev 20)
00:10.4 Host bridge: Intel Corporation 5400 Chipset FSB Registers (rev 20)
00:11.0 Host bridge: Intel Corporation 5400 Chipset CE/SF Registers (rev 20)
00:15.0 Host bridge: Intel Corporation 5400 Chipset FBD Registers (rev 20)
00:15.1 Host bridge: Intel Corporation 5400 Chipset FBD Registers (rev 20)
00:16.0 Host bridge: Intel Corporation 5400 Chipset FBD Registers (rev 20)
00:16.1 Host bridge: Intel Corporation 5400 Chipset FBD Registers (rev 20)
00:1c.0 PCI bridge: Intel Corporation 631xESB/632xESB/3100 Chipset PCI Express Root Port 1 (rev 09)
00:1d.0 USB controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #1 (rev 09)
00:1d.1 USB controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #2 (rev 09)
00:1d.2 USB controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #3 (rev 09)
00:1d.3 USB controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #4 (rev 09)
00:1d.7 USB controller: Intel Corporation 631xESB/632xESB/3100 Chipset EHCI USB2 Controller (rev 09)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d9)
00:1f.0 ISA bridge: Intel Corporation 631xESB/632xESB/3100 Chipset LPC Interface Controller (rev 09)
00:1f.1 IDE interface: Intel Corporation 631xESB/632xESB IDE Controller (rev 09)
00:1f.2 SATA controller: Intel Corporation 631xESB/632xESB SATA AHCI Controller (rev 09)
00:1f.3 SMBus: Intel Corporation 631xESB/632xESB/3100 Chipset SMBus Controller (rev 09)
01:00.0 VGA compatible controller: NVIDIA Corporation GF100GL [Quadro 4000] (rev a3)
01:00.1 Audio device: NVIDIA Corporation GF100 High Definition Audio Controller (rev a1)
02:00.0 Multimedia video controller: Conexant Systems, Inc. CX23885 PCI Video and Audio Decoder (rev 04)
03:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Upstream Port (rev 01)
03:00.3 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express to PCI-X Bridge (rev 01)
04:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Downstream Port E1 (rev 01)
04:01.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Downstream Port E2 (rev 01)
05:00.0 SCSI storage controller: Broadcom / LSI SAS1068E PCI-Express Fusion-MPT SAS (rev 08)
07:06.0 Multimedia audio controller: Creative Labs EMU10k2/CA0100/CA0102/CA10200 [Sound Blaster Audigy Series] (rev 04)
07:06.1 Input device controller: Creative Labs SB Audigy Game Port (rev 04)
07:06.2 FireWire (IEEE 1394): Creative Labs SB Audigy FireWire Port (rev 04)
08:00.0 Ethernet controller: Broadcom Inc. and subsidiaries NetXtreme BCM5754 Gigabit Ethernet PCI Express (rev 02)
09:0a.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22A IEEE-1394a-2000 Controller (PHY/Link) [iOHCI-Lynx]
pacman -Qs nvidia
local/egl-wayland 2:1.1.10-1
    EGLStream-based Wayland external platform
local/libnvidia-container 1.4.0-1
    NVIDIA container runtime library
local/libnvidia-container-tools 1.4.0-1
    NVIDIA container runtime library
local/libvdpau 1.5-1
    Nvidia VDPAU library
local/nvidia-390xx-dkms 390.154-1
    NVIDIA drivers - module sources
local/nvidia-390xx-utils 390.154-1
    NVIDIA drivers utilities
local/nvidia-container-runtime 3.5.0-2
    NVIDIA opencontainer runtime fork to expose GPU devices to containers.
local/nvidia-container-toolkit 1.5.0-2
    NVIDIA container runtime toolkit
local/nvidia-docker 2.6.0-1
    Build and run Docker containers leveraging NVIDIA GPUs
local/nvtop 2.0.2-1
    An htop like monitoring tool for AMD and NVIDIA GPUs
local/opencl-nvidia-390xx 390.154-1
    OpenCL implemention for NVIDIA
local/xf86-video-nouveau 1.0.17-2 (xorg-drivers)
    Open Source 3D acceleration driver for nVidia cards

Last edited by MarcoIs (2022-09-02 08:29:25)

Offline

#8 2022-09-02 09:23:56

Lone_Wolf
Administrator
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 15,276

Re: qemu nvida 390xx OpenGL XOrg X-Server docker

02:00.0 Multimedia video controller: Conexant Systems, Inc. CX23885 PCI Video and Audio Decoder (rev 04)

Looks like some type of capture card.
Does it have video/audio outputs or only inputs ?

remove xf86-video-nouveau (atleast for now).
install lib32-nvidia-390xx-utils and lib32-opencl-nvidia-390xx

You do have gtk3 installed, right ?


Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.

clean chroot building not flexible enough ?
Try clean chroot manager by graysky

Offline

#9 2022-09-02 21:40:27

MarcoIs
Member
Registered: 2021-10-21
Posts: 6

Re: qemu nvida 390xx OpenGL XOrg X-Server docker

Conexant CX23885 is a DVBT TV recording card. I had never used it on linux. It is not doing video output.

I removed the legacy nouveau package and I installed lib32-nvidia-390xx-utils. lib32-opencl-nvidia-390xx points to be the same repo. So I skiped last one.

gtk3 is installed and up to date. Without opengl=on  (so gl=off) the system is booting. So the problem relates to gtk+opengl only.

The error still pops up and still no GUI window when starting qemu with gtk+opengl...

Does someone has more ideas?

Last edited by MarcoIs (2022-09-11 09:41:18)

Offline

Board footer

Powered by FluxBB