On Jan 21, 2010, at 4:28 PM, Peter Tyser wrote: > 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 <pty...@xes-inc.com> >> Signed-off-by: Nate Case <nc...@xes-inc.com> >> Reported-by: Dipen Dudhat <b09...@freescale.com> >> Tested-by: Dipen Dudhat <b09...@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.
This just got lost in my queue. Will apply and send up for .33 - k _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
