Bug 69851 – kudzu hangs on dell poweredge 1650

Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.

Bug 69851 - kudzu hangs on dell poweredge 1650

Summary:	kudzu hangs on dell poweredge 1650

Status:	CLOSED WONTFIX

Aliases:	None

Product:	Red Hat Linux
Classification:	Retired
Component:	kudzu (Show other bugs)
Sub Component:
Version:	7.3
Hardware:	i386 Linux

Priority	medium Severity medium
Target Milestone:	---
Target Release:	---
Assigned To:	Bill Nottingham
QA Contact:	David Lawrence
Docs Contact:

URL:
Whiteboard:
Keywords:

Depends On:
Blocks:
	Show dependency tree / graph

Reported:	2002-07-25 17:56 EDT by Marc MERLIN
Modified:	2014-03-16 22:29 EDT (History)
CC List:	1 user (show)

See Also:
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:
Story Points:	---
Clone Of:
Environment:
Last Closed:	2005-02-04 17:55:44 EST
Type:	---
Regression:	---
Mount Type:	---
Documentation:	---
CRM:
Verified Versions:
Category:	---
oVirt Team:	---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---

Attachments	(Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

Groups: None (edit)

Description Marc MERLIN 2002-07-25 17:56:55 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

Comment 1 Bill Nottingham 2002-07-25 21:32:39 EDT

So, presumably, if you from the command line run "kudzu -p -b serial", it also
hangs?

Comment 2 Marc MERLIN 2002-07-26 13:15:18 EDT

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)

Comment 3 Dave Miller 2003-07-08 18:03:51 EDT

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.

Comment 4 Bill Nottingham 2005-02-04 17:55:44 EST

Closing out bugs on older, no longer supported releases. Apologies for any lack
of response. Please attempt to confirm with more recent releases.

Note You need to log in before you can comment on or make changes to this bug.