There seem to be stability issues on a number of cards.
bugs: https://bugs.freedesktop.org/show_bug.cgi?id=76286 https://bugzilla.redhat.com/show_bug.cgi?id=1085785 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741619
Signed-off-by: Alex Deucher alexander.deucher@amd.com Cc: matthias.graf@st.ovqu.de Cc: bp@alien8.de Cc: stable@vger.kernel.org --- drivers/gpu/drm/radeon/radeon_pm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c b/drivers/gpu/drm/radeon/radeon_pm.c index ee738a5..0c4473d 100644 --- a/drivers/gpu/drm/radeon/radeon_pm.c +++ b/drivers/gpu/drm/radeon/radeon_pm.c @@ -1257,6 +1257,7 @@ int radeon_pm_init(struct radeon_device *rdev) case CHIP_RV670: case CHIP_RS780: case CHIP_RS880: + case CHIP_RV770: case CHIP_BARTS: case CHIP_TURKS: case CHIP_CAICOS: @@ -1273,7 +1274,6 @@ int radeon_pm_init(struct radeon_device *rdev) else rdev->pm.pm_method = PM_METHOD_PROFILE; break; - case CHIP_RV770: case CHIP_RV730: case CHIP_RV710: case CHIP_RV740:
Am 18.04.2014 15:08, schrieb Alex Deucher:
There seem to be stability issues on a number of cards.
bugs: https://bugs.freedesktop.org/show_bug.cgi?id=76286 https://bugzilla.redhat.com/show_bug.cgi?id=1085785 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741619
Signed-off-by: Alex Deucher alexander.deucher@amd.com Cc: matthias.graf@st.ovqu.de Cc: bp@alien8.de Cc: stable@vger.kernel.org
Added to my 3.15 queue.
Christian.
drivers/gpu/drm/radeon/radeon_pm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c b/drivers/gpu/drm/radeon/radeon_pm.c index ee738a5..0c4473d 100644 --- a/drivers/gpu/drm/radeon/radeon_pm.c +++ b/drivers/gpu/drm/radeon/radeon_pm.c @@ -1257,6 +1257,7 @@ int radeon_pm_init(struct radeon_device *rdev) case CHIP_RV670: case CHIP_RS780: case CHIP_RS880:
- case CHIP_RV770: case CHIP_BARTS: case CHIP_TURKS: case CHIP_CAICOS:
@@ -1273,7 +1274,6 @@ int radeon_pm_init(struct radeon_device *rdev) else rdev->pm.pm_method = PM_METHOD_PROFILE; break;
- case CHIP_RV770: case CHIP_RV730: case CHIP_RV710: case CHIP_RV740:
Alex Deucher wrote:
There seem to be stability issues on a number of cards.
bugs: https://bugs.freedesktop.org/show_bug.cgi?id=76286 https://bugzilla.redhat.com/show_bug.cgi?id=1085785 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741619
Well TBH I don't know whether the following is useful info or not - it could just be an unrelated waste of your time.
I have run my 4890 with dpm=1 from when it first appeared without issue till recently.
As in the bug above I can't now use two screens - but the thing is, I use a (getting old) LFS, I don't use the TV that much, but when I noticed the issue I tried to bisect and I reached the commit after my working start point.
It turned out that my working was the last kernel I compiled with GCC 4.6.3. I had upgraded to GCC 4.8.2 and no kernel built with that can handle 2 screens without locking, no sysrq, no network but very rarely may unlock for a short while (did a dmesg when this happened, nothing unusual logged then it locked again).
I built my GCC 4.6.3 again and built the same recent kernel (I run drm next or fixes) and I have so far not been able to lock it with 2 screens.
Of course it could just be something on my LFS is too old for recent GCC, or because I don't use TV much I am being lucky with 4.6.3.
I will when I get time build 4.8.2 again and see if dpm=0 works for me.
On Sat, Apr 19, 2014 at 2:02 PM, Andy Furniss adf.lists@gmail.com wrote:
Alex Deucher wrote:
There seem to be stability issues on a number of cards.
bugs: https://bugs.freedesktop.org/show_bug.cgi?id=76286 https://bugzilla.redhat.com/show_bug.cgi?id=1085785 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741619
Well TBH I don't know whether the following is useful info or not - it could just be an unrelated waste of your time.
I have run my 4890 with dpm=1 from when it first appeared without issue till recently.
As in the bug above I can't now use two screens - but the thing is, I use a (getting old) LFS, I don't use the TV that much, but when I noticed the issue I tried to bisect and I reached the commit after my working start point.
It turned out that my working was the last kernel I compiled with GCC 4.6.3. I had upgraded to GCC 4.8.2 and no kernel built with that can handle 2 screens without locking, no sysrq, no network but very rarely may unlock for a short while (did a dmesg when this happened, nothing unusual logged then it locked again).
I built my GCC 4.6.3 again and built the same recent kernel (I run drm next or fixes) and I have so far not been able to lock it with 2 screens.
Of course it could just be something on my LFS is too old for recent GCC, or because I don't use TV much I am being lucky with 4.6.3.
I will when I get time build 4.8.2 again and see if dpm=0 works for me.
I ran into similar issues right after dpm support was released. I'd done most of my development on gcc 4.6 and everything worked fine and upon upgrading to 4.7 or 4.8, tons of stuff broke. It ended up at least partially being related to indexing variable sized arrays: 48fa04c3fcdb4f6ac041976bedaf19ca5bee20c0 f90555cbe629e14c6af1dcec1933a3833ecd321f 607f2c2791ec81e5abca6213ff037e9405378be1 a7ee824a6255e347ea76e2f00827e81bbe01004e plus some others, but there may still be problematic cases.
Alex
Alex Deucher wrote:
I ran into similar issues right after dpm support was released. I'd done most of my development on gcc 4.6 and everything worked fine and upon upgrading to 4.7 or 4.8, tons of stuff broke. It ended up at least partially being related to indexing variable sized arrays: 48fa04c3fcdb4f6ac041976bedaf19ca5bee20c0 f90555cbe629e14c6af1dcec1933a3833ecd321f 607f2c2791ec81e5abca6213ff037e9405378be1 a7ee824a6255e347ea76e2f00827e81bbe01004e plus some others, but there may still be problematic cases.
Ahh, thanks for that, at least I know now there's no point in me building a whole new LFS.
dri-devel@lists.freedesktop.org
-
Alex Deucher -
Andy Furniss -
Christian König