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>
next prev parent 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.fr \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.