Date: Tue, 07 Apr 2009 21:04:51 +0200 From: Dominic Fandrey <kamikaze@bsdforen.de> To: Robert Noland <rnoland@FreeBSD.org> Cc: Alexander Motin <mav@FreeBSD.org>, freebsd-stable@freebsd.org Subject: Re: powerd broken Message-ID: <49DBA3D3.70407@bsdforen.de> In-Reply-To: <1238863450.65025.55.camel@balrog.2hip.net> References: <1238293386.00093672.1238281804@10.7.7.3> <49CF0803.1070505@FreeBSD.org> <49CF2F8D.6000905@bsdforen.de> <49CF4EB9.60108@FreeBSD.org> <49CF49F5.6010800@bsdforen.de> <49CF615A.6050304@FreeBSD.org> <49CF595A.30805@bsdforen.de> <49CF6B28.2080400@FreeBSD.org> <49CF60AB.4040709@bsdforen.de> <49CF6899.2060002@bsdforen.de> <49CF8E8D.1080604@bsdforen.de> <49CF9C19.3020509@FreeBSD.org> <49D5DA33.4010800@bsdforen.de> <1238778004.65025.30.camel@balrog.2hip.net> <49D73715.6050700@bsdforen.de> <1238863450.65025.55.camel@balrog.2hip.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49DBA3D3.70407>