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. _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
