Summary: | Oopses on R9270X using UVD since radeon/uvd: use PIPE_USAGE_STAGING for msg&fb buffers | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | DRI | Reporter: | Andy Furniss <adf.lists> | ||||||||||||
Component: | DRM/Radeon | Assignee: | Default DRI bug account <dri-devel> | ||||||||||||
Status: | RESOLVED DUPLICATE | QA Contact: | |||||||||||||
Severity: | normal | ||||||||||||||
Priority: | medium | ||||||||||||||
Version: | unspecified | ||||||||||||||
Hardware: | Other | ||||||||||||||
OS: | All | ||||||||||||||
Whiteboard: | |||||||||||||||
i915 platform: | i915 features: | ||||||||||||||
Attachments: |
|
Description
Andy Furniss
2014-09-17 14:14:07 UTC
Created attachment 106433 [details]
Oops uvd
Created attachment 106434 [details]
oom-killer uvd
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 have 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? If there's an older kernel where this doesn't happen, it might be possible to bisect. 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 *** |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.