| Bug ID | 104291 |
|---|---|
| Summary | Virgl broken on current mesa (17.4+), with nouveau/nv50 as ho= st |
| Product | Mesa |
| Version | git |
| Hardware | x86-64 (AMD64) |
| OS | Linux (All) |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | Drivers/DRI/nouveau |
| Assignee | nouveau@lists.freedesktop.org |
| Reporter | randrik@mail.ru |
| QA Contact | nouveau@lists.freedesktop.org |
Hello. Sorry for possibly irrelevant bug report, but I just tested virgl and found= it broken - glxinfo works, but glxgears or any gl program segfaults. On both host and guest (self-assembled live DVD) I have mesa Mesa 17.4.0-de= vel (git-96fc5fbf23), X server 1.19.5. Host kernel - Linux slax 4.14.3-x64 #18 = SMP Sun Dec 3 09:13:07 MSK 2017 x86_64 AMD FX(tm)-4300 Quad-Core Processor AuthenticAMD GNU/Linux, guest kernel - 4.12.0-x64. Qemu - 2.11. Launch command and output: qemu-system-x86_64 -M q35 -enable-kvm -cdrom /dev/shm/slax_16_12_2017_test.= iso -m 512 -display sdl,gl=3Don -soundhw es1370 -smp 4 -vga virtio -usbdevice m= ouse qemu-system-x86_64: -usbdevice mouse: '-usbdevice' is deprecated, please use '-device usb-...' instead gl_version 33 - core profile enabled startx inside guest works, glxinfo shows virgl as renderer, but glxgears or= any gl program (chromium BSU [old arcade game], glblur from xscreensavers) segfaults. At some point it was working better, but it was long ago .... (16.02.2016, = to be prescie). I also run into assertion on qemu side, described here:=20 https://lists.gnu.org/archive/html/qemu-devel/2017-04/msg05461.html Because I had only dvd image connected as dvd rom - nothing bad happened, b= ut be aware about this abort if you connect real hard disk ....
One more comment - while both kernels are 64-bit - whole users= pace for guest and host are just 32-bit binaries. It may play some role.
If you can capture an apitrace of qemu that replays incorrectl= y on nouveau but correctly on other hardware, then this is a nouveau bug. If virgl / virglrenderer code crashes (or generates an incorrect GL operati= on sequence), then it's a virgl bug.
Created attachment =
136219 [details]
glxinfo -l from inside guest
Created attachment 136220 [details]<=
/a>
gdb log
Unfortunately, I stripped debug symbols for smaller file sizes. I can recom=
pile
mesa with debug symbols, but it will take some time.
If it crashes inside the guest, then it's nothing to do with n= ouveau. Most likely.
(In reply to Ilia Mirkin from comment #5) > If it crashes inside the guest, then it's nothin= g to do with nouveau. Most > likely. ya, but I was unable to find virgl as specific component in bugzilla, so I just added bug to nouveau. Don't feel blamed. (and after swithcing virtual desktops whole image inside qemu just become real black ..I killed this VM)=
It also doesn't work with LIBGL_ALWAYS_SOFTWARE=3D1 (llvmpipe= ). So, yes, not nouveau bug....
| What | Removed | Added |
|---|---|---|
| Attachment #136220 is obsolete | 1 |
Created attachment 13622=
1 [details]
slightly better gdb log
Created attachment=
136222 [details]
X log (from guest, of course)
Created attachment 136223 [detai=
ls]
apitrace
I tried few older mesa releases (17.1.10 - without llvm, 17.2.= 7 and 17.3.0 - with llvm 5.0.0), and they all segfaults :/ This is kinda strange, because according to this bugreport it was working in 17.1-dev era: https://b= ugzilla.redhat.com/show_bug.cgi?id=3D1426549 I tried disabling PageFlipping (not sure if it makes any sense for VM), and switching dri mode to dri3. Nothing helped :/
| What | Removed | Added |
|---|---|---|
| Resolution | --- | FIXED |
| Status | NEW | RESOLVED |
Sorry, it works now (Mesa 18.2.0-devel (git-96ed3714fc) for bo= th guest and host). Apparently, I just forgot to mount /dev/shm in initscripts in guest,= and dri3 failed.