© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
35a32c5
(Get the code!)
(In reply to comment #76)
> @Alex Deucher: Yes, the modern operating systems and hardware are complex
> beasts and I surely understand that some bugs may be hard to track down. The
> point is however that there wasn't a systematic effort to resolve this
> particular issue except for some "there is a random problem X described in
> ticket Y, which may be the reason for your troubles too, so why don't you
> try the solution proposed there". By the way I tried the change proposed by
> Michel Dänzer in https:/
> unfortunately it doesn't seem to help either.
There were several suggestions on this bug, but apparently none of them helped.
> I am clueless about the kernel internals, but the manifestations of this bug
> seem to be consistent with the hypothesis that there is something wrong with
> the "radeon" driver. It seems like something locks the system for long
> periods of time and the other time sensitive modules "freak out". On my
> laptop the problem became even more pronounced when I swapped the "1440x900"
> LCD panel with a "1600x1200" one.
A bigger display means more data is being moved around. It sounds to me like a chipset issue when large amounts of data are being transferred across the bus. KMS uses system memory more readily than UMS did which is likely why the issues shows up with KMS. I don't know of any other options to try in the driver. We don't have these problems with the same radeon chips is other systems. Unfortunately, I'm not a chipset expert so I'm not sure what sort of pci quirks, etc. to try.
It could also be that the there is an issue in the sound or wifi driver which didn't show up as readily when there was less traffic on the bug. As far as I know no one has investigated these avenues very much.