Nforce2 apic timer ack delay

[Jamie Lokier]

Ross Dickson wrote:
> a) The Nforce2 DASP speculates and gets it right, pre-fetching the
> code for the local apic timer interrupt, so the interrupt code
> executes sooner after activation than it does with other chipsets
> for AMD.
> 
> b) The AMD cpu may not be over its timing and stability issues when
> coming out of C1 disconnect. Plenty stable soon enough for other
> chipsets and other codepaths in linux which pull the cpu out of C1
> disconnect, but not quite soon enough for the "cached" short code
> path to the local apic timer ack. So most of the time any latent
> lockup potential is not realised, but on occasion we hit it.

Ross,

Is the AMD C1 Disconnect state only entered when the CPU is idle, as in a
"hlt" instruction?

If it is, we could set a flag just before the "hlt" instruction in the
idle task and clear it afterwards.  If the flag is set, the interrupt
path could clear the flag and do the delay thing.  Then you could use
a longer, safe delay, and have it in the generic intrrupt path not
just the local apic timer.  A delay coming out of the idle state is no
big deal.

-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/