Red Hat Bugzilla – Bug 69851
kudzu hangs on dell poweredge 1650
Last modified: 2014-03-16 22:29:18 EDT
kudzu hangs the box at boot time while probing. The machine hasn't crashed, but since the init process will not continue if kudzu waits forever, I had to reboot and remove kudzu from the boot process I'm attaching an strace of kudzu ran by hand You used to have a script that dumped most of the hw config, but I can't find that in RH 7.3 anymore. Feel free to ask for config info that you'd like. You have the whole strace, but basically it seems to hang on the probing of the second serial port: stat64("/var/lock/LCK..ttyS1", 0xbffff550) = -1 ENOENT (No such file or director y) readlink("/dev/modem", 0xbffff620, 32) = -1 ENOENT (No such file or directory) open("/dev/ttyS1", O_RDWR|O_NONBLOCK) = 3 fcntl64(3, F_SETFL, O_RDONLY) = 0 ioctl(3, SNDCTL_TMR_TIMEBASE, {B1200 -opost -isig -icanon -echo ...}) = 0 ioctl(3, SNDCTL_TMR_TIMEBASE, {B1200 -opost -isig -icanon -echo ...}) = 0 ioctl(3, SNDCTL_TMR_START, {B9600 -opost -isig -icanon -echo ...}) = 0 ioctl(3, SNDCTL_TMR_TIMEBASE, {B9600 -opost -isig -icanon -echo ...}) = 0 ioctl(3, 0x5415, [TIOCM_DTR|TIOCM_RTS|TIOCM_CTS|TIOCM_CAR|TIOCM_RNG|TIOCM_DSR|0x 4000]) = 0 ioctl(3, 0x5418, [TIOCM_DTR|TIOCM_CTS|TIOCM_CAR|TIOCM_RNG|TIOCM_DSR|0x4000]) = 0 nanosleep({0, 200000000}, 0) = -1 EINTR (Interrupted system call) It sits in that nanosleep forever
So, presumably, if you from the command line run "kudzu -p -b serial", it also hangs?
Correct, kudzu -p -b serial hang in the exact same place Outside of fixing the specific problem, wouldn't it be a good idea for kudzu to touch a file in /var/something as often it it can, and spawn a small shell process in the kudzu init script that kills kudzu if it hasn't touched the file in x seconds? (considering that hanging the boot process is bad, that'd probably be a good thing)
We are seeing what appears to be this same bug under Red Hat 9 with the SMP kernel. We did *NOT* see it on the same boxes with Red Hat 7.3. It only appears to occur on specific systems. My only guess is that it is specific to particular BIOS revisions or possibly something even more subtle like the chipset revision.
Closing out bugs on older, no longer supported releases. Apologies for any lack of response. Please attempt to confirm with more recent releases.