| Bug ID | 98505 |
|---|---|
| Summary | [Topaz] Regression introduces in 4.8-rc3 |
| Product | DRI |
| Version | unspecified |
| Hardware | x86-64 (AMD64) |
| OS | Linux (All) |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | DRM/AMDgpu |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | nayan26deshmukh@gmail.com |
Everything was working fine with v4.8-rc2, but with v4.8-rc3 t= he module loads successfully but when I try to use it via vdpau it results in following errors:- [ 101.129388] [drm:gfx_v8_0_ring_test_ring [amdgpu]] *ERROR* amdgpu: ring 1 test failed (scratch(0xC040)=3D0xCAFEDEAD) [ 101.340282] [drm:gfx_v8_0_ring_test_ring [amdgpu]] *ERROR* amdgpu: ring 2 test failed (scratch(0xC040)=3D0xCAFEDEAD) [ 101.551074] [drm:gfx_v8_0_ring_test_ring [amdgpu]] *ERROR* amdgpu: ring 3 test failed (scratch(0xC040)=3D0xCAFEDEAD) [ 101.761909] [drm:gfx_v8_0_ring_test_ring [amdgpu]] *ERROR* amdgpu: ring 4 test failed (scratch(0xC040)=3D0xCAFEDEAD) [ 101.972856] [drm:gfx_v8_0_ring_test_ring [amdgpu]] *ERROR* amdgpu: ring 5 test failed (scratch(0xC040)=3D0xCAFEDEAD) [ 102.183708] [drm:gfx_v8_0_ring_test_ring [amdgpu]] *ERROR* amdgpu: ring 6 test failed (scratch(0xC040)=3D0xCAFEDEAD) [ 102.394620] [drm:gfx_v8_0_ring_test_ring [amdgpu]] *ERROR* amdgpu: ring 7 test failed (scratch(0xC040)=3D0xCAFEDEAD) [ 102.605321] [drm:gfx_v8_0_ring_test_ring [amdgpu]] *ERROR* amdgpu: ring 8 test failed (scratch(0xC040)=3D0xCAFEDEAD) [ 102.709055] [drm:sdma_v2_4_ring_test_ring [amdgpu]] *ERROR* amdgpu: ring= 9 test failed (0xCAFEDEAD) [ 102.709065] [drm:amdgpu_resume [amdgpu]] *ERROR* resume of IP block <sdma_v2_4> failed -22 [ 102.709074] [drm:amdgpu_resume_kms [amdgpu]] *ERROR* amdgpu_resume failed (-22). [ 126.965536] [TTM] Buffer eviction failed
After the git bisect, the following commit was leading to erro= r:-=20 commit c39b487f195b93235ee76384427467786f7bf29f Author: Alex Deucher <a= lexander.deucher@amd.com> Date: Tue Aug 9 00:20:28 2016 -0400 Revert "drm/amdgpu: work around lack of upstream ACPI support for = D3cold" This reverts commit c63695cc5e5f685e924e25a8f9555f6e846f1fc6. Now that d3cold support is upstream, there is no more need for this workaround. bug: https://bugs.freedesktop.org/show_bug.c= gi?id=3D97248
I had a look at Peter Wu's patch that landed today on drm-fixe= s. Do we also need to have a patch like that which maybe tweaks amdgpu_atpx_handler to ma= ke it work?
| What | Removed | Added |
|---|---|---|
| CC | peter@lekensteyn.nl | |
| Status | NEW | NEEDINFO |
@Nayan To see whether the problem is similar as nouveau, I= need more information about your machine. Could you provide your acpidump? You can also submit a whole tarball as described at https://bu= gs.launchpad.net/lpbugreporter/+bug/752542, that would include the acpidump among other things.
Created attachmen=
t 127673 [details]
Dell_Inc.-Inspiron_5548.tar.gz
| What | Removed | Added |
|---|---|---|
| Status | NEEDINFO | NEW |
After I run any program which uses the AMD gpu the system will=
hang if I
perform any heavy task like starting chrome for example.=20
Please let me know if you need any more info or need to test some patches.<=
/pre>
Created attachment 127678 [details] [review] amdgpu patch that checks whether the new interface can be used for PM PCIe port PM is not enabled because this BIOS is pre-2015: 12/04/2014 The BIOS seems to be able to report support for lots of things (can you pos= t a fuller dmesg that include the supported functions?): Scope (\_SB.PCI0.GFX0) { Method (ATPX, 2, Serialized) { // ... If (Arg0 =3D=3D One) { Name (TMP2, Buffer (0x0100) { 0x00 }) CreateWordField (TMP2, Zero, F1SS) CreateDWordField (TMP2, 0x02, F1VM) CreateDWordField (TMP2, 0x06, F1FG) F1SS =3D 0x0A F1VM =3D 0x7FC0 If ((\_SB.PCI0.RP05.PXSX.SGMD & 0x0F) =3D=3D 0x02) { // ... If (\_SB.PCI0.RP05.PXSX.PXDY =3D=3D One) { F1FG |=3D 0x80 /* ATPX_DYNAMIC_PX_SUPPORTED */ F1VM |=3D 0x80 } // If (\_SB.PCI0.RP05.PXSX.FDPD =3D=3D One) { F1FG |=3D 0x0400 /* ATPX_DYNAMIC_DGPU_POWER_OFF_SUP= PORTED */ F1VM |=3D 0x0400 If (OSYS >=3D 0x07DC) { F1FG |=3D 0x0800 /* ATPX_DGPU_REQ_POWER_FOR_DIS= PLAYS */ F1VM |=3D 0x0800 } } // ... If (OSYS >=3D 0x07DD) { F1FG |=3D 0x4000 /* ATPX_MS_HYBRID_GFX_SUPPORTED */= =20 F1VM |=3D 0x4000 } amdgpu (and radeon) needs to check whether PCIe port PM is really supported. Possible patch is attached (there should probably be a pci_d3cold_disable c= all somewhere, see commit 279cf3f23870f7eb8ca071115e06d3d5ca0a2b9e for nouveau)= .
Comment on attachment 127678 [details] [review= ] amdgpu patch that checks whether the new interface can be used for PM Review of attachment 127678 [details] [review]: ----------------------------------------------------------------- ::: drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c @@ +206,5 @@ > atpx->is_hybrid =3D false; > if (valid_bits & ATPX_MS_HYBRID_GFX_SUPPORTED) { > printk("ATPX Hybrid Graphics\n"); > + /* Disable legacy PM methods only when pcie port PM is usable. */ > + atpx->functions.power_cntl =3D !amdgpu_atpx_priv->bridge_pm_u= sable; With this replaced by=20 atpx->functions.power_cntl =3D !amdgpu_atpx_priv.bridge_pm_usable; The patch fixes the issue. :)
I will also try to the master branch of kernel to see if bug 98357 is gone
(In reply to Peter Wu from comment #7) > Created attachment 127678 [details]= [review] [review] > amdgpu patch that checks whether the new interface can be used for PM >=20 > PCIe port PM is not enabled because this BIOS is pre-2015: 12/04/2014 > The BIOS seems to be able to report support for lots of things (can yo= u post > a fuller dmesg that include the supported functions?): Can we bump the bios white list to 2014? Windows enabled Hybrid graphics on windows 8.x as well as 10, and a number of preliminary win10 systems have 2= 014 bios versions. I'd prefer that to doing all of these hacks in the drivers.=
(In reply to Alex Deucher from comment #10) > (In reply to Peter Wu from comment #7) > > Created attachment 127678 [details] [review] = [review] [review] > > amdgpu patch that checks whether the new interface can be used fo= r PM > >=20 > > PCIe port PM is not enabled because this BIOS is pre-2015: 12/04/= 2014 > > The BIOS seems to be able to report support for lots of things (c= an you post > > a fuller dmesg that include the supported functions?): >=20 > Can we bump the bios white list to 2014? Windows enabled Hybrid graph= ics on > windows 8.x as well as 10, and a number of preliminary win10 systems h= ave > 2014 bios versions. I'd prefer that to doing all of these hacks in the= drivers. Lowering the minumum from 2015 to 2014 should work for nouveau: https://lists.freedesktop.org/archives/nouveau/2016-July/025619.html<= /a> You can try to ask Mika, see v4.7-rc2-3-g9d26d3a. Maybe the presence of a p= ower resource (_PR3 or flags.power_resources) can be used as a hint whether to enable port PM.
(In reply to Peter Wu from comment #11) > (In reply to Alex Deucher from comment #10) > > (In reply to Peter Wu from comment #7) > > > Created attachment 127678 [details] [review]= [review] [review] [review] > > > amdgpu patch that checks whether the new interface can be us= ed for PM > > >=20 > > > PCIe port PM is not enabled because this BIOS is pre-2015: 1= 2/04/2014 > > > The BIOS seems to be able to report support for lots of thin= gs (can you post > > > a fuller dmesg that include the supported functions?): > >=20 > > Can we bump the bios white list to 2014? Windows enabled Hybrid = graphics on > > windows 8.x as well as 10, and a number of preliminary win10 syst= ems have > > 2014 bios versions. I'd prefer that to doing all of these hacks i= n the drivers. >=20 > Lowering the minumum from 2015 to 2014 should work for nouveau: > https://lists.freedesktop.org/archives/nouveau/2016-July/025619.= html > For further clarify on your research, the current hybrid graphics spec requ= ires no connectors on the dGPU and hence no audio devices. For devices with connectors on the dGPU, they should use the older vendor specific methods a= nd PR# should not be exposed. > You can try to ask Mika, see v4.7-rc2-3-g9d26d3a= . Maybe the presence of a > power resource (_PR3 or flags.power_resources) can be used as a hint w= hether > to enable port PM. Yes, the presence of _PR3 would be a great way to determine when to enable = it.
(In reply to Alex Deucher from comment #12) > methods and PR# should not be exposed. PR3
(In reply to Alex Deucher from comment #12) [..] > > Lowering the minumum from 2015 to 2014 shou= ld work for nouveau: > > https://lists.freedesktop.org/archives/nouveau/2016-July/02= 5619.html > >=20 >=20 > For further clarify on your research, the current hybrid graphics spec > requires no connectors on the dGPU and hence no audio devices. For de= vices > with connectors on the dGPU, they should use the older vendor specific > methods and PR3 should not be exposed. The list was mentioned because of the BIOS dates and whether _PR3 is used. The Windows 8 requirements state that the discrete GPU is render-only[0], b= ut the Win10 reqs have no such requirement[1]. (Are these the same specs you h= ad in mind? If not, could you share the right one?) On my new hybrid nvidia laptop, there are actually DP/HDMI ports to the dGPU (HDMI with audio). [0]: https://msdn.microsoft.com/en-us/library/windows/hardwa= re/dn265510(v=3Dvs.85).aspx [1]: https://msdn.microsoft.com/en-us/windows/hardware/commercialize/design/= compatibility/systems#systemfundamentalsgraphicshybridgraphicsmultigpu > > You can try to ask Mika, see v4.7-rc2-3-g9d= 26d3a. Maybe the presence of a > > power resource (_PR3 or flags.power_resources) can be used as a h= int whether > > to enable port PM. >=20 > Yes, the presence of _PR3 would be a great way to determine when to en= able > it. Have you been working on this or should I have a look?
(In reply to Peter Wu from comment #14) > (In reply to Alex Deucher from comment #12) > [..] > > > Lowering the minumum from 2015 to 2014 should work for nouve= au: > > > https://lists.freedesktop.org/archives/nouveau/2016-Ju= ly/025619.html > > >=20 > >=20 > > For further clarify on your research, the current hybrid graphics= spec > > requires no connectors on the dGPU and hence no audio devices. F= or devices > > with connectors on the dGPU, they should use the older vendor spe= cific > > methods and PR3 should not be exposed. >=20 > The list was mentioned because of the BIOS dates and whether _PR3 is u= sed. >=20 > The Windows 8 requirements state that the discrete GPU is render-only[= 0], > but the Win10 reqs have no such requirement[1]. (Are these the same sp= ecs > you had in mind? If not, could you share the right one?) On my new hyb= rid > nvidia laptop, there are actually DP/HDMI ports to the dGPU (HDMI with > audio). > I had access to the PR3 spec internally. I'm not sure if it's available publicly or not. Support for displays was not included in the information I saw or from talking with our internal hybrid graphics architects. It's possible the spec has been updated since I last talked to them earlier this year. I can double check. Does your new laptop use PR3 or the older nvidia proprietary ACPI method? > [0]: > https://msdn.microsoft.com/en-us/library/windows/hardwar= e/dn265510(v=3Dvs.85). > aspx > [1]: > https://msdn.microsoft.com/en-us/windows/hardware/commerciali= ze/design/ > compatibility/systems#systemfundamentalsgraphicshybridgraphicsmultigpu >=20 > > > You can try to ask Mika, see v4.7-rc2-3-g9d26d3a. Maybe the = presence of a > > > power resource (_PR3 or flags.power_resources) can be used a= s a hint whether > > > to enable port PM. > >=20 > > Yes, the presence of _PR3 would be a great way to determine when = to enable > > it. >=20 > Have you been working on this or should I have a look? I have not been. Please have a look. Thanks!
(In reply to Alex Deucher from comment #15) > (In reply to Peter Wu from comment #14) [..] > > The Windows 8 requirements state that the d= iscrete GPU is render-only[0], > > but the Win10 reqs have no such requirement[1]. (Are these the sa= me specs > > you had in mind? If not, could you share the right one?) On my ne= w hybrid > > nvidia laptop, there are actually DP/HDMI ports to the dGPU (HDMI= with > > audio). >=20 > I had access to the PR3 spec internally. I'm not sure if it's availab= le > publicly or not. Support for displays was not included in the informa= tion I > saw or from talking with our internal hybrid graphics architects. It's > possible the spec has been updated since I last talked to them earlier= this > year. I can double check. >=20 > Does your new laptop use PR3 or the older nvidia proprietary ACPI meth= od? The laptop (Clevo P651RA) uses PR3 (confirmed via a Windows 10 trace): https://github.com/Bumblebee-Project/bbswitch/issues/115#i= ssuecomment-218622306 > > Have you been working on this or should I h= ave a look? >=20 > I have not been. Please have a look. Thanks! Ok, do you have any certainty about the earliest BIOS date where _PR3 is us= ed? E.g. if the minimum date is lowered to 2014 without checking for _PR3, woul= d it be likely to miss out some models?
(In reply to Peter Wu from comment #16) > Ok, do you have any certainty about the earliest= BIOS date where _PR3 is > used? E.g. if the minimum date is lowered to 2014 without checking for= _PR3, > would it be likely to miss out some models? It's always used if it's available. I think 2014 should be ok (should catch most of the early ones), but I'll check with our windows architects. I sus= pect it will come down to OEM/ODMs.
| What | Removed | Added |
|---|---|---|
| CC | pavel.ondracka@email.cz |
*** Bug 98687 has been marked as a dupl= icate of this bug. ***
| What | Removed | Added |
|---|---|---|
| Summary | [Topaz] Regression introduces in 4.8-rc3 | [radeon, amdgpu] Regression introduced in 4.8-rc3 |
(In reply to Peter Wu from comment #16) > Ok, do you have any certainty about the earliest= BIOS date where _PR3 is > used? E.g. if the minimum date is lowered to 2014 without checking for= _PR3, > would it be likely to miss out some models? Can you add me to any relevant threads? I'd like to help get this fixed for 4.9.
(In reply to Alex Deucher from comment #19) > (In reply to Peter Wu from comment #16) > > Ok, do you have any certainty about the earliest BIOS date where = _PR3 is > > used? E.g. if the minimum date is lowered to 2014 without checkin= g for _PR3, > > would it be likely to miss out some models? >=20 > Can you add me to any relevant threads? I'd like to help get this fix= ed for > 4.9. I will, but did you get any feedback from the Windows architects yet? I'd l= ike to get some solid reasons that support lowering the version requirement.