Summary: | x11-drivers/xf86-video-ati-6.12.191: X CPU usage jumps to maximum after running a while | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Alex Lyon <alexblyon> |
Component: | Current packages | Assignee: | Gentoo X packagers <x11> |
Status: | RESOLVED OBSOLETE | ||
Severity: | minor | CC: | kripton |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
Xorg.conf, unchanged across all cases
Xorg.0.log from first crash under 6.12.191 Xorg.0.log under 6.12.5, system operates normally under this version |
Description
Alex Lyon
2010-03-15 07:06:36 UTC
Created attachment 223583 [details]
Xorg.conf, unchanged across all cases
Created attachment 223585 [details]
Xorg.0.log from first crash under 6.12.191
A log of the 2nd crash is also available upon demand.
Created attachment 223587 [details]
Xorg.0.log under 6.12.5, system operates normally under this version
There was some disagreement on Freenode as to whether I should file the bug here, or with the upstream developers. I decided it would be best to start here, and take direction from Gentoo devs. I have reverted to 6.12.5, which is just peachy for now. 6.12.191 is apparently a pre-release for 6.13, so I do not even know if it is worth the effort of examining this bug. To make a long story short, please provide instructions on how to proceed from here. AND I apologize if this bug has been a waste of time to those concerned. Thank you. Well, all I can say is that xf86-video-ati-6.12.191 works pretty fine on 2.6.33 kernel with radeon.modeset=1 on radeon 9600. The more recent radeon versions (above r500, IIRC) need a bit more work (perhaps even a git or two of the required packages). However, I do recall having memory related crashes with OpenGL apps on 2.6.32 with modeset=0. Patch for that problem went into 2.6.34-rc1 - I don't know, if it got backported. I can reproduce your issue with kms disabled. Could you try to enable KMS in kernel and report back to us if it has the issue too? I myself think it is working fine with KMS. Rafał, Tomáš, Thank you for your suggestion, and thank you Tomáš for making the effort to reproduce the issue. I have followed these instructions: http://en.gentoo-wiki.com/wiki/Radeon And enabled KMS with gentoo-sources-2.6.31-r6, then ran under X successfully for more than an hour under normal use. The problem did not reoccur. I did however read in Xorg.0.log that: "[KMS] drm report modesetting isn't supported." so I decided to change to 2.6.32-r2 kernel, which resulted in the blanking of displays during what I estimate was drm init during boot, however the VT was still responsive and I was able to do a blind reboot from the console. I am about to try again with 2.6.33 and report back. However I believe the problem has been solved, and I ask you to mark the bug accordingly if you are in agreement. This is my final update on the matter, unless subsequent requests for information are made. I have tried with both 2.6.32-gentoo-r2, and 2.6.33-gentoo, but the loss of video signal still occurs with both versions and radeon.modesetting=1, if I pass radeon.modesetting=0 to either kernel version, it boots normally, but the CPU saturation issue returns. As I mentioned earlier, 2.6.31-gentoo-r6 works just fine with KMS enabled, so I will ignore the Xorg.0.log error and continue to work happily with this configuration. I also flew through "make oldconfig", without altering any questions it asked, so I might have opened myself up to problems when I upgraded to 2.6.32-gentoo-r2 and 2.6.33-gentoo. Thank you very much for your rapid and acute responses to this bug posting. Please let me know if I may be of assistance in any way. If the console turns black on initializing of kernel modesetting, this usually means that your kernel is missing framebuffer console support. (In reply to comment #9) > If the console turns black on initializing of kernel modesetting, this usually > means that your kernel is missing framebuffer console support. > This can also happen, if uvesafb/radeonfb/etc. was not disabled. Hopefully fixed long ago. If not, open a bug upstream https://bugs.freedesktop.org/enter_bug.cgi?product=xorg&component=Driver/Radeon |