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]

Date:	Tue, 30 Jun 2009 04:46:38 +0100 (IST)
From:	Dave Airlie <airlied@...ux.ie>
To:	Alberto Gonzalez <alberto6674@...il.com>
cc:	Kay Sievers <kay.sievers@...y.org>, linux-kernel@...r.kernel.org,
	linux-hotplug@...r.kernel.org, jbarnes@...tuousgeek.org
Subject: Re: Kernel 2.6.30 and udevd problem


> 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?

Dave.

> 
> [22652] event_queue_insert: seq 168515 queued, 'change' 'drm'
> [22657] udev_device_new_from_syspath: device 0x2040320 has devpath 
> '/devices/pci0000:00/0000:00:02.0/drm/card0'
> [22657] udev_device_read_db: device 0x2040320 filled with db symlink data 
> '/dev/dri/card0'
> [22657] udev_rules_apply_to_event: LINK 'char/226:0' /lib/udev/rules.d/50-
> udev-default.rules:5
> [22657] udev_rules_apply_to_event: NAME 'dri/card0' /lib/udev/rules.d/50-udev-
> default.rules:38
> [22657] udev_rules_apply_to_event: GROUP 91 /lib/udev/rules.d/50-udev-
> default.rules:42
> [22657] udev_device_new_from_syspath: device 0x2040790 has devpath 
> '/devices/pci0000:00/0000:00:02.0'
> [22657] udev_device_new_from_syspath: device 0x2040a80 has devpath 
> '/devices/pci0000:00'
> [22657] udev_rules_apply_to_event: RUN 
> 'socket:@/org/freedesktop/hal/udev_event' /etc/udev/rules.d/90-hal.rules:2
> [22657] udev_device_update_db: create db link (dri/card0 char/226:0)
> [22657] udev_node_add: creating device node '/dev/dri/card0', devnum=226:0, 
> mode=0660, uid=0, gid=91
> [22657] udev_node_mknod: preserve file '/dev/dri/card0', because it has correct 
> dev_t
> [22657] update_link: '/dev/char/226:0' with target '/dev/dri/card0' has the 
> highest priority 0, create it
> [22657] node_symlink: preserve already existing symlink '/dev/char/226:0' to 
> '../dri/card0'
> [22657] udev_monitor_send_device: passed 230 bytes to monitor 0x2040320
> [22657] udev_monitor_send_device: passed -1 bytes to monitor 0x2036150
> [22657] event_fork: seq 168515 exit with 0
> [22652] event_fork: seq 168515 forked, pid [22657], 'change' 'drm', 0 seconds 
> old
> [22652] udev_done: seq 168515 cleanup, pid [22657], status 0, 0 seconds old
> 
> It goes on in an infinite loop.
> 
> Then using "udevadm monitor" I also get a loop of these two messages:
> 
> KERNEL[1246192153.094553] change   /devices/pci0000:00/0000:00:02.0/drm/card0 
> (drm)
> UDEV  [1246192153.096463] change   /devices/pci0000:00/0000:00:02.0/drm/card0 
> (drm)
> 
> Killing udevd stops the UDEV messages (and CPU usage goes down), but the 
> KERNEL messages continue.
> 
> My system is a Dell Studio desktop with Intel graphics (G45). I'm using a 
> standard distro kernel (Arch LInux). The problem occurs both with EXA and with 
> UXA+KMS, and in both 32 bit and 64 bit systems.
> 
> Thanks,
> Alberto.
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/