On 16-12-07 22:42, H. Peter Anvin wrote:
It probably comes down to which version is bigger (you probably also
want to try uninlining.)
slow_down_io() sort of needs to stay inline due to the REALLY_SLOW_IO thing.
That stuff could use a cleanup, but that would be a diferent patch.
Thanks for the heads up (also saw the SMBIOS update to this) but those
don't seem to be a problem in fact. David Reed has been running with
the simple udelay(2) version of this and reported no more hangs. He
moreover reported no trouble after booting with "acpi=off" meaning
that things seem to be fine pre-acpi which the boot code (and this
io_delay_init) is. So I believe we get to ignore those.
Okay, so there is something inside ACPI which tickles this. Which
brings further credibility that it's activating a debugging hack,
probably inside the SuperIO/system controller chip.
It would be interesting to know exactly which part of ACPI triggers
this. I bet it is a reference to system controller namespace.
Do you expect a BIOS update to be able to fix it? If so, I guess any DMI
hack should take BIOS version into account.
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/
