Possible regression due to "tick: broadcast: Prevent livelock from event handler"

Commit Message

Thomas Gleixner July 3, 2015, 3:53 p.m. UTC

On Fri, 3 Jul 2015, Wolfram Sang wrote:
> > Ok. One more check please. Does nohz=off on the command line fix/hide
> > the issue as well?
> 
> Yes, it does. It boots to the prompt then.

So something is fishy with this timer. In your UP setting we don't
have any interaction with the broadcast stuff. It's just the single
em_sti timer involved.

Now looking at the code I notice, that this is one of the overly
clever designed compare register based trainwrecks.

Can you try the patch below, whether it makes a difference?

Thanks,

	tglx
---

Comments

Wolfram Sang July 3, 2015, 4 p.m. UTC | #1

> Can you try the patch below, whether it makes a difference?

It doesn't. Board locks again.

> -	clockevents_config_and_register(ced, 1, 2, 0xffffffff);
> +	clockevents_config_and_register(ced, 1, 100, 0xffffffff);

Patch

diff --git a/drivers/clocksource/em_sti.c b/drivers/clocksource/em_sti.c
index dc3c6ee04aaa..41d8035d294e 100644
--- a/drivers/clocksource/em_sti.c
+++ b/drivers/clocksource/em_sti.c
@@ -308,7 +308,7 @@  static void em_sti_register_clockevent(struct em_sti_priv *p)
 	dev_info(&p->pdev->dev, "used for clock events\n");
 
 	/* Register with dummy 1 Hz value, gets updated in ->set_mode() */
-	clockevents_config_and_register(ced, 1, 2, 0xffffffff);
+	clockevents_config_and_register(ced, 1, 100, 0xffffffff);
 }
 
 static int em_sti_probe(struct platform_device *pdev)