Segmentation fault in brw_meta_fast_clear
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| | Mesa |
Confirmed
|
Critical
|
||
| | mesa (Debian) |
Fix Released
|
Unknown
|
||
| | mesa (Ubuntu) |
Critical
|
Unassigned | ||
Bug Description
I have an nvidia optimus notebook, and since yesterdays updates X crashes on the nvidia driver, so I switched to intel. But now, every couple minutes plasmashell crashes with
Thread 1 (Thread 0x7f7b245c6800 (LWP 5307)):
[KCrash Handler]
#6 brw_meta_fast_clear (brw=brw@
#7 0x00007f7b06b3506c in brw_clear (ctx=0x1abcf08, mask=34) at ../../.
#8 0x00007f7b2264737a in QSGBatchRendere
#9 0x00007f7b2264bb3a in QSGBatchRendere
#10 0x00007f7b22656a1c in QSGRenderer:
#11 0x00007f7b22656e9b in QSGRenderer:
#12 0x00007f7b226655be in QSGRenderContex
#13 0x00007f7b226af20c in QQuickWindowPri
#14 0x00007f7b2267fbac in ?? () from /usr/lib/
#15 0x00007f7b226806d1 in ?? () from /usr/lib/
#16 0x00007f7b2015eb8c in QApplicationPri
#17 0x00007f7b20164230 in QApplication:
#18 0x00007f7b1f680a9b in QCoreApplicatio
#19 0x00007f7b1f6d6c1d in QTimerInfoList:
#20 0x00007f7b1f6d7121 in ?? () from /usr/lib/
#21 0x00007f7b1bb59f87 in g_main_
#22 0x00007f7b1bb5a1e0 in ?? () from /lib/x86_
#23 0x00007f7b1bb5a28c in g_main_
#24 0x00007f7b1f6d7e1b in QEventDispatche
#25 0x00007f7b1f67e2da in QEventLoop:
#26 0x00007f7b1f685e4c in QCoreApplicatio
#27 0x00000000004322c3 in main ()
ProblemType: Bug
DistroRelease: Ubuntu 15.10
Package: libgl1-mesa-dri 10.6.3-1ubuntu1
ProcVersionSign
Uname: Linux 4.1.0-3-generic x86_64
ApportVersion: 2.18-0ubuntu9
Architecture: amd64
CompizPlugins: No value set for `/apps/
CompositorRunning: None
Date: Thu Sep 3 23:10:45 2015
DistUpgraded: Fresh install
DistroCodename: wily
DistroVariant: ubuntu
EcryptfsInUse: Yes
ExtraDebuggingI
GraphicsCard:
Intel Corporation Broadwell-U Integrated Graphics [8086:1616] (rev 09) (prog-if 00 [VGA controller])
Subsystem: Lenovo Device [17aa:2225]
Subsystem: Lenovo Device [17aa:2225]
InstallationDate: Installed on 2015-07-20 (45 days ago)
InstallationMedia: Kubuntu 15.04 "Vivid Vervet" - Release amd64 (20150422)
MachineType: LENOVO 20CKCTO1WW
ProcKernelCmdLine: BOOT_IMAGE=
SourcePackage: mesa
UdevLog: Error: [Errno 2] No such file or directory: '/var/log/udev'
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 03/19/2015
dmi.bios.vendor: LENOVO
dmi.bios.version: N11ET31W (1.07 )
dmi.board.
dmi.board.name: 20CKCTO1WW
dmi.board.vendor: LENOVO
dmi.board.version: SDK0E50512 STD
dmi.chassis.
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.
dmi.modalias: dmi:bvnLENOVO:
dmi.product.name: 20CKCTO1WW
dmi.product.
dmi.sys.vendor: LENOVO
version.compiz: compiz N/A
version.ia32-libs: ia32-libs N/A
version.libdrm2: libdrm2 2.4.64-1
version.
version.
version.
version.
version.
version.
version.
version.
xserver.bootTime: Thu Sep 3 22:20:47 2015
xserver.configfile: default
xserver.errors:
xserver.logfile: /var/log/Xorg.0.log
xserver.outputs:
product id 5571
vendor CMN
xserver.version: 2:1.17.2-1ubuntu5
|
|
#8 |
A bunch of fixes have been committed to the fast clear code. Please test a new version of Mesa.
Just recompiled 10.4.6 on my Debian system and can't reproduce the crash anymore. Thanks!
Here is the new backtrace using 10.5.5-1:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffdbfff700 (LWP 15019)]
brw_meta_fast_clear (brw=brw@
fb=fb@entry=
partial_
at ../../.
446 if (irb->mt-
(gdb) bt
#0 brw_meta_fast_clear (brw=brw@
fb=fb@entry=
partial_
at ../../.
#1 0x00007fffdb36bbb8 in brw_clear (ctx=0x7fffd40b
../../.
#2 0x0000555555637269 in gl_video_
../video/
#3 0x000055555563c354 in draw_image (vo=<optimized out>,
mpi=0x5555562c1700) at ../video/
#4 0x0000555555639fa3 in render_frame (vo=0x5555560c00e0) at
../video/
#5 vo_thread (ptr=0x5555560c
#6 0x00007ffff6ac20a4 in start_thread (arg=0x7fffdbff
pthread_
#7 0x00007ffff00b004d in clone () at
../sysdeps/
See the `bt full` here:
https:/
|
|
#11 |
(In reply to mathieu.malaterre from comment #3)
> Here is the new backtrace using 10.5.5-1:
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7fffdbfff700 (LWP 15019)]
> brw_meta_fast_clear (brw=brw@
> fb=fb@entry=
> partial_
> at
> ../../.
> 446 if (irb->mt-
> (gdb) bt
> #0 brw_meta_fast_clear (brw=brw@
> fb=fb@entry=
> partial_
> at
> ../../.
> #1 0x00007fffdb36bbb8 in brw_clear (ctx=0x7fffd40b
> ../../.
> #2 0x0000555555637269 in gl_video_
> ../video/
> #3 0x000055555563c354 in draw_image (vo=<optimized out>,
> mpi=0x5555562c1700) at ../video/
> #4 0x0000555555639fa3 in render_frame (vo=0x5555560c00e0) at
> ../video/
> #5 vo_thread (ptr=0x5555560c
> #6 0x00007ffff6ac20a4 in start_thread (arg=0x7fffdbff
> pthread_
> #7 0x00007ffff00b004d in clone () at
> ../sysdeps/
>
> See the `bt full` here:
> https:/
Is this still on Sandybridge (like the debian bug report)?
No, it's my laptop. If I use the default debian package on it I could reproduce *exactly* the same original segfault, so I assumed I could report it here also.
References:
$ lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)
01:00.0 VGA compatible controller: NVIDIA Corporation GF108M [GeForce GT 525M] (rev a1)
$ lspci -vv -s 00:02.0
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller])
Subsystem: Dell Device 04c6
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 54
Region 0: Memory at f1400000 (64-bit, non-prefetchable) [size=4M]
Region 2: Memory at e0000000 (64-bit, prefetchable) [size=256M]
Region 4: I/O ports at 5000 [size=64]
Expansion ROM at <unassigned> [disabled]
Capabilities: <access denied>
Kernel driver in use: i915
Please note, that I cannot reproduce this issue when using the NVidia card (need to prefix `mpv` with `optirun`).
If that matters, it's a DELL Vostro 3750 with:
$ glxinfo | grep renderer
OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Mobile
|
|
#14 |
(In reply to mathieu.malaterre from comment #6)
> If that matters, it's a DELL Vostro 3750 with:
>
> $ glxinfo | grep renderer
> OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Mobile
OK, thanks. Why I asked is that fast clears are not supported on Sandybridge and the backtrace points to a part of code that would not execute on SNB, there are checks for it. Would it be possible that the backtrace is bogus?
|
|
#15 |
(In reply to Tapani Pälli from comment #7)
> (In reply to mathieu.malaterre from comment #6)
> > If that matters, it's a DELL Vostro 3750 with:
> >
> > $ glxinfo | grep renderer
> > OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Mobile
>
> OK, thanks. Why I asked is that fast clears are not supported on Sandybridge
> and the backtrace points to a part of code that would not execute on SNB,
> there are checks for it. Would it be possible that the backtrace is bogus?
Oops sorry, I was bogus. Fast clear path gets executed on SNB too, it'll just be not that fast. This might be still SNB specific, so it is good to know.
I've followed suggestion from Tapani Pälli and here is what I have now:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffdbfff700 (LWP 19870)]
brw_meta_fast_clear (brw=brw@
at ../../.
449 if (irb->mt-
(gdb) list
444 clear_type = REP_CLEAR;
445
446 assert(irb);
447 struct intel_mipmap_tree *mt = irb->mt;
448 assert(mt);
449 if (irb->mt-
450 clear_type = REP_CLEAR;
451
452 /* We can't do scissored fast clears because of the restrictions on the
453 * fast clear rectangle size.
(gdb) p irb
$1 = <optimized out>
(gdb) p mt
$2 = (struct intel_mipmap_tree *) 0x0
(gdb)
|
|
#17 |
I could not reproduce this with a Sandybridge laptop running Ubuntu 14.10, I used oibaf-ppa repositories with Mesa 10.7.0-devel (current git head). I tried to rew and ffwd multiple times. I tried with libvdpau-va-gl1 and also --vo=opengl, did not seem to make difference.
Difficult for me to reproduce here, since mesa 10.7 now requires libdrm_intel >= 2.4.60.
I'll try to update both packages here.
|
|
#19 |
I have a similar issue which started happening recently, plasmashell crashes a lot in the same function.
#5 0x00007fbf834cfed0 in brw_meta_fast_clear () from /usr/lib/
#6 0x00007fbf83469bec in brw_clear () from /usr/lib/
#7 0x00007fbfa4fe1d4a in QSGBatchRendere
#8 0x00007fbfa4fe650a in QSGBatchRendere
#9 0x00007fbfa4ff115c in QSGRenderer:
#10 0x00007fbfa4ff15db in QSGRenderer:
#11 0x00007fbfa4fffcde in QSGRenderContex
#12 0x00007fbfa504995c in QQuickWindowPri
#13 0x00007fbfa501a2bc in ?? () from /usr/lib/
#14 0x00007fbfa501ade1 in ?? () from /usr/lib/
#15 0x00007fbfa2ba262c in QApplicationPri
#16 0x00007fbfa2ba7d10 in QApplication:
#17 0x00007fbfa184b57b in QCoreApplicatio
#18 0x00007fbfa18a1b1d in QTimerInfoList:
#19 0x00007fbfa18a2021 in ?? () from /usr/lib/
#20 0x00007fbf9d23d9fd in g_main_
#21 0x00007fbf9d23dce0 in ?? () from /usr/lib/
#22 0x00007fbf9d23dd8c in g_main_
#23 0x00007fbfa18a2cff in QEventDispatche
#24 0x00007fbfa1848ffa in QEventLoop:
#25 0x00007fbfa1850a4c in QCoreApplicatio
#26 0x000000000042ed66 in main ()
|
|
#20 |
I forgot to say that I am on ArchLinux with Mesa 10.6, I've also tried mesa-git, same issue.
I can reproduce it here on ArchLinux with broadwell. Googling a bit shows it happening for people using xbmc, gnome shell or plasma on various distros.
I just hacked in a null check to stop the crashing for now (hard to work when the desktop shell keeps crashing):
diff --git a/src/mesa/
index 5b8191c..f0e5e77 100644
--- a/src/mesa/
+++ b/src/mesa/
@@ -442,6 +442,10 @@ brw_meta_
if (rb == NULL)
continue;
+ // For some reason this render buffer can lack a mipmap tree
+ if (irb->mt == NULL)
+ continue;
+
clear_type = FAST_CLEAR;
/* We don't have fast clear until gen7. */
... which didn't work all that well, now it crashes in gen8_update_
I guess I need to figure out why the mipmap tree is not set.
Some users report that changing the AccelMethod for the xorg intel driver to UXA seems to fix it. This seems weird to me, because I didn't think it would affect mesa?
Another KDE developer suggested that the bug seems to happen when the system is under above normal load, so I guess this might be the result of some resource exhaustion, and something not checking if their allocation actually succeeded before using the buffer?
|
|
#24 |
I can reproduce this on Arch Linux (kernel 4.1.2, Xorg ga8a0f64 and Mesa 8c8a71f0 from GIT) on Haswell, also using plasmashell:
#5 0x00007f5836872340 in brw_meta_fast_clear (brw=brw@
#6 0x00007f583680f6cc in brw_clear (ctx=0x25f6ae8, mask=34) at brw_clear.c:247
#7 0x00007f5854d57946 in QSGBatchRendere
#8 0x00007f5854d5d536 in QSGBatchRendere
#9 0x00007f5854d6b0cf in QSGRenderer:
#10 0x00007f5854d6ba1b in QSGRenderer:
#11 0x00007f5854d7f03e in QSGRenderContex
#12 0x00007f5854dd12fb in QQuickWindowPri
#13 0x00007f5854d9daa1 in QSGGuiThreadRen
#14 0x00007f5854d9ed41 in QSGGuiThreadRen
#15 0x00007f58527e4204 in QApplicationPri
#16 0x00007f58527e97e9 in QApplication:
#17 0x00007f585143431d in QCoreApplicatio
#18 0x00007f585148908a in QTimerInfoList:
#19 0x00007f585148908a in QTimerInfoList:
#20 0x00007f5851489669 in idleTimerSource
#21 0x00007f5851489669 in idleTimerSource
#22 0x00007f584cdcfd57 in g_main_
#23 0x00007f584cdcffb0 in () at /usr/lib/
#24 0x00007f584cdd005c in g_main_
#25 0x00007f5851489a3f in QEventDispatche
#26 0x00007f5851432c5a in QEventLoop:
|
|
#25 |
*** Bug 91449 has been marked as a duplicate of this bug. ***
I reproduced this bug on my SNB laptop and Mesa master (HEAD 7850774). I found that just before crashing at brw_meta_
Failed to open BO for returned DRI2 buffer (1600x900, dri2 back buffer, named 11).
This is likely a bug in the X Server that will lead to a crash soon.
Which is printed at intel_process_
My distro is Debian Jessie with a Linux kernel 3.14.
Hope this helps.
(In reply to Samuel Iglesias from comment #19)
> I reproduced this bug on my SNB laptop and Mesa master (HEAD 7850774). I
> found that just before crashing at brw_meta_
> the following error:
>
> Failed to open BO for returned DRI2 buffer (1600x900, dri2 back buffer,
> named 11).
> This is likely a bug in the X Server that will lead to a crash soon.
>
> Which is printed at intel_process_
> drm_intel_
Forgot to mention that when this error message is printed out, we return from intel_process_
> I added some
> traces to that function at libdrm and found that drmIoctl(
> DRM_IOCTL_GEM_OPEN, &open_arg) is returning an error, so this bug seems to
> be produced by the kernel driver.
>
> My distro is Debian Jessie with a Linux kernel 3.14.
>
> Hope this helps.
Good job tracking it further! I kind of gave up, especially after figuring out the workaround by choosing UXA as AccelMethod.
I'm not sure exactly what the proper behavior should be here (should everything check if the mipmap tree is null?), which makes it harder for me to get started on a patch. Trying to trace the failing path in the kernel is a bit beyond my skills and what I have time for at the moment
Martin, which xf86-video-intel version are you using?
Chris, any idea what would this affect?
I currently have xf86-video-intel 1:2.99.
|
|
#31 |
I can reproduce this crash on a Broadwell laptop running Arch, both in mpv with vo=gl and in other OpenGL applications.
mesa 10.6.3-1
xf86-video-intel 1:2.99.
I have not been able to reproduce the issue with AccelMethod UXA. However, UXA method on this system does not perform at an adequate level.
I have not been able to reproduce the issue with DRI3. I have observed no performance issues with DRI3, so this can be an alternative workaround if you experience low performance on UXA.
|
|
#32 |
I am now actually getting this crash a lot of times per day, it's crashing plasmashell all the time.
I'm not sure when it started happening but I didn't have any issues before. I'm guessing it started after an update to xf86-video-intel.
xf86-video-intel 1:2.99.
mesa 10.6.3
Many people running Plasma 5 seem to be affected:
https:/
(In reply to Samuel Iglesias from comment #20)
> (In reply to Samuel Iglesias from comment #19)
> > I added some
> > traces to that function at libdrm and found that drmIoctl(
> > DRM_IOCTL_GEM_OPEN, &open_arg) is returning an error, so this bug seems to
> > be produced by the kernel driver.
> >
> > My distro is Debian Jessie with a Linux kernel 3.14.
Just my 5 cents:
I had several semi-rare crashes in plasma/
As per this comment, this may be an old bug in the kernel, so you should probably test with new *kernels*, not mesa.
People on Arch Linux are using kernel 4.1.4 at the moment, so it's definitely not an issue that's solved with new kernel.
I'm quite confident the problem is in mesa.
I was told on IRC earlier today that someone from Intel said the bug was fixed in git, but I just tested with 30a7e0c021c3a77
Just a few comments in case it helps. I run Manjaro KDE - currently Plasma 5.3.2-2 64 bit.
I started seeing these segmentation issues about a month ago - seemed to coincide with a Plasma update so initially blamed that. Was also running an older kernel (3.18), and wondered about that to.
Recently switched to kernel 4.1 - this made no difference.
As suggested by others, switching to UXA mode solved the problem, but graphics performance (Haswell i5) was unacceptable.
Last night started progressively downgrading mesa and xf86-video-intel in various combinations. Cross fingers I have stable behavior now - having dropped to:
mesa 10.5.7-1
My testing wasn't extensive, but switching to either of these on their own did not seem to solve the problem - only downgrading both packages.
|
|
#37 |
(In reply to Martin Sandsmark from comment #28)
> I was told on IRC earlier today that someone from Intel said the bug was
> fixed in git, but I just tested with
> 30a7e0c021c3a77
> when I logged in was this crash.
He probably meant the git from xf86-video-intel.
I've started using mesa-git and xf86-video-
|
|
#38 |
There is no commit to xf86-drv-intel since July 31, but today or yesterday a log of commits happened in mesa git.
With kernel-4.2rc5/mesa git/xf86-drv-intel git, I can confirm there is no such crash when enable dri3 in driver.
I just update the mesa git and switch driver back to dri2 to verify it's fixed or not.
|
|
#39 |
(In reply to Martin Sandsmark from comment #28)
> I was told on IRC earlier today that someone from Intel said the bug was
> fixed in git, but I just tested with
> 30a7e0c021c3a77
> when I logged in was this crash.
Bug not fixed, when enabling dri2 of driver, with kernel-4.2rc5/mesa git head/xf86-drv-video git head/drm git head.
Hardware is "Thinkpad x250" with "00:02.0 VGA compatible controller: Intel Corporation Broadwell-U Integrated Graphics (rev 09)"(00:02.0 0300: 8086:1616 (rev 09)).
There is still no easy way to reproduce it, generally, I started ltp test and clicked kickoff menu or some popups. after serveral minutes, segfault happened.
Thread 1 (Thread 0x7f55086dd840 (LWP 983)):
[KCrash Handler]
#6 0x00007f54f7af19dc in brw_meta_fast_clear (brw=brw@
#7 0x00007f54f7a8d73c in brw_clear (ctx=0x1c69aa8, mask=34) at brw_clear.c:247
#8 0x0000003b56527676 in QSGBatchRendere
#9 0x0000003b5652cdb2 in QSGBatchRendere
#10 0x0000003b565386af in QSGRenderer:
#11 0x0000003b56538edb in QSGRenderer:
#12 0x0000003b56548a7e in QSGRenderContex
#13 0x0000003b5659009b in QQuickWindowPri
#14 0x0000003b56562933 in () at /lib/libQt5Quic
#15 0x0000003b56563a31 in () at /lib/libQt5Quic
#16 0x0000003b4f59632c in QApplicationPri
#17 0x0000003b4f59b446 in QApplication:
#18 0x00000035b8490b73 in QCoreApplicatio
#19 0x00000035b84e321d in QTimerInfoList:
#20 0x00000035b84e3769 in () at /lib/libQt5Core
#21 0x00000038dec48847 in g_main_
#22 0x00000038dec48a78 in () at /lib/libglib-
#23 0x00000038dec48b1c in g_main_
#24 0x00000035b84e436f in QEventDispatche
#25 0x00000035b848e6da in QEventLoop:
#26 0x00000035b849624d in QCoreApplicatio
#27 0x000000000042e8fd in main ()
|
|
#40 |
I can confirm that with mesa-git and xf86-video-
I looked at the stuff Samuel found out and went to look at the libdrm git, where I found a couple of commits related to passing buffer alignment restrictions to the kernel, which I thought looked plausibly relevant to my layman eyes.
So I installed libdrm-git yesterday, and I haven't had a crash in almost two days.
It's hard to definitely say if it is fixed because of the spurious nature of the bug, but it looks good so far (if I'm not mistaken there could also be several reasons for the miptree to not be allocated, though, so it's not given that all crashes with this backtrace are related).
Never mind, crashed again. Back to square one. (And sorry for all the noise here...)
I looked in the user journal, and found first this:
aug. 08 01:40:07 neruval kernel: [drm:gen8_
Then it seems like kscreen (the display handler for Plasma) tried to launch another instance of itself (which fails, because it is already running), and then receives some weird notifications about the displays changing:
aug. 08 01:40:07 neruval kscreen_
aug. 08 01:40:07 neruval kscreen_
aug. 08 01:40:07 neruval kscreen_
aug. 08 01:40:07 neruval kscreen_
aug. 08 01:40:07 neruval kscreen_
aug. 08 01:40:07 neruval kscreen_
aug. 08 01:40:07 neruval kscreen_
aug. 08 01:40:07 neruval kscreen_
aug. 08 01:40:07 neruval kscreen_
aug. 08 01:40:07 neruval kscreen_
aug. 08 01:40:07 neruval kscreen_
And a couple of seconds after that, Plasma crashes:
aug. 08 01:40:09 neruval drkonqi[28805]: Sending SIGSTOP to process
My theory from these logs was that because of these weird display changes Plasma resizes itself to some really weird sizes, which leads to mesa trying to allocate some really weird BOs, which the kernel fails to allocate, and then things crash.
I added some debug output to libdrm, to see what errors the kernel was actually returning:
================= DRMIOCTL FAILED 22: Invalid argument
================= DRMIOCTL FAILED 1: Operation not permitted
================= DRMIOCTL FAILED 22: Invalid argument
The invalid argument error I think might support my theory. I forgot to log the actual request, but I'll do that now, hopefully it will help to track this further. If it is the error from the IRQ handler that causes this, I'm even more out of my depth, though.
|
|
#44 |
(In reply to Martin Sandsmark from comment #36)
> I looked in the user journal, and found first this:
>
> aug. 08 01:40:07 neruval kernel: [drm:gen8_
> master control interrupt lied (SDE)!
>
> Then it seems like kscreen (the display handler for Plasma) tried to launch
> another instance of itself (which fails, because it is already running), and
> then receives some weird notifications about the displays changing:
I never got such outputs when crash happened.
It seems the crash only happened when high workload， but I am not sure about that.
The bios I used also had some problems(I guess) with VTD and iommu, I also not sure is this issue relate to bios or not.
You can have a try to build xf86-video-intel with "--with-
|
|
#45 |
I have probably the same issue, the backtrace on the crash is a bit different, but my card might not have fast_clear.
I have the
Failed to open BO for returned DRI2 buffer
message before the crash. And it doesn't happen with uxa or sna+dri3.
I have an apitrace trace that makes it happen for me in 4 out of 5 times.
run with (after decompressing)
$ glretrace replay test_case.trace
It's 14MB so I uploaded it on an external site. (https:/
Software versions:
------------------
Linux 4.1.4 (Archlinux)
mesa 10.6.3
libdrm 2.4.62+
xf86-video-intel 2.99.917+
Hack to fix it in gdb
-------
After drm_intel_
then it succeds.
(This is what has to be done when dri2 buffers got invalidated)
Backtrace when drm_intel_
-------
#0 intel_process_
at brw_context.c:1423
#1 intel_update_
#2 intel_update_
#3 0x00007ffff203d5b1 in intel_prepare_
#4 0x00007ffff2031290 in brw_clear (ctx=0x7ffff7fd
#5 0x00000000004e8c96 in ?? ()
#6 0x000000000040bd1d in ?? ()
#7 0x000000000040c37c in ?? ()
#8 0x0000000000407b05 in ?? ()
#9 0x00007ffff61e0790 in __libc_start_main () from /usr/lib/libc.so.6
#10 0x00000000004095e9 in _start ()
This patch should be a good workaround: http://
I will test it tonight on my home machine and see if I can reproduce it. The patch may make the screen flicker for a frame instead of crashing. The actual problem is a race condition of DRI2 that is not trivial to fix.
|
|
#47 |
Created attachment 117626
Description of problem, test case.
|
|
#48 |
(In reply to Martin Peres from comment #39)
> This patch should be a good workaround:
> http://
> batch&id=
>
> I will test it tonight on my home machine and see if I can reproduce it. The
> patch may make the screen flicker for a frame instead of crashing. The
> actual problem is a race condition of DRI2 that is not trivial to fix.
This patch seems to solve the brw_meta_fast_clear crashes I've had in Firefox and Steam since Mesa 10.6. Cheers!
(In reply to Jan Alexander Steffens (heftig) from comment #41)
> (In reply to Martin Peres from comment #39)
> > This patch should be a good workaround:
> > http://
> > batch&id=
> >
> > I will test it tonight on my home machine and see if I can reproduce it. The
> > patch may make the screen flicker for a frame instead of crashing. The
> > actual problem is a race condition of DRI2 that is not trivial to fix.
>
> This patch seems to solve the brw_meta_fast_clear crashes I've had in
> Firefox and Steam since Mesa 10.6. Cheers!
Same at home. No crashes to report since I applied the patch. I will review the patch and push it upstream tomorrow.
I'd rather a complete fix merged into upstream. Workaround should be applied by user-patched builds.
(In reply to Tatsuyuki Ishi from comment #43)
> I'd rather a complete fix merged into upstream. Workaround should be applied
> by user-patched builds.
The complete fix requires fixing the xserver, the ddx and mesa. This is in the pipe but it is not coming any time soon. In the mean time, let's avoid crashing if we can. The code will still be useful when everything is fixed!
|
|
#52 |
Has the patch been included in mesa git?
| Philip Muškovac (yofel) wrote : | #1 |
| Launchpad Janitor (janitor) wrote : | #2 |
Status changed to 'Confirmed' because the bug affects multiple users.
| Changed in mesa (Ubuntu): | |
| status: | New → Confirmed |
| Changed in mesa (Ubuntu): | |
| importance: | Undecided → Critical |
Please:
1. Report to <https:/
2. Paste the new report URL here.
3. Set this bug status back to "confirmed".
Thank you 😉
| Changed in mesa (Ubuntu): | |
| status: | Confirmed → Incomplete |
| tags: | added: asked-to-upstream |
| Philip Muškovac (yofel) wrote : | #4 |
So it turns out that is already known upstream..
| Changed in mesa: | |
| importance: | Undecided → Unknown |
| status: | New → Unknown |
| Changed in mesa (Ubuntu): | |
| status: | Incomplete → Confirmed |
| Philip Muškovac (yofel) wrote : | #5 |
David Edmundson pointed out that this was also discussed by the kde developers suggesting to switch back to UXA from SNA on intel
https:/
the freedesktop bug also seems to have a workaround attached to it
| tags: | added: kubuntu |
So that's all then 🍵
| Changed in mesa (Ubuntu): | |
| status: | Confirmed → Triaged |
Reported also in <https:/
Fedora bugreport of this bug (linked to Freedesktop bugreport too)
https:/
| Changed in mesa (Debian): | |
| status: | Unknown → Confirmed |
| Changed in mesa: | |
| importance: | Unknown → Critical |
| status: | Unknown → Confirmed |
| Timo Aaltonen (tjaalton) wrote : | #55 |
ppa:canonical-
| Philip Muškovac (yofel) wrote : | #56 |
Ok, after adding mesa 11.0.0 I haven't seen this crash for 2 days now. So I guess the patch helps as I had this crash several times per day before that.
| Launchpad Janitor (janitor) wrote : | #57 |
This bug was fixed in the package mesa - 11.0.0-1ubuntu1
---------------
mesa (11.0.0-1ubuntu1) wily; urgency=medium
* Merge from Debian. (LP: #1484279)
* egl-platform-
* i965-remove-
fix crashes in brw_meta_
* control, rules: Default to llvm-3.6 again, because 3.7 won't be in
main for wily.
mesa (11.0.0-1) experimental; urgency=medium
* New upstream release.
mesa (11.0.0~rc3-1) experimental; urgency=medium
[ Andreas Boll ]
* Use https for Vcs-* fields.
[ Timo Aaltonen ]
* New upstream release candidate.
mesa (11.0.0~rc2-1) experimental; urgency=medium
* New upstream release candidate.
mesa (11.0.0~rc1-1) experimental; urgency=medium
[ Andreas Boll ]
* New upstream release candidate.
* control: Drop unneeded libomxil-
* rules: Explicitly disable vaapi (Closes: #789100).
* control: Update upstream url.
* control: Update Vcs-* fields.
* Drop libgl1-mesa-swx11* packages.
* control: Update package description.
[ Timo Aaltonen ]
* control: Delete commented out libgl1-
* control: Bump llvm/libclang build-deps to match versions where
amdgpu is enabled.
mesa (11.0.0~
* New upstream snapshot
* control: Bump libdrm build-dep to 2.4.63.
* control: Add libomxil-
* rules: Disable gles1 & 2 for swx11 builds.
* libegl1-
* control, rules: Migrate to llvm 3.7.
* rules: Enable llvmpipe on armhf again.
mesa (10.6.7-1) unstable; urgency=medium
* New upstream release.
mesa (10.6.5-1) unstable; urgency=medium
[ Andreas Boll ]
* New upstream release.
[ Julien Cristau ]
* Break libopengl-perl (<< 0.6704+dfsg-2), thanks to Niko Tyni
(closes: #796918)
mesa (10.6.4-1) unstable; urgency=medium
* New upstream release.
-- Timo Aaltonen <email address hidden> Tue, 22 Sep 2015 19:20:17 +0300
| Changed in mesa (Ubuntu): | |
| status: | Triaged → Fix Released |
|
|
#58 |
Anything new on merging the patch?
(In reply to AnAkkk from comment #48)
> Anything new on merging the patch?
Done!
| Changed in mesa (Debian): | |
| status: | Confirmed → Fix Released |
I can get a segfault in i915 driver using this simple steps (debian/
$ wget http://
$ sudo apt-get install mpv
$ mpv big_buck_
-> press 'f' to get full screen
-> press & hold right-arrow key to fast-forward
See:
https:/
Backtrace is:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffdbfff700 (LWP 32052)]
brw_meta_fast_clear (brw=brw@
at ../../.
447 ../../.
(gdb) bt
#0 brw_meta_fast_clear (brw=brw@
at ../../.
#1 0x00007fffdb3c2a48 in brw_clear (ctx=0x7fffd409
#2 0x0000555555637269 in gl_video_
#3 0x000055555563c354 in draw_image (vo=<optimized out>, mpi=0x555556370e00) at ../video/
#4 0x0000555555639fa3 in render_frame (vo=0x55555631de90) at ../video/
#5 vo_thread (ptr=0x55555631
#6 0x00007ffff6ac20a4 in start_thread (arg=0x7fffdbff
#7 0x00007ffff00b3ccd in clone () at ../sysdeps/
See:
https:/