Using recent kernel versions, my Debian testing machine always hangs after the graphical log in. The X server and lightdm start normally but a few seconds after entering the credentials and pressing log in, the machine hangs. Kernel 3.8.1 works perfectly, but the Debian 3.11-2-amd64, 3.12-1-amd64 and 3.13-1-amd64 kernels don't. In order to ensure that nothing has gone wrong with my installation, I also tried the openSUSE 13.1 KDE Live DVD but it also hangs shortly after the desktop has fully loaded. My graphics card is a Radeon HD5450 (CEDAR).
please attach your xorg log and dmesg output. Can you use git to bisect the kernel and find out what commit caused the regression?
Created attachment 96897 [details] Xorg log
Created attachment 96898 [details] dmesg
I did a small "bisection" and installed the 3.9.0-030900-generic, 3.10.0-031000-generic and 3.14.0-031400-generic kernels from the Ubuntu MainlineBuilds. 3.9 works, 3.10 and 3.14 hang. The attached logs are for the 3.9 kernel. I'm sorry, I prefer not to do a git bisect because I can only spend a limited amount of time on this bug.
The result of the bisect is d4788db30a1a66255b592dd12613dda80c1443f7 is the first bad commit commit d4788db30a1a66255b592dd12613dda80c1443f7 Author: Alex Deucher Date: Thu Feb 28 14:40:09 2013 -0500 drm/radeon/evergreen: add support for golden register init Signed-off-by: Alex Deucher
(In reply to comment #5) > The result of the bisect is > d4788db30a1a66255b592dd12613dda80c1443f7 is the first bad commit > commit d4788db30a1a66255b592dd12613dda80c1443f7 > Author: Alex Deucher > Date: Thu Feb 28 14:40:09 2013 -0500 > > drm/radeon/evergreen: add support for golden register init > > Signed-off-by: Alex Deucher Do you think you could go through the golden register arrays for cedar and narrow down which register(s) are problematic?
Yes, I think I can. In fact, I already tried and managed to go through the register arrays. There is a single problematic register in cedar_golden_registers, namely 0x5cc. The complete corresponding row of the array is 0x5cc, 0xffffffff, 0x00000001 (line 384).
Created attachment 102392 [details] [review] possible fix The attached patch should fix the issue.
I can confirm that this patch fixes the issue.
I am closing this bug as the fix has landed in kernels 3.16-rc5, 3.15.6, 3.14.13, 3.12.25 and 3.10.49 .
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.