after upgrade edgy->feisty, high udev CPU usage

Bug #89693 reported by Stephen Sinclair
8
Affects Status Importance Assigned to Milestone
udev (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

Binary package hint: udev

During my upgrade from edgy to feisty (using update-manager), I had a few errors with a few packages, including udev. I simply used apt-get from the command line to complete the installation, which worked fine. (I took notes of which ones had errors, about 10 or so, and apt-get installed them explicitly.)

Anyways, on reboot, the text-mode display was flooded with these messages:

[ 4554.079347] device-mapper: ioctl: error adding target to table
[ 4554.080101] device-mapper: table: 253:1: linear: dm-linear: Device lookup failed
[ 4554.080283] device-mapper: ioctl: error adding target to table
[ 4554.081027] device-mapper: table: 253:1: linear: dm-linear: Device lookup failed
[ 4554.081210] device-mapper: ioctl: error adding target to table
[ 4554.081955] device-mapper: table: 253:1: linear: dm-linear: Device lookup failed
[ 4554.082135] device-mapper: ioctl: error adding target to table

So many that I could barely see what I was typing. When GNOME came up, I saw that my CPU monitor was reported very heavy CPU usage, in an unstable behaviour. (That is, not a straight line, but going up and down quite frequently.)

Using "top", I saw that "udevd" was eating all the CPU.

After "sudo /etc/init.d/udevd stop", the CPU usage returns to normal.
After "sudo /etc/init.d/udevd start", the CPU usage becomes heavy and unstable again.

After stopping udevd, the "dm-linear: Device lookup failed" messages also cease, and start coming again when it is started.

I'm not sure what the fix is, since I don't want to run my system with udevd stopped.

I should note, if it's related, that I'm not using any RAID or LVM partitions.
I have two hard drives, though the system is installed entirely on hdc.

I am running a custom-compiled version of 2.6.19, because I need the BadRAM patch.
Kernel settings are copied from the Ubuntu kernel.
I will reboot to the Ubuntu-provided kernel and report if it makes any difference.

ProblemType: Bug
Date: Sun Mar 4 12:59:37 2007
DistroRelease: Ubuntu 7.04
Uname: Linux hal9000 2.6.19 #1 SMP PREEMPT Tue Feb 27 11:47:09 EST 2007 i686 GNU/Linux

Revision history for this message
Stephen Sinclair (radarsat1) wrote :

Okay, sorry. Nevermind. I rebooted to the Ubuntu kernel (2.6.20-9-generic) and I did not get the same behaviour. I guess it is related to some upstream kernel bug that has been fixed in later versions. For my part, I removed the dm-mod.ko module, and it "fixed" this problem for me. (Since I am not using LVM I don't need this anyway.)

This bug can be closed.

Revision history for this message
WillDyson (will-dyson) wrote :

I get a similar symptom when testing a mainline 2.6.21-rc3 kernel.

It seems to be some kind of udev event loop involving the lvm2 and evms udev rules. It is triggered for me when evms_activate is run.

Attached file is a log obtained by booting without the evms init script, turning on udev debug logging and then running evms_activate manually.

What is very confusing to me is why (how) the ubuntu 2.6.20 kernel suppresses this behavior.

Revision history for this message
phaidros (phaidros) wrote :

I get similar behaviour on 2.6.19-4 with xen. (which is the only xen kernel in feisty so far).

2.6.20-[9-13]-[generic|lowlatency|server] don't have this behaviour.

2.6.20-X xen kernel might solve this :)

Changed in udev:
status: Unconfirmed → Fix Released
Revision history for this message
Scudette (scudette) wrote :

I also have the same problem with kernel 2.6.18 running on a cryptroot. This does seem to be some kind of loop entered by udev. For me this fixed the issue:

/etc/udev/rules.d/85-evms.rules:

commenting out this:
#SUBSYSTEM=="block", ACTION=="add|change", KERNEL=="dm-*", GOTO="evms_activate_do"

fixes the issue.

Revision history for this message
Sebastian Berthold (sleif) wrote :

the fix above disables usage of dm (softraid) feature - this is not so good :-(

so I am not able to use the feisty xen kernel together with Software Raid0 or Raid5.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.