From owner-freebsd-stable@FreeBSD.ORG Tue Apr 7 19:04:57 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9B9A106568B; Tue, 7 Apr 2009 19:04:57 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id 6063C8FC25; Tue, 7 Apr 2009 19:04:57 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mobileKamikaze.norad (unknown [88.130.192.0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id E0C448A0193; Tue, 7 Apr 2009 21:04:55 +0200 (CEST) Message-ID: <49DBA3D3.70407@bsdforen.de> Date: Tue, 07 Apr 2009 21:04:51 +0200 From: Dominic Fandrey User-Agent: Thunderbird 2.0.0.21 (X11/20090321) MIME-Version: 1.0 To: Robert Noland 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> In-Reply-To: <1238863450.65025.55.camel@balrog.2hip.net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Motin , freebsd-stable@freebsd.org Subject: Re: powerd broken X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 19:04:58 -0000 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.