Bug 107880 - 440GX chipset machine has non working IRQ routing
Summary: 440GX chipset machine has non working IRQ routing
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 2
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Dave Jones
QA Contact:
: 107893 109346 109693 110260 116645 119748 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2003-10-23 23:53 UTC by Phil Oester
Modified: 2015-01-04 22:03 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-04-16 04:15:56 UTC

Attachments (Terms of Use)
console output for successful RHL9.0 boot.iso (5.10 KB, text/plain)
2003-10-24 05:08 UTC, Len Brown
no flags Details
console output for failed Fedora Core 1 test3 boot.iso (4.34 KB, text/plain)
2003-10-24 05:22 UTC, Len Brown
no flags Details
console output for failed Fedora Core 1 test3 boot.iso w/ acpi=force (7.14 KB, text/plain)
2003-10-24 05:28 UTC, Len Brown
no flags Details
proposed patch (1.42 KB, patch)
2003-10-28 23:27 UTC, Phil Oester
no flags Details | Diff
Working patch (1.51 KB, patch)
2003-11-08 00:18 UTC, Phil Oester
no flags Details | Diff
2.6.5 patch (719 bytes, patch)
2004-04-17 01:53 UTC, Len Brown
no flags Details | Diff
Log from successful boot under RH8 (14.71 KB, text/plain)
2004-06-25 14:53 UTC, Brett Wyer
no flags Details
L440GX+ with "C3" boot disk, no parameters specified (8.32 KB, text/plain)
2004-06-25 19:09 UTC, Brett Wyer
no flags Details
L440GX+ with "C3" boot disk, acpi=off pci=usepirqmask specified (6.32 KB, text/plain)
2004-06-25 19:26 UTC, Brett Wyer
no flags Details

Description Phil Oester 2003-10-23 23:53:52 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)

Description of problem:
Unfortunately, the bug with 440GX motherboards has returned.  This same 
behavior occurred in RH 7.1+ (and maybe even 8?).  See this bug for history:


This is an Intel L440GX+ motherboard with onboard AIC7896.  Anaconda gets to 
the point of 'Loading AIC7XXX driver...', then hangs forever.

I have tried booting with the 'apic' option, which was a workaround for the old 
issue, but it still hangs.

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

How reproducible:

Steps to Reproduce:
1.Boot off CD burned from boot.iso with 'ks' option

Actual Results:  Installer hangs when trying to load aic7xxx driver

Expected Results:  Continued installation

Additional info:

Comment 1 Bill Nottingham 2003-10-24 03:55:32 UTC
*** Bug 107893 has been marked as a duplicate of this bug. ***

Comment 2 Len Brown 2003-10-24 05:08:41 UTC
Created attachment 95449 [details]
console output for successful RHL9.0 boot.iso

Comment 3 Len Brown 2003-10-24 05:22:40 UTC
Created attachment 95450 [details]
console output for failed Fedora Core 1 test3 boot.iso

Looks like RHL9.0 ran the dmi_scan.c broken_pirq() function:
> *** Possibly defective BIOS detected (irqtable)
which would enable the APIC, which would work were it
actually built into the install kernel.

RHL9 then tries to read the PIRQ tables:
> PCI: Error 89 when fetching IRQ routing table.
that fails so it presumably continues w/o attempting any PIRQ programming,
which works.

Fedora Core 1 doesn't seem to have broken_pirq() in dmi_scan.c anymore.
I guess the only value it would add is it would over-ride somebody foolishly
asking for "noapic" on a 440gx with APIC built-in.  It was a no-op on the
PIC kernel anyway.

FC1 tries to read the PIRQ tables 
> PCI: Using IRQ router PIIX/ICH [8086/7110] at 00:12.0
and it is a victim of its success -- as the (undisclosed) 440GX PIRQ router
is not compatible with the PIIX.

Too bad we can't tell the kernel to give up on PIRQ routing like it did in

Comment 4 Len Brown 2003-10-24 05:28:16 UTC
Created attachment 95451 [details]
console output for failed Fedora Core 1 test3 boot.iso w/ acpi=force

Unlike RHL9, ACPI is present (but disabled) in the FC1 Test3 install kernel.
Typically acpi=on will enable it, but on the 440GX, the latest BIOS is from
2000 and ACPI disables itself when it sees something that old.

acpi=force (console output attached) gives ACPI a chance to save the day
and program the 440GX PIC, but instead it chokes on the _PRT in the BIOS --
turns out that ignoring ACPI BIOS support from < 2001 was a good idea;-)

Comment 5 Arjan van de Ven 2003-10-24 07:09:42 UTC
There is supposed to be a different workaround for 440GX now; Alan cleaned up
the code we had in RHL9

Comment 6 Alan Cox 2003-10-24 23:18:41 UTC
The Fedora code checks for a 440GX bridge being present and if so it punts back
to BIOS IRQ routing. If that isnt working its a small bug, or perhaps a missing
PCI ident in the check code in pci-irq.c.

You might want to glance over that routine and the rules it uses to decide the
IRQ router isnt valid in the piix router setup function, or I can take a look at
it in July 2004 when I'm back...

Comment 7 Michael K. Johnson 2003-10-27 16:26:41 UTC
Len, can you check the pci-irq.c code as suggested by Alan?

Comment 8 Phil Oester 2003-10-28 23:27:15 UTC
Created attachment 95560 [details]
proposed patch

Comment 9 Phil Oester 2003-10-28 23:28:21 UTC
Looks like this got hosed by the -ac1 patch.  Basically, the comment in pci-
irq.c about not touching 440GX is correct, but the code checks for _450GX_.  

I believe the above patch should fix it, but have not yet rebuild the isolinux 
vmlinuz to verify.

Comment 10 Phil Oester 2003-10-29 15:54:26 UTC
Two questions: 

1) how do I rebuild the vmlinuz in isolinux?  I assumed it would be built by 
rebuilding the BOOT rpm, but the sizes of initrd/vmlinuz are drastically 

2) since 440gx boxes can't be kickstarted at present, will this be fixed prior 
to Core 1 release

Comment 11 Phil Oester 2003-11-08 00:18:57 UTC
Created attachment 95809 [details]
Working patch

I have confirmed that the attached patch allows 440GX boxes to successfully

For those interested, I did the following to replace the isolinux vmlinuz:

rpm -i gcc32-3.2.3-6.i386.rpm
rpm -i kernel-source-2.4.22-1.2115.nptl.i386.rpm
cd linux-2.4.22-1.2115.nptl
cat 440gx.patch | patch -p1
cp configs/kernel-2.4.22-i586.config .config
make oldconfig && make oldconfig     (don't ask...dumb bug)
make dep && make bzImage

Of course the kernel which gets installed by kickstart won't boot on this box
either, but fortunately I install a new one in %post.

Comment 12 Dave Jones 2003-11-20 19:17:02 UTC
*** Bug 110260 has been marked as a duplicate of this bug. ***

Comment 13 Dave Jones 2003-11-20 19:33:18 UTC
*** Bug 109346 has been marked as a duplicate of this bug. ***

Comment 14 acount closed by user 2003-11-21 23:13:25 UTC
This board has a lot of firmware updates, it's interesting to get latest

-> Software & Drivers
-> Non-OS Dependent

2.4.23-rcX kernel contains a fix, give it a try.

Comment 15 Alan Cox 2003-12-24 15:23:23 UTC
The best "Non expert" way to update to Fedora 1 on such a box btw
seems to be the following (a decent net connection helps but you do
only need CD 1 for this 8))

Install RH9 (if not upgrading from it anyway)
Install fedora-release and yum packages from CD#1 of FC1
yum update rpm
rpm --rebuilddb
yum update krb5-libs e2fsprogs
yum update

Then rpm install the RH9 errata kernel

Comment 16 Dave Jones 2004-02-24 12:13:14 UTC
*** Bug 116645 has been marked as a duplicate of this bug. ***

Comment 17 Brent 2004-03-01 14:02:05 UTC
This problem seems to have bitten my again with Fedora Core 2 Test 1.

Now the installer doesn't hang, it detects the Adaptec controller and
it also detects my Mylex controller.  It also detects the RAID 0 drive
that is on the Mylex controller when it is still in the console mode.
 It then brings up X and goes through the various screens, but once it
gets to the "Partitioning Drives" section it barfs on a "No valid
drives to create filesystems on" error.  It doesn't make much sense to
me since I can see in the DMESG output that it detected the drive on
the mylex card.

Comment 18 Len Brown 2004-04-16 21:17:58 UTC
my L440GX+ booted 2.6.5 with "acpi=force" both with 
IOAPIC enabled or with IOAPIC disabled (PIC mode). 
ACPI/PIC-mode had some complaints, so it may 
not work in all configs, but it did boot -- which 
was not the case with earlier kernels. 
While the system booted and interrupts worked, 
the two basic ACPI features didn't work properly. 
The power button did not register ACPI events. 
(though it also didn't instantly poweroff the box, 
 which indicates the system _is_ in ACPI mode) 
Also "init 0" didn't soft power-off the box, but acted 
like "init 6" and rebooted the system. 
I'd be interested in other's experience with "acpi=force" 
on this type of system. 

Comment 19 Len Brown 2004-04-16 22:37:33 UTC
I tested 4 configurations 
2.6.5 SMP kernel acpi=force 
2.4.26 SMP kernel acpi=force 
2.6.5 SMP kernel acpi=force nosmp noapic * 
2.4.26 SMP kernel acpi=force nosmp noapic 
In all 4 cases: 
L440GX+ booted off SCSI & talked to ethernet. 
power button press invoked ACPI events as seen in /proc/interrupts 
init 0 gracefully shut down the system and powered off. 
two notes: 
1. needed to hack 2.5.6 dmi_scan.c for "noapic" to take effect 
    so I could get into PIC mode using the SMP kernel for this test. 
    otherwise it forces ioapic to be enabled when it sees this machine. 
    2.4.26 did not need this hack since it doesn't have that dmi_scan entry. 
2. previously reported 2.6.5 button/init 0 failure turned out to be 
    a configuration problem.  I tested the 2.6 kernel on RHL9 w/ 
    original modutils, so the kernel modules didn't load. 
    So I simply re-built with static modules for the test. 
Maybe the 440GX+ is now a candidate for the fabled ACPI "white list" 
to exempt it from disabling ACPI by default on a system older than 2001, 
or we should consider rolling the default cutoff date back a year. 

Comment 20 Len Brown 2004-04-17 01:53:55 UTC
Created attachment 99505 [details]
2.6.5 patch

Looks like Linus excluded the 440GX part when he ported Alan's
patch to 2.6 from 2.4.	I'll check this into 2.6.6, as well as delete
the dmi_scan stuff it replaces.

Comment 21 Len Brown 2004-04-17 03:25:01 UTC
I've installed FC2-test2 on L440GX+ by using 
linux acpi=force 
on the ISO boot command line. 
So it looks like ACPI can be a "workaround" until the PIRQ patch above 
appears in the non-ACPI kernel -- or you can just stick with ACPI;-) 

Comment 22 Kenneth Bakalar 2004-04-20 01:30:42 UTC
Fedora Core 1. HP Kayak XU 6/300 dual Pentium II, AIC7880 chip. Same 

linux acpi=force

causes a kernel panic.

Comment 23 Florin Andrei 2004-04-28 21:53:54 UTC
acpi=force fixes it for me (FC2test3)

Please note that the actual kernel (not the one that boots up the
installer) does not need acpi=force, however that parameter, if
present, does not hamper normal functioning. It just doesn't care, as
it seems.
Only the install CD needs the acpi=force.

Comment 24 Drew Bertola 2004-05-16 01:07:14 UTC
From Alan's comment above (#15):

    Install RH9 (if not upgrading from it anyway)
    Install fedora-release and yum packages from CD#1 of FC1
    yum update rpm
    rpm --rebuilddb
    yum update krb5-libs e2fsprogs
    yum update

    Then rpm install the RH9 errata kernel  <<<<<<<

Why revert back to the RH9 errata kernel (or is this still necessary
as of todays date)?

Comment 25 Alan Cox 2004-05-17 17:49:58 UTC
Thats from a while ago. It appears that all that is needed is to use
acpi=force. At the time that wasn't know. An FC2 errata will probably
fix the problem for good

Comment 26 Len Brown 2004-05-19 21:50:57 UTC
It is expected that FC1 acpi=force fails on this sytem -- OS is too old. 
It is expected that the workaround is needed only on the install kernel. 
The install kernel uses PIC mode and PIRQ routing is needed. 
The installED kernel uses IOAPIC, and PIRQ routing is not needed. 
2.6.6 has two things to help PIC-mode on this box: 
1. Alan's 440GX PIRQ-disable workaround has been un-commented. 
to match 2.4. 
2. OSDL bug 1581 has been fixed, which makes ACPI work better 
on a box with a BIOS like this one. 
Note that until we roll back the ACPI cutoff date, "acpi=force" 
will be necessary to enable ACPI on boxes of this vintage. 

Comment 27 Len Brown 2004-05-19 22:37:34 UTC
*** Bug 119748 has been marked as a duplicate of this bug. ***

Comment 28 Dave Jones 2004-06-18 23:20:50 UTC
*** Bug 109693 has been marked as a duplicate of this bug. ***

Comment 29 Brett Wyer 2004-06-24 21:39:42 UTC
I'm attempting to upgrade from RH8 to FC2 and encountering this same
issue.  L440GX+ MB, 2xP3 750, 4xIDE drive, CDROM on internal SCSI.
Just upgraded all firmware to latest releases from Intel site.

Anaconda gets to 'Loading AIC7XXX driver...' and hangs.  Alt-F4 shows
it having hit the onboard SCSI and just sits there.

I've tried acpi=force as well as noapic and still don't get past this
point, although the messages do vary.

Am I missing something here?  I'm installing from the FC2 release CD
with all of its files dated 5/13/2004.  The vmlinuz shipped with
this ISO states it is 2.6.5-1.358.

Has anyone had any luck with a true L440gx+ booting off of the FC2
release using any of the aforementioned switches?  Is there a 2.6.6
install ISO image available that I can try?

Comment 30 Alan Cox 2004-06-24 22:33:44 UTC
people.redhat.com/arjanv has a boot image with newer kernel for C3 and
for a problem ASUS board. Try that on the 440GX+ and let me know

Comment 31 Brett Wyer 2004-06-24 22:43:42 UTC
Thanks for the quick response, Alan.  I actually have tried that
image without success, but I didn't record the results.  I'm
currently imaging my drives, which should be done early tomorrow,
so I'll give it another try and let you know.

One other thing I wanted to try is turning off the Plug-N-Play
function in the BIOS.  I don't know if that is having an impact or
not, but it seems like it would be worth a shot from some other
bugs I've read.

Comment 32 Brett Wyer 2004-06-25 14:53:15 UTC
Created attachment 101412 [details]
Log from successful boot under RH8

Okay, my backup is done, so I can do some hacking :).

I assume when you were referring to the c3 image, you meant c3boot-2.iso. 
that, I did a number of tests this morning to see if I could get this beast to
boot under FC2.  Here are the results:

Plug-N-Play OS turned OFF in the BIOS:

- Generic FC2 install disks, acpi=force - fail
- c3boot-2.iso, no parameters - fail (used acpi)
- c3boot-2.iso, pci=noacpi - fail (lots of devices using IRQ 11)

Turned Plug-N-Play back on:

- c3boot-2.iso, no parameters - fail (used acpi)

Note that when I say "used acpi", I'm referring to all of the ACPI: messages
with the associated "Pin A" and "PRQx" messages, like another attachment that
was posted earlier.  If you would like, I can see about trying to post the
boot messages if I can figure out how to get a serial console working on my

Finally, after a quick (not particularly careful) scan of the various console
messages during my tests, I didn't see the message that RH8 would spit out when

it detected my BIOS.  I'm wondering if the appropriate code path has been
enabled or put back in.  The messages I'm referring to are (and it is in there
twice-see attachment):

*** Possibly defective BIOS detected (irqtable)
*** Many BIOSes matching this signature have incorrect IRQ routing tables.
*** If you see IRQ problems, in particular SCSI resets and hangs at boot
*** contact your hardware vendor and ask about updates.
*** Building an SMP kernel may evade the bug some of the time.
*** Possibly defective BIOS detected (irqtable)
*** Many BIOSes matching this signature have incorrect IRQ routing tables.
*** If you see IRQ problems, in particular SCSI resets and hangs at boot
*** contact your hardware vendor and ask about updates.
*** Building an SMP kernel may evade the bug some of the time.

As always, any assistance would be appreciated, and thanks in advance.

Comment 33 Alan Cox 2004-06-25 15:36:58 UTC
The case in question got fixed (ACPI=force) and also in the later
images for non ACPI so the message went away.. Now it seems at least
one box has othe rproblems

Next amusement
  acpi=off pci=usepirqmask

Comment 34 Brett Wyer 2004-06-25 15:48:23 UTC
Okay, I assume you meant with the "c3" image.  I tried that and
got what looks to be the same results as pci=noacpi.  I.e. 3-4
devices using IRQ 11.  Hang after scsi0 access during load of
aic7xxx driver.  Never gets to scsi1.

I would be happy to attach console output once I finish hacking my
way through my BIOS config, although how I'm going to send an ALT-F4
is beyond me... :)

Comment 35 Brett Wyer 2004-06-25 16:46:04 UTC
I just did a "strings" against the vmlinuz that is on the 
c3boot-2.iso and it claims that it is 2.6.5-1.358.  Shouldn't it
be 2.6.6?

Comment 36 Alan Cox 2004-06-25 17:01:33 UTC
My error. Arjan backported the fix not forward ported the install
image. It should still have worked with acpi=force though.

Comment 37 Brett Wyer 2004-06-25 17:06:54 UTC
Okay, just so I'm clear here, according to Comment #26, there were
two fixes worked into 2.6.6.  Did Arjan backport those into his
2.6.5 kernel for the C3 boards?

Comment 38 Brett Wyer 2004-06-25 18:05:06 UTC
I guess my other question here is... is this worth spending a whole 
lot of time working on from your perspective?  I'm willing to hack 
through this to figure out what the issue is and get it fixed "for 
the good of Linux," or I can rearrange some hardware in my box (add a 
PCI IDE controller) so that I can run an IDE CD-ROM drive, and boot 
up with the noprobe option.

Obviously, I'd like to get this fixed, but I'd also like to get to 
FC2 while I'm out sick from work and have the time to hack with it.



Comment 39 Brett Wyer 2004-06-25 19:09:22 UTC
Created attachment 101427 [details]
L440GX+ with "C3" boot disk, no parameters specified

Okay, I made some progress with my serial console.  I've attached a copy of the
console output if I boot the "C3" (c3boot-2.iso) image specifying nothing.

Comment 40 Brett Wyer 2004-06-25 19:26:35 UTC
Created attachment 101428 [details]
L440GX+ with "C3" boot disk, acpi=off pci=usepirqmask specified

Here's a log of the boot with the above parameters specified.  Note that both
hang in the same place (driver loading).

Comment 41 Florin Andrei 2004-06-28 19:58:04 UTC
Hm, acpi=force used to work with FC2test3, but it's not working with
FC2final. I have no idea what's going on.

Comment 42 Brett Wyer 2004-06-28 23:26:39 UTC
Okay... I feel a little better now--I thought it was just my board, 
or maybe the fact that I have four Ethernet devices along with all of 
the PIIX4 stuff.  I haven't tried FC2test3 on my board.

Comment 43 Florin Andrei 2004-07-19 23:17:41 UTC
Sorry, my bad, acpi=force does work with FC2 final version, but only
after changing a setting in the BIOS. Unfortunately, i did this a few
weeks ago and i can't remember the setting. Sorry. :-(

Comment 44 Florin Andrei 2004-07-19 23:18:51 UTC
I tested FC3test1 and it works fine on 440GX. I didn't even had to
enter acpi=force, it just booted up fine, it saw the SCSI disks, etc.

Comment 45 David Lawrence 2004-09-29 19:34:12 UTC
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/

Comment 46 Alan Cox 2004-09-29 21:07:06 UTC
Re-opening from the auto tools. This one does affect FC2 for some
users and wasn't marked FC2. Fixed that

Comment 47 Dave Jones 2005-04-16 04:15:56 UTC
Fedora Core 2 has now reached end of life, and no further updates will be
provided by Red Hat.  The Fedora legacy project will be producing further kernel
updates for security problems only.

If this bug has not been fixed in the latest Fedora Core 2 update kernel, please
try to reproduce it under Fedora Core 3, and reopen if necessary, changing the
product version accordingly.

Thank you.

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