Re: Linux 3.8-rc4

[Shuah Khan]

On Tue, Jan 29, 2013 at 6:05 AM, Deucher, Alexander
<Alexander.Deucher@xxxxxxx> wrote:
>> -----Original Message-----
>> I was out sick for a few days and finally picked this bisect backup
>> again. I started at 3.7 tag instead of 3.8-rc1 that I did in the past
>> and also did bisect at drivers/gpu/drm/radeon instead. Here are the
>> results:
>>
>> 6253e4c75d96006c06b9ac8f417eba873de2497b is the first bad commit
>> commit 6253e4c75d96006c06b9ac8f417eba873de2497b
>> Author: Alex Deucher <alexander.deucher@xxxxxxx>
>> Date:   Wed Dec 12 14:30:32 2012 -0500
>>
>>     drm/radeon: improve mc_stop/mc_resume on r5xx-r7xx
>>
>>     Along the same lines of what was done for evergreen+
>>     in the last kernel.
>>
>>     Signed-off-by: Alex Deucher <alexander.deucher@xxxxxxx>
>>
>> git bisect log attached.
>>
>
> Try the attached patch.  I think it should fix the issue.  I just applied a similar patch for newer asics.
>
> Alex
>

I reverted 6253e4c75d96006c06b9ac8f417eba873de2497b and DMAR faults
went away. Undid the revert and applied your new patch. DMAR faults
are back again.


[   25.158653] [drm] PCIE GART of 512M enabled (table at 0x0000000000040000).
[   25.158715] radeon 0000:01:00.0: WB enabled
[   25.158719] radeon 0000:01:00.0: fence driver on ring 0 use gpu
addr 0x0000000008000c00 and cpu addr 0xffff88002f143c00
[   25.158721] radeon 0000:01:00.0: fence driver on ring 3 use gpu
addr 0x0000000008000c0c and cpu addr 0xffff88002f143c0c

A few observations and questions about r600_startup() code sequence:

I notice DMAR faults right after

[drm] Loading RV620 Microcode message which is from
r600_init_microcode(). This routine does a series of
request_firmware() calls. btw. don't see release_firmware() calls in
regular code path, only from error legs in r600_init_microcode().

However, this routine doesn't do any loading yet. When this routine
returns, I am assuming request_firmware() step isn't complete yet
based on my reading request_firmware() interface. At this point
r600_startup() keeps chugging along, and does r600_mc_program() which
in turn calls rv515_mc_stop() which was changed with the
6253e4c75d96006c06b9ac8f417eba873de2497b commit.

I am thinking the changes somehow eliminated a wait or delay that used
be there for request_firmware() step to complete (?)

I can see from dmesg that the faults occur right after:

r600_init_microcode(rdev);

and stop before r600_pcie_gart_enable()

-- Shuah
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/