public inbox for linux-arm-kernel@lists.infradead.org 
 help / color / mirror / Atom feed
From: slash.tmp@free•fr (Mason)
To: linux-arm-kernel@lists•infradead.org
Subject: Dropping "depends on SMP" for HAVE_ARM_TWD -- take 2
Date: Fri, 2 Oct 2015 15:24:20 +0200	[thread overview]
Message-ID: <560E8584.8000207@free.fr> (raw)
In-Reply-To: <560E53E3.7070207@free.fr>

[ Adding original reporter ]

On 02/10/2015 11:52, Mason wrote:

> [ take 1 was sent on 2015-03-26 ]
> 
> Hello everyone,
> 
> In http://thread.gmane.org/gmane.linux.ports.arm.kernel/389931/focus=392348
> Stephen Boyd wrote:
> 
>> I don't see any problem with the TWD dropping the dependency on SMP.
>> The code should work the same on a UP configuration [...]
> 
> And Arnd recently said:
> 
>> I think this has come up before and should be fixed. Could you
>> send a patch that allows using TWD in uniprocessor configurations?
> 
> Basically, this means reverting Shawn Guo's 904464b91eca patch.
> and removing "depends on SMP" for HAVE_ARM_TWD.
> 
> However, Shawn's patch fixed an issue, therefore it seems likely
> that simply reverting is not the proper solution?
> 
> What should I do?

For reference, the warning used to be:

    ------------[ cut here ]------------
    WARNING: at arch/arm/kernel/smp_twd.c:345
    twd_local_timer_of_register+0x7c/0x90()
    twd_local_timer_of_register failed (-6)
    Modules linked in:
    Backtrace:
    [<80011f14>] (dump_backtrace+0x0/0x10c) from [<8044dd30>]
    (dump_stack+0x18/0x1c)
     r7:805e9f58 r6:805ba84c r5:80539331 r4:00000159
    [<8044dd18>] (dump_stack+0x0/0x1c) from [<80020fbc>]
    (warn_slowpath_common+0x54/0x6c)
    [<80020f68>] (warn_slowpath_common+0x0/0x6c) from [<80021078>]
    (warn_slowpath_fmt+0x38/0x40)
     r9:412fc09a r8:8fffffff r7:ffffffff r6:00000001 r5:80633b8c
    r4:80b32da8
    [<80021040>] (warn_slowpath_fmt+0x0/0x40) from [<805ba84]
    (twd_local_timer_of_register+0x7c/0x90)
     r3:fffffffa r2:8053934b
    [<805ba7d0>] (twd_local_timer_of_register+0x0/0x90) from [<805c0bec>]
    (imx6q_timer_init+0x18/0x4c)
     r5:80633800 r4:8053b701
    [<805c0bd4>] (imx6q_timer_init+0x0/0x4c) from [<805ba4e8>]
    (time_init+0x28/0x38)
     r5:80633800 r4:805dc0f4
    [<805ba4c0>] (time_init+0x0/0x38) from [<805b6854>]
    (start_kernel+0x1a0/0x310)
    [<805b66b4>] (start_kernel+0x0/0x310) from [<10008044>] (0x10008044)
     r8:1000406a r7:805f3f8c r6:805dc0c4 r5:805f0518 r4:10c5387d
    ---[ end trace 1b75b31a2719ed1c ]---


I cannot reproduce on v4.2 + my platform...

Booting with the following command line:
ip=dhcp root=/dev/nfs rdinit=/none console=ttyS0,115200 mem=640M debug nosmp

produces the attached boot log (no run-time warning).

Perhaps CONFIG_SMP_ON_UP matters? (I have it enabled.)
Nope, I don't get any warning with CONFIG_SMP_ON_UP disabled.

Running out of ideas...

What does nosmp actually do?

static int __init nosmp(char *str)
{
	setup_max_cpus = 0;
	arch_disable_smp_support();

	return 0;
}

I don't think arch/arm overrides arch_disable_smp_support, so it's
just a NOP. So we're just setting setup_max_cpus to 0...

There have been several updates to arch/arm/kernel/smp_twd.c since
Shawn's patch, perhaps one of them unknowingly fixed the problem?

$ git ls arch/arm/kernel/smp_twd.c 
4ed89f222806 ARM: convert printk(KERN_* to pr_*
06b96c8beb94 arm: Replace __this_cpu_ptr with raw_cpu_ptr
0b443ead714f cpufreq: remove unused notifier: CPUFREQ_{SUSPENDCHANGE|RESUMECHANGE}
2e874ea34214 ARM: twd: data endian fix
47dcd3563e45 Merge tag 'remove-local-timers' of git://git.kernel.org/pub/scm/linux/kernel/git/davidb/linux-msm into next/cleanup
8bd26e3a7e49 arm: delete __cpuinit/__CPUINIT usage from all ARM users
cbbe6f82b489 ARM: 7778/1: smp_twd: twd_update_frequency need be run on all online CPUs
a894fcc2d01a ARM: smp_twd: Divorce smp_twd from local timer API
da4a686a2cfb ARM: smp_twd: convert to use CLKSRC_OF init
904464b91eca ARM: 7655/1: smp_twd: make twd_local_timer_of_register() no-op for nosmp

"smp_twd: Divorce smp_twd from local timer API" might be a likely candidate.
(What do you think, Stephen?)

Regards.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: boot.log
Type: text/x-log
Size: 7666 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20151002/85eb1a49/attachment-0001.bin>

  reply	other threads:[~2015-10-02 13:24 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-02  9:52 Dropping "depends on SMP" for HAVE_ARM_TWD -- take 2 Mason
2015-10-02 13:24 ` Mason [this message]
2015-10-02 18:02   ` Stephen Boyd
2015-10-02 18:48     ` Felipe Balbi
2015-10-02 18:55       ` Russell King - ARM Linux
2015-10-02 19:18         ` Felipe Balbi
2015-10-02 18:50     ` Mason
2015-10-02 19:41       ` Stephen Boyd
2015-10-02 23:34       ` Måns Rullgård
2015-10-03  9:32         ` Marc Zyngier
2015-10-03  9:49           ` Mason
2015-10-03 10:12             ` Marc Zyngier
2015-10-05  5:46               ` Sören Brinkmann
2015-10-05  7:38                 ` Mason
2015-10-05  9:03                   ` Linus Walleij
2015-10-05 11:49                 ` Afzal Mohammed
2015-10-05 15:13                   ` Sören Brinkmann
2015-10-05 15:25                     ` Russell King - ARM Linux
2015-10-06  8:21     ` Mason
2015-10-06 19:38       ` Stephen Boyd
2015-10-06 20:01         ` Felipe Balbi
2015-10-06 20:17         ` Mason
2015-10-06 21:05           ` Felipe Balbi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=560E8584.8000207@free.fr \
    --to=slash.tmp@free$(echo .)fr \
    --cc=linux-arm-kernel@lists$(echo .)infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox