Summary: | System freeze upon X startup with KMS enabled (RV730) | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | DRI | Reporter: | Mathias Brodala <info> | ||||||
Component: | DRM/Radeon | Assignee: | Default DRI bug account <dri-devel> | ||||||
Status: | RESOLVED FIXED | QA Contact: | |||||||
Severity: | major | ||||||||
Priority: | medium | ||||||||
Version: | XOrg 6.7.0 | ||||||||
Hardware: | Other | ||||||||
OS: | All | ||||||||
Whiteboard: | |||||||||
i915 platform: | i915 features: | ||||||||
Attachments: |
|
Description
Mathias Brodala
2010-08-27 03:35:42 UTC
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 ? 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.