ARM: avoid Cortex-A9 livelock on tight dmb loops

Executing loops such as:

	while (1)
		cpu_relax();

with interrupts disabled results in a livelock of the entire system, as other CPUs are prevented making progress. This is most noticable as a failure of crashdump kexec, which stops just after issuing:

Loading crashdump kernel...

to the system console. A workaround for this is to use 10 nops in cpu_relax().

We also use wfe() in while (1) loops to avoid burning cycles in a tight loop, giving the CPU a hint that we're not doing anything useful.

Signed-off-by Russell King <[email protected]>

---
It's been a while since this was posted, Will's suggestion was to use 10 nops in cpu_relax() last time around. I still prefer wfe() in these infinite-not-doing-anything-ever loops.

Quoted 18 lines · Russell King

Executing loops such as:

	while (1)
		cpu_relax();

with interrupts disabled results in a livelock of the entire system, as other CPUs are prevented making progress. This is most noticable as a failure of crashdump kexec, which stops just after issuing:

Loading crashdump kernel...

to the system console. A workaround for this is to use 10 nops in cpu_relax().

We also use wfe() in while (1) loops to avoid burning cycles in a tight loop, giving the CPU a hint that we're not doing anything useful.

Quoted 5 lines

Signed-off-by Russell King <[email protected]>

---
It's been a while since this was posted, Will's suggestion was to use 10 nops in cpu_relax() last time around. I still prefer wfe() in these infinite-not-doing-anything-ever loops.

Works for me:

Tested-by Tony Lindgren <[email protected]>

Quoted 25 lines · Tony Lindgren

Quoted 18 lines · Russell King

Executing loops such as:

	while (1)
		cpu_relax();

with interrupts disabled results in a livelock of the entire system, as other CPUs are prevented making progress. This is most noticable as a failure of crashdump kexec, which stops just after issuing:

Loading crashdump kernel...

to the system console. A workaround for this is to use 10 nops in cpu_relax().

We also use wfe() in while (1) loops to avoid burning cycles in a tight loop, giving the CPU a hint that we're not doing anything useful.

Quoted 5 lines

Signed-off-by Russell King <[email protected]>

---
It's been a while since this was posted, Will's suggestion was to use 10 nops in cpu_relax() last time around. I still prefer wfe() in these infinite-not-doing-anything-ever loops.

Quoted 3 lines

Works for me:

Tested-by Tony Lindgren <[email protected]>

There was some concern in the past that WFE, like WFI, might cause the core to assert an external signal that might cause the SoC integration to place the core into a low-power mode from which it might not be able to wake up. This could happen on OMAP, for example, with WFI.

I don't recall the outcome of those discussions. Was a conclusion ever reached?

Quoted 36 lines · Paul Walmsley

Quoted 25 lines · Tony Lindgren

Quoted 18 lines · Russell King

Executing loops such as:

	while (1)
		cpu_relax();

with interrupts disabled results in a livelock of the entire system, as other CPUs are prevented making progress. This is most noticable as a failure of crashdump kexec, which stops just after issuing:

Loading crashdump kernel...

to the system console. A workaround for this is to use 10 nops in cpu_relax().

We also use wfe() in while (1) loops to avoid burning cycles in a tight loop, giving the CPU a hint that we're not doing anything useful.

Quoted 5 lines

Signed-off-by Russell King <[email protected]>

---
It's been a while since this was posted, Will's suggestion was to use 10 nops in cpu_relax() last time around. I still prefer wfe() in these infinite-not-doing-anything-ever loops.

Quoted 3 lines

Works for me:

Tested-by Tony Lindgren <[email protected]>

There was some concern in the past that WFE, like WFI, might cause the core to assert an external signal that might cause the SoC integration to place the core into a low-power mode from which it might not be able to wake up. This could happen on OMAP, for example, with WFI.

Quoted 2 lines

I don't recall the outcome of those discussions. Was a conclusion ever reached?

First, we use WFE in spinlocks. If WFE were to place the CPU in a low power state that it may not be able to wake up from, all our spinlocks would be unsafe.

Next, in all of the situations in this patch, we're executing an infinite loop. If it were to cause the core to go into a low power mode, surely that's a good thing, rather than the core endlessly executing NOPs? The only way out of that is for the core to receive a reset _anyway_.

Quoted 37 lines · Russell King - ARM Linux admin

Quoted 36 lines · Paul Walmsley

Quoted 25 lines · Tony Lindgren

Quoted 18 lines · Russell King

Executing loops such as:

	while (1)
		cpu_relax();

with interrupts disabled results in a livelock of the entire system, as other CPUs are prevented making progress. This is most noticable as a failure of crashdump kexec, which stops just after issuing:

Loading crashdump kernel...

to the system console. A workaround for this is to use 10 nops in cpu_relax().

We also use wfe() in while (1) loops to avoid burning cycles in a tight loop, giving the CPU a hint that we're not doing anything useful.

Quoted 5 lines

Signed-off-by Russell King <[email protected]>

---
It's been a while since this was posted, Will's suggestion was to use 10 nops in cpu_relax() last time around. I still prefer wfe() in these infinite-not-doing-anything-ever loops.

Quoted 3 lines

Works for me:

Tested-by Tony Lindgren <[email protected]>

There was some concern in the past that WFE, like WFI, might cause the core to assert an external signal that might cause the SoC integration to place the core into a low-power mode from which it might not be able to wake up. This could happen on OMAP, for example, with WFI.

Quoted 6 lines

Quoted 2 lines

I don't recall the outcome of those discussions. Was a conclusion ever reached?

First, we use WFE in spinlocks. If WFE were to place the CPU in a low power state that it may not be able to wake up from, all our spinlocks would be unsafe.

Good point. WFE must not assert the external signal that indicates that the core is inactive.

Quoted 5 lines

Next, in all of the situations in this patch, we're executing an infinite loop. If it were to cause the core to go into a low power mode, surely that's a good thing, rather than the core endlessly executing NOPs? The only way out of that is for the core to receive a reset _anyway_.

Makes sense.

Do you recall what Will's reasoning was for preferring 10 NOPs to a WFE?

Quoted 23 lines · Paul Walmsley

Quoted 6 lines · Russell King - ARM Linux admin

Quoted 5 lines · Paul Walmsley

There was some concern in the past that WFE, like WFI, might cause the core to assert an external signal that might cause the SoC integration to place the core into a low-power mode from which it might not be able to wake up. This could happen on OMAP, for example, with WFI.

Quoted 6 lines

Quoted 2 lines

I don't recall the outcome of those discussions. Was a conclusion ever reached?

First, we use WFE in spinlocks. If WFE were to place the CPU in a low power state that it may not be able to wake up from, all our spinlocks would be unsafe.

Good point. WFE must not assert the external signal that indicates that the core is inactive.

Quoted 5 lines

Next, in all of the situations in this patch, we're executing an infinite loop. If it were to cause the core to go into a low power mode, surely that's a good thing, rather than the core endlessly executing NOPs? The only way out of that is for the core to receive a reset _anyway_.

Quoted 3 lines

Makes sense.

Do you recall what Will's reasoning was for preferring 10 NOPs to a WFE?

I think there may be an erratum for this which specifies 10 NOPs as its workaround, but I don't have its number.

Hi Russell, Paul,

Quoted 24 lines · Russell King - ARM Linux admin

Quoted 23 lines · Paul Walmsley

Quoted 6 lines · Russell King - ARM Linux admin

Quoted 5 lines · Paul Walmsley

There was some concern in the past that WFE, like WFI, might cause the core to assert an external signal that might cause the SoC integration to place the core into a low-power mode from which it might not be able to wake up. This could happen on OMAP, for example, with WFI.

Quoted 6 lines

Quoted 2 lines

I don't recall the outcome of those discussions. Was a conclusion ever reached?

First, we use WFE in spinlocks. If WFE were to place the CPU in a low power state that it may not be able to wake up from, all our spinlocks would be unsafe.

Good point. WFE must not assert the external signal that indicates that the core is inactive.

Quoted 5 lines

Next, in all of the situations in this patch, we're executing an infinite loop. If it were to cause the core to go into a low power mode, surely that's a good thing, rather than the core endlessly executing NOPs? The only way out of that is for the core to receive a reset _anyway_.

Quoted 6 lines

Quoted 3 lines

Makes sense.

Do you recall what Will's reasoning was for preferring 10 NOPs to a WFE?

I think there may be an erratum for this which specifies 10 NOPs as its workaround, but I don't have its number.

The erratum hits because cpu_relax() is a DMB instruction due to erratum 754327. That then triggers erratum 794072 because a tight loop of DMB instructions can cause a denial of service. One of the conditions for that to occur is:

| * No more than 10 instructions other than the DMB are executed between
| each DMB

Digging up the workaround:

  |  This erratum can be worked round by setting bit[4] of the undocumented
  |  Diagnostic Control Register to 1. This register is encoded as
  |  CP15 c15 0 c0 1. This bit can be written in Secure state only, with the
  |  following Read/Modify/Write code sequence:
  |
  |	MRC p15,0,rt,c15,c0,1
  |	ORR rt,rt,#0x10
  |	MCR p15,0,rt,c15,c0,1
  |
  |  When it is set, this bit causes the DMB instruction to be decoded and
  |  executed like a DSB. Using this software workaround is not expected to
  |  have any impact on the overall performance of the processor on a typical
  |  code base.
  |
  |  Other workarounds are also available for this erratum, to either prevent
  |  or interrupt the continuous stream of DMB instructions that causes the
  |  deadlock.
  |
  |  For example:
  |	* Inserting a non-conditional Load or Store instruction in the loop
  |	  between each DMB
  |	* Inserting additional instructions in the loop, such as NOPs, to
  |       avoid the processor seeing back to back DMB instructions.
  |	* Making the processor executing the short loop take regular
  |	  interrupts.

So the reason I prefer the NOPs is because that's guaranteed by the h/w folks to do the trick, whereas they say nothing about WFE. It should be dead easy to use NOPs instead, so I'm not sure why we're not just following the workaround here. We could even use NOPs + WFE if you like!

Executing loops such as:

	while (1)
		cpu_relax();

with interrupts disabled results in a livelock of the entire system, as other CPUs are prevented making progress. This is most noticable as a failure of crashdump kexec, which stops just after issuing:

Loading crashdump kernel...

to the system console. A workaround for this is to use 10 nops in cpu_relax().

We also use wfe() in while (1) loops to avoid burning cycles in a tight loop, giving the CPU a hint that we're not doing anything useful.

Signed-off-by Russell King <[email protected]>

---
It's been a while since this was posted, Will's suggestion was to use 10 nops in cpu_relax() last time around. I still prefer wfe() in these infinite-not-doing-anything-ever loops.

 arch/arm/include/asm/barrier.h   | 2 ++
 arch/arm/include/asm/processor.h | 6 +++++-
 arch/arm/kernel/machine_kexec.c  | 5 ++++-
 arch/arm/kernel/smp.c            | 4 +++-
 arch/arm/mach-omap2/prm_common.c | 4 +++-
 5 files changed, 17 insertions(+), 4 deletions(-)

Hi Russell,

Quoted 24 lines · Russell King

Executing loops such as:

	while (1)
		cpu_relax();

with interrupts disabled results in a livelock of the entire system, as other CPUs are prevented making progress. This is most noticable as a failure of crashdump kexec, which stops just after issuing:

Loading crashdump kernel...

to the system console. A workaround for this is to use 10 nops in cpu_relax().

We also use wfe() in while (1) loops to avoid burning cycles in a tight loop, giving the CPU a hint that we're not doing anything useful.

Signed-off-by Russell King <[email protected]>

---
It's been a while since this was posted, Will's suggestion was to use 10 nops in cpu_relax() last time around. I still prefer wfe() in these infinite-not-doing-anything-ever loops.

Quoted 6 lines

 arch/arm/include/asm/barrier.h   | 2 ++
 arch/arm/include/asm/processor.h | 6 +++++-
 arch/arm/kernel/machine_kexec.c  | 5 ++++-
 arch/arm/kernel/smp.c            | 4 +++-
 arch/arm/mach-omap2/prm_common.c | 4 +++-
 5 files changed, 17 insertions(+), 4 deletions(-)

Thanks, this looks good to me and your explanation later in the thread makes a lot of sense:

Acked-by Will Deacon <[email protected]>

Feel free to put some of the erratum writeup that I shared in the commit message, if you like.