Udev times out at boot

tmvphil · 2010-02-22 23:20:00

When I first installed arch several months ago, I had an issue with Udev timing out at boot. After doing some reading I got the suggestion to use the ubuntu-udev package from AUR. This fixed the problem, but had the unfortunate side effect of not playing nice with other packages, preventing me from updating the rest of the system. I removed the ubuntu version and reinstalled udev from core, hoping an update would have fixed it in the intervening time. Unfortunately no.

At login udev hangs and times out, then flashes a bunch of messages with pci:0000.... headers. /var/log/errors.log gives these messages

Feb 21 19:18:41 thanatos kernel: ACPI: I/O resource 0000:00:1f.3 [0x1c00-0x1c1f] conflicts with ACPI region SMBI [0x1c00-0x1c0f]
Feb 21 19:18:41 thanatos kernel: mmc0: Unknown controller version (2). You may experience problems.

lspci -s 1f.3 shows

00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 03)

grepping dmesg for 1f.3 shows

i801_smbus 0000:00:1f.3: PCI INT C -> GSI 19 (level, low) -> IRQ 19
ACPI: I/O resource 0000:00:1f.3 [0x1c00-0x1c1f] conflicts with ACPI region SMBI [0x1c00-0x1c0f]
ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver

regarding the mmc0 problem dmesg gives

sdhci-pci 0000:0d:06.2: SDHCI controller found [1217:7120] (rev 2)
sdhci-pci 0000:0d:06.2: PCI INT A -> GSI 22 (level, low) -> IRQ 22
mmc0: Unknown controller version (2). You may experience problems.
Registered led device: mmc0::
mmc0: SDHCI controller on PCI [0000:0d:06.2] using DMA

for reference the hardware section of rc.conf reads

MOD_AUTOLOAD="yes"
#MOD_BLACKLIST=() #deprecated
MODULES=(!usblp !pcspkr !acerhdf !ieee1394 !ohci1394 !snd_pcsp)

Some people reported unblacklisting pcspkr and snd_pscp solving their udev problems, but it doesn't seem to work for me.

Thanks in advance to anyone who can help.

tmvphil · 2010-02-27 01:48:48

Further inspection of the messages printed at boot show that it is the 1f.*2* device that is causing the issue. It lspci's as

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

I'd really appreciate any help on this issue as it dramatically increases my boot time. I know I could reduce the timeout on udevadm but I'd like to avoid having to do that if at all possible.

tmvphil · 2010-03-03 02:45:55

Alright, I've rebooted enough times that i've managed to piece together the message udevadm presents at boot. it reads

sys/devices/pci0000:00/0000:00:1f.2/host5/target5:0:0/5:0:0/ (1735)

It appears that all the messages are identical with the exception of the number at the end. I went to this directory but can't seem to find anything unusual.
Anyone have any idea what this means? Sorry to keep bumping my own post. I'll let it rest after this.

djgera · 2010-03-03 03:10:26

Hello

Some questions/tasks to do:

1) experimenting slow time at initramfs step?
2) experimenting slow time at initscripts step?
3) Ensure that do not have any "lost" (orphaned) udev rule file (of course ignore your custom rules)

for x in /lib/udev/rules.d/* /etc/udev/rules.d/*; do pacman -Qo $x;done > /dev/null

if something is found, and is not custom rule, delete or move to another location outside rules.d path, reboot and test.
4) at console, login as root then:

killall udevd
udevd --daemon
udevadm trigger # experiment the slow here(t)?
udevadm settle #experiment the slow here(s)?

Some usefull options for trigger is --verbose, or doing "split trigger" for example --subsystem-match=block, --subsystem-match=input, etc (names for this at /sys/class/) or using --type

udevadm trigger --verbose --subsystem-match=block

You can trigger for a specyfic device path, etc

also you can monitor events with udevadm monitor to view where is the delay... etc

Good luck

Last edited by djgera (2010-03-03 03:12:30)

tmvphil · 2010-03-03 09:09:07

Hello djgera, and thanks for your reply.

for 1 & 2: I'm not sure what the standard time for these are, but it doesn't seem to be a problem.
3: I have some hplip (printer) rules defined that aren't owned by any package. Just to make sure I moved these files to another directory, but no change.
4: The slowdown is definitely during the settle phase. running udevadm here I can see that what is printed is the event queue remaining at timeout. Again it is the 1f.2 pci device. that is remaining. It seems udev is incapable of settling this device's events.

i ran udevadm test sys/devices/pci0000:00/0000:00:1f.2/host5/target5:0:0/5:0:0/ which show

udev_device_new_from_syspath: device 0x12ac140 has devpath '/devices/pci0000:00/0000:00:1f.2/host5/target5:0:0/5:0:0:0'
udev_device_new_from_syspath: device 0x12bbbd0 has devpath '/devices/pci0000:00/0000:00:1f.2/host5/target5:0:0'
udev_device_new_from_syspath: device 0x12c3ba0 has devpath '/devices/pci0000:00/0000:00:1f.2/host5'
udev_device_new_from_syspath: device 0x12c3e60 has devpath '/devices/pci0000:00/0000:00:1f.2'
udev_device_new_from_syspath: device 0x12c4160 has devpath '/devices/pci0000:00'
udev_device_new_from_syspath: device 0x12c4410 has devpath '/module/sg'
util_resolve_subsys_kernel: path '[module/sg](null)' is '/sys/module/sg'
udev_rules_apply_to_event: RUN 'socket:@/org/freedesktop/hal/udev_event' /etc/udev/rules.d/90-hal.rules:2
udevadm_test: UDEV_LOG=6
udevadm_test: DEVPATH=/devices/pci0000:00/0000:00:1f.2/host5/target5:0:0/5:0:0:0
udevadm_test: DEVTYPE=scsi_device
udevadm_test: DRIVER=sr
udevadm_test: MODALIAS=scsi:t-0x05
udevadm_test: ACTION=add
udevadm_test: SUBSYSTEM=scsi
udevadm_test: run: 'socket:@/org/freedesktop/hal/udev_event'

So the subsystem is scsi. I did udevadm monitor --subsystem-match=scsi. This printed a long stream of kernel change messages, which referred to the same 1f.2 device.

*edit* I did udevadm monitor without filtering by subsystem, and it constantly spams udev and kernel change messages and exclusively this. My entire monitor log for several minutes is made up entirely of 1f.2 messages.

djgera · 2010-03-03 12:58:29

OK, good

Maybe something with cdrom and hal...Try commenting the line RUN at file /etc/udev/rules.d/90-hal.rules and see if the problem goes away. In this way udev does not notify any event to HAL.

djgera · 2010-03-03 13:11:37

Try disable media hal polling the device as suggested below. See
http://bugs.archlinux.org/task/16001

hal-disable-polling --device /dev/yourcddrive

tmvphil · 2010-03-03 23:56:35

I disabled the hal polling for the cd drive. This clears up udevadm monitor but unfortunately it only works if I restart udev after boot. Udev still times out at boot.

I rarely use my cdrom drive... Is there a way to just eradicate it from the system completely? I tried blacklisting sr_mod but that had no effect (maybe I was doing it wrong?)

Thanks again

tmvphil · 2010-03-05 21:47:11

Update: Putting a cd in the drive stops udev from timing out at boot. Its a kludge but it works I guess. The only thing is it continually spins up the disc which is quite loud and annoying. I'd rather just disable the thing completely if possible.

Arch Linux

#1 2010-02-22 23:20:00

Udev times out at boot

#2 2010-02-27 01:48:48

Re: Udev times out at boot

#3 2010-03-03 02:45:55

Re: Udev times out at boot

#4 2010-03-03 03:10:26

Re: Udev times out at boot

#5 2010-03-03 09:09:07

Re: Udev times out at boot

#6 2010-03-03 12:58:29

Re: Udev times out at boot

#7 2010-03-03 13:11:37

Re: Udev times out at boot

#8 2010-03-03 23:56:35

Re: Udev times out at boot

#9 2010-03-05 21:47:11

Re: Udev times out at boot

Board footer