Created attachment 38216 [details] [review] kern.log messages upon freeze Trying to start X with KMS enabled on my HD4670 (RV730) card freezes the system and I have to SysRq out of that situation. Since this only happens with the final release of the 2.6.35 kernel I am currently stuck with the RC6 which does not display this behavior. See the attached kern.log output in case of such freeze. I am running the latest Git masters of both xf86-video-ati (5a7c9d94733a0db1d3565447acc9f0e751db5950 here ATM) as well as mesa (f3ec111b0af9d268e6b3c6d3226a448d19e45d8c here ATM).
Can you bisect what commit is causing the issue?
nevermind. I see the problem. Yo can work around it for now by booting with radeon.agpmode=-1
Created attachment 38227 [details] [review] fix This patch fixes the issue.
Mathias can you confirm the patch fix your issue ?
Verified in https://bugzilla.kernel.org/show_bug.cgi?id=17201
Patch queued
Sorry but I cannot verify the patch ATM since that seems to require a recent (but at least 2.6.36) kernel whereas I can only build 2.6.35 here. I’ll leave a comment as soon as a newer version is packaged.
It should apply to 2.6.35 as well.
(In reply to comment #8) > It should apply to 2.6.35 as well. Not really. The first part of the patch looks like this: > diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c > index 667c237..5668b90 100644 > --- a/drivers/gpu/drm/radeon/r600.c > +++ b/drivers/gpu/drm/radeon/r600.c > @@ -3491,7 +3491,7 @@ void r600_ioctl_wait_idle(struct radeon_device *rdev, struct radeon_bo *bo) > * rather than write to HDP_REG_COHERENCY_FLUSH_CNTL > */ > if ((rdev->family >= CHIP_RV770) && (rdev->family <= CHIP_RV740)) { > - void __iomem *ptr = (void *)rdev->gart.table.vram.ptr; > + void __iomem *ptr = (void *)rdev->vram_scratch.ptr; > u32 tmp; > > WREG32(HDP_DEBUG1, 0); That function looks like this here though: > void r600_ioctl_wait_idle(struct radeon_device *rdev, struct radeon_bo *bo) > { > WREG32(R_005480_HDP_MEM_COHERENCY_FLUSH_CNTL, 0x1); > } Thus this hunk already fails to apply.
Mathias, in your case it seem to be something else as the problematic patch (812d046915f48236657f02c06d7dc47140e9ceda) was not applied until after 2.6.35. Any chance you could bisect?
(In reply to comment #10) > Mathias, in your case it seem to be something else as the problematic patch > (812d046915f48236657f02c06d7dc47140e9ceda) was not applied until after 2.6.35. > Any chance you could bisect? I am not really sure what you are asking me to do. Shall I apply the patch from 812d046915f48236657f02c06d7dc47140e9ceda here as well and the patch from this report after that? Otherwise I guess I can also wait for a kernel 2.6.36 RC to hit my package repositories.
(In reply to comment #11) > Otherwise I guess I can also wait for a kernel 2.6.36 RC to > hit my package repositories. … is what I did now and I can start just fine. So this issue also seems fixed for me.
I think it should be fixed by this patch: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e488459a0e131acc9e14df093cfee740bc431953
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.