Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Tue, Jan 15, 2013 at 7:19 AM, Borislav Petkov wrote:
> On Fri, Jan 11, 2013 at 12:43:36PM +0100, Borislav Petkov wrote:
>> Ok, I'm running -rc3 with this and will watch it for any changes in
>> behavior.
>
> AFAICT, this fixes the CP stalls, for I haven't seen any of them in
> dmesg for the last couple of days after applying your revert.
Can you remove that revert and try the attached patch as an alternative?
Thanks,
Alex
>
> Thanks.
>
> --
> Regards/Gruss,
> Boris.
>
> Sent from a fat crate under my desk. Formatting is fine.
> --
From cb5206aa1c6c52b1b459eaf93797c593cff0c8db Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Mon, 14 Jan 2013 11:04:39 -0500
Subject: [PATCH] drm/radeon: clear reset flags if engines are idle
Fixes a regression in the gpu reset code after the
rework for DMA support.
Reported-by: Eldad Zack
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/evergreen.c |6 ++
drivers/gpu/drm/radeon/ni.c|6 ++
drivers/gpu/drm/radeon/r600.c |6 ++
drivers/gpu/drm/radeon/si.c|6 ++
4 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c b/drivers/gpu/drm/radeon/evergreen.c
index 061fa0a..4d0e60a 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -2401,6 +2401,12 @@ static int evergreen_gpu_soft_reset(struct radeon_device *rdev, u32 reset_mask)
{
struct evergreen_mc_save save;
+ if (!(RREG32(GRBM_STATUS) & GUI_ACTIVE))
+ reset_mask &= ~(RADEON_RESET_GFX | RADEON_RESET_COMPUTE);
+
+ if (RREG32(DMA_STATUS_REG) & DMA_IDLE)
+ reset_mask &= ~RADEON_RESET_DMA;
+
if (reset_mask == 0)
return 0;
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 896f1cb..59acabb 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1409,6 +1409,12 @@ static int cayman_gpu_soft_reset(struct radeon_device *rdev, u32 reset_mask)
{
struct evergreen_mc_save save;
+ if (!(RREG32(GRBM_STATUS) & GUI_ACTIVE))
+ reset_mask &= ~(RADEON_RESET_GFX | RADEON_RESET_COMPUTE);
+
+ if (RREG32(DMA_STATUS_REG) & DMA_IDLE)
+ reset_mask &= ~RADEON_RESET_DMA;
+
if (reset_mask == 0)
return 0;
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 537e259..3cb9d60 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -1378,6 +1378,12 @@ static int r600_gpu_soft_reset(struct radeon_device *rdev, u32 reset_mask)
{
struct rv515_mc_save save;
+ if (!(RREG32(GRBM_STATUS) & GUI_ACTIVE))
+ reset_mask &= ~(RADEON_RESET_GFX | RADEON_RESET_COMPUTE);
+
+ if (RREG32(DMA_STATUS_REG) & DMA_IDLE)
+ reset_mask &= ~RADEON_RESET_DMA;
+
if (reset_mask == 0)
return 0;
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index 3240a3d..ae8b482 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -2215,6 +2215,12 @@ static int si_gpu_soft_reset(struct radeon_device *rdev, u32 reset_mask)
{
struct evergreen_mc_save save;
+ if (!(RREG32(GRBM_STATUS) & GUI_ACTIVE))
+ reset_mask &= ~(RADEON_RESET_GFX | RADEON_RESET_COMPUTE);
+
+ if (RREG32(DMA_STATUS_REG) & DMA_IDLE)
+ reset_mask &= ~RADEON_RESET_DMA;
+
if (reset_mask == 0)
return 0;
--
1.7.7.5
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Fri, Jan 11, 2013 at 12:43:36PM +0100, Borislav Petkov wrote: > Ok, I'm running -rc3 with this and will watch it for any changes in > behavior. AFAICT, this fixes the CP stalls, for I haven't seen any of them in dmesg for the last couple of days after applying your revert. Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Thu, Jan 10, 2013 at 03:47:01PM -0500, Alex Deucher wrote: > >> Does disabling the new DMA ring for ttm bo moves avoid the issue? > > > > How do I do that? > > diff --git a/drivers/gpu/drm/radeon/radeon_asic.c > b/drivers/gpu/drm/radeon/radeon_asic.c > index 9056faf..b0cc46d 100644 [ … ] Ok, I'm running -rc3 with this and will watch it for any changes in behavior. Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Thu, Jan 10, 2013 at 3:32 PM, Borislav Petkov wrote:
> On Thu, Jan 10, 2013 at 11:21:21AM -0500, Alex Deucher wrote:
>> I'm assuming you didn't also update your userspace gfx stack?
>
> By that you mean x.org etc, right? Or GPU microcode too? In any case, I
> haven't touched any of those deliberately, AFAICR at least.
Right. Xorg drivers or mesa drivers.
>
>> Does disabling the new DMA ring for ttm bo moves avoid the issue?
>
> How do I do that?
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
b/drivers/gpu/drm/radeon/radeon_asic.c
index 9056faf..b0cc46d 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -974,8 +974,8 @@ static struct radeon_asic r600_asic = {
.blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
.dma = &r600_copy_dma,
.dma_ring_index = R600_RING_TYPE_DMA_INDEX,
- .copy = &r600_copy_dma,
- .copy_ring_index = R600_RING_TYPE_DMA_INDEX,
+ .copy = &r600_copy_blit,
+ .copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
},
.surface = {
.set_reg = r600_set_surface_reg,
@@ -1058,8 +1058,8 @@ static struct radeon_asic rs780_asic = {
.blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
.dma = &r600_copy_dma,
.dma_ring_index = R600_RING_TYPE_DMA_INDEX,
- .copy = &r600_copy_dma,
- .copy_ring_index = R600_RING_TYPE_DMA_INDEX,
+ .copy = &r600_copy_blit,
+ .copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
},
.surface = {
.set_reg = r600_set_surface_reg,
>
> Thanks.
>
> --
> Regards/Gruss,
> Boris.
>
> Sent from a fat crate under my desk. Formatting is fine.
> --
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Thu, Jan 10, 2013 at 11:21:21AM -0500, Alex Deucher wrote: > I'm assuming you didn't also update your userspace gfx stack? By that you mean x.org etc, right? Or GPU microcode too? In any case, I haven't touched any of those deliberately, AFAICR at least. > Does disabling the new DMA ring for ttm bo moves avoid the issue? How do I do that? Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Thu, Jan 10, 2013 at 4:38 AM, Borislav Petkov wrote: > [ deliberately breaking the thread because it got too long] > > On Sat, Dec 22, 2012 at 09:35:47PM +0100, Borislav Petkov wrote: >> Hi Alex, >> >> got the sickest bug on 3.8-rc1, see below. The GPU locks up somewhere >> down radeon_fence_wait_seq, judging by the error messages. >> >> And this doesn't happen with 3.7, of course. >> >> Let me know if you need any more info, thanks. >> >> [16273.668350] radeon :02:00.0: GPU lockup CP stall for more than >> 1msec >> [16273.668361] radeon :02:00.0: GPU lockup (waiting for >> 0x002b last fence id 0x002a) >> [16273.882550] plugin-containe[11435]: segfault at 7f1f0a66cc08 ip >> 7f1f13289bdb sp 7f1f0a2fe9e0 error 4 in >> libflashplayer.so[7f1f130c5000+117b000] >> [16274.502807] [ cut here ] >> [16274.502845] WARNING: at lib/list_debug.c:53 __list_del_entry+0x63/0xd0() > > Ok, this got fixed by 909d9eb67f1e4e39f2ea88e96bde03d560cde3eb which is > upstream now. And I'm testing -rc2+ which contains this patch already > + tip/master + another fix from Alan which reworks fb console locking > (should be unrelated) and the machine gets unresponsive for a couple of > seconds and then it is fine again. > > See dmesg below, the GPU gets the same lockup CP stall without the list > corruption so it recovers fine. But I didn't have those stalls before so > it has to be something which came up with 3.8 merge window. I'm assuming you didn't also update your userspace gfx stack? Does disabling the new DMA ring for ttm bo moves avoid the issue? Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
[ deliberately breaking the thread because it got too long] On Sat, Dec 22, 2012 at 09:35:47PM +0100, Borislav Petkov wrote: > Hi Alex, > > got the sickest bug on 3.8-rc1, see below. The GPU locks up somewhere > down radeon_fence_wait_seq, judging by the error messages. > > And this doesn't happen with 3.7, of course. > > Let me know if you need any more info, thanks. > > [16273.668350] radeon :02:00.0: GPU lockup CP stall for more than > 1msec > [16273.668361] radeon :02:00.0: GPU lockup (waiting for > 0x002b last fence id 0x002a) > [16273.882550] plugin-containe[11435]: segfault at 7f1f0a66cc08 ip > 7f1f13289bdb sp 7f1f0a2fe9e0 error 4 in > libflashplayer.so[7f1f130c5000+117b000] > [16274.502807] [ cut here ] > [16274.502845] WARNING: at lib/list_debug.c:53 __list_del_entry+0x63/0xd0() Ok, this got fixed by 909d9eb67f1e4e39f2ea88e96bde03d560cde3eb which is upstream now. And I'm testing -rc2+ which contains this patch already + tip/master + another fix from Alan which reworks fb console locking (should be unrelated) and the machine gets unresponsive for a couple of seconds and then it is fine again. See dmesg below, the GPU gets the same lockup CP stall without the list corruption so it recovers fine. But I didn't have those stalls before so it has to be something which came up with 3.8 merge window. [44730.749380] radeon :02:00.0: GPU lockup CP stall for more than 1msec [44730.749391] radeon :02:00.0: GPU lockup (waiting for 0x00305211 last fence id 0x00305210) [44730.750596] radeon :02:00.0: Saved 25 dwords of commands on ring 0. [44730.750612] radeon :02:00.0: GPU softreset: 0x0007 [44730.768865] radeon :02:00.0: R_008010_GRBM_STATUS = 0xA0003030 [44730.768874] radeon :02:00.0: R_008014_GRBM_STATUS2 = 0x0003 [44730.768880] radeon :02:00.0: R_000E50_SRBM_STATUS = 0x20C0 [44730.768885] radeon :02:00.0: R_008674_CP_STALLED_STAT1 = 0x [44730.768889] radeon :02:00.0: R_008678_CP_STALLED_STAT2 = 0x [44730.768894] radeon :02:00.0: R_00867C_CP_BUSY_STAT = 0x00020184 [44730.768898] radeon :02:00.0: R_008680_CP_STAT = 0x80028645 [44730.768903] radeon :02:00.0: R_008020_GRBM_SOFT_RESET=0x7FEE [44730.783898] radeon :02:00.0: R_008020_GRBM_SOFT_RESET=0x0001 [44730.798893] radeon :02:00.0: R_008010_GRBM_STATUS = 0xA0003030 [44730.798896] radeon :02:00.0: R_008014_GRBM_STATUS2 = 0x0003 [44730.798899] radeon :02:00.0: R_000E50_SRBM_STATUS = 0x200080C0 [44730.798901] radeon :02:00.0: R_008674_CP_STALLED_STAT1 = 0x [44730.798904] radeon :02:00.0: R_008678_CP_STALLED_STAT2 = 0x [44730.798907] radeon :02:00.0: R_00867C_CP_BUSY_STAT = 0x [44730.798909] radeon :02:00.0: R_008680_CP_STAT = 0x8010 [44730.819926] radeon :02:00.0: GPU reset succeeded, trying to resume [44730.836763] [drm] probing gen 2 caps for device 10de:377 = 1/0 [44730.839732] [drm] PCIE GART of 512M enabled (table at 0x0004). [44730.839826] radeon :02:00.0: WB enabled [44730.839831] radeon :02:00.0: fence driver on ring 0 use gpu addr 0x2c00 and cpu addr 0x880220223c00 [44730.839834] radeon :02:00.0: fence driver on ring 3 use gpu addr 0x2c0c and cpu addr 0x880220223c0c [44730.871080] [drm] ring test on 0 succeeded in 0 usecs [44730.871140] [drm] ring test on 3 succeeded in 1 usecs [44730.871187] [drm] ib test on ring 0 succeeded in 0 usecs [44730.871206] [drm] ib test on ring 3 succeeded in 1 usecs Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Fri, Jan 4, 2013 at 6:16 AM, Boszormenyi Zoltan wrote:
> 2013-01-04 08:40 keltezéssel, Borislav Petkov írta:
>
>> On Wed, Jan 02, 2013 at 06:37:23PM -0500, Alex Deucher wrote:
>>>
>>> From: Alex Deucher
>>> Date: Wed, 2 Jan 2013 18:30:21 -0500
>>> Subject: [PATCH] drm/radeon/r6xx: fix DMA engine for ttm bo transfers
>>>
>>> count must be a multiple of 2.
>>>
>>> Cc: Borislav Petkov
>>> Cc: Markus Trippelsdorf
>>> Signed-off-by: Alex Deucher
>>
>> Thanks, will run it on the box in question next week when I have access.
>>
>> Btw, you could add the note about count needing to be a multiple of 2 as
>> a comment in the code below, for future reference.
>>
>>> ---
>>> drivers/gpu/drm/radeon/r600.c |4 ++--
>>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/radeon/r600.c
>>> b/drivers/gpu/drm/radeon/r600.c
>>> index 2aaf147..9f4ce5e 100644
>>> --- a/drivers/gpu/drm/radeon/r600.c
>>> +++ b/drivers/gpu/drm/radeon/r600.c
>>> @@ -2636,8 +2636,8 @@ int r600_copy_dma(struct radeon_device *rdev,
>>> for (i = 0; i < num_loops; i++) {
>>> cur_size_in_dw = size_in_dw;
>>> - if (cur_size_in_dw > 0x)
>>> - cur_size_in_dw = 0x;
>>> + if (cur_size_in_dw > 0xFFFE)
>>> + cur_size_in_dw = 0xFFFE;
>
>
> How about any other odd numbers? Like 0xFFFB, or 0x0003?
> They will get passed as is after this change, no? Shouldn't they
> be also fixed? Something like this below?
>
> if (cur_size_in_dw & 0x0001)
>cur_size_in_dw &= ~1;
This function only deals with pages so they will always be even.
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
2013-01-04 08:40 keltezéssel, Borislav Petkov írta:
On Wed, Jan 02, 2013 at 06:37:23PM -0500, Alex Deucher wrote:
From: Alex Deucher
Date: Wed, 2 Jan 2013 18:30:21 -0500
Subject: [PATCH] drm/radeon/r6xx: fix DMA engine for ttm bo transfers
count must be a multiple of 2.
Cc: Borislav Petkov
Cc: Markus Trippelsdorf
Signed-off-by: Alex Deucher
Thanks, will run it on the box in question next week when I have access.
Btw, you could add the note about count needing to be a multiple of 2 as
a comment in the code below, for future reference.
---
drivers/gpu/drm/radeon/r600.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 2aaf147..9f4ce5e 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -2636,8 +2636,8 @@ int r600_copy_dma(struct radeon_device *rdev,
for (i = 0; i < num_loops; i++) {
cur_size_in_dw = size_in_dw;
- if (cur_size_in_dw > 0x)
- cur_size_in_dw = 0x;
+ if (cur_size_in_dw > 0xFFFE)
+ cur_size_in_dw = 0xFFFE;
How about any other odd numbers? Like 0xFFFB, or 0x0003?
They will get passed as is after this change, no? Shouldn't they
be also fixed? Something like this below?
if (cur_size_in_dw & 0x0001)
cur_size_in_dw &= ~1;
size_in_dw -= cur_size_in_dw;
radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_COPY, 0, 0,
cur_size_in_dw));
radeon_ring_write(ring, dst_offset & 0xfffc);
--
1.7.7.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Wed, Jan 02, 2013 at 06:37:23PM -0500, Alex Deucher wrote:
> From: Alex Deucher
> Date: Wed, 2 Jan 2013 18:30:21 -0500
> Subject: [PATCH] drm/radeon/r6xx: fix DMA engine for ttm bo transfers
>
> count must be a multiple of 2.
>
> Cc: Borislav Petkov
> Cc: Markus Trippelsdorf
> Signed-off-by: Alex Deucher
Thanks, will run it on the box in question next week when I have access.
Btw, you could add the note about count needing to be a multiple of 2 as
a comment in the code below, for future reference.
> ---
> drivers/gpu/drm/radeon/r600.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
> index 2aaf147..9f4ce5e 100644
> --- a/drivers/gpu/drm/radeon/r600.c
> +++ b/drivers/gpu/drm/radeon/r600.c
> @@ -2636,8 +2636,8 @@ int r600_copy_dma(struct radeon_device *rdev,
>
> for (i = 0; i < num_loops; i++) {
> cur_size_in_dw = size_in_dw;
> - if (cur_size_in_dw > 0x)
> - cur_size_in_dw = 0x;
> + if (cur_size_in_dw > 0xFFFE)
> + cur_size_in_dw = 0xFFFE;
> size_in_dw -= cur_size_in_dw;
> radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_COPY, 0, 0,
> cur_size_in_dw));
> radeon_ring_write(ring, dst_offset & 0xfffc);
> --
> 1.7.7.5
--
Regards/Gruss,
Boris.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Thu, Jan 3, 2013 at 7:12 AM, Deucher, Alexander wrote: >> -Original Message- >> From: Boszormenyi Zoltan [mailto:zbos...@pr.hu] >> Sent: Thursday, January 03, 2013 6:37 AM >> To: Alex Deucher >> Cc: Markus Trippelsdorf; lkml; dri-de...@lists.freedesktop.org; Deucher, >> Alexander; Borislav Petkov; Shuah Khan >> Subject: Re: radeon 0000:02:00.0: GPU lockup CP stall for more than >> 1msec >> >> 2013-01-03 00:37 keltezéssel, Alex Deucher írta: >> > On Wed, Jan 2, 2013 at 5:38 PM, Markus Trippelsdorf >> > wrote: >> >> On 2013.01.02 at 17:31 -0500, Jerome Glisse wrote: >> >>> Please affected people can you test if patch : >> >>> http://people.freedesktop.org/~glisse/0003-drm-radeon-fix-dma-copy- >> on-r6xx-r7xx-evergen-ni-si-g.patch >> >>> >> >>> Fix the issue, you need to make sure you don't have the patch that >> >>> disable dma on r6xx ie that line 977-978 & 1061-1062 in radeon_asic.c >> >>> is : >> >>> .copy = &r600_copy_dma, >> >>> .copy_ring_index = R600_RING_TYPE_DMA_INDEX, >> >> It fixes the issue for me. Thanks. >> > The count is actually the count, not count - 1. The real fix seems to >> > be that r6xx requires 2 dw aligned transfers. The attached patch >> > fixes the issue for me. >> > >> > Alex >> >> I tried this patch over kernel 3.8.0-rc2 but the GDM screen is mostly >> garbage. >> Only some text, like "Not on the list?" below the users and small icons are >> visible >> but many user names are not rendered. http://tinypic.com/r/33xihit/6 >> I am on Fedora 18/x86_64, Radeon HD6570. > > I don't think the issue you are seeing is related to this one. Looks similar > to: > https://bugs.freedesktop.org/show_bug.cgi?id=55574 > > Alex > Tested the patch on 3.8-rc2 and didn't see any problems. -- Shuah -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
> -Original Message- > From: Boszormenyi Zoltan [mailto:zbos...@pr.hu] > Sent: Thursday, January 03, 2013 6:37 AM > To: Alex Deucher > Cc: Markus Trippelsdorf; lkml; dri-de...@lists.freedesktop.org; Deucher, > Alexander; Borislav Petkov; Shuah Khan > Subject: Re: radeon 0000:02:00.0: GPU lockup CP stall for more than > 1msec > > 2013-01-03 00:37 keltezéssel, Alex Deucher írta: > > On Wed, Jan 2, 2013 at 5:38 PM, Markus Trippelsdorf > > wrote: > >> On 2013.01.02 at 17:31 -0500, Jerome Glisse wrote: > >>> Please affected people can you test if patch : > >>> http://people.freedesktop.org/~glisse/0003-drm-radeon-fix-dma-copy- > on-r6xx-r7xx-evergen-ni-si-g.patch > >>> > >>> Fix the issue, you need to make sure you don't have the patch that > >>> disable dma on r6xx ie that line 977-978 & 1061-1062 in radeon_asic.c > >>> is : > >>> .copy = &r600_copy_dma, > >>> .copy_ring_index = R600_RING_TYPE_DMA_INDEX, > >> It fixes the issue for me. Thanks. > > The count is actually the count, not count - 1. The real fix seems to > > be that r6xx requires 2 dw aligned transfers. The attached patch > > fixes the issue for me. > > > > Alex > > I tried this patch over kernel 3.8.0-rc2 but the GDM screen is mostly garbage. > Only some text, like "Not on the list?" below the users and small icons are > visible > but many user names are not rendered. http://tinypic.com/r/33xihit/6 > I am on Fedora 18/x86_64, Radeon HD6570. I don't think the issue you are seeing is related to this one. Looks similar to: https://bugs.freedesktop.org/show_bug.cgi?id=55574 Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
2013-01-03 00:37 keltezéssel, Alex Deucher írta: On Wed, Jan 2, 2013 at 5:38 PM, Markus Trippelsdorf wrote: On 2013.01.02 at 17:31 -0500, Jerome Glisse wrote: Please affected people can you test if patch : http://people.freedesktop.org/~glisse/0003-drm-radeon-fix-dma-copy-on-r6xx-r7xx-evergen-ni-si-g.patch Fix the issue, you need to make sure you don't have the patch that disable dma on r6xx ie that line 977-978 & 1061-1062 in radeon_asic.c is : .copy = &r600_copy_dma, .copy_ring_index = R600_RING_TYPE_DMA_INDEX, It fixes the issue for me. Thanks. The count is actually the count, not count - 1. The real fix seems to be that r6xx requires 2 dw aligned transfers. The attached patch fixes the issue for me. Alex I tried this patch over kernel 3.8.0-rc2 but the GDM screen is mostly garbage. Only some text, like "Not on the list?" below the users and small icons are visible but many user names are not rendered. http://tinypic.com/r/33xihit/6 I am on Fedora 18/x86_64, Radeon HD6570. Best regards, Zoltán Böszörményi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On 2013.01.02 at 18:37 -0500, Alex Deucher wrote: > On Wed, Jan 2, 2013 at 5:38 PM, Markus Trippelsdorf > wrote: > > On 2013.01.02 at 17:31 -0500, Jerome Glisse wrote: > >> Please affected people can you test if patch : > >> http://people.freedesktop.org/~glisse/0003-drm-radeon-fix-dma-copy-on-r6xx-r7xx-evergen-ni-si-g.patch > >> > >> Fix the issue, you need to make sure you don't have the patch that > >> disable dma on r6xx ie that line 977-978 & 1061-1062 in radeon_asic.c > >> is : > >> .copy = &r600_copy_dma, > >> .copy_ring_index = R600_RING_TYPE_DMA_INDEX, > > > > It fixes the issue for me. Thanks. > > The count is actually the count, not count - 1. The real fix seems to > be that r6xx requires 2 dw aligned transfers. The attached patch > fixes the issue for me. Yes, this one also works for me. Thanks. -- Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Wed, Jan 2, 2013 at 4:59 PM, Alex Deucher wrote: >>> >> >> Catching up with this thread. I reverted the >> >> drm/radeon: use async dma for ttm buffer moves on 6xx-SI >> commit id: 2d6cc7296d4ee128ab0fa3b715f0afde511f49c2 >> >> Do I need to apply this patch without reverting >> 2d6cc7296d4ee128ab0fa3b715f0afde511f49c2? > > Correct. Don't revert anything. Just apply this patch. > > Alex Alex, Your patch fixed the problem I was seeing. -- Shuah -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On 01/03/2013 01:59 AM, Alex Deucher wrote: On Wed, Jan 2, 2013 at 6:58 PM, Shuah Khan wrote: On Wed, Jan 2, 2013 at 4:37 PM, Alex Deucher wrote: On Wed, Jan 2, 2013 at 5:38 PM, Markus Trippelsdorf wrote: On 2013.01.02 at 17:31 -0500, Jerome Glisse wrote: Please affected people can you test if patch : http://people.freedesktop.org/~glisse/0003-drm-radeon-fix-dma-copy-on-r6xx-r7xx-evergen-ni-si-g.patch Fix the issue, you need to make sure you don't have the patch that disable dma on r6xx ie that line 977-978 & 1061-1062 in radeon_asic.c is : .copy = &r600_copy_dma, .copy_ring_index = R600_RING_TYPE_DMA_INDEX, It fixes the issue for me. Thanks. The count is actually the count, not count - 1. The real fix seems to be that r6xx requires 2 dw aligned transfers. The attached patch fixes the issue for me. Catching up with this thread. I reverted the drm/radeon: use async dma for ttm buffer moves on 6xx-SI commit id: 2d6cc7296d4ee128ab0fa3b715f0afde511f49c2 Do I need to apply this patch without reverting 2d6cc7296d4ee128ab0fa3b715f0afde511f49c2? Correct. Don't revert anything. Just apply this patch. Tested, it is working. I didn't revert anything, just added that latest patch. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Wed, Jan 2, 2013 at 6:58 PM, Shuah Khan wrote: > On Wed, Jan 2, 2013 at 4:37 PM, Alex Deucher wrote: >> On Wed, Jan 2, 2013 at 5:38 PM, Markus Trippelsdorf >> wrote: >>> On 2013.01.02 at 17:31 -0500, Jerome Glisse wrote: Please affected people can you test if patch : http://people.freedesktop.org/~glisse/0003-drm-radeon-fix-dma-copy-on-r6xx-r7xx-evergen-ni-si-g.patch Fix the issue, you need to make sure you don't have the patch that disable dma on r6xx ie that line 977-978 & 1061-1062 in radeon_asic.c is : .copy = &r600_copy_dma, .copy_ring_index = R600_RING_TYPE_DMA_INDEX, >>> >>> It fixes the issue for me. Thanks. >> >> The count is actually the count, not count - 1. The real fix seems to >> be that r6xx requires 2 dw aligned transfers. The attached patch >> fixes the issue for me. >> > > Catching up with this thread. I reverted the > > drm/radeon: use async dma for ttm buffer moves on 6xx-SI > commit id: 2d6cc7296d4ee128ab0fa3b715f0afde511f49c2 > > Do I need to apply this patch without reverting > 2d6cc7296d4ee128ab0fa3b715f0afde511f49c2? Correct. Don't revert anything. Just apply this patch. Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Wed, Jan 2, 2013 at 4:37 PM, Alex Deucher wrote: > On Wed, Jan 2, 2013 at 5:38 PM, Markus Trippelsdorf > wrote: >> On 2013.01.02 at 17:31 -0500, Jerome Glisse wrote: >>> Please affected people can you test if patch : >>> http://people.freedesktop.org/~glisse/0003-drm-radeon-fix-dma-copy-on-r6xx-r7xx-evergen-ni-si-g.patch >>> >>> Fix the issue, you need to make sure you don't have the patch that >>> disable dma on r6xx ie that line 977-978 & 1061-1062 in radeon_asic.c >>> is : >>> .copy = &r600_copy_dma, >>> .copy_ring_index = R600_RING_TYPE_DMA_INDEX, >> >> It fixes the issue for me. Thanks. > > The count is actually the count, not count - 1. The real fix seems to > be that r6xx requires 2 dw aligned transfers. The attached patch > fixes the issue for me. > Catching up with this thread. I reverted the drm/radeon: use async dma for ttm buffer moves on 6xx-SI commit id: 2d6cc7296d4ee128ab0fa3b715f0afde511f49c2 Do I need to apply this patch without reverting 2d6cc7296d4ee128ab0fa3b715f0afde511f49c2? Thanks, -- Shuah -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Wed, Jan 2, 2013 at 5:38 PM, Markus Trippelsdorf
wrote:
> On 2013.01.02 at 17:31 -0500, Jerome Glisse wrote:
>> Please affected people can you test if patch :
>> http://people.freedesktop.org/~glisse/0003-drm-radeon-fix-dma-copy-on-r6xx-r7xx-evergen-ni-si-g.patch
>>
>> Fix the issue, you need to make sure you don't have the patch that
>> disable dma on r6xx ie that line 977-978 & 1061-1062 in radeon_asic.c
>> is :
>> .copy = &r600_copy_dma,
>> .copy_ring_index = R600_RING_TYPE_DMA_INDEX,
>
> It fixes the issue for me. Thanks.
The count is actually the count, not count - 1. The real fix seems to
be that r6xx requires 2 dw aligned transfers. The attached patch
fixes the issue for me.
Alex
>
> --
> Markus
From 47996fe2cc4ee82ac9db514fca36df889172cf30 Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Wed, 2 Jan 2013 18:30:21 -0500
Subject: [PATCH] drm/radeon/r6xx: fix DMA engine for ttm bo transfers
count must be a multiple of 2.
Cc: Borislav Petkov
Cc: Markus Trippelsdorf
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r600.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 2aaf147..9f4ce5e 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -2636,8 +2636,8 @@ int r600_copy_dma(struct radeon_device *rdev,
for (i = 0; i < num_loops; i++) {
cur_size_in_dw = size_in_dw;
- if (cur_size_in_dw > 0x)
- cur_size_in_dw = 0x;
+ if (cur_size_in_dw > 0xFFFE)
+ cur_size_in_dw = 0xFFFE;
size_in_dw -= cur_size_in_dw;
radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_COPY, 0, 0, cur_size_in_dw));
radeon_ring_write(ring, dst_offset & 0xfffc);
--
1.7.7.5
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On 2013.01.02 at 17:31 -0500, Jerome Glisse wrote: > Please affected people can you test if patch : > http://people.freedesktop.org/~glisse/0003-drm-radeon-fix-dma-copy-on-r6xx-r7xx-evergen-ni-si-g.patch > > Fix the issue, you need to make sure you don't have the patch that > disable dma on r6xx ie that line 977-978 & 1061-1062 in radeon_asic.c > is : > .copy = &r600_copy_dma, > .copy_ring_index = R600_RING_TYPE_DMA_INDEX, It fixes the issue for me. Thanks. -- Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
Please affected people can you test if patch : http://people.freedesktop.org/~glisse/0003-drm-radeon-fix-dma-copy-on-r6xx-r7xx-evergen-ni-si-g.patch Fix the issue, you need to make sure you don't have the patch that disable dma on r6xx ie that line 977-978 & 1061-1062 in radeon_asic.c is : .copy = &r600_copy_dma, .copy_ring_index = R600_RING_TYPE_DMA_INDEX, Cheers, Jerome -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On 01/02/2013 07:19 PM, Jerome Glisse wrote: On Wed, Jan 2, 2013 at 7:02 AM, Borislav Petkov wrote: On Wed, Jan 02, 2013 at 03:42:20AM +0200, Antti Palosaari wrote: I ended up also that same commit after bisecting from current 3.8 master. 01:05.0 VGA compatible controller: ATI Technologies Inc 760G [Radeon 3000] It is ASUS M5A78L-M/USB3 with integrated GPU. I cannot even boot unless graphical boot is removed from Fedora 17 boot options (rhgb quiet). Random GPU crashes still. You could try the temporary R600-only fix although I can't see whether your GPU is also an R600 ASIC or something different by staring at the model string above: http://marc.info/?l=dri-devel&m=135628734704029 HTH. -- Regards/Gruss, Boris. How do you trigger the issue ? Does it happens right away on boot ? Cheers, Jerome Sorry for utterly unclear description. I meant it randomly crashes desktop in case I got it booting by removing graphical boot option. In that case Cinnamon desktop "freezes", I was able to move mouse cursor but clicking buttons or moving windows etc. didn't worked at all. Only mouse cursor moves. It was possible to switch to console by ctrl+alt+fN. When Fedora graphical boot was enabled (options rhgb quiet) and I selected Kernel from the grub, it makes just blank screen and after 10sec or so monitor switches off saying "no signal". Nothing happened after that, boot was forced. I use dm-crypt and normally about the first thing is to show is graphical lock screen asking passphrase. I did some grepping from the syslog and that same message is seen: Jan 2 03:35:34 localhost kernel: [ 1164.433117] radeon :01:05.0: GPU lockup CP stall for more than 1msec Jan 2 03:35:34 localhost kernel: [ 1164.433121] radeon :01:05.0: GPU lockup (waiting for 0x0003 last fence id 0x0002) After I reverted bisected patch it has been working just fine. I has been running whole day without problems. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Wed, Jan 02, 2013 at 03:42:20AM +0200, Antti Palosaari wrote: > I ended up also that same commit after bisecting from current 3.8 > master. > > 01:05.0 VGA compatible controller: ATI Technologies Inc 760G [Radeon > 3000] It is ASUS M5A78L-M/USB3 with integrated GPU. > > I cannot even boot unless graphical boot is removed from Fedora 17 > boot options (rhgb quiet). Random GPU crashes still. You could try the temporary R600-only fix although I can't see whether your GPU is also an R600 ASIC or something different by staring at the model string above: http://marc.info/?l=dri-devel&m=135628734704029 HTH. -- Regards/Gruss, Boris. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On 12/25/2012 06:50 AM, Shuah Khan wrote: On Sun, Dec 23, 2012 at 6:31 AM, Borislav Petkov wrote: On Sun, Dec 23, 2012 at 01:22:12PM +0100, Borislav Petkov wrote: Right, let me try that and report back. Yep, looks like reverting the above commit fixes it - the boston.com website loads just fine. Thanks. -- Regards/Gruss, Boris. Saw the same error and after reading this thread, reverted the Commit 2d6cc7296d4ee128ab0fa3b715f0afde511f49c2. drm/radeon: use async dma for ttm buffer moves on 6xx-SI and the problem is gone. In my case, it is a solid hang right after system switches to vga. I was able to login on console once or twice. But dmesg showed the same message reported in this thread: [ 35.812085] radeon :01:00.0: GPU lockup CP stall for more than 1msec [ 35.812091] radeon :01:00.0: GPU lockup (waiting for 0x0002 last fence id 0x0001) My system has: 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV620 [Mobility Radeon HD 3400 Series] I ended up also that same commit after bisecting from current 3.8 master. 01:05.0 VGA compatible controller: ATI Technologies Inc 760G [Radeon 3000] It is ASUS M5A78L-M/USB3 with integrated GPU. I cannot even boot unless graphical boot is removed from Fedora 17 boot options (rhgb quiet). Random GPU crashes still. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Mon, Dec 24, 2012 at 09:50:11PM -0700, Shuah Khan wrote: > Saw the same error and after reading this thread, reverted the > > Commit 2d6cc7296d4ee128ab0fa3b715f0afde511f49c2. > > drm/radeon: use async dma for ttm buffer moves on 6xx-SI > > and the problem is gone. In my case, it is a solid hang right after > system switches to vga. I was able to login on console once or twice. > But dmesg showed the same message reported in this thread: > > [ 35.812085] radeon :01:00.0: GPU lockup CP stall for more than > 1msec [ 35.812091] radeon :01:00.0: GPU lockup (waiting for > 0x0002 last fence id 0x0001) > > > My system has: 01:00.0 VGA compatible controller: Advanced Micro > Devices [AMD] nee ATI RV620 [Mobility Radeon HD 3400 Series] You can apply http://marc.info/?l=dri-devel&m=135628734704029 instead, in the meantime. It partially reverts the above commit and if RV620 is a R600 asic (it should be) then it would fix your observation too. Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Sun, Dec 23, 2012 at 6:31 AM, Borislav Petkov wrote: > On Sun, Dec 23, 2012 at 01:22:12PM +0100, Borislav Petkov wrote: >> Right, let me try that and report back. > > Yep, looks like reverting the above commit fixes it - the boston.com > website loads just fine. > > Thanks. > > -- > Regards/Gruss, > Boris. Saw the same error and after reading this thread, reverted the Commit 2d6cc7296d4ee128ab0fa3b715f0afde511f49c2. drm/radeon: use async dma for ttm buffer moves on 6xx-SI and the problem is gone. In my case, it is a solid hang right after system switches to vga. I was able to login on console once or twice. But dmesg showed the same message reported in this thread: [ 35.812085] radeon :01:00.0: GPU lockup CP stall for more than 1msec [ 35.812091] radeon :01:00.0: GPU lockup (waiting for 0x0002 last fence id 0x0001) My system has: 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV620 [Mobility Radeon HD 3400 Series] -- Shuah -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Sun, Dec 23, 2012 at 01:22:12PM +0100, Borislav Petkov wrote: > Right, let me try that and report back. Yep, looks like reverting the above commit fixes it - the boston.com website loads just fine. Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Sun, Dec 23, 2012 at 12:51:33PM +0100, Markus Trippelsdorf wrote: > (If you don't use modules: git grep MODULE_PARM_DESC -- > drivers/gpu/drm/radeon/ ) Yeah. > You may have hit the same issue as I, see: > http://thread.gmane.org/gmane.comp.video.dri.devel/78328 Yes, it very much looks like it. That same page kills the machine here too. Maybe the GPU gets scared from the graphic nature of those images and gives up. :-D Although the box is not completely dead - I can login to a console and save dmesg before rebooting. And this bug becomes funnier and funnier - Alex, you might want to add that webpage to your testsuite :-). > Reverting commit 2d6cc729 fixes the problem for me, setting > radeon.no_wb=1 doesn't help. Right, let me try that and report back. Good job Markus, thanks! -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Sun, 2012-12-23 at 11:01 +, Andy Furniss wrote: > Borislav Petkov wrote: > > > [ 28.191072] radeon: `0' invalid for parameter `wb' > > > > although the whole driver blubber didn't appear on the console fterwards > > aso something got turned off allright. > > > > Then, I went and tried "radeon.no_wb" where the driver blubber appeared > > but AGP writeback was still enabled: > > no_wb=1 should work. Perhaps some of the module_param_named(,,int,) should be bool Also, are all of the various permissions appropriate? $ git grep module_param_named drivers/gpu/drm/radeon/ drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(no_wb, radeon_no_wb, int, 0444); drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(modeset, radeon_modeset, int, 0400); drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(dynclks, radeon_dynclks, int, 0444); drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(r4xx_atom, radeon_r4xx_atom, int, 0444); drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(vramlimit, radeon_vram_limit, int, 0600); drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(agpmode, radeon_agpmode, int, 0444); drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(gartsize, radeon_gart_size, int, 0600); drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(benchmark, radeon_benchmarking, int, 0444); drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(test, radeon_testing, int, 0444); drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(connector_table, radeon_connector_table, int, 0444); drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(tv, radeon_tv, int, 0444); drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(audio, radeon_audio, int, 0444); drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(disp_priority, radeon_disp_priority, int, 0444); drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(hw_i2c, radeon_hw_i2c, int, 0444); drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(pcie_gen2, radeon_pcie_gen2, int, 0444); drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(msi, radeon_msi, int, 0444); drivers/gpu/drm/radeon/radeon_drv.c:module_param_named(lockup_timeout, radeon_lockup_timeout, int, 0444); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On 2012.12.23 at 12:31 +0100, Borislav Petkov wrote: > On Sun, Dec 23, 2012 at 11:19:00AM +, Andy Furniss wrote: > > modinfo radeon > > > > will give a list assuming you use modules, I think all of them need =. > > Yep, that is one way of getting that info, thanks. I always go and look > at Documentation/kernel-parameters.txt and forget about modinfo. > > As you say 'radeon' needs to be module but since this is the case with > the distros, the majority of Linux installations out there have it this > way so we're fine. (If you don't use modules: git grep MODULE_PARM_DESC -- drivers/gpu/drm/radeon/ ) You may have hit the same issue as I, see: http://thread.gmane.org/gmane.comp.video.dri.devel/78328 Reverting commit 2d6cc729 fixes the problem for me, setting radeon.no_wb=1 doesn't help. -- Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Sun, Dec 23, 2012 at 11:19:00AM +, Andy Furniss wrote: > modinfo radeon > > will give a list assuming you use modules, I think all of them need =. Yep, that is one way of getting that info, thanks. I always go and look at Documentation/kernel-parameters.txt and forget about modinfo. As you say 'radeon' needs to be module but since this is the case with the distros, the majority of Linux installations out there have it this way so we're fine. Btw, there's a typo in the param list, if anyone wants to write a patch for it :-): parm: lockup_timeout:GPU lockup timeout in ms (defaul 1 = 10 seconds, 0 = disable) (int) Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
Borislav Petkov wrote: [ 28.191072] radeon: `0' invalid for parameter `wb' although the whole driver blubber didn't appear on the console fterwards aso something got turned off allright. Then, I went and tried "radeon.no_wb" where the driver blubber appeared but AGP writeback was still enabled: no_wb=1 should work. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
Borislav Petkov wrote: On Sun, Dec 23, 2012 at 11:01:37AM +, Andy Furniss wrote: no_wb=1 should work. Yeah, maybe all those radeon and other GPU module parameters' syntax should be documented somewhere - Documentation/kernel-parameters.txt for example, or a GPU-specific file, whatever - so that we can save us all the time and confusion. Provided this hasn't happened yet, of course. modinfo radeon will give a list assuming you use modules, I think all of them need =. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Sun, Dec 23, 2012 at 11:01:37AM +, Andy Furniss wrote: > no_wb=1 should work. Yeah, maybe all those radeon and other GPU module parameters' syntax should be documented somewhere - Documentation/kernel-parameters.txt for example, or a GPU-specific file, whatever - so that we can save us all the time and confusion. Provided this hasn't happened yet, of course. Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Sat, Dec 22, 2012 at 07:42:16PM -0500, Alex Deucher wrote:
> Does booting with radeon.wb=0 help?
Right, this param specification somehow didn't work here:
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.8.0-rc1 root=/dev/sda1
ro vga=0 log_bug_len=10M resume=/dev/sda2 no_console_suspend ignore_loglevel
hpet=force radeon.wb=0
[0.00] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.8.0-rc1
root=/dev/sda1 ro vga=0 log_bug_len=10M resume=/dev/sda2 no_console_suspend
ignore_loglevel hpet=force radeon.wb=0
[ … ]
[6.910104] radeon: `0' invalid for parameter `wb'
[ … ]
[ 28.191072] radeon: `0' invalid for parameter `wb'
although the whole driver blubber didn't appear on the console fterwards
aso something got turned off allright.
Then, I went and tried "radeon.no_wb" where the driver blubber appeared
but AGP writeback was still enabled:
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.8.0-rc1 root=/dev/sda1
ro vga=0 log_bug_len=10M resume=/dev/sda2 no_console_suspend ignore_loglevel
hpet=force radeon.no_wb
[0.00] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.8.0-rc1
root=/dev/sda1 ro vga=0 log_bug_len=10M resume=/dev/sda2 no_console_suspend
ignore_loglevel hpet=force radeon.no_wb
[ … ]
[6.382636] [drm] radeon kernel modesetting enabled.
[6.384915] radeon :02:00.0: VRAM: 512M 0x -
0x1FFF (512M used)
[6.384981] radeon :02:00.0: GTT: 512M 0x2000 -
0x3FFF
[6.388137] [drm] radeon: 512M of VRAM memory ready
[6.388181] [drm] radeon: 512M of GTT memory ready.
[6.388509] radeon :02:00.0: irq 42 for MSI/MSI-X
[6.388570] radeon :02:00.0: radeon: using MSI.
[6.388705] [drm] radeon: irq initialized.
[6.567811] radeon :02:00.0: WB enabled
^^
[6.567856] radeon :02:00.0: fence driver on ring 0 use gpu addr
0x2c00 and cpu addr 0x8802243e5c00
[6.567922] radeon :02:00.0: fence driver on ring 3 use gpu addr
0x2c0c and cpu addr 0x8802243e5c0c
[6.601247] [drm] Radeon Display Connectors
[6.602427] [drm] radeon: power management initialized
[6.722544] fbcon: radeondrmfb (fb0) is primary device
[6.945065] radeon :02:00.0: fb0: radeondrmfb frame buffer device
[6.945100] radeon :02:00.0: registered panic notifier
[6.945159] [drm] Initialized radeon 2.27.0 20080528 for :02:00.0 on
minor 0
At this point, I got tired of this experimenting and went and took the
big hammer :-):
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index 49b06590001e..00214312db23 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -307,6 +307,11 @@ int radeon_wb_init(struct radeon_device *rdev)
rdev->wb.use_event = true;
}
+ if (rdev->wb.enabled) {
+ pr_err("%s: disable the goddam WB: radeon_no_wb: %d\n",
__func__, radeon_no_wb);
+ rdev->wb.enabled = false;
+ }
+
dev_info(rdev->dev, "WB %sabled\n", rdev->wb.enabled ? "en" : "dis");
return 0;
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.8.0-rc1+ root=/dev/sda1
ro vga=0 log_bug_len=10M resume=/dev/sda2 no_console_suspend ignore_loglevel
hpet=force radeon.no_wb no_wb
[0.00] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.8.0-rc1+
root=/dev/sda1 ro vga=0 log_bug_len=10M resume=/dev/sda2 no_console_suspend
ignore_loglevel hpet=force radeon.no_wb no_wb
[6.562905] [drm] radeon kernel modesetting enabled.
[6.565106] radeon :02:00.0: VRAM: 512M 0x -
0x1FFF (512M used)
[6.565172] radeon :02:00.0: GTT: 512M 0x2000 -
0x3FFF
[6.567696] [drm] radeon: 512M of VRAM memory ready
[6.567742] [drm] radeon: 512M of GTT memory ready.
[6.568068] radeon :02:00.0: irq 42 for MSI/MSI-X
[6.568130] radeon :02:00.0: radeon: using MSI.
[6.568269] [drm] radeon: irq initialized.
[6.684920] radeon_wb_init: disable the goddam WB: radeon_no_wb: 0
[6.684967] radeon :02:00.0: WB disabled
^^^
[6.685011] radeon :02:00.0: fence driver on ring 0 use gpu addr
0x2c00 and cpu addr 0x880221ea3c00
[6.685077] radeon :02:00.0: fence driver on ring 3 use gpu addr
0x2c0c and cpu addr 0x880221ea3c0c
[6.722367] [drm] Radeon Display Connectors
[6.723548] [drm] radeon: power management initialized
[6.843185] fbcon: radeondrmfb (fb0) is primary device
[7.066368] radeon :02:00.0: fb0: radeondrmfb frame buffer device
[7.066402] radeon :02:00.0: registered panic notifier
[7.066462] [drm] Initialized radeon 2.27.0 20080528 for :02:00.0 on
minor 0
Ok, I hope I turned off the proper WB thing (I'm assuming you meant the
radeon_no_wb param
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Sat, Dec 22, 2012 at 7:25 PM, Borislav Petkov wrote: > On Sat, Dec 22, 2012 at 07:01:31PM -0500, Alex Deucher wrote: >> What chip is this? > > I think it is RV635. Here's the whole 3.8-rc1 dmesg. Does booting with radeon.wb=0 help? Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Sat, Dec 22, 2012 at 07:01:31PM -0500, Alex Deucher wrote: > What chip is this? I think it is RV635. Here's the whole 3.8-rc1 dmesg. [0.00] Linux version 3.8.0-rc1 (boris@liondog) (gcc version 4.7.2 (Debian 4.7.2-4) ) #13 SMP PREEMPT Sat Dec 22 11:48:54 CET 2012 [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.8.0-rc1 root=/dev/sda1 ro vga=0 log_bug_len=10M resume=/dev/sda2 no_console_suspend ignore_loglevel hpet=force [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009f7ff] usable [0.00] BIOS-e820: [mem 0x0009f800-0x0009] reserved [0.00] BIOS-e820: [mem 0x000f-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xcffe] usable [0.00] BIOS-e820: [mem 0xcfff-0xcfff2fff] ACPI NVS [0.00] BIOS-e820: [mem 0xcfff3000-0xcfff] ACPI data [0.00] BIOS-e820: [mem 0xd000-0xdfff] reserved [0.00] BIOS-e820: [mem 0xf000-0xf7ff] reserved [0.00] BIOS-e820: [mem 0xfec0-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00022fff] usable [0.00] debug: ignoring loglevel setting. [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.3 present. [0.00] DMI:/M57SLI-S4, BIOS FF 01/24/2008 [0.00] e820: update [mem 0x-0x] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] No AGP bridge found [0.00] e820: last_pfn = 0x23 max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-C7FFF write-protect [0.00] C8000-E uncachable [0.00] F-F write-through [0.00] MTRR variable ranges enabled: [0.00] 0 base mask 8000 write-back [0.00] 1 base 8000 mask C000 write-back [0.00] 2 base C000 mask F000 write-back [0.00] 3 base 0001 mask write-back [0.00] 4 base 0002 mask E000 write-back [0.00] 5 base 00022000 mask F000 write-back [0.00] 6 disabled [0.00] 7 disabled [0.00] TOM2: 00023000 aka 8960M [0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [0.00] e820: update [mem 0xd000-0x] usable ==> reserved [0.00] e820: last_pfn = 0xcfff0 max_arch_pfn = 0x4 [0.00] initial memory mapped: [mem 0x-0x1fff] [0.00] Base memory trampoline at [88099000] 99000 size 24576 [0.00] Using GB pages for direct mapping [0.00] init_memory_mapping: [mem 0x-0xcffe] [0.00] [mem 0x-0xbfff] page 1G [0.00] [mem 0xc000-0xcfdf] page 2M [0.00] [mem 0xcfe0-0xcffe] page 4k [0.00] kernel direct mapping tables up to 0xcffe @ [mem 0x1fffd000-0x1fff] [0.00] init_memory_mapping: [mem 0x1-0x22fff] [0.00] [mem 0x1-0x1] page 1G [0.00] [mem 0x2-0x22fff] page 2M [0.00] kernel direct mapping tables up to 0x22fff @ [mem 0xcffee000-0xcffe] [0.00] ACPI: RSDP 000f6620 00014 (v00 GBT ) [0.00] ACPI: RSDT cfff3000 00038 (v01 GBTNVDAACPI 42302E31 NVDA 01010101) [0.00] ACPI: FACP cfff3040 00074 (v01 GBTNVDAACPI 42302E31 NVDA 01010101) [0.00] ACPI: DSDT cfff30c0 04C8E (v01 GBTNVDAACPI 1000 MSFT 010C) [0.00] ACPI: FACS cfff 00040 [0.00] ACPI: SSDT cfff7e40 004CE (v01 PTLTD POWERNOW 0001 LTP 0001) [0.00] ACPI: HPET cfff8340 00038 (v01 GBTNVDAACPI 42302E31 NVDA 0098) [0.00] ACPI: MCFG cfff8380 0003C (v01 GBTNVDAACPI 42302E31 NVDA 01010101) [0.00] ACPI: APIC cfff7d80 00098 (v01 GBTNVDAACPI 42302E31 NVDA 01010101) [0.00] ACPI: Local APIC address 0xfee0 [0.00] [ea00-ea0008bf] PMD -> [88022760-88022f5f] on node 0 [0.00] Zone ranges: [0.00] DMA [mem 0x0001-0x00ff] [0.00] DMA32[mem 0x0100-0x] [0.00] Normal [mem 0x1-0x22fff] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x0001-0x0009efff] [0.00] node 0: [mem 0x0010-0xcffe] [0.00] node 0: [mem 0x1-0x22fff] [0.00] On node 0 totalpages: 2097023 [0.00] DMA zo
Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
On Sat, Dec 22, 2012 at 3:35 PM, Borislav Petkov wrote: > Hi Alex, > > got the sickest bug on 3.8-rc1, see below. The GPU locks up somewhere > down radeon_fence_wait_seq, judging by the error messages. > > And this doesn't happen with 3.7, of course. > > Let me know if you need any more info, thanks. What chip is this? Alex > > [16273.668350] radeon :02:00.0: GPU lockup CP stall for more than > 1msec > [16273.668361] radeon :02:00.0: GPU lockup (waiting for > 0x002b last fence id 0x002a) > [16273.882550] plugin-containe[11435]: segfault at 7f1f0a66cc08 ip > 7f1f13289bdb sp 7f1f0a2fe9e0 error 4 in > libflashplayer.so[7f1f130c5000+117b000] > [16274.502807] [ cut here ] > [16274.502845] WARNING: at lib/list_debug.c:53 __list_del_entry+0x63/0xd0() > [16274.502880] Hardware name: > [16274.502897] list_del corruption, 8802216a3f10->next is LIST_POISON1 > (dead00100100) > [16274.502939] Modules linked in: nls_iso8859_15 nls_cp437 acpi_cpufreq mperf > cpufreq_powersave cpufreq_userspace cpufreq_conservative cpufreq_stats > binfmt_misc dm_crypt dm_mod ipv6 vfat fat fuse kvm_amd kvm radeon > drm_kms_helper ttm edac_core microcode cfbfillrect cfbimgblt cfbcopyarea > k10temp > [16274.503141] Pid: 17386, comm: Xorg Not tainted 3.8.0-rc1 #13 > [16274.503172] Call Trace: > [16274.503190] [] ? __list_del_entry+0x60/0xd0 > [16274.503224] [] warn_slowpath_common+0x7f/0xc0 > [16274.503257] [] warn_slowpath_fmt+0x46/0x50 > [16274.503289] [] __list_del_entry+0x63/0xd0 > [16274.503320] [] list_del+0x11/0x40 > [16274.503348] [] drm_mm_remove_node+0x9e/0xd0 > [16274.503383] [] drm_mm_put_block+0x25/0x70 > [16274.503422] [] ? ttm_bo_man_put_node+0x31/0x60 [ttm] > [16274.503464] [] ttm_bo_man_put_node+0x39/0x60 [ttm] > [16274.503503] [] ttm_bo_cleanup_memtype_use+0x80/0xb0 > [ttm] > [16274.503545] [] ttm_bo_release+0x1fb/0x270 [ttm] > [16274.503585] [] ttm_bo_unref+0x31/0x40 [ttm] > [16274.503656] [] radeon_bo_unref+0x47/0x80 [radeon] > [16274.503707] [] radeon_gem_object_free+0x39/0x40 [radeon] > [16274.503748] [] drm_gem_object_free+0x29/0x30 > [16274.503781] [] drm_gem_object_release_handle+0xb8/0xd0 > [16274.503819] [] idr_for_each+0xdd/0x180 > [16274.503850] [] ? drm_gem_handle_create+0x100/0x100 > [16274.503887] [] ? trace_hardirqs_on+0xd/0x10 > [16274.503920] [] drm_gem_release+0x24/0x40 > [16274.503952] [] drm_release+0x54a/0x5e0 > [16274.503984] [] ? lg_local_unlock+0x42/0x70 > [16274.504016] [] __fput+0xb2/0x240 > [16274.504044] [] fput+0xe/0x10 > [16274.504073] [] task_work_run+0xb5/0xd0 > [16274.504105] [] do_exit+0x23a/0xac0 > [16274.504135] [] do_group_exit+0x4c/0xc0 > [16274.504167] [] get_signal_to_deliver+0x22d/0x960 > [16274.504202] [] do_signal+0x3f/0x5a0 > [16274.504233] [] ? trace_hardirqs_on_thunk+0x3a/0x3f > [16274.504269] [] do_notify_resume+0x5d/0x90 > [16274.504300] [] ? trace_hardirqs_on_thunk+0x3a/0x3f > [16274.504337] [] int_signal+0x12/0x17 > [16274.504366] ---[ end trace 4aad5b52e5533e3e ]--- > > > -- > Regards/Gruss, > Boris. > > Sent from a fat crate under my desk. Formatting is fine. > -- > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
