That is correct.

In effect the kernel is complaining that the motherboard is not handling the interrupts correctly.

This falls outside they pervue of the kernel itself.

The motherboard is doing something it shouldn't causing the kernel to panic.

Causes can range from spurious interrupts, shorted lines, conflicts, a bad or damaged chipset, bad ram, etc. or even just an old "brain dead" chipset...

That is one with a bug in it which the kernel cannot simply ignore.

I had exactly the same error, only not after installing but at the first attempt to install Fedora Core 3 on an old system.
It hung on mounting /dev/hdc, the Cdrom device.
I found a suggestion to replace the Cdrom, tried it and it worked. So, it may be worth while trying to interpret the error messages before the final panic report. It may be the Cdrom, but could also be another hardware device that has a conflicting IRQ.

Hi,

I've solved it disabling "CFQ I/O Scheduler" in the kernel. There's a thread about this in the Gentoo forums. I hope it's helpful.

Hi, how did you disable this?

I currently only have remote access to the machine, what would be the best way of disabling "CFQ I/O Scheduler" in the kernel?

Thanks

While the CFK patches are interesting, they are basically an attempt to disable the normal scheduled queuing of I/O.

One thing is to try to tweak things for performance, another is to disable it altogether.

This is not really a solution.

In effect the OP's system has a problem that must be addressed.

Switching cards around is a good start.

If you followed some of the threads indicated you would have seen people both complaining and talking about the CMOS/BIOS IRQ assignments...

What they failed to understand is that while most bioses permit you to select WHICH IRQ is to be assigned, they bios does not give you direct control over which devices share the IRQ lines.

This (usually) is done in hardware.

On most systems 2, 3, or more devices are "tied together" in hardware (with some exceptions particularly server systems which have far more IRQ's available via backplanes, etc...).

Thus when you change an IRQ for one of these devices, you'll find that all 2, 3 or more will end up with the same IRQ no matter what you do.

Now couple the bonding with devices that generate a lot of NMI's at high rates like video cards, drive controllers and LAN interfaces and you have a problem which the kernel cannot cope with.

It's equally problematic for Windows too.

No, the problem needs to be solved at the hardware level.

One trick is to shove things around so that IRQ's are only shared by devices which usually are not active simultaneously...

e.g. your modem and LAN card, etc.


Gawd... after all these years I can't believe that resource battles still rear their ugly heads.

These problems should have gone the way of the Do-Do ages ago.