linux-kernel - Re: Kernel 2.6.30 and udevd problem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090701102214.352bfe72@jbarnes-g45>
Date:	Wed, 1 Jul 2009 10:22:14 -0700
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	Alberto Gonzalez <alberto6674@...il.com>
Cc:	Dave Airlie <airlied@...ux.ie>,
	Alberto Gonzalez <alberto6674@...il.com>,
	Kay Sievers <kay.sievers@...y.org>,
	linux-kernel@...r.kernel.org, linux-hotplug@...r.kernel.org
Subject: Re: Kernel 2.6.30 and udevd problem

On Wed, 1 Jul 2009 09:09:03 +0200
Alberto Gonzalez <alberto6674@...il.com> wrote:

> On Tuesday 30 June 2009 18:08:35 Jesse Barnes wrote:
> > On Tue, 30 Jun 2009 04:46:38 +0100 (IST)
> >
> > Dave Airlie <airlied@...ux.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?

Here's a patch against git, it should apply to 2.6.30 though I think.

I'll just need your dmesg output from when the problem is occurring (if
I'm right this patch should flood your logs).

-- 
Jesse Barnes, Intel Open Source Technology Center


View attachment "i915-hotplug-error.patch" of type "text/x-patch" (597 bytes)