The subject describes the complete patch:
mtrr first disables the local caches, then it calls smp_call_function().
This causes 2 problems:
* it's not guaranteed that smp_call_function() will return on the same
cpu as it was called [internally, it calls schedule()].
* waiting for IPI delivery with disabled local interrupts can easily
cause a
lock-up.
Linus, I think the patch is obviously correct (tm), and we still comply
with Intel's "Multile-Processor Considerations" for MTRR changes. Could
you add it to the next (pre-)kernel?
-- Manfred
--- 2.3/arch/i386/kernel/mtrr.c Wed Dec 8 23:17:02 1999 +++ build-2.3/arch/i386/kernel/mtrr.c Thu Dec 23 23:07:05 1999 @@ -957,11 +957,11 @@ wait_barrier_execute = TRUE; wait_barrier_cache_enable = TRUE; atomic_set (&undone_count, smp_num_cpus - 1); - /* Flush and disable the local CPU's cache and start the ball rolling on - other CPUs */ - set_mtrr_prepare (&ctxt); + /* Start the ball rolling on other CPUs */ if (smp_call_function (ipi_handler, &data, 1, 0) != 0) panic ("mtrr: timed out waiting for other CPUs\n"); + /* Flush and disable the local CPU's cache */ + set_mtrr_prepare (&ctxt); /* Wait for all other CPUs to flush and disable their caches */ while (atomic_read (&undone_count) > 0) barrier (); /* Set up for completion wait and then release other CPUs to change MTRRs*/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jan 07 2000 - 21:00:07 EST