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 <rnol...@freebsd.org> FreeBSD
signature.asc
Description: This is a digitally signed message part
