From: gregory.clement@free-electrons.com (Gregory CLEMENT)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/4] ARM: mm: kill unused TLB_CAN_READ_FROM_L1_CACHE and use ALT_SMP instead
Date: Wed, 15 May 2013 18:29:03 +0200 [thread overview]
Message-ID: <5193B7CF.2020208@free-electrons.com> (raw)
In-Reply-To: <20130515154113.GM23869@mudshark.cambridge.arm.com>
On 05/15/2013 05:41 PM, Will Deacon wrote:
> On Wed, May 15, 2013 at 04:36:43PM +0100, Gregory CLEMENT wrote:
>> On 05/15/2013 05:04 PM, Will Deacon wrote:
>>> On Wed, May 15, 2013 at 03:46:20PM +0100, Gregory CLEMENT wrote:
>>>> On 05/15/2013 04:06 PM, Will Deacon wrote:
>>>>> You could also try deleting both of the ALT_* lines and just putting a
>>>>> W(nop) in there directly.
>>>>
>>>> If I just delete the both of the ALT_* lines it no more hangs.
>>>> If I put a W(nop) instead it hangs.
>>
>> It also hang with a simple nop by the way
>
> Ok. Have you tried adding a different instruction (mov r0, r0, for example)?
it hanged again :(
I also try to boot a kernel in Thumb2, it doesn't hang in the same place but the kernel
crash latter
>
>>>
>>> Wow. This doesn't sound good for your CPU and you might want to check with
>>> the Marvell guys...
>>>
>>> Extra things you could try:
>>>
>>> - Try adding a 16-bit nop instead (remove the W, build thumb-2 and
>>> double check in your diasassembly)
>>>
>>> - Try adding the W(nop) to other places in the kernel and see if you
>>> can tickle the lock-up elsewhere.
>>
>> I managed to add W(nop) elsewhere in the kernel without getting any lock-up.
>>
>> Is the fact that this nop is the first instruction of the macro could have an
>> influence ?
>
> I can't think why -- the macro is just expanded inline during assembly.
If I put anything before the "dcache_line_size r2, r3" line the kernel hang, but
just after it's ok.
>
>>
>>>
>>> - Can you reproduce on the Armada XP? (since I have access to one of
>>> those)
>>
>> No on Armada XP I don't have this kind of problem even on UP.
>
> Is that compiling with CONFIG_SMP=n?
Yes
>
> Will
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
next prev parent reply other threads:[~2013-05-15 16:29 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-25 18:19 [PATCH 0/4] TLB and mm-related optimisations Will Deacon
2013-03-25 18:19 ` [PATCH 1/4] ARM: tlb: don't perform inner-shareable invalidation for local TLB ops Will Deacon
2013-03-27 10:34 ` Catalin Marinas
2013-03-27 12:07 ` Will Deacon
2013-03-27 12:30 ` Catalin Marinas
2013-03-27 12:56 ` Will Deacon
2013-03-27 13:40 ` Catalin Marinas
2013-03-27 13:54 ` Will Deacon
2013-03-25 18:19 ` [PATCH 2/4] ARM: tlb: don't perform inner-shareable invalidation for local BP ops Will Deacon
2013-03-27 10:36 ` Catalin Marinas
2013-03-25 18:19 ` [PATCH 3/4] ARM: mm: kill unused TLB_CAN_READ_FROM_L1_CACHE and use ALT_SMP instead Will Deacon
2013-03-27 10:53 ` Catalin Marinas
2013-03-27 12:20 ` Will Deacon
2013-05-15 13:18 ` Gregory CLEMENT
2013-05-15 13:41 ` Will Deacon
2013-05-15 13:54 ` Gregory CLEMENT
2013-05-15 14:06 ` Will Deacon
2013-05-15 14:46 ` Gregory CLEMENT
2013-05-15 15:04 ` Will Deacon
2013-05-15 15:36 ` Gregory CLEMENT
2013-05-15 15:41 ` Will Deacon
2013-05-15 16:29 ` Gregory CLEMENT [this message]
2013-05-15 16:48 ` Will Deacon
2013-05-15 17:16 ` Russell King - ARM Linux
2013-03-25 18:19 ` [PATCH 4/4] ARM: atomics: don't use exclusives for atomic64 read/set with LPAE Will Deacon
2013-03-27 10:57 ` Catalin Marinas
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=5193B7CF.2020208@free-electrons.com \
--to=gregory.clement@free-electrons.com \
--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.