All of lore.kernel.org
 help / color / mirror / Atom feed
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 17:36:43 +0200	[thread overview]
Message-ID: <5193AB8B.90100@free-electrons.com> (raw)
In-Reply-To: <20130515150402.GK23869@mudshark.cambridge.arm.com>

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

> 
> 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 ?


> 
> 	- 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.

> 
>>> Early in boot (head.S:__fixup_smp), we detect whether the CPU has the MP
>>> extensions then, if we're actually UP but the kernel has CONFIG_SMP=y, we
>>> walk over the .alt.smp.init section looking at each entry in there. The
>>> ALT_UP macro spits out an (address, instruction) pair, so in
>>> __do_fixup_smp_on_up, we store the instruction to the address for each pair,
>>> replacing the SMP instruction which sat there in the compiled image.
>>>
>>> It could be that the CPUID checks are failing on your Marvell part. Can you
>>> tell me what you have in your mpidr (mrc p15, 0, Rd, c0, c0, 5) and also
>>> your midr (mrc p15, 0, Rd, c0, c0) please?
>>
>> mpidr= 0x0
>> midr= 0x561F5811
> 
> Should be fine, but it doesn't look like the patching is the issue here.
> 
> Will
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

  reply	other threads:[~2013-05-15 15:36 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 [this message]
2013-05-15 15:41                 ` Will Deacon
2013-05-15 16:29                   ` Gregory CLEMENT
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=5193AB8B.90100@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.