From e2f999a5df3d3e188ca69ffe375ea320b33d0992 Mon Sep 17 00:00:00 2001 From: Gregory Nutt Date: Tue, 15 Nov 2016 07:35:30 -0600 Subject: [PATCH] Update Changelog --- configs/sabre-6quad/README.txt | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/configs/sabre-6quad/README.txt b/configs/sabre-6quad/README.txt index f94614ae63..beb140cd8b 100644 --- a/configs/sabre-6quad/README.txt +++ b/configs/sabre-6quad/README.txt @@ -498,6 +498,15 @@ Open Issues: CPU (which may not be CPU0). Perhaps that should be a spinlock to prohibit execution of interrupts on CPU0 when other CPUs are in a critical section? + 2016-11-15: When the critical section is used to lock a resource that is also + used by interupt handling, I believe that what is required is that the interrupt + handling logic must also take the spinlock. This will cause the interrupt handlers + on other CPUs to spin until leave_critical_section() is called. + + NOTE: Currently enter_critical section takes the spinlock before disabling + (local) interrupts. That orderwould have to change or you could potentially get + deadlocks if the interrupt handler on the same CPU tries to take the spinlock. + 2. Cache Concurency. This is a complex problem. There is logic in place now to clean CPU0 D-cache before starting a new CPU and for invalidating the D-Cache when the new CPU is started. REVISIT: Seems that this should not be necessary.