It is supposed to be MP-1.1 compliant, not MP-1.4 ... because it's too old.
> The MP-1.4 specs are largely silent on what you are supposed to do in this
> situation (which is why HP implemented an ELCR I suppose). I'm really loth to
> have the general case rely on a value returned from a register that isn't
> there.
>
> As I see it, there are two possibilities for handling this:
>
> 1) code an exception in the IO-APIC setup that recognises the board from it's
> id strings (if it provides them anywhere) and read the ELCR in this special
> case.
It's too specific, and the general scheme I prepose below has never been
attempted, so cannot be rejected until someone proves that it brokes
another box.
> 2) PCI interrupts are by spec defined to be level in this situation, so put a
> hook into the PCI code for informing the IO-APIC code when it finally locates
> an interrupt. If we find this interrupt on an ISA bus, we set it to level
> instead of edge.
It's a run time patch so it will have a very small time cost, and if we
can avoid it in these time of stupid nomeaning benchmarks, let's avoid it.
I'd say this is what you'll have to try if the solution I propose below also
fails.
> I think it's going to turn out that your board won't have an easy
> identification string, so 2) is probably the correct way to go. However, I'd
> like the PCI people to comment on this before I code it for you to try.
My preposal:
The obvious way to do the patch properly is to modify the function that
generates the IRQ table when it's empty at Bios level, and use ELCR
register there, and only there, if it's value is not the one of an unused
IO port. This has never been tryed and must be.
Ingo made the same mistake as you do : he attempted to patch the general
function instead of the very peticular that my board and very few others
use. Very few boads have no information at all in the Bios table, (he created
to function that generates the information when the bios table is empty ...
for my board, but at that time, he did not know that it needed some interrupts
to be level trigger because I discovered at a later point with a durty patch
of mine that it was the way to get the box stable). Now, if you rely on the
ELCR register only in that peticular function which is rarely used, and only
when it's value is not the one of an unsused IO port, the probability to brake
another board is very low and that's why it's the best solution to try first.
The HP-UX board is one of the first SMP box that has been released as a desktop
box, so at that time the SMP specs where not as clean as now. Now the Hewlett
packard engeneers are not know for doing crazy work, so if they did not
provided
informations through the Bios, it's very natural that they provided it through
another way, and the only other known way is the ELCR register, and any other
manufacturer that did not provide the interrupts table in the Bios is likely to
have done the same.
During the 2.1.x serie, the main problem with various io_apic patches was that
solving the problem for a box was breaking another, so patching in a function
which is rarely used (We know that several boxes have broken Bios interrupt
tables, but I don't know yet if there is any other SMP box that have no Bios
interrupts table at all) is realy the right way to get things done, peticularly
in a stable kernel.
Regards,
Huber Tonneau
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/