Commit 0b46b8a718c6e ("clocksource: arch_timer: Fix code to...") fixes
timer issues with certain ARMv7 platforms, but unfortunately breaks
arm64 platforms with hyp mode (EL2) enabled.
The commit only sets arch_timer_use_virtual to false under CONFIG_ARM,
but forgets that the config variable is also set in other code paths
(actually, right underneath the check in the patch) with detrimental
consequences as we've now introduced a direct early call to BUG() on
practically all arm64 platforms.
One could argue that this code could be refactored to use different
variables for checking which *timer* to use and which *counter* to use,
which seems to be the desired difference between ARM and arm64 in this
case, but this approach fixes an urgent issue for now.
Cc: Sonny Rao <[email protected]>
Cc: Catalin Marinas <[email protected]>
Cc: Daniel Lezcano <[email protected]>
Cc: Olof Johansson <[email protected]>
Cc: Mark Rutland <[email protected]>
Cc: Catalin Marinas <[email protected]>
Cc: Marc Zyngier <[email protected]>
Cc: Yingjoe Chen <[email protected]>
Signed-off-by: Christoffer Dall <[email protected]>
---
This was apparently already discovered by Yingjoe Chen in this thread
https://lkml.org/lkml/2014/11/24/41 and Catalin recommended a similar
fix.
drivers/clocksource/arm_arch_timer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index 6a79fc4..095c177 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -462,7 +462,7 @@ static void __init arch_counter_register(unsigned type)
/* Register the CP15 based counter if we have one */
if (type & ARCH_CP15_TIMER) {
- if (arch_timer_use_virtual)
+ if (IS_ENABLED(CONFIG_ARM64) || arch_timer_use_virtual)
arch_timer_read_counter = arch_counter_get_cntvct;
else
arch_timer_read_counter = arch_counter_get_cntpct;
--
2.1.2.330.g565301e.dirty
On 2014-12-28 14:20, Christoffer Dall wrote:
> Commit 0b46b8a718c6e ("clocksource: arch_timer: Fix code to...")
> fixes
> timer issues with certain ARMv7 platforms, but unfortunately breaks
> arm64 platforms with hyp mode (EL2) enabled.
>
> The commit only sets arch_timer_use_virtual to false under
> CONFIG_ARM,
> but forgets that the config variable is also set in other code paths
> (actually, right underneath the check in the patch) with detrimental
> consequences as we've now introduced a direct early call to BUG() on
> practically all arm64 platforms.
>
> One could argue that this code could be refactored to use different
> variables for checking which *timer* to use and which *counter* to
> use,
> which seems to be the desired difference between ARM and arm64 in
> this
> case, but this approach fixes an urgent issue for now.
>
> Cc: Sonny Rao <[email protected]>
> Cc: Catalin Marinas <[email protected]>
> Cc: Daniel Lezcano <[email protected]>
> Cc: Olof Johansson <[email protected]>
> Cc: Mark Rutland <[email protected]>
> Cc: Catalin Marinas <[email protected]>
> Cc: Marc Zyngier <[email protected]>
> Cc: Yingjoe Chen <[email protected]>
> Signed-off-by: Christoffer Dall <[email protected]>
> ---
> This was apparently already discovered by Yingjoe Chen in this thread
> https://lkml.org/lkml/2014/11/24/41 and Catalin recommended a similar
> fix.
I'm increasingly worried about the time it takes to get such critical
fixes into the tree (arm64 is *dead* without it).
What is holding this patch which, as far as I remember, has been posted
by Catalin almost three weeks ago?
Daniel?
M.
--
Fast, cheap, reliable. Pick two.
On Sun, Dec 28, 2014 at 09:46:20PM +0000, Marc Zyngier wrote:
> On 2014-12-28 14:20, Christoffer Dall wrote:
> >Commit 0b46b8a718c6e ("clocksource: arch_timer: Fix code to...")
> >fixes
> >timer issues with certain ARMv7 platforms, but unfortunately breaks
> >arm64 platforms with hyp mode (EL2) enabled.
> >
> >The commit only sets arch_timer_use_virtual to false under
> >CONFIG_ARM,
> >but forgets that the config variable is also set in other code paths
> >(actually, right underneath the check in the patch) with detrimental
> >consequences as we've now introduced a direct early call to BUG() on
> >practically all arm64 platforms.
> >
> >One could argue that this code could be refactored to use different
> >variables for checking which *timer* to use and which *counter* to
> >use,
> >which seems to be the desired difference between ARM and arm64 in
> >this
> >case, but this approach fixes an urgent issue for now.
> >
> >Cc: Sonny Rao <[email protected]>
> >Cc: Catalin Marinas <[email protected]>
> >Cc: Daniel Lezcano <[email protected]>
> >Cc: Olof Johansson <[email protected]>
> >Cc: Mark Rutland <[email protected]>
> >Cc: Catalin Marinas <[email protected]>
> >Cc: Marc Zyngier <[email protected]>
> >Cc: Yingjoe Chen <[email protected]>
> >Signed-off-by: Christoffer Dall <[email protected]>
> >---
> >This was apparently already discovered by Yingjoe Chen in this thread
> >https://lkml.org/lkml/2014/11/24/41 and Catalin recommended a similar
> >fix.
>
> I'm increasingly worried about the time it takes to get such critical
> fixes into the tree (arm64 is *dead* without it).
>
> What is holding this patch which, as far as I remember, has been posted
> by Catalin almost three weeks ago?
>
I didn't find that since I didn't think I'd have to go back that long on
lakml for something that breaks boot of an entire architecture. Sorry
for the confusion of a second patch, but fwiw, I now spent another few
hours bisecting this, so I would really like to see this fix go into
mainline ASAP as well to save others the trouble.
Thanks,
-Christoffer
[Adding Arnd]
On Mon, Dec 29, 2014 at 08:35:09AM +0000, Christoffer Dall wrote:
> On Sun, Dec 28, 2014 at 09:46:20PM +0000, Marc Zyngier wrote:
> > On 2014-12-28 14:20, Christoffer Dall wrote:
> > >Commit 0b46b8a718c6e ("clocksource: arch_timer: Fix code to...")
> > >fixes
> > >timer issues with certain ARMv7 platforms, but unfortunately breaks
> > >arm64 platforms with hyp mode (EL2) enabled.
> > >
> > >The commit only sets arch_timer_use_virtual to false under
> > >CONFIG_ARM,
> > >but forgets that the config variable is also set in other code paths
> > >(actually, right underneath the check in the patch) with detrimental
> > >consequences as we've now introduced a direct early call to BUG() on
> > >practically all arm64 platforms.
> > >
> > >One could argue that this code could be refactored to use different
> > >variables for checking which *timer* to use and which *counter* to
> > >use,
> > >which seems to be the desired difference between ARM and arm64 in
> > >this
> > >case, but this approach fixes an urgent issue for now.
> > >
> > >Cc: Sonny Rao <[email protected]>
> > >Cc: Catalin Marinas <[email protected]>
> > >Cc: Daniel Lezcano <[email protected]>
> > >Cc: Olof Johansson <[email protected]>
> > >Cc: Mark Rutland <[email protected]>
> > >Cc: Catalin Marinas <[email protected]>
> > >Cc: Marc Zyngier <[email protected]>
> > >Cc: Yingjoe Chen <[email protected]>
> > >Signed-off-by: Christoffer Dall <[email protected]>
> > >---
> > >This was apparently already discovered by Yingjoe Chen in this thread
> > >https://lkml.org/lkml/2014/11/24/41 and Catalin recommended a similar
> > >fix.
> >
> > I'm increasingly worried about the time it takes to get such critical
> > fixes into the tree (arm64 is *dead* without it).
> >
> > What is holding this patch which, as far as I remember, has been posted
> > by Catalin almost three weeks ago?
> >
> I didn't find that since I didn't think I'd have to go back that long on
> lakml for something that breaks boot of an entire architecture. Sorry
> for the confusion of a second patch, but fwiw, I now spent another few
> hours bisecting this, so I would really like to see this fix go into
> mainline ASAP as well to save others the trouble.
Last I knew, Arnd was going to take the fix [1], which has been in
arm-soc's for-next and fixes branches for almost two weeks now. It
didn't make it into the last pull req due to some confusion over who was
going to take it.
Arnd, what's the plan for getting this into mainline ASAP?
Mark.
[1] https://git.kernel.org/cgit/linux/kernel/git/arm/arm-soc.git/commit/?h=fixes&id=d6ad36913083d683aad4e02e53580c995f1a6ede
On 12/29/2014 08:13 PM, Mark Rutland wrote:
> [Adding Arnd]
>
> On Mon, Dec 29, 2014 at 08:35:09AM +0000, Christoffer Dall wrote:
>> On Sun, Dec 28, 2014 at 09:46:20PM +0000, Marc Zyngier wrote:
>>> On 2014-12-28 14:20, Christoffer Dall wrote:
>>>> Commit 0b46b8a718c6e ("clocksource: arch_timer: Fix code to...")
>>>> fixes
>>>> timer issues with certain ARMv7 platforms, but unfortunately breaks
>>>> arm64 platforms with hyp mode (EL2) enabled.
>>>>
>>>> The commit only sets arch_timer_use_virtual to false under
>>>> CONFIG_ARM,
>>>> but forgets that the config variable is also set in other code paths
>>>> (actually, right underneath the check in the patch) with detrimental
>>>> consequences as we've now introduced a direct early call to BUG() on
>>>> practically all arm64 platforms.
>>>>
>>>> One could argue that this code could be refactored to use different
>>>> variables for checking which *timer* to use and which *counter* to
>>>> use,
>>>> which seems to be the desired difference between ARM and arm64 in
>>>> this
>>>> case, but this approach fixes an urgent issue for now.
>>>>
>>>> Cc: Sonny Rao <[email protected]>
>>>> Cc: Catalin Marinas <[email protected]>
>>>> Cc: Daniel Lezcano <[email protected]>
>>>> Cc: Olof Johansson <[email protected]>
>>>> Cc: Mark Rutland <[email protected]>
>>>> Cc: Catalin Marinas <[email protected]>
>>>> Cc: Marc Zyngier <[email protected]>
>>>> Cc: Yingjoe Chen <[email protected]>
>>>> Signed-off-by: Christoffer Dall <[email protected]>
>>>> ---
>>>> This was apparently already discovered by Yingjoe Chen in this thread
>>>> https://lkml.org/lkml/2014/11/24/41 and Catalin recommended a similar
>>>> fix.
>>>
>>> I'm increasingly worried about the time it takes to get such critical
>>> fixes into the tree (arm64 is *dead* without it).
>>>
>>> What is holding this patch which, as far as I remember, has been posted
>>> by Catalin almost three weeks ago?
>>>
>> I didn't find that since I didn't think I'd have to go back that long on
>> lakml for something that breaks boot of an entire architecture. Sorry
>> for the confusion of a second patch, but fwiw, I now spent another few
>> hours bisecting this, so I would really like to see this fix go into
>> mainline ASAP as well to save others the trouble.
>
> Last I knew, Arnd was going to take the fix [1], which has been in
> arm-soc's for-next and fixes branches for almost two weeks now. It
> didn't make it into the last pull req due to some confusion over who was
> going to take it.
I asked arm-soc team to take the fix because it was depending on a patch
which was already in their tree [1].
Merry Christmas
-- Daniel
[1] http://www.spinics.net/lists/arm-kernel/msg385704.html
> Arnd, what's the plan for getting this into mainline ASAP?
>
> Mark.
>
> [1] https://git.kernel.org/cgit/linux/kernel/git/arm/arm-soc.git/commit/?h=fixes&id=d6ad36913083d683aad4e02e53580c995f1a6ede
>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
On Monday 29 December 2014 21:54:33 Daniel Lezcano wrote:
> On 12/29/2014 08:13 PM, Mark Rutland wrote:
> > On Mon, Dec 29, 2014 at 08:35:09AM +0000, Christoffer Dall wrote:
> >> On Sun, Dec 28, 2014 at 09:46:20PM +0000, Marc Zyngier wrote:
> >>> What is holding this patch which, as far as I remember, has been posted
> >>> by Catalin almost three weeks ago?
> >>>
> >> I didn't find that since I didn't think I'd have to go back that long on
> >> lakml for something that breaks boot of an entire architecture. Sorry
> >> for the confusion of a second patch, but fwiw, I now spent another few
> >> hours bisecting this, so I would really like to see this fix go into
> >> mainline ASAP as well to save others the trouble.
> >
> > Last I knew, Arnd was going to take the fix [1], which has been in
> > arm-soc's for-next and fixes branches for almost two weeks now. It
> > didn't make it into the last pull req due to some confusion over who was
> > going to take it.
>
> I asked arm-soc team to take the fix because it was depending on a patch
> which was already in their tree [1].
Sorry for dropping the ball on this, I've send out a pull request to Linus
now.
Arnd