On 28/04/14 18:44, Colin Cross wrote:
Is that case documented somewhere in the code comments?
Perhaps not near enough to the _nolock but the primary bit of comment is here (and in same file as kdb_sr). --- cut here ---
- kdb_main_loop - After initial setup and assignment of the
controlling cpu, all cpus are in this loop. One cpu is incontrol and will issue the kdb prompt, the others will spinuntil 'go' or cpu switch.--- cut here ---
The mechanism kgdb uses to quiesce other CPUs means other CPUs cannot be in irqsave critical sections.
One of the advantages of FIQ debugger is that it can be triggered from an FIQ (NMI for those in x86 land), and Jason and I have discussed using FIQs for kgdb to allow interrupting cpus stuck in critical sections. If that gets implemented the above assumption will no longer be correct.
Reviewing this I realized I missed one of the most critical points in the above.
Today kdb, even if triggered by FIQ/NMI, would still be likely to wedge waiting for the IPI interrupts to be delivered to other processors.
Did you and Jason discuss getting the active CPU to quiesce the other processors using FIQ/NMI, or to allow the active CPU to timeout while waiting for them the stop?
Daniel.