powerd broken

[Dominic Fandrey]

Robert Noland wrote:
> On Sat, 2009-04-04 at 12:31 +0200, Dominic Fandrey wrote:
>> Robert Noland wrote:
>>> On Fri, 2009-04-03 at 11:43 +0200, Dominic Fandrey wrote:
>>>> Alexander Motin wrote:
>>>>> Dominic Fandrey wrote:
>>>>>> I can rule out drm0 as the cause, because uhci0 is the only common
>>>>>> presence in all occurrences of this problem. 
>>>>> You have other examples? If you mean "irq16: hdac0 uhci+" string, then
>>>>> "+" there means "and some other devices", which in this case is probably
>>>>> drm0.
>>>>>
>>>>> There were some drm related commits last time and there are also some
>>>>> IRQ related problems were reported/patched in CURRENT recently. So I
>>>>> would not ignore this possibility without additional testing.
>>>>>
>>>> Is there anything I can do, apart from turning off drm? This is really
>>>> annoying (well, it eats a whole core while I'm compiling and it keeps
>>>> the fans going, when the machine should be idle).
>>>>
>>>> Is there somehow I can generate useful information? Someone to send a
>>>> kernel dump to?
>>> Use a radeon? ;(
>> Nay, I use an Intel GM965.
>>
>>> I've been working on the Intel vblank / irq issues.  Every time I commit
>>> something thinking that I have it resolved, it isn't.  So I'm waiting on
>>> hardware to arrive that will let me test this all more thoroughly.  I do
>>> have a patch that I think fixes most of the issues on Intel, but the ddx
>>> driver is still doing some silly things that cause issues in some cases.
>>> I *think* the only outstanding issue I have with Intel is if something
>>> is rendering (synced to vblank or not) when the display goes into dpms
>>> sleep, there isn't anything to block that app, so it renders as hard as
>>> it can even though it isn't being displayed.  In reality, this probably
>>> isn't a huge issue, but running gears while the display is asleep keeps
>>> the cpu at 100%, which isn't ideal.  Normal apps that aren't trying to
>>> draw as fast as they can, shouldn't cause an issue.
>>>
>>> The other issue with my current patches is that I had to change around a
>>> fair amount of infrastructure code to try and fix Intel's brain damage,
>>> so I have to finish fixing the rest of the drivers so they don't break.
>>> I have Intel and radeon fixed, I just have to hit the more obscure
>>> drivers.
>>>
>>> robert.
>> So it appears all I've got to do is wait. Correct me if I'm wrong.
> 
> You can set the tuneable hw.drm.msi=0 for now and see if that helps.  I
> haven't followed this whole thread, but the primary issue that people
> were having is that interrupts would not work after a vt switch with
> msi.  So, it that isn't your issue, you may need to look elsewhere.

That doesn't make any difference. Turning hardware acceleration helps,
though. However I cannot play Quake that way.