Bug 185236 - Kudzu causes system lock up, during boot processing
Summary: Kudzu causes system lock up, during boot processing
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel   
(Show other bugs)
Version: 5
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2006-03-12 13:57 UTC by Leslie Satenstein
Modified: 2007-11-30 22:11 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-04-26 00:02:52 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Leslie Satenstein 2006-03-12 13:57:57 UTC
+++ This bug was initially created as a clone of Bug #177456 +++

How reproducible:
Every time

Steps to Reproduce:
1. Install FC5 apply patches to version indicated 
Actual results:
system locks up solidly, no indication after 1 second or less of disk activity.
Expected results:
No segfault, as in previous version, and previous version had no lockup

Additional info: 
Hardware is AMD Semptron with 1.98ghz, 756m RAM
/boot is on IDE hda1, grub is on MBR of that disk.
/logical volume setup (default core5 install)

Please attach a backtrace from gdb  (you'll probably want to install

-- Additional comment from aph@redhat.com on 2006-03-10 13:45 EST --
Forget it -- kudzu.x86_64 0: fixes the problem.

Sorry for the noise.

-- Additional comment from lsatenstein@yahoo.com on 2006-03-12 08:43 EST --
root@localhost log]# rpm -qa "kudzu*"

[root@localhost ~]# uname -r
[root@localhost ~]#

I can see the disk led on for about 1 second, then absolute lockup. Tried to
wait 5 minutes to see if there would be a time out, but there was none.

You said (earlier bug report)
Please attach a backtrace from gdb  (you'll probably want to install

My reply...
Please tell me more about how I can help you debug this problem.

Comment 1 Bill Nottingham 2006-03-13 18:03:14 UTC
This does imply a kernel issue. Does this continue with the 2041 kernel?

Comment 2 Leslie Satenstein 2006-03-16 02:23:21 UTC
Please tell me what is gdb going to do for me during (re)boot. I found the
information by starting the program within the program and also within the man
pages.  Back to the problem.

The lockup is now with the following upgrades.

I am writing about a hypervisor problem. Kudzu works fine with the regular
kernel (kernel-2.6.15-1.2054_FC5) but not with the last two recent hypervisors.

Because of Kudzu we are unable to issue a programmable(unattended) reboot
command. The only circumvention is to prevent kudzu from starting.

The weekend of March20 is three days away and I hope that a fix appears in the
iso distribution before the iso images hit the mirrors.


Comment 3 Leslie Satenstein 2006-03-16 02:25:07 UTC
Summary revised to be more precise.

Comment 4 Bill Nottingham 2006-03-16 06:39:07 UTC
If you install strace (may already be installed) and run:

strace /usr/sbin/kudzu

what are the last 10-20 lines?

Comment 5 Dan Thurman 2006-03-16 19:40:45 UTC
Bill asked me to put this information into buzilla so here it is!

1) kudzu hangs the system at boot.  X11 runs but stops at kudzu
script message: "Checking for hardware changes" and it is determined
that kudzu itself (/sbin/kudzu) hangs and ^C (or ANY key-combo) within
boot will NOT terminate kudzu.  You can switch windows with Ctrl-Alt-F1/F8
but the above message is the same - there is no login prompt to log into,
the system is totally hung.

2) You can use FC Rescue and disable kudzu via chkconfig kudzu off,
reboot, then you can log into FC5T3 as I did.  At this point, you can
run kudzu, and it will hang in the terminal window and you can terminate
kuzdu with ^C.  So, somehow kudzu is probably not receiving the ^C signal
at boot time from with the script or perhaps maybe SELinux is blocking,
or ZEN is interferring...  dunno...  that is left to the developer to solve!

3) Following is lspci of my hardware.  Please note that I have NOT installed
ANY drivers or software outside that given from the Fedora Core Development
distribution and that in particular, my "nvidia" is a CHIP-SET installed on
my motherboard - MAYBE this is related but maybe not...  this is not clear.

[root@mysystem ~]# lspci
00:00.0 Host bridge: Intel Corporation 82815 815 Chipset Host Bridge and Memory
Controller Hub (rev 02)
00:01.0 PCI bridge: Intel Corporation 82815 815 Chipset AGP Bridge (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 01)
00:1f.0 ISA bridge: Intel Corporation 82801BA ISA Bridge (LPC) (rev 01)
00:1f.1 IDE interface: Intel Corporation 82801BA IDE U100 (rev 01)
00:1f.2 USB Controller: Intel Corporation 82801BA/BAM USB (Hub #1) (rev 01)
00:1f.3 SMBus: Intel Corporation 82801BA/BAM SMBus (rev 01)
00:1f.4 USB Controller: Intel Corporation 82801BA/BAM USB (Hub #2) (rev 01)
00:1f.5 Multimedia audio controller: Intel Corporation 82801BA/BAM AC'97 Audio
(rev 01)
01:08.0 Ethernet controller: Intel Corporation 82801BA/BAM/CA/CAM Ethernet
Controller (rev 01)
01:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
02:00.0 VGA compatible controller: nVidia Corporation NV5M64 [RIVA TNT2 Model
64/Model 64 Pro] (rev 15)
You have mail in /var/spool/mail/root

Please let me know if you need anything else.


Comment 6 Leslie Satenstein 2006-03-18 00:56:47 UTC
Here is one feedback that was requested. When kudzu locks up with the
hypervisor, the keyboard is dead (non-responsive). Numlock, caps, etc leds do
not reflect the associated keypresses).  

A control-c as requested, does nothing.

I did not try kudzu with selinux disabled, to see if it was the cause of the lockup.

On an non-hypervisor kernel I experience no problems with kudzu. I will test
with selinux disabled and if there is an improvement, I will certainly be
reporting it here.

Comment 7 Markus 2006-03-31 16:04:22 UTC
It also hang up with the kernel-2.6.15-1.2054_FC5 
it hangs at boot time, also at gdb, also at console without a posibility to do a

rgds Markus 

Comment 8 Leslie Satenstein 2006-03-31 17:49:51 UTC
For non-hypervisor kernels, (2054 & 2080) Kudzu performs as expected.At least it
does on my system.

Comment 9 Leslie Satenstein 2006-04-26 00:02:52 UTC
Since the non test version of core5 (March 20th) was released, kudzu, for the
regular kernel (and now 2096) appears to be working normally. By that, I can
only say that it does not lock up the system during a boot.

I would like to close this problem, as my current use shows that it is not a

It was  not a problem for me with Core4 either.

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