> 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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
