Bug 29834 - System freeze upon X startup with KMS enabled (RV730)
System freeze upon X startup with KMS enabled (RV730)
Status: RESOLVED FIXED
Product: DRI
Classification: Unclassified
Component: DRM/Radeon
XOrg 6.7.0
Other All
: medium major
Assigned To: Default DRI bug account
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-08-27 03:35 UTC by Mathias Brodala
Modified: 2010-10-04 13:22 UTC (History)
0 users

See Also:


Attachments
kern.log messages upon freeze (10.15 KB, patch)
2010-08-27 03:35 UTC, Mathias Brodala
no flags Details | Splinter Review
fix (4.23 KB, patch)
2010-08-27 10:14 UTC, Alex Deucher
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Mathias Brodala 2010-08-27 03:35:42 UTC
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).
Comment 1 Alex Deucher 2010-08-27 09:22:15 UTC
Can you bisect what commit is causing the issue?
Comment 2 Alex Deucher 2010-08-27 09:28:15 UTC
nevermind.  I see the problem.  Yo can work around it for now by booting with radeon.agpmode=-1
Comment 3 Alex Deucher 2010-08-27 10:14:50 UTC
Created attachment 38227 [details] [review]
fix

This patch fixes the issue.
Comment 4 Jerome Glisse 2010-08-27 13:48:39 UTC
Mathias can you confirm the patch fix your issue ?
Comment 5 Alex Deucher 2010-08-29 14:38:19 UTC
Verified in https://bugzilla.kernel.org/show_bug.cgi?id=17201
Comment 6 Jerome Glisse 2010-09-02 14:44:06 UTC
Patch queued
Comment 7 Mathias Brodala 2010-09-02 15:32:23 UTC
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.
Comment 8 Alex Deucher 2010-09-02 21:36:41 UTC
It should apply to 2.6.35 as well.
Comment 9 Mathias Brodala 2010-09-03 01:14:14 UTC
(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.
Comment 10 Alex Deucher 2010-09-03 09:02:29 UTC
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?
Comment 11 Mathias Brodala 2010-09-05 09:01:03 UTC
(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.
Comment 12 Mathias Brodala 2010-10-04 11:46:16 UTC
(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.