UDEV issues (SOLVED)

[gaf-mNDKBlG2WHs at public.gmane.org (Jerry Feldman)]

After some research of my own as well as some feedback on GNHLUG, the
problem and solution is on the Red Hat Bugzilla list (bug #444900)

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

There are a lot of hits on the web regarding udev hanging, but this one n=
arrowed it right in. The solution was to blacklist edac_mc and i5000_edac=
=2E If you set the modprobedebug kernel flag (RHEL 5) you will see the la=
st 2 entries are when tries to load edac_mc and i5000_edac. Note that the=
 kernel flags are a bit different on Fedora. Part of the difficulty in de=
bugging this is that the problem seems to show up when the /sbin/starting=
_udev script executes its wait_for_queue)() function that is essentially =
/sbin/udevsettle with or without a timeout. This also seems to be specifi=
c with various Supermicro mother boards.=20

On 01/08/2010 02:07 PM, Jerry Feldman wrote:
> On 01/07/2010 12:35 PM, Jerry Feldman wrote:
>  =20
>> I'm trying to get one of our servers to boot with 64GB. One of the
>> servers won't recognize 4GB DIMMs, but after switching to another brok=
en
>> server we were able to get it up to 53GB with a good boot (RHEL 5.2),
>> but after adding an additional SATA and replacing the 4 remaining 1GB
>> DIMMs, the kernel boots fine, but we hang on udev. I've got a few othe=
r
>> things I might try, but I am looking for some other ideas. This is an
>> Intel whitebox with a Supermicro X7DB8+ MB currently flashed at BIOS
>> 2.1. I may reflash it to 2.1a and possibly remove the second SATA.
>>
>>  =20
>>    =20
> I've been doing more checking. Note that in RHEL you can turn on udev
> debugging as a kernel argument (udevdebug).
> First, 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=3D180). With udevdebug set I have a number of messages show=
ing
> 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, paralle=
l
> and floppy ports in the BIOS. I've also set the noapic and acpi=3Doff
> kernel flags.
>
> I'm going to try to just replace the udevsettle with with a sleep
> command for about 3 minutes. I'd like to know what device we're hanging=

> on because I could rewrite the rules.
>
> Also I have 3 other servers running in the same hardware configuration
> with no problems.
>
>  =20


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