From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jesse Barnes Date: Tue, 30 Jun 2009 16:08:35 +0000 Subject: Re: Kernel 2.6.30 and udevd problem Message-Id: <20090630090835.5536a465@jbarnes-g45> List-Id: References: <200906280821.58631.info@gnebu.es> <200906281622.10072.info@gnebu.es> <200906300540.18916.info@gnebu.es> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Dave Airlie Cc: Alberto Gonzalez , Kay Sievers , linux-kernel@vger.kernel.org, linux-hotplug@vger.kernel.org On Tue, 30 Jun 2009 04:46:38 +0100 (IST) Dave Airlie wrote: > > > On Sunday 28 June 2009 16:28:44 Kay Sievers wrote: > > > If there isn't something else running which acts on uevents that > > > trigger drm events, which I wouldn't expect, it seems like a drm > > > kernel problem. > > > > Ok, thanks for looking at it. I'll sum up the problem for DRM > > people: > > > > The problem started after upgrading to 2.6.30. At some point, udevd > > starts to use a lot of CPU time. It happens randomly, but it seems > > easier to trigger when running something graphics intensive > > (glxgears, gtkperf, tuxracer..). > > > > Killing udevd and starting it with the --debug switch throws up > > this when the problem starts: > > I've added jbarnes to the list, > > Jesses are we sending events yet? what for? Right now we just send uevents at hotplug time, so maybe one of our hotplug interrupt bits is getting stuck, resulting in a continuous stream of events as we generate other interrupts (which would happen when running 3D apps for example). There's a DRM_DEBUG statement in drivers/gpu/drm/i915/i915_irq.c under the if (I915_HAS_HOTPLUG(dev)) { check, if you make it into DRM_ERROR we can see which one is getting stuck. -- Jesse Barnes, Intel Open Source Technology Center