On Wed, 02 Jan 2008 00:11:54 +0100 Rene Herman <[EMAIL PROTECTED]> wrote:
> 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 Both 0xed and 0xf0 are mapped to internal functions on the AMD Elan SC400 processor. It is an AMD 486 based system on a chip and since AMD just knew that it would never have a math coprocessor, they reused the 0xf0-0xf2 range for the PCMCIA controller. I guess the AMD Elan SC500 will have similar problems. I seem to recall that back when I was working with the Elan SC400 (sometime around 1998?) there were discussions about finding an alternate delay port because outb to 0x80 messed up the debug port. I think the Elan stopped those discussions because just about every port on the Elan was reused for some alternate purpose. /Christer -- 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/
