On Tue, Jan 29, 2013 at 6:05 AM, Deucher, Alexander <alexander.deuc...@amd.com> 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.deuc...@amd.com> >> 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.deuc...@amd.com> >> >> 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 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/
