With 2.6.18.4-116, udev hangs when loading sr_mod on my machine. I bisected the issue down to: http://git.engineering.redhat.com/?p=users/dzickus/rhel5/kernel;a=commit;h=325d5462da6613a1353fa8cbc4603e8f056e67b1 commit 325d5462da6613a1353fa8cbc4603e8f056e67b1 [scsi] modify failfast so it does not always fail fast Attaching 'lspci -v' output and a log from booting with 'udevdebug' The log shows that 'modprobe sr_mod' is the first command to hang; also, at the end it shows: sr 0:0:1:0: timing out command, waited 120s sr 0:0:1:0: timing out command, waited 120s sr 0:0:1:0: timing out command, waited 120s sr 0:0:1:0: timing out command, waited 120s The issue seems to be caused by a fairly simple typo; attaching a patch below
Created attachment 317454 [details] 'lspci -v' output
Created attachment 317456 [details] 2.6.18.4-116.el5-udev-hang.long
Created attachment 317458 [details] scsi-fix-regression-introduced-by-typo-in-failfast.patch
Created attachment 317459 [details] scsi-fix-regression-introduced-by-typo-in-failfast.patch Wow - emacs really screwed that up ...
This is keeping our performance team from running their standard battery of tests.
Looks like this patch actually made it into -117.el5 and I'm not longer seeing the hang. Will continue to test.
in kernel-2.6.18-117.el5 You can download this test kernel from http://people.redhat.com/dzickus/el5
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2009-0225.html