Bug 28016 - KMS:RV635:HD3650 GPU lockup
Summary: KMS:RV635:HD3650 GPU lockup
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: high critical
Assignee: Default DRI bug account
QA Contact:
Depends on:
Reported: 2010-05-07 04:41 UTC by Grzegorz Kowal
Modified: 2010-07-05 21:05 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

kernel log with the backtrace (36.83 KB, text/plain)
2010-05-07 04:41 UTC, Grzegorz Kowal
no flags Details
lspci -v output (12.60 KB, text/plain)
2010-05-07 04:42 UTC, Grzegorz Kowal
no flags Details
dmesg output from drm-next (15.15 KB, text/plain)
2010-05-07 08:36 UTC, Grzegorz Kowal
no flags Details
Full dmesg without the revert. (51.93 KB, text/plain)
2010-05-10 12:22 UTC, Grzegorz Kowal
no flags Details
Full dmesg with the revert. (40.91 KB, text/plain)
2010-05-10 12:30 UTC, Grzegorz Kowal
no flags Details
HDP NONSURF to maximum size (1.92 KB, patch)
2010-06-03 12:10 UTC, Jerome Glisse
no flags Details | Splinter Review

Description Grzegorz Kowal 2010-05-07 04:41:20 UTC
Created attachment 35492 [details]
kernel log with the backtrace

I have tested recent branches drm-radeon-testing (last commit 7a1ffce50373c177d3f6eecce52badc40c90e1dd) and drm-next (last commit 9e51159c14c29ebd485a45ba56f148e180d62c29) from http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git.  These branches contain patches for enabling unmappable VRAM. However, soon after booting I am getting a GPU lockup and corrupted console and X.

My hardware is laptop ASUS M50SA with 4GB system memory, and graphics 1GB
Mobility Radeon HD 3650.

I am attaching the kernel output with the backtrace and lspci -v output.
Comment 1 Grzegorz Kowal 2010-05-07 04:42:22 UTC
Created attachment 35493 [details]
lspci -v output
Comment 2 Grzegorz Kowal 2010-05-07 04:48:35 UTC
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.
Comment 3 Alex Deucher 2010-05-07 06:18:03 UTC

*** This bug has been marked as a duplicate of bug 27822 ***
Comment 4 Grzegorz Kowal 2010-05-07 08:35:57 UTC
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.
Comment 5 Grzegorz Kowal 2010-05-07 08:36:30 UTC
Created attachment 35498 [details]
dmesg output from drm-next
Comment 6 Jerome Glisse 2010-05-10 03:14:46 UTC
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 :

and report if it helps
Comment 7 Grzegorz Kowal 2010-05-10 06:29:42 UTC
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.
Comment 8 Jerome Glisse 2010-05-10 06:51:33 UTC
Please attach full dmesg
Comment 9 Jerome Glisse 2010-05-10 06:51:51 UTC
Full dmesg without the revert.
Comment 10 Grzegorz Kowal 2010-05-10 12:22:58 UTC
Created attachment 35552 [details]
Full dmesg without the revert.
Comment 11 Grzegorz Kowal 2010-05-10 12:30:42 UTC
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.

Comment 12 Jerome Glisse 2010-06-03 12:10:06 UTC
Created attachment 36035 [details] [review]
HDP NONSURF to maximum size

Can you confirm that attach patch fix the issue for you
Comment 13 Grzegorz Kowal 2010-06-03 14:39:09 UTC
I can confirm, that the patch fixes my problems.

Comment 14 Grzegorz Kowal 2010-06-09 08:21:00 UTC
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.