You are not logged in.
Pages: 1
Hi! I've been having a strange and annoying problem on my laptop (Clevo M860TU) for a while now.
My udev is acting up. 99% of boots it starts up numerous times (At this very moment 'pgrep -lu root | grep -c udevd' outputs 100.), hogging up to 25% of my CPU at best. I have an Intel Core 2 Duo P9500 2.53GHz processor, so it not really connected to that as far as I can see. Killing and restarting udev changes only the number of udev's running, the CPU load stays the same, only now htop doesn't seem to be able to tell what actually is hogging it. The only things it shows as using more than 0.0% of CPU is a single udev with a load of 2.0%, gvfs-gdu-volume-monitor with 3-4% and devkit-disks-daemon with 0.1-1% CPU usage.
Other strange thing with udev I'm having is during boot. If I boot the laptop with battery power only, there's about a 50% chance that "Waiting for UDev uevents to be processed" hangs for a few minutes.
A similar problem is reported and discussed here. I tried the same tricks as in that topic, starting with de-blacklisting pcspkr-module. /var/log/errors.log gives only two possible leads:
Nov 1 17:33:24 Hostname kernel: ACPI: I/O resource 0000:00:1f.3 [0x1c00-0x1c1f] conflicts with ACPI region SMBI [0x1c00-0x1c0f]
Nov 1 17:33:29 Hostname pulseaudio[6225]: module.c: Module "module-stream-restore" should be loaded once at most. Refusing to load.
0000:00:1f.3 is SMBUS: Intel Corporation 82801I and pulseaudio is quite self-explanatory *grin* I have no idea what Pulse is doing there, though.
Next thing suggested in the topic is using a trick from this topic. The output I get using that trick is the following, flowing over and over again:
UDEV[time] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0 (scsi)
UDEV[time] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr0 (block)
KERNEL[time] change /devices/pci0000:00/0000:00:1f:2/host1/target1:0:0/1:0:0:0 (scsi)
KERNEL[time] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr0 (block)
I am not sure if there's something other than this right at the beginning of the spammage, but this message keeps repeating over and over again, even after the boot sequence. The message spam stops if I kill udevd, leaving behind only the KERNEL change (scsi) and KERNEL change (block) reposting itself every.. 5 seconds I'd say.
'lspci -s 1f.2' shows that 1f.2 is the SATA controller. Also looking into /dev/disk/by-path/pci-0000/:00/:1f.2-scsi-1:0:0:0, it points to /dev/sr0, so optical drive it is.
Problem is I still have no idea what I should do about it all.
The topic ends being resolved by removing a udevd rule file meant for Creative Zen mp3-players. I don't have the said rule, although there is a similar rule (45-libnjb.rules) for multiple Creative and other mp3-players, removing that changed nothing. I still got the hang-on-boot and the elevated CPU-levels.
Would anyone have any ideas what could be causing this? Note that I am obviously not the only person with the problem, in the above topic nick alienman says he has a similar problem, also depending on whether he is booting with AC power or battery power. He does not spesify though, if the hang while booting takes place at Waiting for UDev uevents or ACPI modules.
Last edited by AapoAlas (2009-11-01 16:20:18)
Offline
Pages: 1