| Bug ID | 85207 |
|---|---|
| Summary | agd5f drm-next-3.19-wip + Unreal Elemental sometimes = list_add corruption/hung task |
| Product | DRI |
| Version | XOrg CVS |
| Hardware | Other |
| OS | All |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | DRM/Radeon |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | adf.lists@gmail.com |
Created attachment 108075 [details]
dmesg when Unreal Elemental hangs on start
R9270X Sometime running unreal elemental demo it hangs at startup with errors
in dmesg attached.
This doesn't always happen.
Mesa is currently on winsys/radeon: Use a single buffer cache manager again,
previously produced with slightly older.
Haven't seen on drm-next-3.18-wip (but really need to test more with current
mesa)
Possibly unrelated, but new for drm-next-3.19-wip I get below when running
Unigine Valley - it runs OK.
Oct 17 11:15:35 ph4 kernel: radeon 0000:01:00.0: GPU fault detected: 146
0x0af03504
Oct 17 11:15:35 ph4 kernel: radeon 0000:01:00.0:
VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00010E57
Oct 17 11:15:35 ph4 kernel: radeon 0000:01:00.0:
VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x10035004
Oct 17 11:15:35 ph4 kernel: VM fault (0x04, vmid 8) at page 69207, read from
VGT (53)
Also noticed in that dmesg and searching kern log that I sometimes get apparently without effect - kernel: [drm:radeon_gem_va_update_vm] *ERROR* Couldn't update BO_VA (-512) With this kernel.
(In reply to Andy Furniss from comment #0) > Haven't seen on drm-next-3.18-wip Can you bisect the kernel?
(In reply to Michel D=C3=A4nzer from comment #2) > (In reply to Andy Furniss from comment #0) > > Haven't seen on drm-next-3.18-wip >=20 > Can you bisect the kernel? May be a bit early, but I will sit on the one before for a while to confirm. Looks like the head commit - commit bb9a49819ed30f3f5782b2504066547a8507a591 Author: Christian K=C3=B6nig <christian.koenig@amd.com> Date: Mon Oct 13 12:41:47 2014 +0200 drm/radeon: update the VM after setting BO address This way the necessary VM update is kicked off immediately if all BOs involved are in GPU accessible memory. I haven't managed to lock or get Valley to GPU fault on the one before so f= ar. FWIW I noticed even on head the valley fault doesn't always happen - it see= ms that I need to have set my CPUs to perf (which I nearly always do when test= ing things like this). With cpufreq ondemand I didn't see the fault.
| What | Removed | Added |
|---|---|---|
| CC | deathsimple@vodafone.de |
Created attachment 108165 = [details] [review] Possible fix Ups! Forgotten to take the VM lock in radeon_gem_va_update_vm. Fix is attac= hed. Thanks for testing, Christian.
(In reply to Christian K=C3=B6nig from comment #4) > Created attachment 10= 8165 [details] [review] [review] > Possible fix >=20 > Ups! Forgotten to take the VM lock in radeon_gem_va_update_vm. Fix is > attached. >=20 > Thanks for testing, > Christian. I don't know about Elemental as it's far harder to trigger, but first try w= ith valley produced - [ 156.617954] radeon 0000:01:00.0: GPU fault detected: 146 0x02e83504 [ 156.617960] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR=20= =20 0x00010F17 [ 156.617961] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x08035004 [ 156.617963] VM fault (0x04, vmid 4) at page 69399, read from VGT (53)
(In reply to Andy Furniss from comment #5) > I don't know about Elemental as it's far harder = to trigger, but first try > with valley produced - >=20 > [ 156.617954] radeon 0000:01:00.0: GPU fault detected: 146 0x02e83504 > [ 156.617960] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADD= R=20=20 > 0x00010F17 > [ 156.617961] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STA= TUS > 0x08035004 > [ 156.617963] VM fault (0x04, vmid 4) at page 69399, read from VGT (5= 3) Sounds like a different problem triggered by the same patchset to me. But first things first, is the original issue with the list corruption fixe= d? If yes we can start to look into this one as well.
(In reply to Christian K=C3=B6nig from comment #6) > (In reply to Andy Furniss from comment #5) > > I don't know about Elemental as it's far harder to trigger, but f= irst try > > with valley produced - > >=20 > > [ 156.617954] radeon 0000:01:00.0: GPU fault detected: 146 0x02e= 83504 > > [ 156.617960] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAUL= T_ADDR=20=20 > > 0x00010F17 > > [ 156.617961] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAUL= T_STATUS > > 0x08035004 > > [ 156.617963] VM fault (0x04, vmid 4) at page 69399, read from V= GT (53) >=20 > Sounds like a different problem triggered by the same patchset to me. >=20 > But first things first, is the original issue with the list corruption > fixed? If yes we can start to look into this one as well. It's OK so far, but then I need more time as I don't really know how to tri= gger it and last time I called it as OK (in another bug) it wasn't.
(In reply to Andy Furniss from comment #7) > (In reply to Christian K=C3=B6nig from comment #6) > > (In reply to Andy Furniss from comment #5) > > > I don't know about Elemental as it's far harder to trigger, = but first try > > > with valley produced - > > >=20 > > > [ 156.617954] radeon 0000:01:00.0: GPU fault detected: 146 = 0x02e83504 > > > [ 156.617960] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION= _FAULT_ADDR=20=20 > > > 0x00010F17 > > > [ 156.617961] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION= _FAULT_STATUS > > > 0x08035004 > > > [ 156.617963] VM fault (0x04, vmid 4) at page 69399, read f= rom VGT (53) > >=20 > > Sounds like a different problem triggered by the same patchset to= me. > >=20 > > But first things first, is the original issue with the list corru= ption > > fixed? If yes we can start to look into this one as well. >=20 > It's OK so far, but then I need more time as I don't really know how to > trigger it and last time I called it as OK (in another bug) it wasn't.= Still haven't crashed Elemental but have got - [29066.333908] [drm:radeon_gem_va_update_vm] *ERROR* Couldn't update BO_VA (-512) [29066.335653] [drm:radeon_gem_va_update_vm] *ERROR* Couldn't update BO_VA (-512)
(In reply to Christian K=C3=B6nig from comment #6) > But first things first, is the original issue wi= th the list corruption > fixed? If yes we can start to look into this one as well. Enough time has passed now, so I do think that the patch fixed the list corruption.
I found same issues here. [ 1384.901951] [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-512) [ 1453.198866] [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-512) [ 2215.773607] [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-512) [ 2351.238014] [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-512) [ 3877.903397] [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-512) Self compiled kernel from Linus git. 3.19-rc2+ right now.
(In reply to Lorenzo Bona from comment #10) >=20 > [ 1384.901951] [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't upd= ate > BO_VA (-512) Christian, any ideas for these? Various people including myself are still hitting them occasionally.
Created attac= hment 111961 [details] [revi= ew] Fix for printing the error message
(In reply to Michel D=C3=A4nzer from comment #11) > (In reply to Lorenzo Bona from comment #10) > >=20 > > [ 1384.901951] [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn'= t update > > BO_VA (-512) >=20 > Christian, any ideas for these? Various people including myself are st= ill > hitting them occasionally. Ups, yeah trivial to fix.
| What | Removed | Added |
|---|---|---|
| Status | NEW | RESOLVED |
| Resolution | --- | FIXED |
| What | Removed | Added |
|---|---|---|
| CC | commiethebeastie@gmail.com |
*** Bug 88211 has been marked as a dupl= icate of this bug. ***
| What | Removed | Added |
|---|---|---|
| Status | RESOLVED | CLOSED |