#1 00000001 Program to modify APIC, ACPI, and BIOS Interrupts

[GinEric]

If we're going to get anywhere with writing any form
of driver whatsoever, we need to first create a
program to monitor and edit the Interrupt structure of
a motherboard. Specifically, in order to get out
interrupt ducks all in a row, we need a duckrower.

Nobody has their ducks in a row right now when it
comes to such things as drivers and installation
software, especially of Operating Systems, then
followed by various devices, especially sound cards,
and this is so because instead of being able to tell
the chipset what interrupt goes to what device, the
software makes guesses.

Even Linux is guilty of this.

irq.c and pci_irq.c make no provision whatsoever to
actually read and/or modify the interrupts. They are
limited to a descending order search from Interrupt 15
down to Interrupt 10, and, as we all know, this is
entirely deficient.

Basically, most motherboards have none of these
interrupts left for configuration, once they are
taken, and they are taken upon shipment of the
motherboard: 15 for hard disk, 14 for hard disk, 13
for math co-processor or cpu interrupt line, 12 for
mouse, 11 for video, and 10 for both ethernet card and
sound.

The last one is a big problem, and as Microsoft
says "Sharing Interrupts is a Bad Idea!"

Interrupts 7, 5, 4, and 3, which are not used as in
the old days for parallel port printers 7, sound cards
5, serial1 4, and serial0 3, were completely left
hanging in the lurch in Linux, Windows, Intel, APIC,
ACPI, and all of the other expertise that missed their
own objective: programmable interrupts.

The oversight finally hit a major failure wall when
the SoundBlaster series, from the AWE to the Audigy,
came out and wanted Interrupt 10. This led to mostl
Alsa failures in Linux, but also many failures in
Windows when, for example, an onboard Cirrus sound
chip wanted Interrupt 11.

There was no where for the interrupt to be reassigned,
no one had thought to reassign to an available lower
interrupt number, and the term IRQ [Interrupt Request
Queue] was used completely without proper definition
and completely out of context with what it is, a stack
queue and not a number at all. A number would be
something like Interrupt Number [IN] or Interrupt
Request Line [IRL], not IRQ.

Therefore, we have to go back and fix the misnomered
Linux routines, Windows routines, and the accompanying
documentation, all of which erroneously call the
physical interrupt number the "IRQ." It is not.

There are still a limited set of IN's, but there can
easily be 100,000 and more IRQ's, interrupts waiting
in the Interrupt Request Queue to be processed by the
Input/Output Module [IOM].

Finally, even the engineers at Intel, AMD, and others
do not have the proper definition of IRQ nor do they
use it in proper context.

Almost, but not quite, as if they haven't done much
real work in interrupt architecture; which is probably
true since the poor attempts at Plug and Play as a
replacement for real physical interrupt lines [wires,
cables, traces on a printed circuit board or silicon
substrate].

I have had to pull up some rather ancient drawings on
the original designs of the Interrupt driven
architecture of computer systems.

The whole of the architecture has fallen through the
cracks of misinterpretation and misunderstanding.

So now, more than ever, we need to fix this problem
once and for all time.

Author.