Summary: | hang on CEDAR right after log on | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | DRI | Reporter: | tcl_de | ||||||||
Component: | DRM/Radeon | Assignee: | Default DRI bug account <dri-devel> | ||||||||
Status: | RESOLVED FIXED | QA Contact: | |||||||||
Severity: | critical | ||||||||||
Priority: | medium | ||||||||||
Version: | unspecified | ||||||||||
Hardware: | x86-64 (AMD64) | ||||||||||
OS: | Linux (All) | ||||||||||
Whiteboard: | |||||||||||
i915 platform: | i915 features: | ||||||||||
Attachments: |
|
Description
tcl_de
2014-04-03 12:25:24 UTC
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.