> a minor concern, but I did also point out that using an unused port > causes the bus to be tied up for a microsecond or two, which matters on > a fast SMP machine.
And I did point out I'd found locking cases that may be relying upon this > I also note that curent machines like the problem machine have ACPI, and > maybe those would be the ones that vendors might start to define port 80 > to mean something. As I noted, it /seems/ to be only when ACPI is turned Port 0x80 means debug. You appear to have a laptop with some kind of buggy firmware that wants a BIOS update. Everyone use 0x80 for debug - its in the chipset hardware quite often. > My belief is that my machine has some device that is responding to port > 80 by doing something. And that something requires some other program > to "service" port 80 in some way. But it sure would be nice to know. > I can't personally sand off the top of the chipset to put probes into it > - so my normal approach of putting a logic analyzer on the bus doesn't work. Almost certainly a SMI trap. > PS: If I have time, I may try to build Rene's port 80 test for Windows > and run it under WinXP on this machine That would be very interesting. Alan -- 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/
