On Tue, 30 Jun 2009 04:46:38 +0100 (IST)
Dave Airlie <airlied@xxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
