Bug 185236
| Summary: | Kudzu causes system lock up, during boot processing | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Leslie Satenstein <lsatenstein> |
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> |
| Status: | CLOSED NOTABUG | QA Contact: | Brian Brock <bbrock> |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | 5 | CC: | aph, dant, dex.mbox, notting, svandermeer7, wtogami |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-04-26 00:02:52 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Leslie Satenstein
2006-03-12 13:57:57 UTC
This does imply a kernel issue. Does this continue with the 2041 kernel? 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. kernel-xen0-devel-2.6.15-1.2041_FC5 kernel-xen0-devel-2.6.15-1.2054_FC5 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. Leslie Summary revised to be more precise. If you install strace (may already be installed) and run: strace /usr/sbin/kudzu what are the last 10-20 lines? 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. Dan 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. 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 ctrl-c rgds Markus For non-hypervisor kernels, (2054 & 2080) Kudzu performs as expected.At least it does on my system. 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 problem. It was not a problem for me with Core4 either. |