Bug 151173
Summary: | Disabling IRQ #10 causes install to fail | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Matt Domsch <matt_domsch> |
Component: | kernel | Assignee: | Dave Jones <davej> |
Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Brian Brock <bbrock> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 4 | CC: | pfrields, wtogami |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2006-05-04 13:22:38 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
Matt Domsch
2005-03-15 17:08:01 UTC
Install succeeds if I use 'noirqdebug=1' on the kernel command line. But it feels slow (about a minute to download ~61MB stage2.img via HTTP from a server over 1GbE with only one switch between the server and the install target. We have the exact same behaviour on a Dell PE 6650 but with RHEL4U1 (works with RHEL4 GA.) The installation is PXE-booted and installed over NFS. Other IA32-boxes suck as Dell PE2650 does not seem to be affected. noirqdebug=1 is a work-around and I can't see a big performance hit. But very disturbing as it took me about ~1 hour to find this bugzilla! Mass update of -test bugs to update version to fc4. (Please retest on final release, and report results if you have not already done so). Thanks. _Probably_ not fixed in FC4, is fixed in rawhide, if it's the same bug as on some of our IBM Blades (older hw revision, newer ones were fine). Using a rawhide kernel for installation fixed the issue Something was causing "disabling IRQ #7" in post-install to happen in any case, and the installer just hung. Didn't try noirqdebug=1 as a workaround yet, as the "use newer kernel" seemed to be much more effective, as the boxes needed acpi=off to make it past "/sbin/loader" in the first place. Mass update to all FC4 bugs: An update has been released (2.6.14-1.1637_FC4) which rebases to a new upstream kernel (2.6.13.2). As there were ~3500 changes upstream between this and the previous kernel, it's possible your bug has been fixed already. Please retest with this update, and update this bug if necessary. Thanks. This is a mass-update to all currently open kernel bugs. A new kernel update has been released (Version: 2.6.15-1.1830_FC4) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO_REPORTER state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. Thank you. Closing per previous comment. |