Messages in this thread | | | Date | Sat, 7 Feb 2004 14:55:44 +0000 | From | Jamie Lokier <> | Subject | Nforce2 apic timer ack delay |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |