[SOLVED] Boot process and issues with UDev

veox · 2010-04-06 18:02:09

I'm using a Hewlett-Packard 6730s laptop and

$ uname -a
Linux <hostname scrubbed> 2.6.32-ARCH #1 SMP PREEMPT <date scrubbed> 2010 x86_64 Intel(R) Core(TM)2 Duo CPU T5670 @ 1.80GHz GenuineIntel GNU/Linux

The kernel is custom, mainly removing unused modules, but also some major stuff.

It has an Intel video card:

$ lspci -vvv | less
00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) (prog-if 00 [VGA controller])
        Subsystem: Hewlett-Packard Company Device 30e8
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Interrupt: pin A routed to IRQ 32
        Region 0: Memory at 58000000 (64-bit, non-prefetchable) [size=4M]
        Region 2: Memory at 40000000 (64-bit, prefetchable) [size=256M]
        Region 4: I/O ports at 70f0 [size=8]
        Expansion ROM at <unassigned> [disabled]
        Capabilities: <access denied>
        Kernel driver in use: i915
        Kernel modules: i915

There were no packages from testing or any system packages built from AUR (-newest or -git).

After updating to kernel 2.6.32.9 (from 2.6.32.8), the screen went blank somewhere along "Starting UDev" or "Loading modules", since KMS was disabled for the video card in the kernel. After setting

$ zcat /proc/config.gz | grep KMS
CONFIG_DRM_KMS_HELPER=m
CONFIG_DRM_I915_KMS=y

this went away.

Updating from 2.6.32.9 to 2.6.32.10 broke things again - the boot process hangs on "Loading modules". The cursor is blinking, but nothing's happening. Running the fallback image blanks the screen (no cursor).

Ideas where to next?

Last edited by veox (2010-04-16 11:43:33)

veox · 2010-04-06 19:34:06

OK, after following these directions on the Wiki it seems that the issue is UDev. Just in case, here's GRUB:

$ cat/boot/grub/menu.lst
timeout   5
default   0
color light-blue/black light-cyan/blue

title  Arch Linux (KMS)
root   (hd0,0)
kernel /vmlinuz26 root=/dev/disk/by-uuid/1b932f10-a3dd-4a5d-8814-28733a8a521e ro i915.modeset=0
initrd /kernel26.img

title  Arch Linux
root   (hd0,0)
kernel /vmlinuz26 root=/dev/disk/by-uuid/1b932f10-a3dd-4a5d-8814-28733a8a521e ro vga=773 logo.nologo
initrd /kernel26.img

title  Arch Linux Fallback
root   (hd0,0)
kernel /vmlinuz26 root=/dev/disk/by-uuid/1b932f10-a3dd-4a5d-8814-28733a8a521e ro logo.nologo
initrd /kernel26-fallback.img

The boot process stalls at "Waiting for UDev uevents" for 180 s, after which a timeout is reached. It then waits for the networking interface, eternally.

sda[1-7] is my (only) hard drive.

Last edited by veox (2010-04-06 19:38:10)

Leonid.I · 2010-04-06 20:48:35

I'm a little confused: can you boot with the stock kernel?
Have you tried compiling out/disabling the KMS support, or use only late KMS?

veox · 2010-04-07 19:23:37

Leonid.I wrote:

I'm a little confused: can you boot with the stock kernel?

I first tried using an oldconfig-generated custom 2.6.32.10 kernel and failed.
The stock 2.6.32.10 kernel also fails.
My old custom 2.6.32.9 works fine.

Leonid.I wrote:

Have you tried compiling out/disabling the KMS support, or use only late KMS?

I've tried specifying i915.modeset=0 in GRUB's menu.lst. The result is in post #2 - it passes the point where the screen used to go blank before. Now it times out during UDev uevents. Can this still be related to KMS?

P.S. One thing that prevents me from properly debugging this is that after it hangs up, there is no other way to restart the machine except the power button. Therefore no log is written to /var/log/everything.log.

Last edited by veox (2010-04-07 20:41:23)

Leonid.I · 2010-04-07 23:20:43

veox wrote:

Now it times out during UDev uevents. Can this still be related to KMS?

Blacklist i915 in rc.conf, just to make sure... The system should use a generic framebuffer, right?

veox wrote:

P.S. One thing that prevents me from properly debugging this is that after it hangs up, there is no other way to restart the machine except the power button. Therefore no log is written to /var/log/everything.log.

If you can modify your /etc/rc.sysinit, there is a call to udevadm. You can always increase timeout:

udevadm settle --timeout=XXX

or call udevadm with --debug option and post the output. Actually, some people from gentoo claimed that they can start the shell instead of udevadm

PS: At least we know, that it is not the filesystem issue

EDIT: Have you considered filing a bug report? The devs should have something constructive to add...

Last edited by Leonid.I (2010-04-07 23:23:13)

veox · 2010-04-09 16:45:15

Thanks, Leonid! I didn't know about /etc/rc.sysinit.

There is currently nowhere to write the udev log, so I'll make a separate partition for that. Without the log, there's not enough information to file a bug report yet.

I'll also try kernels 2.6.32.11 and 2.6.33.2.

veox · 2010-04-16 11:43:14

Update - 2.6.33.2 seems to fix this issue (I tried while it was still in [testing]). It broke another experimental driver I'm using, but that's unrelated.

I'll mark it solved for now.

Arch Linux

#1 2010-04-06 18:02:09

[SOLVED] Boot process and issues with UDev

#2 2010-04-06 19:34:06

Re: [SOLVED] Boot process and issues with UDev

#3 2010-04-06 20:48:35

Re: [SOLVED] Boot process and issues with UDev

#4 2010-04-07 19:23:37

Re: [SOLVED] Boot process and issues with UDev

#5 2010-04-07 23:20:43

Re: [SOLVED] Boot process and issues with UDev

#6 2010-04-09 16:45:15

Re: [SOLVED] Boot process and issues with UDev

#7 2010-04-16 11:43:14

Re: [SOLVED] Boot process and issues with UDev

Board footer