David P. Reed wrote:
Alan, thank you for the pointers. I have been doing variations on this
testing theme for a while - I get intrigued by a good debugging
challenge, and after all it's my machine...
Two relevant new data points, and then some more suggestions:
1. It appears to be a real port. SMI traps are not happening in the
normal outb to 80. Hundreds of them execute perfectly with the expected
instruction counts. If I can trace the particular event that creates
the hard freeze (getting really creative, here) and stop before the
freeze disables the entire computer, I will. That may be an SMI, or
perhaps any other kind of interrupt or exception. Maybe someone knows
how to safely trace through an impending SMI while doing printk's or
something?
2. It appears to be the standard POST diagnostic port. On a whim, I
disassembled my DSDT code, and studied it more closely. It turns out
that there are a bunch of "Store(..., DBUG)" instructions scattered
throughout, and when you look at what DBUG is defined as, it is defined
as an IO Port at IO address DBGP, which is a 1-byte value = 0x80. So
the ACPI BIOS thinks it has something to do with debugging. There's a
little strangeness here, however, because the value sent to the port
occasionally has something to do with arguments to the ACPI operations
relating to sleep and wakeup ... could just be that those arguments are
distinctive.
Dumb question: if you change your iodelay function so it always writes
zero to port 0x80, does it start working?
-hpa
--
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/