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 <[email protected]> Boston Linux and Unix PGP key id: 537C5846 PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB CA3B 4607 4319 537C 5846
signature.asc
Description: OpenPGP digital signature
_______________________________________________ gnhlug-discuss mailing list [email protected] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
