linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Peter Tyser <ptyser@xes-inc.com>
To: linuxppc-dev@ozlabs.org
Cc: "kumar.gala" <kumar.gala@freescale.com>, Nate Case <ncase@xes-inc.com>
Subject: Re: [PATCH] powerpc/85xx: Fix SMP when "cpu-release-addr" is in lowmem
Date: Thu, 21 Jan 2010 16:28:55 -0600	[thread overview]
Message-ID: <1264112935.31570.361.camel@localhost.localdomain> (raw)
In-Reply-To: <1261176637-23912-1-git-send-email-ptyser@xes-inc.com>

On Fri, 2009-12-18 at 16:50 -0600, Peter Tyser wrote:
> Recent U-Boot commit 5ccd29c3679b3669b0bde5c501c1aa0f325a7acb caused
> the "cpu-release-addr" device tree property to contain the physical RAM
> location that secondary cores were spinning at.  Previously, the
> "cpu-release-addr" property contained a value referencing the boot page
> translation address range of 0xfffffxxx, which then indirectly accessed
> RAM.
> 
> The "cpu-release-addr" is currently ioremapped and the secondary cores
> kicked.  However, due to the recent change in "cpu-release-addr", it
> sometimes points to a memory location in low memory that cannot be
> ioremapped.  For example on a P2020-based board with 512MB of RAM the
> following error occurs on bootup:
> 
>   <...>
>   mpic: requesting IPIs ...
>   __ioremap(): phys addr 0x1ffff000 is RAM lr c05df9a0
>   Unable to handle kernel paging request for data at address 0x00000014
>   Faulting instruction address: 0xc05df9b0
>   Oops: Kernel access of bad area, sig: 11 [#1]
>   SMP NR_CPUS=2 P2020 RDB
>   Modules linked in:
>   <... eventual kernel panic>
> 
> Adding logic to conditionally ioremap or access memory directly resolves
> the issue.
> 
> Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
> Signed-off-by: Nate Case <ncase@xes-inc.com>
> Reported-by: Dipen Dudhat <B09055@freescale.com>
> Tested-by: Dipen Dudhat <B09055@freescale.com>

Any chance this going to be picked up for 2.6.33?  The issue is
currently going to bite anyone using an MP-capable 85xx system that
doesn't use highmem.

Thanks,
Peter

  parent reply	other threads:[~2010-01-21 22:29 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-18 22:50 [PATCH] powerpc/85xx: Fix SMP when "cpu-release-addr" is in lowmem Peter Tyser
2009-12-19  2:35 ` DWC_OTG Issues Hunter Cobbs
2009-12-19 18:56   ` Wolfgang Denk
2009-12-20 20:13     ` Hunter Cobbs
2009-12-20 21:58       ` Wolfgang Denk
2010-01-21 22:28 ` Peter Tyser [this message]
2010-01-25 16:50   ` [PATCH] powerpc/85xx: Fix SMP when "cpu-release-addr" is in lowmem Kumar Gala
2010-01-25 16:55 ` Kumar Gala

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=1264112935.31570.361.camel@localhost.localdomain \
    --to=ptyser@xes-inc.com \
    --cc=kumar.gala@freescale.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=ncase@xes-inc.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).