Messages in this thread | | | Date | Thu, 20 May 1999 16:26:20 +0200 | From | Hubert Tonneau <> | Subject | Re: USE_ELCR_TRIGGER_LEVEL removed in 2.2.6 -> linux broken for HP-XU SMP |
| |
James Bottomley wrote: > > I presume you have an MPC default type 5 motherboard.
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/
| |