[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.11.1507031746550.3916@nanos>
Date: Fri, 3 Jul 2015 17:53:38 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Wolfram Sang <wsa@...-dreams.de>
cc: Simon Horman <horms@...ge.net.au>,
Kevin Hilman <khilman@...nel.org>,
Tyler Baker <tyler.baker@...aro.org>,
Borislav Petkov <bp@...en8.de>,
Geert Uytterhoeven <geert+renesas@...der.be>,
Magnus Damm <magnus.damm@...il.com>, linux-sh@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: Possible regression due to "tick: broadcast: Prevent livelock
from event handler"
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
---
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)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists