powerd broken

[Robert Noland]

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.

robert.

> Regards
-- 
Robert Noland <rnoland at FreeBSD.org>
FreeBSD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090404/ba78de28/attachment.pgp