A new version 10.12 is out and I've read on Phoronix it fixes the occasional fglrx crashes that are present in 10.11 Reproducible: Always
Created attachment 257779 [details] ati-drivers-10.12 ebuild I already sent this ebuild to lu. Until he get time to bump it you can test it. It also has experimental support for kernel .37 but a patch is needed (i will attach it in short). Happy holidays!
Created attachment 257780 [details, diff] experimental .37 kernel patch for ati-drivers-10.12
Just used the ebuild and it appears to wotk fine. It compiled with 2.6.36-r3 and runs fine so far.
Since building kernel 2.6.37, I tried this ebuild as 10.11 would not compile. However, this version has the same issue as 10.11: * ati-drivers-10.11 is incompatible with RCU preemption (bug #223281). * Please disable it: * CONFIG_PREEMT_RCU=n The problem is that CONFIG_PREEMT_RCU cannot be disabled in 2.6.37. At least not directly in menuconfig. The only RCU-related option is: General setup -> RCU Subsystem -> RCU Implementation but there is only one choice for a SMP system: Preemptible tree-based hierarchical RCU. I assume that CONFIG_PREEMT_RCU is then enabled automatically. Not surprisingly, if I choose CONFIG_PREEMPT_NONE=y altogether, I get rid of CONFIG_PREEMT_RCU. But for a system with significant GPU usage, you probably want preemption, so this is not a good solution.
can you try editing the ebuild, removing the RCU check and compile/run with CONFIG_PREEMT_RCU enabled? If it works i will remove the check. I will also test it myself as soon as i get some time. Thank you :)
I tested the attached ebuild+patch today. Working fine as-is. Still annoyed that my 6870 is apparently "unsupported hardware" per the watermark, although that's an upstream problem. If the graphics cards works enough to display the watermark, I don't think the watermark is necessary. :P Note that I have Voluntary Kernel Preemption (CONFIG_PREEMPT_VOLUNTARY) enabled, instead of the full version. I did not try full preemption, so I can't confirm whether or not this is still an issue.
Thank you for testing it. Anyway we are talking about CONFIG_PREEMT_RCU not about CONFIG_PREEMPT_* . I think the watermark appers becouse the support is still experimental and not finalized yet. I'm glad to know it work :)
Removed the RCU check from ebuild, works fine on Linux 2.6.37 with full preemption :)
Ok nice, i will remove the check then, give me sometime im really busy today, sorry
since we are talking about kernel checks... Is there any reason to forcibly enable MAGIC_SYSRQ? OK, it's a good policy, but why make it mandatory? Have I missed some documentation?
It was known to be needed. You are free to test without, and if it works (build and run without problems) and report the results :)
(In reply to comment #11) > It was known to be needed. You are free to test without, and if it works (build > and run without problems) and report the results :) > I'm using it right now, it was the reason I asked in the first place. Is there some stress-test that can be performed? After almost one day of 'normal desktop' using, nothing to report: no glitches, no messages, no crashes, and logs are fine.
usually i play some 3d games to test (nexuiz or games-action/chromium), i test glxinfo and glxgear to report no error, and correct values. Of course i test composite (kde kwin) and also video playback with mplayer. Anyway i think the need of the option is very dependent on your kernel config. If a symbol is unused by mainline kernel modules it is dropped, if it is used it is not of course. This makes hard to tell if the check can be removed or not. i will try to do some test tomorrow
(In reply to comment #8) > Removed the RCU check from ebuild, works fine on Linux 2.6.37 with full > preemption :) I can confirm this. This feels like the first version in a very long time that actually works flawlessly and doesn't crash at random on my HD3450.
Bumped to the main portage tree. The RCU check has been removed. The sysrq will be made optional in the next driver version, 11.1. The main reason i don't want to totally remove sysrq is that they are usefull in case of system lock to turn off the system in a more clean way then just pushing reset. When it works indeed :)
