Summary: | KMS:RV635:HD3650 GPU lockup | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | DRI | Reporter: | Grzegorz Kowal <astronomo> | ||||||||||||||
Component: | DRM/Radeon | Assignee: | Default DRI bug account <dri-devel> | ||||||||||||||
Status: | RESOLVED FIXED | QA Contact: | |||||||||||||||
Severity: | critical | ||||||||||||||||
Priority: | high | ||||||||||||||||
Version: | unspecified | ||||||||||||||||
Hardware: | x86-64 (AMD64) | ||||||||||||||||
OS: | Linux (All) | ||||||||||||||||
Whiteboard: | |||||||||||||||||
i915 platform: | i915 features: | ||||||||||||||||
Attachments: |
|
Description
Grzegorz Kowal
2010-05-07 04:41:20 UTC
Created attachment 35493 [details]
lspci -v output
To be more precise, I bisected the commit introducing the problem. It is 6b8b1786a8c29ce6e32298b93ac8d4a18a2b11c4 (drm/radeon/kms: enable use of unmappable VRAM V2). Before it everything works fine. *** This bug has been marked as a duplicate of bug 27822 *** I am reopening the bug since the patch included in bug 27822 does not resolve my problem. I have tested once again the recent branch drm-next with the last commit "drm/ttm: fix, avoid iomapping system memory" (9e51159c14c29ebd485a45ba56f148e180d62c29) and the problem remains. I am attaching dmesg output from this as well. Created attachment 35498 [details]
dmesg output from drm-next
Can you describe what you are doing when it lockup (where you using firefox on heavy website with lot of picture ? ...) Also please try with reverting : 6b8b1786a8c29ce6e32298b93ac8d4a18a2b11c4 and report if it helps Basically, I am just booting the kernel. The screen is corrupted since the initialization of the KMS (bounch of white dots on black background, it looks like each line is shifted horizontally). When I log in using ssh, however, everything seems to work fine. Once I start the X server I am getting the soft lockup. The screen flickers a few times, the server seems to restart ending with the distorted image of kdm background. I can post the images if necessary. After reverting 6b8b1786a8c29ce6e32298b93ac8d4a18a2b11c4 everything works fine. There is no screen corruption after the KMS initialization and the X server works fine. Obviously, the amount of accessible VRAM is reduced from 1024MB to 256MB then. Please attach full dmesg Full dmesg without the revert. Created attachment 35552 [details]
Full dmesg without the revert.
Created attachment 35553 [details]
Full dmesg with the revert.
I have not noticed that my dmesg was not full (kernel log size was too small).
I am submitting two full dmesg outputs for the recent drm-radeon-testing branch: one without any modifications (bad) and the second with the reverted commit 6b8b1786 (good).
Jerome, let me know if you need anything else in order to diagnose this problem.
Thanks!
Created attachment 36035 [details] [review] HDP NONSURF to maximum size Can you confirm that attach patch fix the issue for you I can confirm, that the patch fixes my problems. Thanks! I am reopening this since the patch has not been applied yet. |
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.