| Bug ID | 94727 |
|---|---|
| Summary | nouveau/pushbuf.c:238: pushbuf_krel: Assertion `bkref` failed. |
| Product | Mesa |
| Version | unspecified |
| Hardware | x86-64 (AMD64) |
| OS | Linux (All) |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | Drivers/DRI/nouveau |
| Assignee | nouveau@lists.freedesktop.org |
| Reporter | pappadeux@gmail.com |
| QA Contact | nouveau@lists.freedesktop.org |
Linux, Lubuntu 16.04 beta2, x64 on Intel CPU, NVIDIA Quadro 1500M Multithreaded OpenGL application (C++, Geant4 toolkit, 3D visualisation) Failed to start with the message in Subj. Application is working in VMware, same Linux version, on top of Windows 10
nouveau doesn't handle multithreaded GL usage (even if it's done by having separate contexts per thread). If the application has a mode which adds an interlock to GL calls, please try enabling it. (The issue isn't with multiple contexts, but with concurrent use of multiple contexts.)
Apparently it also affects some KDE applications: https://bugs.debian.org/82222= 0#55
This makes any qt app using qtwebengine which "integrates= chromium's fast moving web capabilities into Qt." crash. Affecting me by making kmail unusable.
I was also able to reproduce this issue on my PowerMac G5 with= GeForce 6600LE, but the crash was pretty random, in most of the cases this crash happened w= hile I was using Linthesia.
This is affecting Xwayland as well, as reported downstream in =
Fedora 25:
https=
://bugzilla.redhat.com/show_bug.cgi?id=3D1372878
wrt comment 1, Xwayland is not u=
sing multithreaded GL, even through glamor, is
it?
A full backtrace of Xwayland that led to this abort() is found= in the downstream bug here: http= s://bugzilla.redhat.com/attachment.cgi?id=3D1197379
(In reply to Olivier Fourdan from comment #5) > This is affecting Xwayland as well, as reported = downstream in Fedora 25: >=20 > = https://bugzilla.redhat.com/show_bug.cgi?id=3D1372878 >=20 > wrt comment 1, Xwayland is = not using multithreaded GL, even through glamor, > is it? Oh dear. That's using glamor on a nv30 (or nv40) board. The nv30 driver is = ... erm ... imperfect. And looking back at the first comments, the Quadro 1500M appears to be a G7= 1, and the 6600LE is obviously some nv4x as well. In which case these issues are just as likely to not be caused by the multithreading stuff at all. But you're in (limited) luck - I have a NV34 plugged in. If you can send me= an apitrace I can replay to cause this to happen, I can investigate [and the N= V34 doesn't support as much stuff as a NV4x, but I can fake it]. I'll also star= e at the nv30_resource_copy_region code to see what it's missing.
| What | Removed | Added |
|---|---|---|
| Summary | nouveau/pushbuf.c:238: pushbuf_krel: Assertion `bkref` faile= d. | [NV30/NV40] nouveau/pushbuf.c:238: pushbuf_krel: Assertion `= bkref` failed. |
OK, well staring at the code didn't do me much good. bkref =3D=3D NULL means that the pushbuf thing doesn't know about the bo we= 're trying to reloc. However just a few lines above in nv30_transfer_rect_m2mf = we do nouveau_pushbuf_refn (push, refs, 2) which should tell it about the src/dst bo's. So either there's concurrency going on, or something's not working as advertised. In the no-concurrency c= ase, I'd need repro steps (that can't start with "install tons of software&= quot;).
Created attachmen=
t 128368 [details]
Backtrace of Xwayland on a G71
Thanks for pointing out that it was on a G71, I have been able to reproduce
using my own old G71 (Dell m1710) with Fedora 25!
Didn't have much luck trying to run Xwayland through apitrace, but I have a
corefile of Xwayland, backtrace attached, if that's of any help...
(In reply to Ilia Mirkin from comment #7) > [...] If you can send me an apitrace I can repla= y to cause this to happen, > I can investigate [and the NV34 doesn't support as much stuff as a NV4= x, > but I can fake it]. [...] Ah! I managed to reproduce with apitrace \o/ Xwayland: pushbuf.c:238: pushbuf_krel: Assertion `bkref' failed. apitrace: warning: caught signal 6 apitrace: flushing trace due to an exception /usr/bin/../lib64/apitrace/wrappers/glxtrace.so+0x224c8c [...] apitrace: info: taking default action for signal 6 The capture is there: = https://people.freedesktop.org/~ofourdan/xwayland-apitrace.bz2 Please let me know if that helps!
| What | Removed | Added |
|---|---|---|
| Depends on | 98039 |
Looks like this is very similiar to #98039
| What | Removed | Added |
|---|---|---|
| Depends on | 98039 |
(In reply to Tomasz Pawe=C5=82 Gajc from comment #11) > Looks like this is very similiar to #98039 Eventually, the assertion hit is the same, but it doesn't mean it's the same problem/root cause.
Olivier, can you see if this patch with mesa helps? https://patchwo= rk.freedesktop.org/patch/132414/ It helped in the repro of bug #99354.
(In reply to Ilia Mirkin from comment #13) > Olivier, can you see if this patch with mesa hel= ps? >=20 > https://pa= tchwork.freedesktop.org/patch/132414/ >=20 > It helped in the repro of bug #99354. Sure! Thanks IIlia! The patch did not apply cleanly on top of 13.0.3 nor master though (in src/gallium/drivers/nouveau/nvc0/nvc0_query_hw.c line 406 [1]) so I changed "nouveau_pushbuf_space(push, 16, 2, 0);" to "nouveau_pushbuf= _space(push, 32, 3, 0);" to match the content of your patch, I hope this is right (sorry, = I'm not familiar with this code). But the issue is quite random and rather hard to reproduce at will, so I'll= run with this for some time see if the issue reoccurs. I shall also prepare a test package for Fedora downstream with the (modifie= d) patch included so that the original reporter can give it a try as well. [1] https://cgit.freedesktop.org/mesa/mesa/t= ree/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw.c#n406 [2] https= ://bugzilla.redhat.com/show_bug.cgi?id=3D1372878
(In reply to Olivier Fourdan from comment #14) > The patch did not apply cleanly on top of 13.0.3= nor master though (in > src/gallium/drivers/nouveau/nvc0/nvc0_query_hw.c line 406 [1]) so I ch= anged > "nouveau_pushbuf_space(push, 16, 2, 0);" to "nouveau_pu= shbuf_space(push, 32, > 3, 0);" to match the content of your patch, I hope this is right = (sorry, I'm > not familiar with this code). Ah yeah, that sounds right. I have some local changes trying to fix that co= de (unsuccessfully). But that in no way affects your situation - the issue the= re is a functional one, not a crashing one.
Haven't heard back from the original reporter downstream, but = FAF (Fedora Analysis Framework) reports thousands (literally) of similar bugs: https:/= /retrace.fedoraproject.org/faf/problems/2833836/ I see the patch in comment 13 h= as landed and is included in mesa-13.0.4, and Fedora has an updated mesa package for 13.0.4 and, interestingly, I don't s= ee any mention of 13.0.4 in the FAF report, so it could be that this patch ind= eed fixes the issue with glamor/Xwayland on nv30. Thanks again for your help, Ilia!
| What | Removed | Added |
|---|---|---|
| Status | NEW | RESOLVED |
| Resolution | --- | MOVED |
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this = link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/1099.