UDEV hangs on boot

Jerry Feldman gaf at blu.org
Sat Jan 9 09:46:34 EST 2010


Good idea.
It is x86_64 with 2 Intel Woodcrest dual core CPUs. BTW: The BIOS sees
all 64GB memory and reports it as good. (I had it set to specifically
check the memory at one point just to make sure).
In your case, you have an i686 that does not support more than 3GB
unless PAE is set. I'm looking for any clues, possibly irrelevant. If
you do a google search for udev hangs at boot, you will get over 100,000
hits.

On 01/09/2010 09:29 AM, Frank DiPrete wrote:
>
>
> Is this an x86_64 or an i686?
> Check your kernel config in /boot
>
> My centOS 5.4 i686 machine running kernel 2.6.18-164.9.1.el5 has the
> following:
>
> CONFIG_HIGHMEM4G=y
> # CONFIG_HIGHMEM64G is not set
>
>
>
>
> Jerry Feldman wrote:
>> I'm trying to get one of our servers to boot with 64GB. The kernel
>> boots, but "starting UDEV" hangs.
>> This is an Intel whitebox with a Supermicro X7DB8+ MB currently flashed
>> at BIOS 2.1a. The memories are 16 4GB DIMMS (Kingston) that have been
>> certified by Supermicro. This occurs on both RHEL 5.2 and RHEL 5.3. I've
>> got 3 other nearly identical servers running successfully. I've changed
>> the PCI hole from 256MB to 1GB to 2GB.. This is a pulldown in the BIOS
>> and I only have these choices (actually 512 also).
>>
>> I've been doing more checking. Note that in RHEL you can turn on udev
>> debugging as a kernel argument (udevdebug).
>> I've determined that the culprit is udevsettle that resides in
>> /sbin/start_udev. This is a hard hang, and setting a timeout value does
>> nothing (eg. udevtimeout=180). With udevdebug set I have a number of
>> messages showing that some of the udev tasks have completed, but I have
>> not been able to track them to a device. The only way to access the
>> script is to boot into the rescue. I've also determined that removing
>> the additional 2 SATA drives makes no difference. I've disabled both the
>> serial, parallel and floppy ports in the BIOS. I've also set the noapic
>> and acpi=off kernel flags. Additionally, I've modified the
>> /sbin/start_udev script replacing udevsettle with /bin/sleep, which also
>> hangs.
>> Setting the udevdebug flag causes a lot of messages to scroll by on the
>> screen, but I don't see anything that would be a red flag. Additionally,
>> I've set modprobedebug. This shows that there are several modules that
>> have FATAL failures because of no file found.
>> If I comment out /sbin/start_udev in rc.sysinit, I do get a somewhat
>> working system, with no graphics (which is ok).
>>
>> Some history, is that we were fiddling around and placed 1 1GB DIMM in
>> each bank and we were able to boot.
>> Additionally, we boot into the rescue with no problems.
>>
>> One thing I am going to try on Monday is possibly trying to run a live
>> CD (possibly Fedora), but in the long run I need to run either RHEL 5.2
>> (preferred) or RHEL 5.3.
>>
>> Just one more tidbit. I had another system that was using 16 1GB DIMMS,
>> when I upgraded that, it had the same problem, but after I rebooted it,
>> I was unable to get it back up, and when I did it would not recognize
>> the 4GB DIMMS, but since I had another dead system (power supply and
>> power switch), we moved the memories to that system.
>>
>> Additionally, I di occasionally receive a checksum error on the BIOS
>> (both machines), but not on every boot.
>>
>>


-- 
Jerry Feldman <gaf at blu.org>
Boston Linux and Unix
PGP key id: 537C5846
PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB  CA3B 4607 4319 537C 5846


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
Url : http://mail.gnhlug.org/mailman/private/gnhlug-discuss/attachments/20100109/87c9038b/attachment.bin 


More information about the gnhlug-discuss mailing list