[SOLVED] 50-udev.rules causes start_udev to hang on boot

peridian · 08-14-2010, 05:53 AM

Hi,

I've been having problems with start_udev on my machine post kernel 2.6.18-162 on my CentOS machine. A previous install would work on the old kernel, but not the newer ones. I recently did a completely fresh install of CentOS 5.5, to see if maybe there was a corruption in my install when it upgraded, but I still have the problem of udev hanging on startup.

Using the rescue option on the disk, I've managed to track the problem down to the 50-udev.rules file. Through trial and error, I moved all the .rules files out of the rules.d directory, and added them back one at a time to see which one(s) caused the system to hang, and which ones it carried on booting as normal with. The only one that causes it to hang is the 50-udev.rules.

From what I can tell, this rules file is responsible for letting udev check various pieces of hardware. I think that it is failing when it runs modprobe on a pci device address.

Only problem is I don't understand the rules file syntax, so I don't know if I can simply comment out or change a line in this file to skip the device that its looking for.

Can anybody help me track down the specific device/line that is doing this?

(I've kept the file out of the folder for now and my system appears to continue operating, but I get the occasional problem that for all I know could be due to udev not having a complete start up).

Regards,
Rob.

DrLove73 · 08-14-2010, 07:06 AM

Have you updated your system to the latest versions?

You are referring to 2.6.18-162, when last kernel is 2.6.18-194.11.1

peridian · 08-14-2010, 09:49 AM

162 is the kernel that I know the system works on.
Its the latest 194 kernels that it does not work on.

162 is what my original install of CentOS was done on, and when I updated to 194, it started having problems.

194 is what my latest fresh install of CentOS was done on, and it has been having problems from the very start.

peridian · 08-14-2010, 09:53 AM

I'm not a hundred percent sure, but could the problem be in my modprobe.conf file?

Code:

alias eth0 r8169
alias eth1 forcedeth
alias eth2 forcedeth
alias scsi_hostadapter sata_nv
alias snd-card-0 snd-hda-intel
options snd-card-0 index=0
options snd-hda-intel index=0
remove snd-hda-intel { /usr/sbin/alsactl store 0 >/dev/null 2>&1 || : ; }; /sbin/modprobe -r --ignore-remove snd-hda-intel

DrLove73 · 08-14-2010, 03:02 PM

Ok. I'll try to help.

First try to replace this line:

Code:

options snd-hda-intel index=0

with this one:

Code:

options snd-hda-intel index=0 enable_msi=0

If this does not help, then please provide motherboard model, info on all cards plugged in motherboard, and output of

Code:

lspci

command, and/or try commenting out line:

Code:

alias scsi_hostadapter sata_nv

And please read this thread: http://www.centos.org/modules/newbb/...7276#threadtop

peridian · 08-15-2010, 07:28 AM

Excellent! The enable_msi part did the trick.

This of course leads me to two questions:

a) Why would that have worked?
b) What problems (if any) will having this option in there cause?

I've posted below the lspci results anyway:

Code:

00:00.0 RAM memory: nVidia Corporation C51 Host Bridge (rev a2)
00:00.1 RAM memory: nVidia Corporation C51 Memory Controller 0 (rev a2)
00:00.2 RAM memory: nVidia Corporation C51 Memory Controller 1 (rev a2)
00:00.3 RAM memory: nVidia Corporation C51 Memory Controller 5 (rev a2)
00:00.4 RAM memory: nVidia Corporation C51 Memory Controller 4 (rev a2)
00:00.5 RAM memory: nVidia Corporation C51 Host Bridge (rev a2)
00:00.6 RAM memory: nVidia Corporation C51 Memory Controller 3 (rev a2)
00:00.7 RAM memory: nVidia Corporation C51 Memory Controller 2 (rev a2)
00:02.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1)
00:03.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1)
00:04.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1)
00:08.0 RAM memory: nVidia Corporation MCP55 Memory Controller (rev a1)
00:09.0 ISA bridge: nVidia Corporation MCP55 LPC Bridge (rev a2)
00:09.1 SMBus: nVidia Corporation MCP55 SMBus (rev a2)
00:09.2 RAM memory: nVidia Corporation MCP55 Memory Controller (rev a2)
00:0a.0 USB Controller: nVidia Corporation MCP55 USB Controller (rev a1)
00:0a.1 USB Controller: nVidia Corporation MCP55 USB Controller (rev a2)
00:0c.0 IDE interface: nVidia Corporation MCP55 IDE (rev a1)
00:0d.0 RAID bus controller: nVidia Corporation MCP55 SATA Controller (rev a2)
00:0d.1 RAID bus controller: nVidia Corporation MCP55 SATA Controller (rev a2)
00:0d.2 RAID bus controller: nVidia Corporation MCP55 SATA Controller (rev a2)
00:0e.0 PCI bridge: nVidia Corporation MCP55 PCI bridge (rev a2)
00:0e.1 Audio device: nVidia Corporation MCP55 High Definition Audio (rev a2)
00:10.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a2)
00:11.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a2)
00:12.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a2)
00:16.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a2)
00:17.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a2)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
03:00.0 VGA compatible controller: ATI Technologies Inc RV710 [Radeon HD 4350]
03:00.1 Audio device: ATI Technologies Inc RV710/730
04:08.0 FireWire (IEEE 1394): Texas Instruments TSB82AA2 IEEE-1394b Link Layer Controller (rev 01)
04:09.0 Ethernet controller: Linksys Gigabit Network Adapter (rev 10)

Thanks again,
Rob.

DrLove73 · 08-15-2010, 03:37 PM

According to a post I read, there are some problems with some nVidia chipsets and "enable_msi=0" fixes something. Did not care to look into it. Most likely it will be fixed in following kernel versions, it's in bugzilla I believe.