On 02-01-08 00:11, Rene Herman wrote:
On 01-01-08 23:39, H. Peter Anvin wrote:
Yes, we do. It's exactly this side effect which makes this safer
than either 0x80 or 0xED -- it's a port that *guaranteed* can't be
reclaimed for other purposes without breaking MS-DOS compatibility.
I see that with CR0.NE set (*) we indeed don't care about IGNNE#...
However, I'm worried about this comment in arch/x86/kernel/i8259_32.c
===
/*
* New motherboards sometimes make IRQ 13 be a PCI interrupt,
* so allow interrupt sharing.
*/
===
Is it really safe to just blindly negate IRQ13 on everything out
there, from regular PC through funky embedded thingies?
It's not any IRQ 13, it's IRQ 13 from the FPU.
Well, on the PIIX it is and I guess on anything where it's _not_ fully
internal an 0xf0 write wouldn't have any effect on IRQ13...
When you earlier mentioned this it seemed 0xed switched on DMI would be
good enough, but well.
Alan, do you have an opinion on the port 0xf0 write? It should probably
still be combined with a replacement/deletion for new machines due to
the bus-locking "bad for real-time" thing you mentioned earlier but in
the short run it could be a fairly low-impact replacement on anything
except a 386+387
We should do a another timing measurement survey and it makes for
sligtly worse code if we indeed feel it's not safe enough to write
anything other than 0, but otherwise it's quite minimal.
Thinking about this, my main worry about 0xf0 as a 0x80 replacement would be
systems that have elected to _not_ let port 0xf0 writes flow through to ISA
changing the timing-characteristics. Given that it's a known port, someone
may have elected to just keep it fully internal.
Upto now the datasheets I've read do put it on ISA...
Rene.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
