| Priority | medium |
|---|---|
| Bug ID | 83998 |
| Assignee | dri-devel@lists.freedesktop.org |
| Summary | Oopses on R9270X using UVD since radeon/uvd: use PIPE_USAGE_S= TAGING for msg&fb buffers |
| Severity | normal |
| Classification | Unclassified |
| OS | All |
| Reporter | adf.lists@gmail.com |
| Hardware | Other |
| Status | NEW |
| Version | git |
| Component | Drivers/Gallium/radeonsi |
| Product | Mesa |
R9270X Getting rareish Oopses and once oomkiller since - commit 6327b584155d040ae089e65fd6747186bdd9666b Author: Christian K=C3=B6nig <christian.koenig@amd.com> Date: Thu Sep 11 09:50:00 2014 +0200 radeon/uvd: use PIPE_USAGE_STAGING for msg&fb buffers That better matches the actual userspace use case, the kernel will force it to VRAM if the hardware requires it. To trigger this I need to repeatedly start mplayer using uvd - it's takes s= ome time, I ended up making a script to do it for me while AFK. I am 99% sure the above is it - I spent a day and a half trying on the comm= it before (radeon/video: use the hw to initial clear the buffers) with no cras= h. The Oopses don't mention radeon or uvd. They will hit as soon as mplayer launches before it renders anything - scre= en locked, no mouse cursor or vt switch but SysRq works, box is still up in so= me ways for a while (one time I had music playing for 30s-1min after). One time oomkiller put on its blindfold and ran around killing :-)
If you use Chrom(e/ium)/Firefox, can you make sure hardware accel is enabled and see if it crashes randomly using them? I wanna see if you have other same symptoms I have with random crashing on my system.
(In reply to comment #3= ) > I wanna see if you have other same symptoms I ha= ve with random crashing on my > system. Aaron, I don't think this bug is related to yours.
This bug is still alive for me. Have randomly tested and reproduced since reporting and failed to reproduce with 6327b584155d040ae089e65fd6747186bdd9666b reverted. Just retried with the new agd5f drm-next-319-wip and it's still there - though this time I got and oops which mentions radeon/ttm so uploading. To produce I am running a script running mplayer on various blu-rays on hard disk. It's not aggressive - run for 10 sec sleep for three .... I added a counter and it got up to 29 before oopsing.
Created attachment 109744 [details]
kernel log with new oops at end
Created attachment 110298 [details]
different trace with newer kernel
This is getting harder to trigger, started to think it was fixed.
Haven't triggered with mpv yet, but can still just with mplayer.
On third attempt, 115 starts in CPUs set to perf (may help trigger, but not
sure).
Uploading because current drm-next-219-wip has some fence changes and the trace
starts with -
radeon_fence_signaled
Created attachment 110470 [details]
Another different trace
Newer kernel different trace - BUG this time.
Slightly different from normal both trace and behavior, in that it froze on
quit and the screen was still showing the vid.
Due to it being a bit different I tried again - same result, both died within 5
minutes. I then reverted the suspect commit in case it was a different issue,
went out came back and it was up to 500 and still going OK, so it does seem to
be the same issue.
That seems to be some kind of random kernel memory corruption,= triggered by using PIPE_USAGE_STAGING for your case. Does anybody have any good idea how to figure out what this is?
| What | Removed | Added |
|---|---|---|
| Component | Drivers/Gallium/radeonsi | DRM/Radeon |
| Version | git | unspecified |
| Product | Mesa | DRI |
If there's an older kernel where this doesn't happen, it might= be possible to bisect.
| What | Removed | Added |
|---|---|---|
| Status | NEW | RESOLVED |
| Resolution | --- | DUPLICATE |
I did try older kernels, but after thinking one was OK which turned out to also have the issue I decided bisecting was not really going to work. I don't have the 270X anymore so marking as a dup of another report. As noted in that report, it seems easier to provoke this with current kernels. It's possible the mesa commit just changed some timing that exposed the issue more. Currently on Tonga I can provoke a similar issue (not oops - just ring stall) and reverting the mesa commit in this bug doesn't help, but playing around with cpufreq can change how easy it is to provoke. *** This bug has been marked as a duplicate of bug 91009 ***