lkml.org 
[lkml]   [2013]   [Jan]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: Linux 3.8-rc4
From
On Tue, Jan 22, 2013 at 11:55 AM, Shuah Khan <shuahkhan@gmail.com> wrote:

>>> init:
>>
>> Does the attached patch stop them? It basically skips all initialization of the DMA ring on your system. What I don't understand is why you still get them with the previous patch, but not with 909d9eb67f1e4e39f2ea88e96bde03d560cde3eb reverted. 909d9eb67f1e4e39f2ea88e96bde03d560cde3eb only affects the use of the DMA ring for buffer migration and the patch I previously attached disables the use of the DMA ring for buffer migration. Does the latest batch of drm-fixes from Dave that Linus just merged help?
>>
>> Alex
>
> Will try your latest patch. Will also try the latest git - I am
> currently on Jan 17th. However, in the meantime, I found that these
> messages might not be new and getting printed now with the
> eaaa6983ab2ccdf826c90838eb584211e0cadb76 [PATCH] drm/radeon: print dma
> status reg on lockup (v2) commit that introduced debug messages in
> r600_gpu_soft_reset(). I couldn't revert this commit, but doing a
> compile with these messages commented out. Will update you on the
> results and then test the new git
>
> -- Shuah

Here is what I tried:

1. Applied your latest disable_dma_ring_on_6xx-2.diff and still see messages.
2. Tried intel_iommu=igfx_off to see if that changes anything. The
reason for trying this option is, I noticed this message: (this is not
a new message, I see this all the time)

[ 1.337112] DMAR: Disabling IOMMU for graphics on this chipset

No change with or without option - still see the same messages.

Next steps:

1. One big difference between 3.7 and 3.8 is in the
r600_gpu_soft_reset() - I started with 3.7 to see the differences if
any of these differences is causing this to be logged. In 3.7
r600_gpu_soft_reset() is called with no reset_mask. I am going to
first verify if softreset happens on 3.7. Does this give you any ideas
of whether this could cause a problem?

2. Another angle I am looking at is the newly added

dev_info(rdev->dev, " R_00D034_DMA_STATUS_REG = 0x%08X\n",
RREG32(DMA_STATUS_REG));

messages in r600_gpu_soft_reset_dma().

Could it be that these newly added debug messages are now showing this
old condition that always existed on my test system. From what I have
observed so far, this is very likely.

Please let me know if you want to me try anything else or if you don't
think these steps won't help.

-- Shuah


\
 
 \ /
  Last update: 2013-01-23 01:42    [W:0.227 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site