Bug 85647 - Random radeonsi crashes with mesa 10.3.x
Summary: Random radeonsi crashes with mesa 10.3.x
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/radeonsi (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
: 81644 85866 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-10-30 12:45 UTC by Hannu
Modified: 2015-03-04 07:31 UTC (History)
6 users (show)

See Also:
i915 platform:
i915 features:


Attachments
dmesg (76.30 KB, text/plain)
2014-10-30 15:09 UTC, Hannu
Details
Xorg.0.log (45.29 KB, text/plain)
2014-10-30 15:10 UTC, Hannu
Details
Xorg.0.log after crash (54.15 KB, text/plain)
2014-11-01 18:26 UTC, Hannu
Details
Crash with mesa 10.2.8, Xorg.0.log (57.19 KB, text/plain)
2014-11-03 21:24 UTC, Hannu
Details
journalctl -b after crash (11.81 KB, text/plain)
2014-11-05 09:03 UTC, Hannu
Details
radeonsi: Disable asynchronous DMA (431 bytes, patch)
2014-11-05 09:59 UTC, Michel Dänzer
Details | Splinter Review
radeonsi: Disable asynchronous DMA except for PIPE_BUFFER (503 bytes, patch)
2014-11-11 07:13 UTC, Michel Dänzer
Details | Splinter Review
diff when patched with "radeonsi: Disable asynchronous DMA except for PIPE_BUFFER" (519 bytes, text/plain)
2014-11-11 08:54 UTC, Hannu
Details
"goto fallback" added before si_dma_copy_tile() (530 bytes, text/plain)
2014-11-13 11:49 UTC, Hannu
Details
check space after r600_need_dma_space() (1.48 KB, text/plain)
2014-11-18 11:20 UTC, Hannu
Details
mesa 10.3.2-1 and linux 3.18.0 crash (6.55 KB, text/plain)
2014-12-08 07:32 UTC, Hannu
Details
journalctl -b after crash, kernel 3.19-rc3 with patches (87.22 KB, text/plain)
2015-01-08 11:31 UTC, Hannu
Details
journalctl -b after crash, linux 4.0.0-rc2 with patches (1.58 MB, text/plain)
2015-03-04 07:29 UTC, Hannu
Details
Xorg.0.log after crash, linux 4.0.0-rc2 with patches (47.54 KB, text/plain)
2015-03-04 07:31 UTC, Hannu
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Hannu 2014-10-30 12:45:53 UTC
This is propably duplicate of some of the 79980 reports, that is why I put the report to DRI and not mesa where it might belong.

Xorg has randomly timed (hours or days between) crashes with mesa 10.3.x. First it stops responding for some seconds, then screen goes black. Sometimes it recovers for a moment after the black screen but you had better reboot the computer while you can, ít will crash again soon after the first crash.

My son is playing steam games with that computer and he complains loudly when the crash happens. It has crashed when he is watching videos from youtube.

I think steam games are i386. Firefox and flash are amd64. So I have both i386 and amd64 libraries installed (debian multiarch). System is otherwise amd64.

I usually try the latest versions from debian archive and after couple of crashes (and loud complaints) I downgrade mesa to 10.2.8-1 which does not crash.

After the crash Xorg.0.log has
"(EE) [mi] EQ overflowing.  Additional events will be discarded until existing events are processed." and so on at the end of the log.

10.3.2 crashed next day after installing (after several hours of gaming) and since I do not know how to compile for multiarched debian I think bisecting is not possible.

debian sid amd64 multiarch
mesa 10.3.2-1
libdrm-radeon1 2.4.58-2
xserver-xorg-video-radeon 7.5.0-1

uname -a:
Linux 3.18.0-rc2-hmaa #1 SMP PREEMPT Mon Oct 27 06:23:54 EET 2014 x86_64 GNU/Linux

lspci:
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Pitcairn XT [Radeon HD 7870 GHz Edition]

-------------------
I have another computer which I use myself, it has Northern Islands card (Barts):
lspci:
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Barts XT [Radeon HD 6870]
Software is the is the same in both computers.

The computer with Northern Islands has not crashed with mesa 10.3.x, so it seems to me that this bug needs the combination of mesa 10.3.x and Southern Islands to occur. I don't do the heavy gaming and long youtube sessions with the Northern Islands card but it is in use about 10 hours daily.
Comment 1 Hannu 2014-10-30 13:51:21 UTC
Some additional info:

grepped aptitude log, shows which versions I have tried:

[UPGRADE] libgl1-mesa-dri:amd64 10.2.6-1 -> 10.2.8-1
[UPGRADE] libgl1-mesa-dri:amd64 10.2.8-1 -> 10.3.0~rc3-3
[DOWNGRADE] libgl1-mesa-dri:amd64 10.3.0~rc3-3 -> 10.2.8-1
[UPGRADE] libgl1-mesa-dri:amd64 10.2.8-1 -> 10.3.0-2
[DOWNGRADE] libgl1-mesa-dri:amd64 10.3.0-2 -> 10.2.8-1
[UPGRADE] libgl1-mesa-dri:amd64 10.2.8-1 -> 10.3.1-1
[DOWNGRADE] libgl1-mesa-dri:amd64 10.3.1-1 -> 10.2.8-1
[UPGRADE] libgl1-mesa-dri:amd64 10.2.8-1 -> 10.3.1-1
[UPGRADE] libgl1-mesa-dri:amd64 10.2.8-1 -> 10.3.2-1


20 october I checked with diff that I have latest ucode from
http://people.freedesktop.org/~agd5f/radeon_ucode/
Comment 2 Alex Deucher 2014-10-30 14:41:15 UTC
(In reply to Hannu from comment #0)
> Xorg has randomly timed (hours or days between) crashes with mesa 10.3.x.
> First it stops responding for some seconds, then screen goes black.
> Sometimes it recovers for a moment after the black screen but you had better
> reboot the computer while you can, ít will crash again soon after the first
> crash.

Are you saying this is a regression between mesa 10.3.x and 10.2.x?  If so, can can bisect?  Also, please attach your dmesg output and xorg log.
Comment 3 Hannu 2014-10-30 15:09:51 UTC
Created attachment 108693 [details]
dmesg
Comment 4 Hannu 2014-10-30 15:10:23 UTC
Created attachment 108694 [details]
Xorg.0.log
Comment 5 Hannu 2014-10-30 15:18:41 UTC
(In reply to Alex Deucher from comment #2)
> (In reply to Hannu from comment #0)
> > Xorg has randomly timed (hours or days between) crashes with mesa 10.3.x.
> > First it stops responding for some seconds, then screen goes black.
> > Sometimes it recovers for a moment after the black screen but you had better
> > reboot the computer while you can, ít will crash again soon after the first
> > crash.
> 
> Are you saying this is a regression between mesa 10.3.x and 10.2.x?  If so,
> can can bisect?  Also, please attach your dmesg output and xorg log.

Well... yes, it seems to be a regression between mesa 10.3.x and 10.2.x. As I explained above, bisecting this is impossible due to random long time between occurrences of the bug.

Attached dmesg and Xorg.0.log. I don't have Xorg.0.log with the error message currently, I'll attach if/when it happens again.

As I wrote above "After the crash Xorg.0.log has
"(EE) [mi] EQ overflowing.  Additional events will be discarded until existing
events are processed." and so on at the end of the log."
Comment 6 Hannu 2014-10-30 15:48:32 UTC
I don't know much about xorg stacks inner workings but it might be that mesa isn't buggy, but has some added functionality between 10.3.x and 10.2.x that exercises buggy code path lower in the driver stack.
Comment 7 Michel Dänzer 2014-10-31 02:24:22 UTC
(In reply to Hannu from comment #5)
> As I explained above, bisecting this is impossible due to random long time
> between occurrences of the bug.

That doesn't make it impossible, it just means you need patience. Take your time, and make sure you test each commit for at least as long (preferably longer, to account for variation) as it's ever taken for the problem to occur before declaring it good. On the bright side, when the problem occurs quickly, you know that commit is bad and can move on to the next one.


(In reply to Hannu from comment #6)
> I don't know much about xorg stacks inner workings but it might be that mesa
> isn't buggy, but has some added functionality between 10.3.x and 10.2.x that
> exercises buggy code path lower in the driver stack.

It doesn't matter. Since the problem happens with Mesa 10.3.y but not with 10.2.y, once we know which change between them makes the difference, we'll be at least a big step closer to solving the problem.
Comment 8 Michel Dänzer 2014-10-31 02:31:56 UTC
(In reply to Michel Dänzer from comment #7)
> That doesn't make it impossible, it just means you need patience. Take your
> time, and make sure you test each commit for at least as long (preferably
> longer, to account for variation) as it's ever taken for the problem to
> occur before declaring it good. On the bright side, when the problem occurs
> quickly, you know that commit is bad and can move on to the next one.

On another bright side, when the problem doesn't occur for a long time, you can enjoy the lack of complaints about it from your son. :) However, it's very important that you don't declare a commit good which would have exhibited the problem after more testing, otherwise the bisection will give the wrong result.
Comment 9 Aaron B 2014-10-31 05:44:18 UTC
*** Bug 81644 has been marked as a duplicate of this bug. ***
Comment 10 Hannu 2014-11-01 18:26:23 UTC
Created attachment 108767 [details]
Xorg.0.log after crash

Xorg.0.log after crash. Mesa 10.3.2
Comment 11 Hannu 2014-11-03 21:19:09 UTC
Now it crashed with mesa 10.2.8-1 for the first time so we can propably forget the "regression between mesa 10.3.x and 10.2.x" part of this report. I will attach Xorg.0.log but it has the same old error. Crash happened while watching flash video full screen.
Comment 12 Hannu 2014-11-03 21:24:11 UTC
Created attachment 108864 [details]
Crash with mesa 10.2.8, Xorg.0.log
Comment 13 Hannu 2014-11-05 09:03:50 UTC
Created attachment 108940 [details]
journalctl -b after crash

Got something new, I updated xserver to 1.16.1.901-1 and linux to 3.18.0-rc3. Crashed same way as before. After crash no error message in Xorg.0.log but found this with journalctl -b:

Nov 05 10:24:10  kernel: radeon 0000:01:00.0: ring 3 stalled for more than 10020msec
Nov 05 10:24:10  kernel: radeon 0000:01:00.0: GPU lockup (current fence id 0x0000000000002757 last fence id 0x0000000000002788 on ring 3)
Nov 05 10:24:10  kernel: radeon 0000:01:00.0: Saved 2028 dwords of commands on ring 0.
Nov 05 10:24:10  kernel: radeon 0000:01:00.0: GPU softreset: 0x0000006C
Nov 05 10:24:10  kernel: radeon 0000:01:00.0:   GRBM_STATUS               = 0xA0003028
Nov 05 10:24:10  kernel: radeon 0000:01:00.0:   GRBM_STATUS_SE0           = 0x00000006
and so on.

Relevant parts attached, error message at end.
Comment 14 Michel Dänzer 2014-11-05 09:59:20 UTC
Created attachment 108943 [details] [review]
radeonsi: Disable asynchronous DMA

Does this patch avoid the lockups?
Comment 15 Hannu 2014-11-06 17:29:21 UTC
(In reply to Michel Dänzer from comment #14)
> Created attachment 108943 [details] [review] [review]
> radeonsi: Disable asynchronous DMA
> 
> Does this patch avoid the lockups?

I have now mesa 10.3.2 package patched, built and installed for i386 and amd64 from debian source package. We will have to wait couple of days or maybe a week to say with some probability if the crash has gone.
Comment 16 Hannu 2014-11-08 12:09:01 UTC
(In reply to Michel Dänzer from comment #14)
> Created attachment 108943 [details] [review] [review]
> radeonsi: Disable asynchronous DMA
> 
> Does this patch avoid the lockups?

No crashes/lockups with your patch after 2 days, testing continues. I will do some full screen flash video testing on monday.

Today Xorg.0.log has a few of these:

[ 12208.821] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip completion event has impossible msc 731959 < target_msc 731960
[ 13141.437] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip completion event has impossible msc 787906 < target_msc 787907
Comment 17 Malte Schröder 2014-11-08 15:37:17 UTC
Hi, running kernel 3.18-rc3 mesa 10.3.2 + the "Disable asynchronous DMA" patch my system has been stable for three days now. Done lots of video watching and using suspend to ram. No misbehaviour up to now. Without the patch this combination would fail pretty quickly.
Comment 18 Hannu 2014-11-10 13:22:07 UTC
(In reply to Michel Dänzer from comment #14)
> Created attachment 108943 [details] [review] [review]
> radeonsi: Disable asynchronous DMA
> 
> Does this patch avoid the lockups?

No lockups/crashes with your "radeonsi: Disable asynchronous DMA"-patch after 4 days.

I did some testing today with a 23 minute full screen flash video:

Mesa 10.3.2 with the patch: 10 playbacks of the video, no crashes/lockups.

I built and installed mesa 10.3.2 from debian same source package without the patch:
Run 1: fifth playback of the video crashed.
Run 2: fourth playback of the video crashed.

I think no further testing of this patch is needed, indicates something wrong with the DMA code?
Comment 19 Michel Dänzer 2014-11-11 07:13:42 UTC
Created attachment 109261 [details] [review]
radeonsi: Disable asynchronous DMA except for PIPE_BUFFER

Can you test this patch as well?
Comment 20 Hannu 2014-11-11 08:54:12 UTC
Created attachment 109263 [details]
diff when patched with "radeonsi: Disable asynchronous DMA except for PIPE_BUFFER"

Applied the patch, it was not for mesa 10.3.2 version. I attached the diff.

I will test with the same video as yesterday as soon as I get the packages built.
Comment 21 Hannu 2014-11-11 12:53:20 UTC
(In reply to Michel Dänzer from comment #19)
> Created attachment 109261 [details] [review] [review]
> radeonsi: Disable asynchronous DMA except for PIPE_BUFFER
> 
> Can you test this patch as well?


Tested with a 23 minute full screen flash video same as before.

Mesa 10.3.2 with the "radeonsi: Disable asynchronous DMA except for PIPE_BUFFER"-patch: 7 playbacks of the video, no crashes/lockups.

I will continue tomorrow, now the computer is needed for gaming.
Comment 22 Itzamna 2014-11-11 13:20:00 UTC
(In reply to Michel Dänzer from comment #19)
> Created attachment 109261 [details] [review] [review]
> radeonsi: Disable asynchronous DMA except for PIPE_BUFFER
> 
> Can you test this patch as well?

Hello Michel,

I suffered from the same crashes Hannu and Malte Schröder reported. After applying this patch, the crashes and lockups ceased.
Comment 23 boombatower 2014-11-11 21:08:21 UTC
I tested attachment 108943 [details] [review] (coming from https://bugs.freedesktop.org/show_bug.cgi?id=85866) which solved the issues for me as well. Radeon HD 7970.
Comment 24 Hannu 2014-11-12 09:17:35 UTC
(In reply to Michel Dänzer from comment #19)
> Created attachment 109261 [details] [review] [review]
> radeonsi: Disable asynchronous DMA except for PIPE_BUFFER
> 
> Can you test this patch as well?

Tested with a 23 minute full screen flash video same as before.

Mesa 10.3.2 with the "radeonsi: Disable asynchronous DMA except for PIPE_BUFFER"-patch: 10 playbacks of the video, no crashes/lockups.

I think the patch makes mesa stable at least for flash videos, no further testing needed for this patch.
Comment 25 boombatower 2014-11-13 05:01:30 UTC
*** Bug 85866 has been marked as a duplicate of this bug. ***
Comment 26 Hannu 2014-11-13 11:49:45 UTC
Created attachment 109402 [details]
"goto fallback" added before si_dma_copy_tile()

I tested today with this:

 		si_dma_copy_buffer(sctx, dst, src, dst_offset, src_offset,
 			    src_box->height * src_pitch);
 	} else {
+		goto fallback;
 		si_dma_copy_tile(sctx, dst, dst_level, dst_x, dst_y, dst_z,

(diff attached)


Tested with a 23 minute full screen flash video same as before.

Mesa 10.3.2 with the "goto fallback" added before si_dma_copy_tile(): 10 playbacks of the video, no crashes/lockups.

I am going to test the original code without changes again tomorrow to be sure that the crash is still there. (I updated firefox yesterday).
Comment 27 Hannu 2014-11-15 10:13:42 UTC
I built mesa 10.4.0-devel (master) from mesa git.

+linux 3.18.0-rc4

Tested with a 23 minute full screen flash video same as before,
sixth playback of the video crashed.



Mesa 10.3.2 with the bypassed si_dma_copy_tile() as in comment 26 has not crashed yet

 		si_dma_copy_buffer(sctx, dst, src, dst_offset, src_offset,
 			    src_box->height * src_pitch);
 	} else {
+		goto fallback;
 		si_dma_copy_tile(sctx, dst, dst_level, dst_x, dst_y, dst_z,
Comment 28 Michel Dänzer 2014-11-17 07:25:05 UTC
Module: Mesa
Branch: master
Commit: ae4536b4f71cbe76230ea7edc7eb4d6041e651b4
URL:    http://cgit.freedesktop.org/mesa/mesa/commit/?id=ae4536b4f71cbe76230ea7edc7eb4d6041e651b4

Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Tue Nov 11 16:10:20 2014 +0900

radeonsi: Disable asynchronous DMA except for PIPE_BUFFER
Comment 29 Hannu 2014-11-17 09:52:50 UTC
(In reply to Michel Dänzer from comment #28)
> Module: Mesa
> Branch: master
> Commit: ae4536b4f71cbe76230ea7edc7eb4d6041e651b4
> URL:   
> http://cgit.freedesktop.org/mesa/mesa/commit/
> ?id=ae4536b4f71cbe76230ea7edc7eb4d6041e651b4
> 
> Author: Michel Dänzer <michel.daenzer@amd.com>
> Date:   Tue Nov 11 16:10:20 2014 +0900
> 
> radeonsi: Disable asynchronous DMA except for PIPE_BUFFER

There might be something that fixes this bug in linux 3.18.0-rc5.
I just tested linux 3.18.0-rc5 with the same mesa 10.4.0-devel package as in comment 27.


Tested with a 23 minute full screen flash video same as before.

Mesa 10.4.0-devel and linux 3.18.0-rc5: 10 playbacks of the video, no crashes/lockups.


I'll test mesa 10.3.2 original debian package without changes and linux 3.18.0-rc5 tomorrow.
Comment 30 Aaron B 2014-11-17 14:58:50 UTC
I would only attempt to say it's fixed after about 2 days of stability playing multimedia content/dynamic content in an accelerated web browser. 23 Minutes is not long enough to test this bug, it sometimes took days with flash for me. 

I got a replacement card, so I can't test anything anymore, so I can't help say if rc5 has any fixes. Sorry.
Comment 31 Malte Schröder 2014-11-17 16:52:20 UTC
3.18-rc5 does not fix the problem. I just tried and the system crashed after a few minutes. Now running gain with my patched mesa 10.3.2.
Comment 32 Hannu 2014-11-18 07:05:17 UTC
mesa 10.3.2 original debian package without changes and linux 3.18.0-rc5 crashed after a few minutes when playing the video. That is worse than before, it has usually crashed after four to six replays of the video.

I'll start testing mesa 10.4.0-devel with rc5 again, probably it was a random fluke that it lasted ten replays, longest this far has been seven replays without the bypassed si_dma_copy_tile().
Comment 33 Hannu 2014-11-18 07:52:35 UTC
Tested with a 23 minute full screen flash video same as before.

Mesa 10.4.0-devel and linux 3.18.0-rc5 again: second replay of the video crashed.

So no luck with that, I'll try "fix that only disables DMA if 1D tiling is involved" from bug 83500, if that doesn't work I give up and use the fix I did in comment 26.
Comment 34 Michel Dänzer 2014-11-18 08:03:11 UTC
(In reply to Hannu from comment #33)
> I'll try "fix that only disables DMA if 1D tiling is involved" from bug 83500, 

You can save the time for that, given that it didn't fully fix the problem for the reporter of that bug.


> if that doesn't work I give up and use the fix I did in comment 26.

Why don't you just use the fix I pushed to resolve this report? :) I deliberately didn't keep the second si_dma_copy_buffer path enabled because I know (from experience trying to port the DMA code to CIK) that it doesn't properly check for all cases it can't handle. I don't think that path is very relevant in practice anyway.
Comment 35 Hannu 2014-11-18 08:15:41 UTC
(In reply to Michel Dänzer from comment #34)
> (In reply to Hannu from comment #33)
> > I'll try "fix that only disables DMA if 1D tiling is involved" from bug 83500, 
> 
> You can save the time for that, given that it didn't fully fix the problem
> for the reporter of that bug.
> 
> 
> > if that doesn't work I give up and use the fix I did in comment 26.
> 
> Why don't you just use the fix I pushed to resolve this report? :) I
> deliberately didn't keep the second si_dma_copy_buffer path enabled because
> I know (from experience trying to port the DMA code to CIK) that it doesn't
> properly check for all cases it can't handle. I don't think that path is
> very relevant in practice anyway.

OK, I'll stop testing for now.
Comment 36 Michel Dänzer 2014-11-18 08:39:31 UTC
Thanks for all your testing, BTW!
Comment 37 Hannu 2014-11-18 11:20:22 UTC
Created attachment 109668 [details]
check space after r600_need_dma_space()

By the way, at some point while testing I noticed that si_dma_copy_tile() does not check that it actually got the space it wanted after this call:

	r600_need_dma_space(&ctx->b, ncopy * 9);


void r600_need_dma_space(struct r600_common_context *ctx, unsigned num_dw)
{
	/* The number of dwords we already used in the DMA so far. */
	num_dw += ctx->rings.dma.cs->cdw;
	/* Flush if there's not enough space. */
	if (num_dw > RADEON_MAX_CMDBUF_DWORDS) {
		ctx->rings.dma.flush(ctx, RADEON_FLUSH_ASYNC, NULL);
	}
}

So I added check after r600_need_dma_space():

r600_need_dma_space(&ctx->b, ncopy * 9);
if (((ncopy * 9) + cs->cdw) > RADEON_MAX_CMDBUF_DWORDS) {
	return 0;
}

and then goto fallback if returns 0, but it crashed anyway so I skipped that as irrelevant to this bug. (diff attached)
Comment 38 Hannu 2014-12-08 07:32:11 UTC
Created attachment 110558 [details]
mesa 10.3.2-1 and linux 3.18.0 crash

attached crash report from journalctl. Linux 3.18.0 and original debian mesa 10.3.2-1. I don't know if this adds anything new to report in attachment 108940 [details], there are some differences though.
Comment 39 agapito 2014-12-09 06:24:59 UTC
(In reply to Hannu from comment #38)
> Created attachment 110558 [details]
> mesa 10.3.2-1 and linux 3.18.0 crash
> 
> attached crash report from journalctl. Linux 3.18.0 and original debian mesa
> 10.3.2-1. I don't know if this adds anything new to report in attachment
> 108940 [details], there are some differences though.

Try with mesa 10.3.4.

http://www.mesa3d.org/relnotes/10.3.4.html
Comment 40 Hannu 2014-12-09 07:05:45 UTC
(In reply to agapito from comment #39)
> (In reply to Hannu from comment #38)
> > Created attachment 110558 [details]
> > mesa 10.3.2-1 and linux 3.18.0 crash
> > 
> > attached crash report from journalctl. Linux 3.18.0 and original debian mesa
> > 10.3.2-1. I don't know if this adds anything new to report in attachment
> > 108940 [details], there are some differences though.
> 
> Try with mesa 10.3.4.
> 
> http://www.mesa3d.org/relnotes/10.3.4.html

Yes I know that 'radeonsi: Disable asynchronous DMA except for PIPE_BUFFER' fixes the crash, but since the patch disables some of the functionality I checked again with latest kernel.
Comment 41 Michel Dänzer 2014-12-09 07:22:30 UTC
(In reply to Hannu from comment #40)
> Yes I know that 'radeonsi: Disable asynchronous DMA except for PIPE_BUFFER'
> fixes the crash, but since the patch disables some of the functionality I
> checked again with latest kernel.

Note that I don't think the disabled functionality made a big difference anyway.
Comment 42 Hannu 2015-01-08 11:31:16 UTC
Created attachment 111954 [details]
journalctl -b after crash, kernel 3.19-rc3 with patches


--- Comment #223 from Michel Dänzer <michel at daenzer.net> ---
(In reply to fdb4c415 from comment #222)


There's a good chance that a newer upstream version of Mesa would help for your
problem, if not fix it completely.

For those still having problems, the kernel patches
http://lists.freedesktop.org/archives/dri-devel/2015-January/074968.html and
http://lists.freedesktop.org/archives/dri-devel/2015-January/074969.html might
be worth a try.

---------------------

Attached crash report from journalctl. Linux 3.19-rc3 with those two patches and original debian mesa 10.3.2-1. Xorg locked up screen same way as before. No error reports in Xorg.0.log.
Comment 43 Hannu 2015-03-04 07:29:15 UTC
Created attachment 113979 [details]
journalctl -b after crash, linux 4.0.0-rc2 with patches

Tested mesa 10.3.2-1 with the dma problem again with linux kernel 4.0.0-rc2 with attachment 166571 from bug 90741 and "drm/radeon: do a posting read in si_set_irq" from posting-read branch applied (I'm testing just for fun, 10.4.5 works fine).

This time X restarted after the lockup (asks username and password). Journalctl -b attached, there is something in Xorg.0.log this time, I'll attach it next.
Comment 44 Hannu 2015-03-04 07:31:49 UTC
Created attachment 113981 [details]
Xorg.0.log after crash, linux 4.0.0-rc2 with patches

Here is Xorg.0.log, backtrace at the end.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.