UDEV hangs on boot

[Frank DiPrete]

ah.

I saw this bug that mentions a problem on super micro boards and ecc ram 
that may be of interest:

https://bugzilla.redhat.com/show_bug.cgi?id=444900

comment 2 is interesting:
I blacklisted edac_mc and i5000_edac by using rescue mode and was able 
to get the system to boot. While this is now fixed, other folks are 
probably going to run into the problem.

good luck.


Jerry Feldman wrote:
> 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.
>>>
>>>
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> gnhlug-discuss mailing list
> gnhlug-discuss at mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/