Bug 151173 - Disabling IRQ #10 causes install to fail
Disabling IRQ #10 causes install to fail
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2005-03-15 12:08 EST by Matt Domsch
Modified: 2015-01-04 17:17 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-05-04 09:22:38 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Matt Domsch 2005-03-15 12:08:01 EST
Description of problem:
FC4-test1 kernel kernel-2.6.11-1.1177_FC4.src.rpm
installing from FC4-test1-i386-DVD.iso, loopback mounted and exported via HTTP
from the server
installing onto a Dell PowerEdge 4600 system
 - onboard tg3 NIC enabled and used for downloading images via PXE and HTTP
 - onboard aic7xxx enabled and used for primary storage

While downloading stage2.img the kernel prints a tombstone saying that IRQ10 and
nobody cared, listing the tg3 driver and aic7xxx drivers as both having been
assigned IRQ10.  It then prints "Disabling IRQ #10".  After which, no further
progress is made by the installer of course.

FC3 kernels work fine on this same system.

Tried pci=routeirq, acpi=noirq, and acpi=off options, with no effect.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. install onto config above
2. failure occurs when downloading stage2.img

Actual results:
install hangs

Expected results:
install succeeds

Additional info:
I'll append kernel messages from the serial console.
Comment 1 Matt Domsch 2005-03-15 17:10:11 EST
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.
Comment 2 Henrik Elowsson 2005-06-13 08:39:56 EDT
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!
Comment 3 Dave Jones 2005-06-27 19:31:24 EDT
Mass update of -test bugs to update version to fc4.
(Please retest on final release, and report results if you have not already done

Comment 4 Pekka Pietikäinen 2005-08-23 10:07:33 EDT
_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.

Comment 5 Dave Jones 2005-11-10 17:00:33 EST
Mass update to all FC4 bugs:

An update has been released (2.6.14-1.1637_FC4) which rebases to a new upstream
kernel ( 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.


Comment 6 Dave Jones 2006-02-03 02:33:06 EST
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.
Comment 7 John Thacker 2006-05-04 09:22:38 EDT
Closing per previous comment.

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