CD-ROM polling on some Optiarc drives causes high CPU usage

I have been seeing this exact same behavior on my Acer 4730Z. I am running Ubuntu 9.04 x64, (clean install) and have 4gb Ram. I first noticed this behavior right after an update about 1 month ago. I also have started seeing issues launching a terminal session, but am unsure if the issue is related. When I stop the udevd daemon, CPU use at idle goes back to normal (1-2%)

Same problem here: new FUJITSU SIEMENS Amilo Si 3655 with fresh install of Ubuntu 9.04 x64. Only out of the ordinary: I have VirtualBox OSE installed.

The kernel seems to constantly generate messages that something changed with the DVD drive and udevd is processing the kernel events (according to the udevadm monitor output). It is actually becoming more and more CPU consuming over time. I have no idea how to figure out what the kernel is up to but if someone knows were to look further I'm more than happy to provide more details.

See attachments for more details.

According to the comment by Christian Mallwitz, this is caused by a high number of messages coming from the kernel that require processing

Hi Guys,

Could one of you also test the latest mainline kernel build? It'd be good know if this issue is exhibited with the upstream kernel and thus likely to still be an issue going into Karmic? I'd suggest testing the 2.6.30-rc8 kernel - https://wiki.ubuntu.com/KernelMainlineBuilds . Please let us know your results. Thanks.

Yes, the problem is still there with linux 2.6.30-rc8. With udev-141-1.1, I get a similar udevadm output as Christian Mallwitz. With version 141-1, udevadm lists only the events with SUBSYSTEM=block and omits those with SUBSYSTEM=scsi.

Andreas just beat me to it :-)

I can't see a change after installing 2.6.30-020630rc8-generic.

A few seconds of output from 'udev monitor' after reboot:

KERNEL[1244486895.025752] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0 (scsi)
KERNEL[1244486895.027201] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr0 (block)
UDEV [1244486895.028022] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0 (scsi)
KERNEL[1244486895.067956] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0 (scsi)
UDEV [1244486895.089674] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr0 (block)
KERNEL[1244486895.092314] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr0 (block)
UDEV [1244486895.092369] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0 (scsi)
KERNEL[1244486895.131498] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0 (scsi)
UDEV [1244486895.159624] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr0 (block)
KERNEL[1244486895.170225] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr0 (block)
UDEV [1244486895.170282] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0 (scsi)
KERNEL[1244486895.195337] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0 (scsi)
UDEV [1244486895.220963] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr0 (block)
KERNEL[1244486895.222868] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr0 (block)
UDEV [1244486895.223189] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0 (scsi)
KERNEL[1244486895.259603] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0 (scsi)
UDEV [1244486895.310993] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr0 (block)
KERNEL[1244486895.313741] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr0 (block)
UDEV [1244486895.313789] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0 (scsi)
UDEV [1244486895.418115] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr0 (block)
KERNEL[1244486897.024989] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0 (scsi)
KERNEL[1244486897.026048] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr0 (block)
UDEV [1244486897.026670] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0 (scsi)
KERNEL[1244486897.067019] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0 (scsi)
UDEV [1244486897.118713] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr0 (block)
KERNEL[1244486897.125426] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr0 (block)
UDEV [1244486897.125488] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0 (scsi)
KERNEL[1244486897.151808] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0 (scsi)
UDEV [1244486897.180443] change /devices/pci0000:00/0000:00:1f.2/host1...

No change in kernel 2.6.30-020630-generic.

Something I wanted to point out as the problem seems to be related to the optical drive: the drive is a slot-in drive which sucks in the CD or DVD when inserting a media into the slot.

This bug affects me too. I have found also by killing hald or dbus-daemon(messagebus) the cpu runs normally.

Hi Guys,

Care to do an additional set of testing the 2.6.31-rc3 kernel - Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . If the issue still remains, would one of you also mind opening an upstream bug report at bugzilla.kernel.org? It will allow additional upstream developers to be notified of the issue and possibly help debug. Thanks.

Neither kernel 2.6.31-rc3 nor udev-141-1.2 changed anything. I reported the bug here:
http://bugzilla.kernel.org/show_bug.cgi?id=13783

It's strange but the problem has gone away on my notebook for a few days now (and a few reboots too) and I'm not aware of anything I could have done to make this happen other than installing regular updates. I'm now on kernel version 2.6.28-14-generic.

For me the problem is still there. If I remove the files generated by "hal-disable-polling --device /dev/scd0" (see kernel bug tracker), cpu usage goes up again, with kernel 2.6.28-14 as well as 2.6.30.2.

Hi Guys,

Just want to get some info from everyone still seeing this issue. Can you report which release you're running, which kernel version, and which version of udev you see this issue with? For example:

Karmic kernel=2.6.31-5 udev=145-1

I'm still seeing the issue with:

Jaunty kernel=2.6.28-14 udev=141-1.2

On 8/11/09, Leann Ogasawara <email address hidden> wrote:
> Hi Guys,
>
> Just want to get some info from everyone still seeing this issue. Can
> you report which release you're running, which kernel version, and which
> version of udev you see this issue with? For example:
>
> Karmic kernel=2.6.31-5 udev=145-1
>
> --
> High cpu usage after upgrade to 141-1.1
> https://bugs.launchpad.net/bugs/379780
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in The Linux Kernel: Confirmed
> Status in “linux” package in Ubuntu: Triaged
>
> Bug description:
> Binary package hint: udev
>
> Before I upgraded the udev version of jaunty from 141-1 to 141-1.1, top
> reported about 2% total cpu usage when idle. After the update, it rarely
> drops below 35%. Though top lists udevd among the more cpu hungry processes,
> it is only listed with about 3%, while system (in line 3) almost never drops
> below 20%.
>
> I am using the amd64 version of Xubuntu 9.04 on a Acer Extensa 5230 laptop
> with a 2 GHz Intel Celeron processor, and I have my root, home and swap
> partitions encrypted with luks. I did a fresh install and installed nothing
> but the software updates.
>
> The output of top looks like this:
>
> top - 18:47:33 up 15 min, 2 users, load average: 1.48, 1.99, 1.50
> Tasks: 125 total, 3 running, 122 sleeping, 0 stopped, 0 zombie
> Cpu(s): 11.3%us, 23.9%sy, 0.0%ni, 60.1%id, 0.0%wa, 4.3%hi, 0.3%si,
> 0.0%st
> Mem: 940212k total, 637176k used, 303036k free, 872k buffers
> Swap: 2103444k total, 0k used, 2103444k free, 346116k cached
>
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>
> 939 root 16 -4 16792 600 296 S 3.0 0.1 0:17.03 udevd
>
> 15937 haldaemo 20 0 36304 4872 3756 S 1.7 0.5 0:04.29 hald
>
> 16403 root 20 0 451m 51m 17m R 1.7 5.6 0:25.92 Xorg
>
> 30 root 15 -5 0 0 0 S 0.7 0.0 0:05.52 scsi_eh_1
>
> 5480 andreas 20 0 19116 1328 988 R 0.3 0.1 0:00.89 top
>
> 22747 andreas 20 0 174m 17m 8960 R 0.3 1.9 0:01.14 xfce4-terminal
>
> 1 root 20 0 4104 924 632 S 0.0 0.1 0:00.87 init
>
> 2 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kthreadd
>
> 3 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/0
>
> 4 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/0
>
> 5 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/0
>
> 6 root 15 -5 0 0 0 S 0.0 0.0 0:00.65 events/0
>
> 7 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 khelper
>
> 8 root RT -5 0 0 0 S 0.0 0.0 0:00.00 kstop/0
>
> 9 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kintegrityd/0
> ...
>

I just upgraded and the problem is still there:

Karmic kernel=2.6.31-5 udev=145-1

Karmic kernel: 2.6.31-6-generic udev: 145-1

I too am getting this bug on the Karmic release version. The only reason I'm reporting is that it's happening on my /dev/sdb1 IDE hard disk root partition, not a DVD-ROM/CD-ROM.

A "sudo stop udev; sudo start udev" seems to stop the stream. Karmic kernel: 2.6.31-14-generic; udev: udev_147~-6

Snippet of "sudo udevadm monitor --environment" off a fresh boot (fresh UDEV actions seem to happen roughly once every 10 milliseconds aka 1/100th of a sec):

KERNEL[1256929569.354578] change /devices/pci0000:00/0000:00:0d.0/host5/target5:0:0/5:0:0:0/block/sdb/sdb1 (block)
[snip]
UDEV [1256929569.354642] change /devices/pci0000:00/0000:00:0d.0/host5/target5:0:0/5:0:0:0/block/sdb/sdb1 (block)
[snip]
KERNEL[1256929569.364357] change /devices/pci0000:00/0000:00:0d.0/host5/target5:0:0/5:0:0:0/block/sdb/sdb1 (block)
[snip]
UDEV [1256929569.364423] change /devices/pci0000:00/0000:00:0d.0/host5/target5:0:0/5:0:0:0/block/sdb/sdb1 (block)
UDEV_LOG=3
ACTION=change
DEVPATH=/devices/pci0000:00/0000:00:0d.0/host5/target5:0:0/5:0:0:0/block/sdb/sdb1
SUBSYSTEM=block
DEVNAME=/dev/sdb1
DEVTYPE=partition
SEQNUM=608167
DKD_PRESENTATION_NOPOLICY=0
MAJOR=8
MINOR=17
DEVLINKS=/dev/block/8:17

I can confirm the same behavior with my sony VAIO NS12M. Stopping and restarting udev solves the problem, though, as MattSchnitz pointed out.

The same problem on my new Lenovo Y550. There was no such a case on my previous laptop.
Karmic kernel=2.6.31-14 udev=147~-6.1
Killing udevd solves it.

Apparently, inserting a CDROM into the cd drive fixes this issue for me. The cpu drops to 2-4% when I do this (even an empty DVD-R will do the trick).

After ejecting it, the CPU will go back to 20-40%.

Can I submit anything to enable someone to find a fix?

I think I am experiencing this bug also. For me, it seems like udev keeps taking more and more memory, and the main CPU issue is swapping. It caused a system with 1 GB of memory to become very slow.

Linux tiger 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:05:01 UTC 2009 x86_64 GNU/Linux

(I have another system running 32-bit karmic and I have not seen the issue there, at least with the most recent update to udev.

Stopping udev after the boot process is the only thing I've found that really works.

Possibly part of this: "grep udev /var/log/messages" includes:

Nov 15 07:42:25 tiger kernel: [31726.790151] udevd: page allocation failure. order:3, mode:0x8020
Nov 15 07:42:26 tiger kernel: [31726.790162] Pid: 498, comm: udevd Tainted: P W 2.6.31-14-generic #48-Ubuntu
Nov 15 07:43:23 tiger kernel: [31790.372717] udevd: page allocation failure. order:3, mode:0x8020
Nov 15 07:43:26 tiger kernel: [31790.372729] Pid: 498, comm: udevd Tainted: P W 2.6.31-14-generic #48-Ubuntu
Nov 15 07:45:45 tiger kernel: [31935.006152] udevd: page allocation failure. order:3, mode:0x8020
Nov 15 07:45:45 tiger kernel: [31935.006163] Pid: 498, comm: udevd Tainted: P W 2.6.31-14-generic #48-Ubuntu
Nov 15 07:46:39 tiger kernel: [31989.546806] udevd: page allocation failure. order:3, mode:0x8020
Nov 15 07:46:39 tiger kernel: [31989.546819] Pid: 498, comm: udevd Tainted: P W 2.6.31-14-generic #48-Ubuntu
Nov 15 07:47:52 tiger kernel: [32062.134996] udevd: page allocation failure. order:3, mode:0x8020
Nov 15 07:47:53 tiger kernel: [32062.135007] Pid: 498, comm: udevd Tainted: P W 2.6.31-14-generic #48-Ubuntu
Nov 15 07:48:43 tiger kernel: [32111.153600] udevd: page allocation failure. order:3, mode:0x8020
Nov 15 07:48:46 tiger kernel: [32111.153611] Pid: 498, comm: udevd Tainted: P W 2.6.31-14-generic #48-Ubuntu
Nov 15 07:57:54 tiger kernel: [32660.825587] udevd: page allocation failure. order:3, mode:0x8020
Nov 15 07:57:54 tiger kernel: [32660.825598] Pid: 498, comm: udevd Tainted: P W 2.6.31-14-generic #48-Ubuntu
Nov 15 07:59:40 tiger kernel: [32767.319352] udevd: page allocation failure. order:3, mode:0x8020
Nov 15 07:59:44 tiger kernel: [32767.319357] Pid: 498, comm: udevd Tainted: P W 2.6.31-14-generic #48-Ubuntu
Nov 15 08:01:19 tiger kernel: [32861.030103] udevd: page allocation failure. order:3, mode:0x8020
Nov 15 08:01:19 tiger kernel: [32861.030115] Pid: 498, comm: udevd Tainted: P W 2.6.31-14-generic #48-Ubuntu
Nov 15 08:08:10 tiger kernel: [33274.882455] udevd: page allocation failure. order:3, mode:0x8020

hello,

i have the same problem on an acer extensa notebook, putting a disc in the cdrom also works for me.

top with empty cdrom-drive:

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
13640 root 20 0 5048 2172 1676 S 9.3 0.1 31:10.03 devkit-disks-da
14338 a 20 0 57648 23m 2012 S 8.6 1.2 29:23.67 gvfs-gdu-volume
 7667 messageb 20 0 3372 1744 840 S 7.3 0.1 25:44.88 dbus-daemon
13548 a 20 0 49676 12m 4172 S 5.3 0.6 17:32.29 update-notifier
13616 a 20 0 28644 8828 1296 S 4.6 0.4 14:08.35 gdu-notificatio
28801 root 18 -2 2348 600 284 R 3.3 0.0 0:31.26 udevd
 8654 root 20 0 141m 62m 26m S 1.7 3.2 4:11.26 Xorg
  525 root 20 0 2148 556 416 S 1.3 0.0 5:32.26 upstart-udev-br

top 2 seconds after inserting cd into drive:

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
 8654 root 20 0 141m 62m 26m S 2.0 3.2 4:14.98 Xorg
13949 a 20 0 340m 108m 14m S 1.0 5.6 6:25.10 firefox-bin
  604 root 20 0 2468 1184 884 R 0.3 0.1 0:00.02 top
10016 a 20 0 58240 8260 4976 S 0.3 0.4 0:01.85 gnome-terminal
13024 a 20 0 144m 15m 2344 S 0.3 0.8 0:32.45 compiz.real

oh, and i can also recommend the empty CD/DVD because with a full disc the drive keeps running all the time making some noise.

Confirming this issue on Acer Extensa 5630EZ with Optiarc DVD RW on up-to-date Karmic Koala. Also confirming the workarounds (restarting udev or inserting a CD). Added a comment to kernel bugzilla.

Totally off-topic but this is why I like linux so much: it's the sense of community! Everybody striving to make stuff better... Thank you bug reporters and bug fixers!

yes, but in the meantime my computer is not working properly :P

please, have a look at Bug #481626, because I fear they are not strictly duplicates

Confirming with another Acer Extensa 5630EZ: udevd hogs the cpu and eats memory until the system starts swapping and gets completely unusable. Problem goes away until next reboot after restarting udevd or inserting a CD. Attached "udevadm monitor -e" output.

Karmic kernel=2.6.31-16 udev=147~-6

See remarks:

https://bugs.launchpad.net/ubuntu/+source/devicekit-disks/+bug/481626/comments/9

Summary: "sudo restart udev" resolves the problem at least until the next reboot.

Works, at least partially.. When I restart udev other issues are being induced (e.g. the gnome-power-manager icon is not shown afterwards). Personally I prefer inserting a blank CD for calming the daemons down.

I am experiencing this using Ubuntu 10.04 (kernel 2.6.32-7-generic), Laptop Lenovo T400 .

It seems to be related to the following error which floods daemon.log:
...
Dec 12 14:16:25 laptop init: ureadahead-other main process (18121) terminated with status 4
...
$ grep -c "ureadahead-other main process" daemon.log
40301

After restarting udev the problem was resolved and the ureadahead message logging stopped.

Please ignore my comment, I have found that on my case the high cpu was a consequence from bug:
https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/480564

Similar problem on a Lenovo SL510 thinkpad. After a while udevd goes to 25% CPU.

"sudo restart udev" does not help, I've got to "sudo killall udevd" a couple of times to kill off all udevd instances. Then the CPU goes quiet. Followed by a "sudo start udev" of course.

Problem: after doing that, my usb keyboard/mouse isn't detected anymore when I plug it in. I could not find a way to get that working again, so I've been restarting a few times in the last days. Any quick way to get around that?

Found solution for me:
Tried to restart udev:
service udev restart
(But after restarting, hal - was stopped, and new USB devices are not working in X)

I was looking at:
udevadm monitor
KERNEL[1262607846.033487] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0 (scsi)
KERNEL[1262607846.033845] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr0 (block)
UDEV [1262607846.033967] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0 (scsi)
UDEV [1262607846.148496] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr0 (block)
...

lspci
00:1f.2 SATA controller: Intel Corporation ICH9M/M-E SATA AHCI Controller (rev 03)

With blank disc works for me too.
At processes found:
root 9997 0.0 0.0 3416 1232 ? S 09:58 0:01 hald-addon-storage: polling /dev/sr0 (every 2 sec)

That's why I was trying to disable polling for my cdrom in hal
sudo hal-disable-polling --device /dev/sr0
Polling for drive /dev/sr0 have been disabled. The fdi file written was
  /etc/hal/fdi/information/media-check-disable-storage_model_DVD_RW_AD_7560S.fdi

After that, at process list:
root 31850 0.0 0.0 3416 1136 ? S 14:27 0:00 hald-addon-storage: no polling on /dev/sr0 because it is explicitly disabled

And now, all works fine.

p.s. Sorry for my english :)

I've just updated my 10.04 alpha and the problem went away. It seems the daily update has some kind of fix for this bug.

Cpu usage levels are normal 0-1% (against 10-20% before), when the computer rests. udev functionality is ok too as udevadm monitor doesn't report a loop.

Thanx

AmadeuS: probably because of the disabled i915 power management in the latest lucid kernel, so this is not really fixed.
see LP:492392 and http://changelogs.ubuntu.com/changelogs/pool/main/l/linux/linux_2.6.32-11.15/changelog

This bug was fixed in the package udisks - 1.0.0~git20100223.a38230-2

---------------
udisks (1.0.0~git20100223.a38230-2) experimental; urgency=low

  * New upstream git snapshot:
    - Add support for "disable polling" udev property. (LP: #379780)
    - Rework partition table probing; In particular, always respect
      UDISKS_PARTITION_* and UDISKS_PARTITION_TABLE_* udev properties.
    - Export alignment offset for a partition
    - testsuite: Fix LVM tests

udisks (1.0.0~git20100212.aae17d9-1) experimental; urgency=low

  [ Michael Biebl ]
  * Git snapshot of the upcoming 1.0.0 release:
    - The project has been renamed from DeviceKit-disks to udisks.
    - A program for bridging D-Bus over TCP/IP over SSH has been provided.
    - An API for benchmarking drives has been added.
    - Host Adapters, Ports and Expanders are now exported as D-Bus objects.
    - Intial support for LVM2.
  * Update packaging files for the udisks renaming.
  * Remove patches that have been merged upstream
    - debian/patches/00git-lv-nopolicy.patch
    - debian/patches/02-allow-simulated-smart.patch
    - debian/patches/03-hide-configuration-partition-12.patch
    - debian/patches/04-hide-wd-smartware-partition.patch
    - debian/patches/06-guid-partition-flags.patch
    - debian/patches/07-fix-atasmart-crash.patch
    - debian/patches/09-reiserfs-support.patch
  * Refresh patches
    - debian/patches/01-mkfs-tempdir.patch
  * Disable patches until ported to udisks
    - debian/patches/08-dont-probe-dm-devices.patch
    - debian/patches/10-ide-cd-support.patch
  * Bump Standards-Version to 3.8.4. No further changes.

  [ Martin Pitt ]
  * Build a transitional devicekit-disks-doc package to faciliate the upgrade
    to udisks-doc. Add an epoch to that binary package, since udisks' version
    number is smaller than devicekit-disks'.

devicekit-disks (009-2) unstable; urgency=low

  [ Michael Biebl ]
  * debian/patches/09-reiserfs-support.patch
    - Add support for ReiserFS.

  [ Martin Pitt ]
  * Add debian/local/ubuntu.pkla: Allow passwordless file system operations
    for local foreground admin user sessions on Ubuntu. Install it in
    debian/rules. (LP: #465054)
  * Add 02-allow-simulated-smart.patch: Allow simulated SMART data on
    non-SMART devices. This is both useful for testing DK-disks itself, as
    well as recreating bugs with SMART handling. (fd.o #24772)
  * Add 03-hide-configuration-partition-12.patch: Hide Compaq recovery
    partition type 0x12. (fd.o #24999, LP: #451304)
  * Add 04-hide-wd-smartware-partition.patch: Ignore Western Digital SmartWare
    partitions. (fd.o #25009, LP: #474790)
  * Add 06-guid-partition-flags.patch: Fix setting flags for GUID partitions.
    (fd.o #25034)
  * Add 07-fix-atasmart-crash.patch: Fix common crash when
    devkit-disks-helper-ata-smart-collect succeeds, but returns invalid base64
    data on stdout. (fd.o #25043, LP: #419663)
  * debian/local/apport-hook.py:
    - Drop attaching /etc/fstab; it might contain samba (etc.) passwords which
      need to be filtered out.
    - Collect available ATA SMART blobs; they are very useful in debugging
      libatasmart related problems and do not usually pose ...

I found a temp fix for me. I had top showing the load in excess of 1.00 but after shutting down udevd the load has come down to 0.04. The way I stopped it was:

service udev stop.

I am running Lucid Alpha on x86_64,

# uname -v
#20-Ubuntu SMP Sat Feb 20 05:18:19 UTC 2010

# udevd --version
151

I am not sure of the impact of stopping udev but the load has definitely come down.

Sorry I forgot to add:

# dmesg|grep DVD
[ 2.763607] ata2.00: ATAPI: Optiarc DVD RW AD-7560S, SX01, max UDMA/100, ATAPI AN
[ 2.779568] scsi 1:0:0:0: CD-ROM Optiarc DVD RW AD-7560S SX01 PQ: 0 ANSI: 5

@Mark Fernandes:

You definitely don't want to kill udev, especially in Lucid. Udev has a key role: it monitors your hardware and enables you to use things as the hardware changes. For example, when you plug in a usb device or insert a dvd, gnome will pop up a dialog box asking you what you would like to do. It won't ruin your system to stop udev (I don't think!) but you definitely want it running in general. Things may also begin to not function after you kill it.

@Chase Douglas,

You are right, if the stop udev command is put into /etc/rc.local my usb keyboard and mouse are not recognized at startup. However if I do not have the stop udev command in /etc/rc.local and only run the stop command after booting up and logging in with the usb keyboard and mouse plugged in I get to keep the mouse and keyboard and still reduce the load. Of course, it wont recognize other usb changes subsequently. I understand this is a hack, but if I do not stop udev then I run out of battery power pretty quickly and my laptop heats up very fast.

One point though: this was not an issue with 9.04, because I never experienced this problem there. I did not try 9.10 so I cannot say. So this, to me, indicates that it might not be a hardware problem because the Optiarc DVD drive was working fine in 9.04, unless the drivers have changed with 10.04 and that is causing the excessive load.

Don't kill udev - just restart it: sudo restart udev

For me and others - this cures the problem...

Scott

On Mon, Mar 1, 2010 at 5:07 PM, Mark Fernandes <email address hidden>wrote:

> @Chase Douglas,
>
> You are right, if the stop udev command is put into /etc/rc.local my usb
> keyboard and mouse are not recognized at startup. However if I do not
> have the stop udev command in /etc/rc.local and only run the stop
> command after booting up and logging in with the usb keyboard and mouse
> plugged in I get to keep the mouse and keyboard and still reduce the
> load. Of course, it wont recognize other usb changes subsequently. I
> understand this is a hack, but if I do not stop udev then I run out of
> battery power pretty quickly and my laptop heats up very fast.
>
> One point though: this was not an issue with 9.04, because I never
> experienced this problem there. I did not try 9.10 so I cannot say. So
> this, to me, indicates that it might not be a hardware problem because
> the Optiarc DVD drive was working fine in 9.04, unless the drivers have
> changed with 10.04 and that is causing the excessive load.
>
> --
> CD-ROM polling on some Optiarc drives causes high CPU usage
> https://bugs.launchpad.net/bugs/379780
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in The Linux Kernel: Confirmed
> Status in abstraction for enumerating and managing block devices: Fix
> Released
> Status in “linux” package in Ubuntu: Triaged
> Status in “udisks” package in Ubuntu: Fix Released
>
> Bug description:
> Binary package hint: udev
>
> Before I upgraded the udev version of jaunty from 141-1 to 141-1.1, top
> reported about 2% total cpu usage when idle. After the update, it rarely
> drops below 35%. Though top lists udevd among the more cpu hungry processes,
> it is only listed with about 3%, while system (in line 3) almost never drops
> below 20%.
>
> I am using the amd64 version of Xubuntu 9.04 on a Acer Extensa 5230 laptop
> with a 2 GHz Intel Celeron processor, and I have my root, home and swap
> partitions encrypted with luks. I did a fresh install and installed nothing
> but the software updates.
>
> The output of top looks like this:
>
> top - 18:47:33 up 15 min, 2 users, load average: 1.48, 1.99, 1.50
> Tasks: 125 total, 3 running, 122 sleeping, 0 stopped, 0 zombie
> Cpu(s): 11.3%us, 23.9%sy, 0.0%ni, 60.1%id, 0.0%wa, 4.3%hi, 0.3%si,
> 0.0%st
> Mem: 940212k total, 637176k used, 303036k free, 872k buffers
> Swap: 2103444k total, 0k used, 2103444k free, 346116k cached
>
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 939 root 16 -4 16792 600 296 S 3.0 0.1 0:17.03 udevd
> 15937 haldaemo 20 0 36304 4872 3756 S 1.7 0.5 0:04.29 hald
> 16403 root 20 0 451m 51m 17m R 1.7 5.6 0:25.92 Xorg
> 30 root 15 -5 0 0 0 S 0.7 0.0 0:05.52 scsi_eh_1
> 5480 andreas 20 0 19116 1328 988 R 0.3 0.1 0:00.89 top
> 22747 andreas 20 0 174m 17m 8960 R 0.3 1.9 0:01.14 xfce4-terminal
> 1 root 20 0 4104 924 632 S 0.0 0.1 0:00.87 init
> 2 root 15 -5 0 0 ...

@Mark Fernandes:

You would not see this in 9.04 because the utilities to manage the dvd drive have changed between 9.10 and 10.04. The new method, through udev, just needs to be updated to include support for disabling polling for your series of dvd drive. That is what Martin Pitt has been working on.

Ok after upgrading to the latest kernel I notice slight drop in load activity with udevd, but it is still too high - never below 0.6. Even after restarting it makes no difference. My details are:

# uname -msrv
Linux 2.6.32-15-generic #22-Ubuntu SMP Tue Mar 2 02:23:29 UTC 2010 x86_64

# udevd --version
151

BTW its udisks-daemon that seems to run constantly and grab CPU resources (>11% almost constantly). Stopping udevd automatically stops udisks-daemon.

replying to #43...
>Is there anyone who has this issue but has a different drive?

I'm having this problem of high CPU usage since I upgraded to Karmic 2.6.31-20 with
a MATSHITA DVD-RAM UJ-820S drive. It is solved (till the next reboot) by typing
sudo stop udev
sudo start udev

Mark Fernandes wrote:
> Ok after upgrading to the latest kernel I notice slight drop in load
> activity with udevd, but it is still too high - never below 0.6. Even
> after restarting it makes no difference. My details are:

Mark, I have found if I restart the daemon as the system is still
loading from a boot it may not work. If I wait until everything in Gnome
is loaded and the drive light is off restarting udev usually works. Try
waiting a little longer if you are acting maybe to quickly too. If on
the chance it does not, restart the daemon a second time. This has
always worked for me.

This bug is really bugging me, because despite being upto date with
everything released so far, it wont go away for me. :)

I have tried everything recommended on this thread, but the load does
not come down as much as if I were to shutdown udev completely. I
include a snapshot of all running process, with intermittent udev
restarts, to show that the problem does not go away on my machine.

As you observe in the attached file, the load drops significantly
as soon as I stop udev, but restarting it at various late intervals
does not change the load much.

Interestingly, powertop reports this suggestion for udevd.

The program 'udevd' is writing to file 'block:sr0' on /dev/devtmpfs.
This prevents the disk from going to powersave mode.

This is getting really annoying. This bug is reported for more than a year and it doesn't look as though something is being done to resolve it. Even 10.04, that up to the last update didn't suffer from this bug, now, has it too. I thought the ubuntu community was more active ...

If some of the maintainers could give this bug an importance boost it would really be nice. An Ubuntu system with udev disabled doesn't work properly and I believe this qualifies the bug for more than a "high" (and less than a year for a direct solution).

@Martin Pitt,

udisks now has the ability to disable polling, but what do we need to do to use that for these optiarc drives?

Chase,

the rule support in udisks is meant to be a local workaround, but not actually a solution. Completely disabling polling will also disable media detection.

See http://cgit.freedesktop.org/udisks/commit/?id=fb86ef144bad470b3d8ed761c7bdbe94886e5edd for how such a rule can look like.

i have msi gt725 quad core 2ghz ddr2 4gb ati hd4850 tried karmic with udev 147 6.0 cpu usage about 0 to max 2% then upgraded it to udev ver 147 6.1 cpu went to 30% sudo restart udev helped cpu went to 0%. but this is no solution.
tried lucid beta too with start udev 151 7 the same issue cpu usage around 30% so every time i start ubuntu i need to type sudo restart udev? better i will go back to windows.:)

aha in karmic udev ver 147 6.0 doesn't recognise usb flash drive. where udev 147 6.1 does but u need to type sudo restart udev:)

just checked lucid and in lucid sudo restart udev doesnt help. sudo stop udev does

i also have this kind of bug. with the below command
sudo restart udev
in terminal all looks fine but when i restart my machine i get the problem with high cpu usage again.

Did you came up with any solution for this?

OK I just found a way to drop the CPU load without stopping udev. The trouble is I cannot confirm that this method will work because I was not able to re-duplicate it before posting, so your mileage might vary. Here is what I did:

# hal-disable-polling --device /dev/sr0

It printed a bunch of messages that got lost because I did a top to check the load and was surprised to find that the CPU load dropped instantaneously!!

The funny thing (to me) is if HAL was dropped from Lucid and if I did a fresh install of Lucid so the /etc scripts should not have had any initialization of HAL, why then should any HAL stuff be running?? I sometimes saw: hal-addon-stor running but never thought of stopping it until now. What is even more strange to me is when I do the following right now:

# ps ax|grep hal

 I see:

1862 ? Ssl 0:00 /usr/sbin/hald
 1863 ? S 0:00 hald-runner
 1899 ? S 0:00 hald-addon-input: Listening on /dev/input/event5 /dev/input/event10 /dev/input/event7 /dev/input/event6 /dev/input/event2 /dev/input/event1 /dev/input/event9 /dev/input/event3 /dev/input/event0
 1902 ? S 0:00 /usr/lib/hal/hald-addon-rfkill-killswitch
 1903 ? S 0:00 /usr/lib/hal/hald-addon-leds
 1913 ? S 0:00 /usr/lib/hal/hald-addon-generic-backlight
 1921 ? S 0:00 hald-addon-storage: no polling on /dev/sr0 because it is explicitly disabled
 1926 ? S 0:00 /usr/lib/hal/hald-addon-cpufreq
 1927 ? S 0:00 hald-addon-acpi: listening on acpid socket /var/run/acpid.socket
 3650 pts/1 S+ 0:00 grep hal

So what's going on? Has HAL truly been disabled or what? Any serious explanation of what happened to solve the problem for me would be much appreciated. The load kind of instantly dropped and do not come back after restarting my laptop, which is a good thing in my book. :)

OK I also found that the steps mentioned in my previous post were
temporary, meaning the changes I made did not persist after a couple
of reboots and resumes from suspend.

The good news is now I now have the exact output that occurs after
stopping /dev/sr0, it is as follows

# hal-disable-polling --device /dev/sr0
Polling for drive /dev/sr0 have been disabled. The fdi file written was
  /etc/hal/fdi/information/media-check-disable-storage_model_Optiarc_DVD_RW_AD_7560S.fdi

Clearly this shows that the Optiarc drive is involved, so it is a
genuine problem for those of us that have Optiarc drives. BTW,
stopping polling reduced my load in a matter of seconds from close to
100% to close to 0%.

Please keep this bug active (and critical) till it is fixed by someone
in the know.

Thanks.

Martin Pitt in comment #72 linked to the commit with instructions on how to fix this issue. Polling is not disabled by default because it stops media detection and does not cause issues for most people. Please follow his instructions to disable polling using udev.

Note that udev has replaced hal in this regard in Lucid. The fdi file that hal-disable-polling will have no effect. Thus, the udev rule Martin pointed out must be used.

Thanks Chase (and Martin). Sorry I had not read his earlier post.

The udev rules outlined in Martin's post worked after I rebooted.
I'll post again should anything come up later.

What I cannot understand though is if HAL is disabled, why then does the hald daemon automatically start. I do not have settings that enabled that daemon to start because I am working with the stock installation of Lucid.

All help is much appreciated!

Mark Fernandes [2010-04-08 13:48 -0000]:
> What I cannot understand though is if HAL is disabled, why then does the
> hald daemon automatically start. I do not have settings that enabled
> that daemon to start because I am working with the stock installation of
> Lucid.

The only thing that still uses HAL is gnome-power-manager, when you
have a graphics card/driver which does not support the XBACKLIGHT
extension. g-p-m falls back to HAL then and triggers its startup.

For those like me, who have no idea what to do with udev rules, here are step by step intructions to fixing this problem:

hit alt+F2 for command line (or open a terminal if you prefer).

paste this command for gedit to open the rules file with root:
# gksu gedit /etc/udev/rules.d/70-persistent-cd.rules

Paste these lines at the end of the file to add the udev rule (provided by Martin Pitt on #72):
SUBSYSTEM=="block", ENV{ID_VENDOR}=="Optiarc*", ENV{ID_MODEL}=="*AD-7640S*", \
      ENV{UDISKS_DISABLE_POLLING}="1"

Save & restart udev (sudo restart udev).

That's it.

I am extremely disappointed by the way this bug was treated. The optiarc cd-rom and dvd drives can be found on many laptops and the high cpu-usage is a real issue. Instead of addressing this problem as a real bug and releasing an actual solution we were presented with a lot of non-user-level data and a problem bypass that doesn't really give an ordinary person the ability to fix the problem.

So much for "Linux for human beings" ... (Again, Extremely disappointed)

Dears,

I have a problem with cpu load too. I have a Optiarc DVDRW drive AD-7560S
dmesg:
[ 1.945663] ata2.00: ATAPI: Optiarc DVD RW AD-7560S, S803, max UDMA/100, ATAPI AN
[ 1.959585] ata2.00: configured for UDMA/100
[ 1.977169] scsi 1:0:0:0: CD-ROM Optiarc DVD RW AD-7560S S803 PQ: 0 ANSI: 5
[ 1.982436] sr0: scsi3-mmc drive: 24x/24x writer dvd-ram cd/rw xa/form2 cdda tray
[ 1.982441] Uniform CD-ROM driver Revision: 3.20
[ 1.982596] sr 1:0:0:0: Attached scsi CD-ROM sr0
[ 1.982691] sr 1:0:0:0: Attached scsi generic sg1 type 5

uname -a
Linux sergey-laptop 2.6.32-22-generic #33-Ubuntu SMP Wed Apr 28 13:27:30 UTC 2010 i686 GNU/Linux

how explained in the in comment #82 /#72, I was add a sting:
SUBSYSTEM=="block", ENV{ID_VENDOR}=="Optiarc*", ENV{ID_MODEL}=="*AD-7640S*", \
      ENV{UDISKS_DISABLE_POLLING}="1"
to /etc/udev/rules.d/70-persistent-cd.rules and changed only part with ID_MODEL for my DVD drive, in the final a had a string:
SUBSYSTEM=="block", ENV{ID_VENDOR}=="Optiarc*", ENV{ID_MODEL}=="*AD-7560S*", \
      ENV{UDISKS_DISABLE_POLLING}="1"

I was save and reboot udevd but this is not help me.
Where I was wrong in the string for my Optiarc DVDRW drive AD-7560S: SUBSYSTEM=="block", ENV{ID_VENDOR}=="Optiarc*", ENV{ID_MODEL}=="*AD-7560S*", \
      ENV{UDISKS_DISABLE_POLLING}="1"

Anybody help please!!!!!

And in: ps ax|grep hal
 2406 ? Ssl 0:04 /usr/sbin/hald
 2407 ? S 0:00 hald-runner
 2434 ? S 0:00 hald-addon-input: Listening on /dev/input/event5 /dev/input/event7 /dev/input/event2 /dev/input/event1 /dev/input/event8 /dev/input/event3 /dev/input/event0 /dev/input/event12
 2436 ? S 0:00 /usr/lib/hal/hald-addon-rfkill-killswitch
 2447 ? S 0:00 /usr/lib/hal/hald-addon-generic-backlight
 2510 ? S 0:00 hald-addon-storage: polling /dev/sr0 (every 2 sec)
 2511 ? S 0:00 /usr/lib/hal/hald-addon-cpufreq
 2512 ? S 0:00 hald-addon-acpi: listening on acpid socket /var/run/acpid.socket
18684 pts/0 S+ 0:00 grep --color=auto hal

so, I was fix this problem:
in the terminal:

sudo hal-disable-polling --device /dev/sr0

sudo service udev restart

as a result the udevd stop a processor load...

maroshka,
    Please do not arbitrarily change bug statuses. If you feel you have an issue that resembles the one in this bug, please open a new bug. This is especially true if you have differing hardware or if the issue is not quite the same.

Thanks!

~JFo

I tried sudo hal-disable-polling --device /dev/sr0, restarting udev, and even the firmware update. Unfortunately udevadm monitor still shows repeats of the following (about once a second):

UDEV [1276134766.174897] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0 (scsi)
UDEV [1276134766.271019] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr0 (block)

Most noticeably annoying with the Lucid CD in the drive, as the software sources pop-up keeps appearing.

@Jeremy Foshee

how do i get this "released fix" ? i use 10.04 with all patches installed and the problem still persists.

broe, then you are experiencing a different issue. Please file a new bug so that we can look into it.

Thanks!

~JFo

I have an MSI GX620 with an optiarc drive. A firmware update fixed it for me. Here is a link to my blog post about it:
http://www.benninger.ca/?p=27

On 08/11/10 01:11, cdawg wrote:
> I have an MSI GX620 with an optiarc drive. A firmware update fixed it for me. Here is a link to my blog post about it:
> http://www.benninger.ca/?p=27
>
The problem had gone away for me on 10.10

The correct file for me would be
http://ftp.euro.dell.com/rmsd/AD-7580S%20FD06.zip in the same directory
as you posted.

Thanks