diff --git a/configs/sabre-6quad/README.txt b/configs/sabre-6quad/README.txt index 72bb78f952..02e6acb6ec 100644 --- a/configs/sabre-6quad/README.txt +++ b/configs/sabre-6quad/README.txt @@ -555,35 +555,14 @@ Open Issues: Should all spinlocks go into a special "strongly ordered" memory region? + Update: Cache inconsistencies seem to be the root cause of all current SMP + issues. + 5. Assertions. On a fatal assertions, other CPUs need to be stopped. The SCR, however, only supports disabling CPUs 1 through 3. Perhaps if the assertion occurs on CPUn, n > 0, then it should use and SGI to perform the assertion on CPU0 always. From CPU0, CPU1-3 can be disabled. -6. I think there is a possibilty for a hang in up_cpu_pause(). Suppose this - situation: - - - CPU1 is in a critical section and has the g_cpu_irqlock spinlock. - - CPU0 takes an interrupt and attempts to enter the critical section. It - spins waiting on g_cpu_irqlock with interrupt disabled. - - CPU1 calls up_cpu_pause() to pause operation on CPU1. This will issue - an inter-CPU interrupt to CPU0 - - But interrupts are disabled. What will happen? I think that this is - a deadlock: Interrupts will stay disabled on CPU0 because it is spinning - in the interrupt handler; up_cpu_pause() will hang becuase the inter- - CPU interrupt is pending. - - Are inter-CPU interrupts maskable in the same way as other interrupts? If - the are not-maskable, then we must also handle them as nested interrupts - in some fashion. - - A work-around might be to check the state of other-CPU interrupt handler - inside the spin loop of up_cpu_pause(). Having the other CPU spinning and - waiting for up_cpu_pause() provided that (1) the pending interrupt can be - cleared, and (2) leave_critical_section() is not called prior to the point - where up_cpu_resume() is called, and (3) up_cpu_resume() is smart enough - to know that it should not attempt to resume a non-paused CPU. - Configurations ==============