Blacklisting edac_mc and i5000_edac did the trick. Additionally, before I did that I tried a few more things, as well as starting the kernel with the 'modprobedebug' flag. This clearly shows that the edac_mc and i5000_edac are the last things that load. What really complicates the debugging is if you look at the start_udev script, the hang appears with the /sbin/udevsettle command which is a red herring.
On 01/10/2010 07:28 AM, Jerry Feldman wrote: > Thanks Frank, > I'll look into this tomorrow. Worth a try. > > On 01/09/2010 03:57 PM, Frank DiPrete wrote: > >> 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. >> >> -- 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/
