lkml.org 
[lkml]   [2009]   [Jul]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Kernel 2.6.30 and udevd problem
Date
On Tuesday 30 June 2009 18:08:35 Jesse Barnes wrote:
> On Tue, 30 Jun 2009 04:46:38 +0100 (IST)
>
> Dave Airlie <airlied@linux.ie> 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.

I am afraid I'll need a bit more guidance here. I guess this means patching
the kernel. Would it be possible to get a test patch against 2.6.30? And then
after patching and compiling, how should I debug it?

Thanks,
Alberto.


\
 
 \ /
  Last update: 2009-07-01 09:11    [W:0.124 / U:0.740 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site