* Re: ppc/sata-fsl: orphan config value: CONFIG_MPC8315_DS
From: Scott Wood @ 2012-05-30 20:20 UTC (permalink / raw)
To: Anthony Foiani
Cc: Robert P.J.Day, linuxppc-dev@lists.ozlabs.org, Li Yang-R58472,
Jeff Garzik, Adrian Bunk
In-Reply-To: <gd35lbf55.fsf@dworkin.scrye.com>
On 05/30/2012 03:14 PM, Anthony Foiani wrote:
> Scott Wood <scottwood@freescale.com> writes:
>
>> Board information is available from the device tree, and from
>> platform code that was selected based on the device tree.
>
> You're right, of course; I was focusing on discovery/probing, and
> completely forgot about "provided information".
>
> However, as I just mentioned in my reply to Yang, I'm pretty happy
> with the kconfig solution (Adrian's patch, basically).
>
> If we find that this is a more widespread problem, we can revisit this
> discussion; but if only a handful of us have encountered this in a
> 5-year-old design, then I don't think it's worth the extra effort of
> making it dynamic.
We currently support building one kernel that supports a bunch of
different boards. The hardcoding of this workaround was harmless so far
because it was conditional on a symbol that was never defined, but now
you'll be enabling this workaround on any kernel that simply has support
for mpc8315erdb. That is not acceptable unless you show it's harmless
on all those other boards.
-Scott
^ permalink raw reply
* Re: ppc/sata-fsl: orphan config value: CONFIG_MPC8315_DS
From: Anthony Foiani @ 2012-05-30 20:14 UTC (permalink / raw)
To: Scott Wood
Cc: Robert P.J.Day, linuxppc-dev@lists.ozlabs.org, Li Yang-R58472,
Jeff Garzik, Adrian Bunk
In-Reply-To: <4FC5546A.4090506@freescale.com>
Scott Wood <scottwood@freescale.com> writes:
> Board information is available from the device tree, and from
> platform code that was selected based on the device tree.
You're right, of course; I was focusing on discovery/probing, and
completely forgot about "provided information".
However, as I just mentioned in my reply to Yang, I'm pretty happy
with the kconfig solution (Adrian's patch, basically).
If we find that this is a more widespread problem, we can revisit this
discussion; but if only a handful of us have encountered this in a
5-year-old design, then I don't think it's worth the extra effort of
making it dynamic.
Maybe someone who knows devtree really well could crank that out in a
few minutes... but I'm not that person. :)
Regardless, thanks very much for helping out on this.
I do advocate that Adrian's patch get put into place, so that we don't
have undocumented / unconnected kconfig symbols in the tree. If we
ever do find out more details about the workaround, we can at least
add some comments at the code site.
Thanks again!
Best regards,
Anthony Foiani
^ permalink raw reply
* Re: ppc/sata-fsl: orphan config value: CONFIG_MPC8315_DS
From: Anthony Foiani @ 2012-05-30 20:07 UTC (permalink / raw)
To: Li Yang
Cc: Li Yang-R58472, Jeff Garzik, Adrian Bunk, Scott Wood,
Robert P.J.Day, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <CADRPPNQ9Dk2OJuQQZm0WdSskW3D1mAqPq21d=h=JEf1nHszDDQ@mail.gmail.com>
Li Yang <leoli@freescale.com> writes:
> The original code was there before I touched the driver. So
> unfortunately I also don't know the history of the problem.
Alas.
> Judging from the comment in code and current test result I guess it
> is a board related issue.
I wonder if anyone on the 8315_DS project knows where the limitation
came from, since that's the origin of the workaround...
Regardless, it's recommended by at least one vendor who based their
design on the 8315 RDB. If it's board-related, then that seems a
reasonable conditional.
> I agree with Anthony that the best action for now is to remove the
> workaround completely.
Eeek.
I'm pretty sure that it needs to stay. (I can't guarantee that it has
fixed my problem, but it's been a week or two without the hang, so I'm
becoming more confident).
I think the question is how to best conditionalize it. The options
seem to be:
1. at compile time, via kconfig bits;
2. at runtime via probing / discovery; or
3. at runtime via device tree.
Given that this is a relatively old platform, and only 2-3 of us have
run into this issue in 5 years, I'm inclined to just go with option 1.
That's exactly what Adrian's patch (from 2008!) does:
http://old.nabble.com/-2.6-patch--sata_fsl.c%3A-fix-8315DS-workaround-td18807647.html
Using CONFIG_831x_RDB seems like a reasonable choice.
Anyway. To be clear, my project is currently in good shape (by
adopting Adrian's patch) so I don't have any actual urgency for fixing
this.
I was hoping that someone might know the "correct" answer offhand, but
I honestly think that this isn't worth spending too much time on.
(But I do think that Adrian's patch is an improvement over the current
state of affairs.)
Thanks again to everyone that's chimed in.
Best regards,
Anthony Foiani
^ permalink raw reply
* MPC8315 PCI express lockup
From: David Laight @ 2012-05-30 15:10 UTC (permalink / raw)
To: linuxppc-dev
(I apologise for this not having much to do with linux...)
We have a system with an MPC8315 ppc running linux 2.6.32
that uses the PCI express interface in RC mode to interface
to an Altera FPGA.
This uses both PIO and the PEX DMA interfaces (locally
written dma driver).
Under normal circumstances this all works fine.
However under some circumstances (eg DMA reads from
addresses that don't have actual slaves on the fpga [1])
the dma transfer requests don't complete.
There are no obvious error bits set in the hisr or csmisr
registers and the csb_status shows 'dma in progress'.
The dma transfer itself can be cancelled (by setting the
SUS bit in the dma_ctrl register), and the relevant
status bit are set to show the transfer has been aborted.
Once in this state all further PCI express transfers fail.
DMA requests timeout (driver gives up waiting for completion)
and PIO requests fault (Oops: Machine check, sig 7 [#1])
locking the kernel solid.
This looks very much like the MPC8315's errata PEX7
except that I don't see the CSMISR[RST] bit set.
I'm not at all sure the recovery for that errata is
actually writable! I'm certainly not going to write it
just to find out if it would help.
In any case it is quite likely that the driver's ISR will
try to do a PIO read while a dma transfer is timing out.
We can look at the fpga side and possibly find out
what it is doing, but it would be useful to know more
about the status on the ppc side.
I presume there is a way of doing a 'probe' type memory
cycle that won't panic on a fault?
Although that may not help me keep linux running as the
ISR needs to to a PCIe write to remove the level-sensitive
interrupt.
Any thought on ways to progress?
David
[1] PIO reads are ok and just return 0xffffffff.
^ permalink raw reply
* kernel panic during kernel module load (powerpc specific part)
From: Steffen Rumler @ 2012-05-30 14:33 UTC (permalink / raw)
To: linuxppc-dev
Hi,
We have seen the following kernel panic, happened during loading a kernel module:
[ 536.107430] Unable to handle kernel paging request for data at address 0xd76a907c
[ 536.114922] Faulting instruction address: 0xc0000770
[ 536.119891] Oops: Kernel access of bad area, sig: 11 [#1]
[ 536.125291] CCEP MPC8541E
[ 536.127908] Modules linked in: pppoe(+) nf_conntrack_ipv6 ...
[ 536.155705] NIP: c0000770 LR: c0000770 CTR: d76ab0d4
[ 536.160674] REGS: d76a8f24 TRAP: 0300 Not tainted (2.6.33-ccep)
[ 536.166857] MSR: 00021000 <ME,CE> CR: 24000482 XER: 20000000
[ 536.172718] DEAR: d76a907c, ESR: 00800000
[ 536.176728] TASK = cbd7f9f0[972] 'insmod' THREAD: cbeb2000
[ 536.182041] GPR00: 83cbfff8 d76a8fd4 cbd7f9f0 00000000 83cbfff8 00000000 cbeb3e1e 00000000
[ 536.190438] GPR08: 0000327b d76aa000 24000482 d76a8fd4 cbd7fc08 10019b04 100c2e5c 00000000
[ 536.198836] GPR16: 00000000 1009bafc 100c44a4 100c2ed4 100c0000 100d1e60 100d1ca8 100017ab
[ 536.207235] GPR24: 100017ae 10001936 c0343ae8 10012018 00000000 834bffe8 836bffec 838bfff0
[ 536.215819] NIP [c0000770] InstructionStorage+0xb0/0xc0
[ 536.221048] LR [c0000770] InstructionStorage+0xb0/0xc0
[ 536.226188] Call Trace:
[ 536.228630] Instruction dump:
[ 536.231600] 90eb002c 910b0030 7cbe0aa6 90ab00b8 7d846378 38a00000 39400401 914b00b0
[ 536.239386] 3d400002 614a1002 512a0420 4800d6f5 <c000e43c> c000e65c 60000000 60000000
[ 536.247348] Kernel panic - not syncing: Fatal exception in interrupt
[ 536.253704] Call Trace:
[ 536.256149] Rebooting in 10 seconds..
The system crashes inside the return of the init entry point of the kernel module.
I've found the following root cause:
(1) The system has a high number of NAT rules configured, which created a bigger vmalloc area.
I've checked this by looking at /proc/vmallocinfo.
(2) The kernel module ELF file contains the separate section .init.text for the init entry point,
which is marked with __init, as usual.
(3) The kernel module ELF file contains the function prologue and epilogue in the .text section.
(4) The epilogue is also called from the init entry point, in order to return to the caller.
It is intended to restore the non-volatile registers from the stack and to jump to the caller.
(5) Because of (1), it is not more possible to jump by a relative branch instruction. The distance is too big.
Instead, the trampoline method is applied, which allows longer jumps via register.
(please see see do_plt_call() in arch/powerpc/kernel/module_32.c)
(6) Unfortunately, the trampoline code (do_plt_call()) is using register r11 to setup the jump.
It looks like the prologue and epilogue are using also the register r11, in order to point to the previous stack frame.
This is a conflict !!! The trampoline code is damaging the content of r11.
According to the current EABI definitions, the register r11 has got a dedicated function (pointer to previous stack frame).
In the following, there are parts of the prologue/epilogue shown, which are generated by the compiler:
...
00000084 <_rest32gpr_28>:
84: 83 8b ff f0 lwz r28,-16(r11)
00000088 <_rest32gpr_29>:
88: 83 ab ff f4 lwz r29,-12(r11)
0000008c <_rest32gpr_30>:
8c: 83 cb ff f8 lwz r30,-8(r11)
00000090 <_rest32gpr_31>:
90: 83 eb ff fc lwz r31,-4(r11)
94: 4e 80 00 20 blr
00000098 <_rest32gpr_14_x>:
98: 81 cb ff b8 lwz r14,-72(r11)
...
I'd suggest to use register r12 instead of r11 in the trampoline generation code, in do_plt_call() (arch/powerpc/kernel/module_32.c).
I'm using kernel 2.6.33, but I think it is also relevant for the current kernel release.
Below, there is the complete debug sessions, showing more the details.
Thanks
Steffen Rumler
--
0xd54990c0: addi r11,r1,48
0xd54990c4: mr r3,r29
0xd54990c8: b 0xd5499100 <-- going to return from the init entry point
(gdb) bt
#0 0xd5499100 in ?? ()
#1 0xd54990ac in ?? ()
#2 0xc0001db0 in do_one_initcall (fn=0, wait=1131130) at init/main.c:719
#3 0xc0059e50 in sys_init_module (umod=<value optimized out>, ...
#4 0xc000e038 in syscall_dotrace_cont () at arch/powerpc/kernel/entry_32.S:331
Backtrace stopped: frame did not save the PC
(gdb) info reg r1
r1 0xcbbdbed0 3418210000
(gdb) x/2x 0xcbbdbed0
0xcbbdbed0: 0xcbbdbf00 0xd54990ac
(gdb) x/2x 0xcbbdbf00
0xcbbdbf00: 0xcbbdbf20 0xc0001db0
(gdb) info reg r11
r11 0xcbbdbf00 3418210048
--> the stack is OK here
--> r11 is OK, pointing to the previous stack frame
0xd5499100: lis r11,-10381 <-- this is the trampoline code using/changing r11 (do_plt_call()).
0xd5499104: addi r11,r11,-3888
0xd5499108: mtctr r11
(gdb) info reg r11
r11 0xd772f0d0 3614634192
<-- r11 is now damaged !!!
0xd549910c: bctr
0xd772f0d0: lwz r28,-16(r11) <-- the epilogue, using damaged r11 as stack pointer
0xd772f0d4: lwz r29,-12(r11)
0xd772f0d8: lwz r30,-8(r11)
0xd772f0dc: lwz r0,4(r11)
0xd772f0e0: lwz r31,-4(r11)
0xd772f0e4: mtlr r0
0xd772f0e8: mr r1,r11
(gdb) info reg lr
lr 0x83abfff4 0x83abfff4
0xd772f0ec: blr
(gdb) stepi
Program received signal SIGSTOP, Stopped (signal).
---> the kernel panic !!!
^ permalink raw reply
* Re: [RFC] [PATCH] powerpc: Add MSR_DE to MSR_KERNEL
From: Bob Cochran @ 2012-05-30 13:26 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-dev, support
In-Reply-To: <1338363814-19565-1-git-send-email-Joakim.Tjernlund@transmode.se>
On 05/30/2012 03:43 AM, Joakim Tjernlund wrote:
> Emulators such as BDI2000 and CodeWarrior needs to have MSR_DE set
> in order to support break points.
> This adds MSR_DE for kernel space only.
> ---
>
> I have tested this briefly with BDI2000 on P2010(e500) and
> it works for me. I don't know if there are any bad side effects, therfore
> this RFC.
>
> arch/powerpc/include/asm/reg.h | 2 +-
> arch/powerpc/include/asm/reg_booke.h | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
snip
I believe that additional patches are required for CodeWarrior to work
properly (e.g., assembly start up). I think the patches should come
from Freescale. For whatever reason, they include them in their SDK,
but haven't submitted them for inclusion in the mainline.
As a developer on Freescale Power products, I would like to see
Freescale offer up a CodeWarrior patch set, so I don't have to manage
the patches myself when working outside the SDK (i.e., on a more recent
kernel).
^ permalink raw reply
* Gianfar TX problems
From: Rodolfo Giometti @ 2012-05-30 12:02 UTC (permalink / raw)
To: linuxppc-dev
Hello,
I'm working on a P1021MDS based board and I have a strange behaviour
regarding the TX packets from the gianfar driver (linux 3.0.4-rc5).
Rx is working correctly but Tx is not... in particular I noticed that
the buffer descriptors are correctly filled but the packets simply do
NOT exit form the TSEC (I looked at TSEC's tx counters)!
What is puzzling me is that sometimes both TX and RX work correctly
but most of the time only Rx is working! Again, testing the same
uImage on a Freescale P1021MDS devboard everything works well!
Maybe something related to DMA/RAM coherence?
Thanks in advance,
Rodolfo
--
GNU/Linux Solutions e-mail: giometti@enneenne.com
Linux Device Driver giometti@linux.it
Embedded Systems phone: +39 349 2432127
UNIX programming skype: rodolfo.giometti
Freelance ICT Italia - Consulente ICT Italia - www.consulenti-ict.it
^ permalink raw reply
* Re[2]: [RFC] [PATCH] powerpc: Add MSR_DE to MSR_KERNEL
From: Abatron Support @ 2012-05-30 12:08 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev, Bob Cochran
In-Reply-To: <6F7E3816-E71B-466A-9C6F-9928E1CFD7B1@digitaldans.com>
>> I have tested this briefly with BDI2000 on P2010(e500) and
>> it works for me. I don't know if there are any bad side effects,
>> therfore
>> this RFC.
> We used to have MSR_DE surrounded by CONFIG_something
> to ensure it wasn't set under normal operation. IIRC, if MSR_DE
> is set, you will have problems with software debuggers that
> utilize the the debugging registers in the chip itself. You only want
> to force this to be set when using the BDI, not at other times.
This MSR_DE is also of interest and used for software debuggers that
make use of the debug registers. Only if MSR_DE is set then debug
interrupts are generated. If a debug event leads to a debug interrupt
handled by a software debugger or if it leads to a debug halt handled
by a JTAG tool is selected with DBCR0_EDM / DBCR0_IDM.
The "e500 Core Family Reference Manual" chapter "Chapter 8
Debug Support" explains in detail the effect of MSR_DE.
Ruedi
^ permalink raw reply
* Re: ppc/sata-fsl: orphan config value: CONFIG_MPC8315_DS
From: Li Yang @ 2012-05-30 10:59 UTC (permalink / raw)
To: Scott Wood
Cc: Li Yang-R58472, Jeff Garzik, Adrian Bunk, Anthony Foiani,
Robert P.J.Day, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4FC5546A.4090506@freescale.com>
On Wed, May 30, 2012 at 6:57 AM, Scott Wood <scottwood@freescale.com> wrote=
:
> On 05/29/2012 05:07 PM, Anthony Foiani wrote:
>> Scott Wood <scottwood@freescale.com> writes:
>>
>>> CONFIG_MPC831x_RDB doesn't mean that you're running on such a board,
>>> only that the kernel supports those boards. =C2=A0It should be a runtim=
e
>>> test.
>>
>> Point taken.
>>
>> If that SATA check is CPU/SOC-based, then it should be easy enough to
>> test. =C2=A0The cpuinfo for my board is:
>>
>> =C2=A0 # cat /proc/cpuinfo
>> =C2=A0 processor =C2=A0 =C2=A0 =C2=A0 : 0
>> =C2=A0 cpu =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : e300c3
>> =C2=A0 clock =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 266.666664MHz
>> =C2=A0 revision =C2=A0 =C2=A0 =C2=A0 =C2=A0: 2.0 (pvr 8085 0020)
>> =C2=A0 bogomips =C2=A0 =C2=A0 =C2=A0 =C2=A0: 66.66
>> =C2=A0 timebase =C2=A0 =C2=A0 =C2=A0 =C2=A0: 33333333
>>
>> On the other hand, if the problem is actually caused by board trace
>> routing (or other hardware that's outside the control of the CPU/SOC),
>> then I don't know how possible a runtime check will be.
>
> Board information is available from the device tree, and from platform
> code that was selected based on the device tree.
>
>> Do you know if there is a specific errata that the MPC8315_DS ran
>> across that required this fix, or was it a band-aid in the first
>> place?
>
> I don't know the history of this, sorry. =C2=A0It looks like Yang Li adde=
d
> this code -- Yang, can you answer this?
The original code was there before I touched the driver. So
unfortunately I also don't know the history of the problem. Judging
from the comment in code and current test result I guess it is a board
related issue. I agree with Anthony that the best action for now is
to remove the workaround completely.
Leo
^ permalink raw reply
* RE: pread() and pwrite() system calls
From: David Laight @ 2012-05-30 10:56 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc-dev
In-Reply-To: <20120525164550.GA32406@visitor2.iram.es>
> > We have a system with linux 2.6.32 and the somewhat archaic
> > uClibc 0.9.27 (but I'm not sure the current version is
> > any better, and I think there are binary compatibility
> > if we update).
> >=20
> > I've just discovered that pread() is 'implemented'
> > by using 3 lseek() system calls and read().
> > (the same is true for the 64bit versions).
...
> I think that it is an uClibc problem.
It seems that uClibc hadn't been changed when the
names of the constants used for the system calls
were changed from __NR_pread to __NR_pread64.
David
^ permalink raw reply
* [RFC PATCH powerpc] make CONFIG_NUMA depends on CONFIG_SMP
From: Li Zhong @ 2012-05-30 9:31 UTC (permalink / raw)
Cc: Paul Mackerras, PowerPC email list
I'm not sure whether it makes sense to add this dependency to avoid
CONFI_NUMA && !CONFIG_SMP.
I want to do this because I saw some build errors on next-tree when
compiling with CONFIG_SMP disabled, and it seems they are caused by some
codes under the CONFIG_NUMA #ifdefs.
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
---
arch/powerpc/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 050cb37..b2aa74b 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -394,7 +394,7 @@ config IRQ_ALL_CPUS
config NUMA
bool "NUMA support"
- depends on PPC64
+ depends on PPC64 && SMP
default y if SMP && PPC_PSERIES
config NODES_SHIFT
--
1.7.1
^ permalink raw reply related
* Re: [RFC] [PATCH] powerpc: Add MSR_DE to MSR_KERNEL
From: Dan Malek @ 2012-05-30 7:59 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-dev, Bob Cochran, support
In-Reply-To: <1338363814-19565-1-git-send-email-Joakim.Tjernlund@transmode.se>
Hi Joakim.
On May 30, 2012, at 12:43 AM, Joakim Tjernlund wrote:
> I have tested this briefly with BDI2000 on P2010(e500) and
> it works for me. I don't know if there are any bad side effects,
> therfore
> this RFC.
We used to have MSR_DE surrounded by CONFIG_something
to ensure it wasn't set under normal operation. IIRC, if MSR_DE
is set, you will have problems with software debuggers that
utilize the the debugging registers in the chip itself. You only want
to force this to be set when using the BDI, not at other times.
Thanks.
-- Dan
^ permalink raw reply
* [RFC] [PATCH] powerpc: Add MSR_DE to MSR_KERNEL
From: Joakim Tjernlund @ 2012-05-30 7:43 UTC (permalink / raw)
To: linuxppc-dev, support, Bob Cochran
Emulators such as BDI2000 and CodeWarrior needs to have MSR_DE set
in order to support break points.
This adds MSR_DE for kernel space only.
---
I have tested this briefly with BDI2000 on P2010(e500) and
it works for me. I don't know if there are any bad side effects, therfore
this RFC.
arch/powerpc/include/asm/reg.h | 2 +-
arch/powerpc/include/asm/reg_booke.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index 7fdc2c0..25c8554 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -108,7 +108,7 @@
#define MSR_USER64 MSR_USER32 | MSR_64BIT
#elif defined(CONFIG_PPC_BOOK3S_32) || defined(CONFIG_8xx)
/* Default MSR for kernel mode. */
-#define MSR_KERNEL (MSR_ME|MSR_RI|MSR_IR|MSR_DR)
+#define MSR_KERNEL (MSR_ME|MSR_RI|MSR_IR|MSR_DR|MSR_DE)
#define MSR_USER (MSR_KERNEL|MSR_PR|MSR_EE)
#endif
diff --git a/arch/powerpc/include/asm/reg_booke.h b/arch/powerpc/include/asm/reg_booke.h
index 500fe1d..0cb259b 100644
--- a/arch/powerpc/include/asm/reg_booke.h
+++ b/arch/powerpc/include/asm/reg_booke.h
@@ -37,7 +37,7 @@
#define MSR_KERNEL (MSR_ME|MSR_RI|MSR_IR|MSR_DR|MSR_CE)
#define MSR_USER (MSR_KERNEL|MSR_PR|MSR_EE)
#else
-#define MSR_KERNEL (MSR_ME|MSR_RI|MSR_CE)
+#define MSR_KERNEL (MSR_ME|MSR_RI|MSR_CE|MSR_DE)
#define MSR_USER (MSR_KERNEL|MSR_PR|MSR_EE)
#endif
--
1.7.3.4
^ permalink raw reply related
* [PATCH 2/2] powerpc: POWER7 optimised copy_page using VMX and enhanced prefetch
From: Anton Blanchard @ 2012-05-30 5:33 UTC (permalink / raw)
To: benh, paulus, michael, linuxppc-dev
In-Reply-To: <20120530153124.6a27d10d@kryten>
Implement a POWER7 optimised copy_page using VMX and enhanced
prefetch instructions. We use enhanced prefetch hints to prefetch
both the load and store side. We copy a cacheline at a time and
fall back to regular loads and stores if we are unable to use VMX
(eg we are in an interrupt).
The following microbenchmark was used to assess the impact of
the patch:
http://ozlabs.org/~anton/junkcode/page_fault_file.c
We test MAP_PRIVATE page faults across a 1GB file, 100 times:
# time ./page_fault_file -p -l 1G -i 100
Before: 22.25s
After: 18.89s
17% faster
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-build/arch/powerpc/lib/copypage_power7.S
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ linux-build/arch/powerpc/lib/copypage_power7.S 2012-05-30 14:20:32.457035092 +1000
@@ -0,0 +1,168 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * Copyright (C) IBM Corporation, 2012
+ *
+ * Author: Anton Blanchard <anton@au.ibm.com>
+ */
+#include <asm/page.h>
+#include <asm/ppc_asm.h>
+
+#define STACKFRAMESIZE 256
+#define STK_REG(i) (112 + ((i)-14)*8)
+
+_GLOBAL(copypage_power7)
+ /*
+ * We prefetch both the source and destination using enhanced touch
+ * instructions. We use a stream ID of 0 for the load side and
+ * 1 for the store side. Since source and destination are page
+ * aligned we don't need to clear the bottom 7 bits of either
+ * address.
+ */
+ ori r9,r3,1 /* stream=1 */
+
+#ifdef CONFIG_PPC_64K_PAGES
+ lis r7,0x0E01 /* depth=7, units=512 */
+#else
+ lis r7,0x0E00 /* depth=7 */
+ ori r7,r7,0x1000 /* units=32 */
+#endif
+ ori r10,r7,1 /* stream=1 */
+
+ lis r8,0x8000 /* GO=1 */
+ clrldi r8,r8,32
+
+.machine push
+.machine "power4"
+ dcbt r0,r4,0b01000
+ dcbt r0,r7,0b01010
+ dcbtst r0,r9,0b01000
+ dcbtst r0,r10,0b01010
+ eieio
+ dcbt r0,r8,0b01010 /* GO */
+.machine pop
+
+#ifdef CONFIG_ALTIVEC
+ mflr r0
+ std r3,48(r1)
+ std r4,56(r1)
+ std r0,16(r1)
+ stdu r1,-STACKFRAMESIZE(r1)
+ bl .enter_vmx_copy
+ cmpwi r3,0
+ ld r0,STACKFRAMESIZE+16(r1)
+ ld r3,STACKFRAMESIZE+48(r1)
+ ld r4,STACKFRAMESIZE+56(r1)
+ mtlr r0
+
+ li r0,(PAGE_SIZE/128)
+ mtctr r0
+
+ beq .Lnonvmx_copy
+
+ addi r1,r1,STACKFRAMESIZE
+
+ li r6,16
+ li r7,32
+ li r8,48
+ li r9,64
+ li r10,80
+ li r11,96
+ li r12,112
+
+ .align 5
+1: lvx vr7,r0,r4
+ lvx vr6,r4,r6
+ lvx vr5,r4,r7
+ lvx vr4,r4,r8
+ lvx vr3,r4,r9
+ lvx vr2,r4,r10
+ lvx vr1,r4,r11
+ lvx vr0,r4,r12
+ addi r4,r4,128
+ stvx vr7,r0,r3
+ stvx vr6,r3,r6
+ stvx vr5,r3,r7
+ stvx vr4,r3,r8
+ stvx vr3,r3,r9
+ stvx vr2,r3,r10
+ stvx vr1,r3,r11
+ stvx vr0,r3,r12
+ addi r3,r3,128
+ bdnz 1b
+
+ b .exit_vmx_copy /* tail call optimise */
+
+#else
+ li r0,(PAGE_SIZE/128)
+ mtctr r0
+
+ stdu r1,-STACKFRAMESIZE(r1)
+#endif
+
+.Lnonvmx_copy:
+ std r14,STK_REG(r14)(r1)
+ std r15,STK_REG(r15)(r1)
+ std r16,STK_REG(r16)(r1)
+ std r17,STK_REG(r17)(r1)
+ std r18,STK_REG(r18)(r1)
+ std r19,STK_REG(r19)(r1)
+ std r20,STK_REG(r20)(r1)
+
+1: ld r0,0(r4)
+ ld r5,8(r4)
+ ld r6,16(r4)
+ ld r7,24(r4)
+ ld r8,32(r4)
+ ld r9,40(r4)
+ ld r10,48(r4)
+ ld r11,56(r4)
+ ld r12,64(r4)
+ ld r14,72(r4)
+ ld r15,80(r4)
+ ld r16,88(r4)
+ ld r17,96(r4)
+ ld r18,104(r4)
+ ld r19,112(r4)
+ ld r20,120(r4)
+ addi r4,r4,128
+ std r0,0(r3)
+ std r5,8(r3)
+ std r6,16(r3)
+ std r7,24(r3)
+ std r8,32(r3)
+ std r9,40(r3)
+ std r10,48(r3)
+ std r11,56(r3)
+ std r12,64(r3)
+ std r14,72(r3)
+ std r15,80(r3)
+ std r16,88(r3)
+ std r17,96(r3)
+ std r18,104(r3)
+ std r19,112(r3)
+ std r20,120(r3)
+ addi r3,r3,128
+ bdnz 1b
+
+ ld r14,STK_REG(r14)(r1)
+ ld r15,STK_REG(r15)(r1)
+ ld r16,STK_REG(r16)(r1)
+ ld r17,STK_REG(r17)(r1)
+ ld r18,STK_REG(r18)(r1)
+ ld r19,STK_REG(r19)(r1)
+ ld r20,STK_REG(r20)(r1)
+ addi r1,r1,STACKFRAMESIZE
+ blr
Index: linux-build/arch/powerpc/lib/Makefile
===================================================================
--- linux-build.orig/arch/powerpc/lib/Makefile 2012-05-30 10:53:03.442309322 +1000
+++ linux-build/arch/powerpc/lib/Makefile 2012-05-30 11:07:54.361827650 +1000
@@ -17,7 +17,7 @@ obj-$(CONFIG_HAS_IOMEM) += devres.o
obj-$(CONFIG_PPC64) += copypage_64.o copyuser_64.o \
memcpy_64.o usercopy_64.o mem_64.o string.o \
checksum_wrappers_64.o hweight_64.o \
- copyuser_power7.o string_64.o
+ copyuser_power7.o string_64.o copypage_power7.o
obj-$(CONFIG_XMON) += sstep.o ldstfp.o
obj-$(CONFIG_KPROBES) += sstep.o ldstfp.o
obj-$(CONFIG_HAVE_HW_BREAKPOINT) += sstep.o ldstfp.o
Index: linux-build/arch/powerpc/lib/copypage_64.S
===================================================================
--- linux-build.orig/arch/powerpc/lib/copypage_64.S 2012-05-30 10:53:03.430309112 +1000
+++ linux-build/arch/powerpc/lib/copypage_64.S 2012-05-30 11:07:54.361827650 +1000
@@ -17,7 +17,11 @@ PPC64_CACHES:
.section ".text"
_GLOBAL(copy_page)
+BEGIN_FTR_SECTION
lis r5,PAGE_SIZE@h
+FTR_SECTION_ELSE
+ b .copypage_power7
+ALT_FTR_SECTION_END_IFCLR(CPU_FTR_VMX_COPY)
ori r5,r5,PAGE_SIZE@l
BEGIN_FTR_SECTION
ld r10,PPC64_CACHES@toc(r2)
Index: linux-build/arch/powerpc/lib/vmx-helper.c
===================================================================
--- linux-build.orig/arch/powerpc/lib/vmx-helper.c 2012-05-30 10:53:03.454309531 +1000
+++ linux-build/arch/powerpc/lib/vmx-helper.c 2012-05-30 14:20:38.637144276 +1000
@@ -49,3 +49,26 @@ int exit_vmx_usercopy(void)
pagefault_enable();
return 0;
}
+
+int enter_vmx_copy(void)
+{
+ if (in_interrupt())
+ return 0;
+
+ preempt_disable();
+
+ enable_kernel_altivec();
+
+ return 1;
+}
+
+/*
+ * All calls to this function will be optimised into tail calls. We are
+ * passed a pointer to the destination which we return as required by a
+ * memcpy implementation.
+ */
+void *exit_vmx_copy(void *dest)
+{
+ preempt_enable();
+ return dest;
+}
^ permalink raw reply
* [PATCH 1/2] powerpc: Rename copyuser_power7_vmx.c to vmx-helper.c
From: Anton Blanchard @ 2012-05-30 5:31 UTC (permalink / raw)
To: benh, paulus, michael, linuxppc-dev
Subsequent patches will add more VMX library functions and it makes
sense to keep all the c-code helper functions in the one file.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-build/arch/powerpc/lib/Makefile
===================================================================
--- linux-build.orig/arch/powerpc/lib/Makefile 2012-05-30 09:39:59.084233436 +1000
+++ linux-build/arch/powerpc/lib/Makefile 2012-05-30 10:22:32.565764322 +1000
@@ -24,7 +24,7 @@ obj-$(CONFIG_HAVE_HW_BREAKPOINT) += sste
ifeq ($(CONFIG_PPC64),y)
obj-$(CONFIG_SMP) += locks.o
-obj-$(CONFIG_ALTIVEC) += copyuser_power7_vmx.o
+obj-$(CONFIG_ALTIVEC) += vmx-helper.o
endif
obj-$(CONFIG_PPC_LIB_RHEAP) += rheap.o
Index: linux-build/arch/powerpc/lib/vmx-helper.c
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ linux-build/arch/powerpc/lib/vmx-helper.c 2012-05-30 10:22:32.577764541 +1000
@@ -0,0 +1,51 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * Copyright (C) IBM Corporation, 2011
+ *
+ * Authors: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
+ * Anton Blanchard <anton@au.ibm.com>
+ */
+#include <linux/uaccess.h>
+#include <linux/hardirq.h>
+#include <asm/switch_to.h>
+
+int enter_vmx_usercopy(void)
+{
+ if (in_interrupt())
+ return 0;
+
+ /* This acts as preempt_disable() as well and will make
+ * enable_kernel_altivec(). We need to disable page faults
+ * as they can call schedule and thus make us lose the VMX
+ * context. So on page faults, we just fail which will cause
+ * a fallback to the normal non-vmx copy.
+ */
+ pagefault_disable();
+
+ enable_kernel_altivec();
+
+ return 1;
+}
+
+/*
+ * This function must return 0 because we tail call optimise when calling
+ * from __copy_tofrom_user_power7 which returns 0 on success.
+ */
+int exit_vmx_usercopy(void)
+{
+ pagefault_enable();
+ return 0;
+}
Index: linux-build/arch/powerpc/lib/copyuser_power7_vmx.c
===================================================================
--- linux-build.orig/arch/powerpc/lib/copyuser_power7_vmx.c 2012-05-28 17:18:38.213091662 +1000
+++ /dev/null 1970-01-01 00:00:00.000000000 +0000
@@ -1,51 +0,0 @@
-/*
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
- *
- * Copyright (C) IBM Corporation, 2011
- *
- * Authors: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
- * Anton Blanchard <anton@au.ibm.com>
- */
-#include <linux/uaccess.h>
-#include <linux/hardirq.h>
-#include <asm/switch_to.h>
-
-int enter_vmx_copy(void)
-{
- if (in_interrupt())
- return 0;
-
- /* This acts as preempt_disable() as well and will make
- * enable_kernel_altivec(). We need to disable page faults
- * as they can call schedule and thus make us lose the VMX
- * context. So on page faults, we just fail which will cause
- * a fallback to the normal non-vmx copy.
- */
- pagefault_disable();
-
- enable_kernel_altivec();
-
- return 1;
-}
-
-/*
- * This function must return 0 because we tail call optimise when calling
- * from __copy_tofrom_user_power7 which returns 0 on success.
- */
-int exit_vmx_copy(void)
-{
- pagefault_enable();
- return 0;
-}
Index: linux-build/arch/powerpc/lib/copyuser_power7.S
===================================================================
--- linux-build.orig/arch/powerpc/lib/copyuser_power7.S 2012-05-29 21:22:43.725611809 +1000
+++ linux-build/arch/powerpc/lib/copyuser_power7.S 2012-05-30 10:23:29.198797007 +1000
@@ -61,7 +61,7 @@
ld r15,STK_REG(r15)(r1)
ld r14,STK_REG(r14)(r1)
.Ldo_err3:
- bl .exit_vmx_copy
+ bl .exit_vmx_usercopy
ld r0,STACKFRAMESIZE+16(r1)
mtlr r0
b .Lexit
@@ -290,7 +290,7 @@ err1; stb r0,0(r3)
mflr r0
std r0,16(r1)
stdu r1,-STACKFRAMESIZE(r1)
- bl .enter_vmx_copy
+ bl .enter_vmx_usercopy
cmpwi r3,0
ld r0,STACKFRAMESIZE+16(r1)
ld r3,STACKFRAMESIZE+48(r1)
@@ -507,7 +507,7 @@ err3; lbz r0,0(r4)
err3; stb r0,0(r3)
15: addi r1,r1,STACKFRAMESIZE
- b .exit_vmx_copy /* tail call optimise */
+ b .exit_vmx_usercopy /* tail call optimise */
.Lvmx_unaligned_copy:
/* Get the destination 16B aligned */
@@ -710,5 +710,5 @@ err3; lbz r0,0(r4)
err3; stb r0,0(r3)
15: addi r1,r1,STACKFRAMESIZE
- b .exit_vmx_copy /* tail call optimise */
+ b .exit_vmx_usercopy /* tail call optimise */
#endif /* CONFiG_ALTIVEC */
^ permalink raw reply
* Re: ppc/sata-fsl: orphan config value: CONFIG_MPC8315_DS
From: Scott Wood @ 2012-05-29 22:57 UTC (permalink / raw)
To: Anthony Foiani
Cc: Robert P.J.Day, linuxppc-dev@lists.ozlabs.org, Li Yang-R58472,
Jeff Garzik, Adrian Bunk
In-Reply-To: <gvcjetze3.fsf@dworkin.scrye.com>
On 05/29/2012 05:07 PM, Anthony Foiani wrote:
> Scott Wood <scottwood@freescale.com> writes:
>
>> CONFIG_MPC831x_RDB doesn't mean that you're running on such a board,
>> only that the kernel supports those boards. It should be a runtime
>> test.
>
> Point taken.
>
> If that SATA check is CPU/SOC-based, then it should be easy enough to
> test. The cpuinfo for my board is:
>
> # cat /proc/cpuinfo
> processor : 0
> cpu : e300c3
> clock : 266.666664MHz
> revision : 2.0 (pvr 8085 0020)
> bogomips : 66.66
> timebase : 33333333
>
> On the other hand, if the problem is actually caused by board trace
> routing (or other hardware that's outside the control of the CPU/SOC),
> then I don't know how possible a runtime check will be.
Board information is available from the device tree, and from platform
code that was selected based on the device tree.
> Do you know if there is a specific errata that the MPC8315_DS ran
> across that required this fix, or was it a band-aid in the first
> place?
I don't know the history of this, sorry. It looks like Yang Li added
this code -- Yang, can you answer this?
-Scott
^ permalink raw reply
* [PATCH] powerpc: Clear RI and EE at the same time in system call exit
From: Anton Blanchard @ 2012-05-29 22:22 UTC (permalink / raw)
To: benh, paulus, michael, scottwood; +Cc: linuxppc-dev
In-Reply-To: <4FC5104E.1000504@freescale.com>
Hi Scott,
> > syscall_exit_work:
> > + mtmsrd r10,1 /* Restore RI */
>
> That mtmsrd needs an #ifdef CONFIG_PPC_BOOK3S
Thanks!
Anton
--
In system call exit we currently clear RI and EE separately. An
mtmsrd is a slow operation and we can save cycles by doing it all
in one go.
This does complicate things a bit - we have to be careful to restore
RI if we branch out before returning to userspace.
On a POWER7 with virtual cputime disabled this patch improves the
null system call by 7%.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-build/arch/powerpc/kernel/entry_64.S
===================================================================
--- linux-build.orig/arch/powerpc/kernel/entry_64.S 2012-05-29 21:22:40.293549055 +1000
+++ linux-build/arch/powerpc/kernel/entry_64.S 2012-05-30 07:47:31.380737406 +1000
@@ -197,7 +197,16 @@ syscall_exit:
wrteei 0
#else
ld r10,PACAKMSR(r13)
- mtmsrd r10,1
+ /*
+ * For performance reasons we clear RI the same time that we
+ * clear EE. We only need to clear RI just before we restore r13
+ * below, but batching it with EE saves us one expensive mtmsrd call.
+ * We have to be careful to restore RI if we branch anywhere from
+ * here (eg syscall_exit_work).
+ */
+ li r9,MSR_RI
+ andc r11,r10,r9
+ mtmsrd r11,1
#endif /* CONFIG_PPC_BOOK3E */
ld r9,TI_FLAGS(r12)
@@ -214,17 +223,6 @@ BEGIN_FTR_SECTION
END_FTR_SECTION_IFCLR(CPU_FTR_STCX_CHECKS_ADDRESS)
andi. r6,r8,MSR_PR
ld r4,_LINK(r1)
- /*
- * Clear RI before restoring r13. If we are returning to
- * userspace and we take an exception after restoring r13,
- * we end up corrupting the userspace r13 value.
- */
-#ifdef CONFIG_PPC_BOOK3S
- /* No MSR:RI on BookE */
- li r12,MSR_RI
- andc r11,r10,r12
- mtmsrd r11,1 /* clear MSR.RI */
-#endif /* CONFIG_PPC_BOOK3S */
beq- 1f
ACCOUNT_CPU_USER_EXIT(r11, r12)
@@ -271,6 +269,9 @@ syscall_enosys:
b syscall_exit
syscall_exit_work:
+#ifdef CONFIG_PPC_BOOK3S
+ mtmsrd r10,1 /* Restore RI */
+#endif
/* If TIF_RESTOREALL is set, don't scribble on either r3 or ccr.
If TIF_NOERROR is set, just save r3 as it is. */
^ permalink raw reply
* Re: ppc/sata-fsl: orphan config value: CONFIG_MPC8315_DS
From: Anthony Foiani @ 2012-05-29 22:07 UTC (permalink / raw)
To: Scott Wood
Cc: Robert P.J.Day, linuxppc-dev@lists.ozlabs.org, Li Yang-R58472,
Jeff Garzik, Adrian Bunk
In-Reply-To: <4FC50F22.2040404@freescale.com>
Scott Wood <scottwood@freescale.com> writes:
> CONFIG_MPC831x_RDB doesn't mean that you're running on such a board,
> only that the kernel supports those boards. It should be a runtime
> test.
Point taken.
If that SATA check is CPU/SOC-based, then it should be easy enough to
test. The cpuinfo for my board is:
# cat /proc/cpuinfo
processor : 0
cpu : e300c3
clock : 266.666664MHz
revision : 2.0 (pvr 8085 0020)
bogomips : 66.66
timebase : 33333333
On the other hand, if the problem is actually caused by board trace
routing (or other hardware that's outside the control of the CPU/SOC),
then I don't know how possible a runtime check will be.
Do you know if there is a specific errata that the MPC8315_DS ran
across that required this fix, or was it a band-aid in the first
place?
Either way, thanks for looking into this.
Thanks,
Tony
^ permalink raw reply
* Re: MSR loses DE bit in 3.3, BDI2000 cant handle breakpoints?
From: Wolfgang Denk @ 2012-05-29 20:13 UTC (permalink / raw)
To: Bob Cochran; +Cc: linuxppc-dev
In-Reply-To: <4FC511C1.4050007@mindchasers.com>
Dear Bob,
In message <4FC511C1.4050007@mindchasers.com> you wrote:
>
> I debug using Freescale CodeWarrior and a USB tap, which also rely on
> MSR[DE] being set. I develop from the mainline & have a patch set that
> I just recently re-tweaked to support kernel debugging.
>
> If you want, I'll send you my set of patches for the kernel. They might
> be useful (not sure since I don't use BDI).
Please rather submit as a patch on the mailing list.
Thanks.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
egrep patterns are full regular expressions; it uses a fast determi-
nistic algorithm that sometimes needs exponential space.
- unix manuals
^ permalink raw reply
* Re: MSR loses DE bit in 3.3, BDI2000 cant handle breakpoints?
From: Bob Cochran @ 2012-05-29 18:13 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-dev
In-Reply-To: <OF00FC5182.FED0E75C-ONC1257A0D.003AA532-C1257A0D.0041F687@transmode.se>
On 05/29/2012 08:00 AM, Joakim Tjernlund wrote:
>
> I cannot make simple break points using BDI2000 work in 3.3, abatro suggests that it
> depends on MSR[DE] is cleared by the kernel. With the emulator I can see that
> MSR[DE] is off quite often by just stopping at random times and looking at MSR so
> it seems like the kernel is turning MSR[DE] off most of the time.
> Anyone else having success debugging 3.3 with BDI2000?
>
> This is on a P2010(E500/BOOKE) CPU.
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
I debug using Freescale CodeWarrior and a USB tap, which also rely on
MSR[DE] being set. I develop from the mainline & have a patch set that
I just recently re-tweaked to support kernel debugging.
If you want, I'll send you my set of patches for the kernel. They might
be useful (not sure since I don't use BDI).
^ permalink raw reply
* Re: MSR loses DE bit in 3.3, BDI2000 cant handle breakpoints?
From: Joakim Tjernlund @ 2012-05-29 18:29 UTC (permalink / raw)
To: Bob Cochran; +Cc: linuxppc-dev, support
In-Reply-To: <4FC511C1.4050007@mindchasers.com>
Bob Cochran <ppc@mindchasers.com> wrote on 2012/05/29 20:13:21:
>
> On 05/29/2012 08:00 AM, Joakim Tjernlund wrote:
> >
> > I cannot make simple break points using BDI2000 work in 3.3, abatro suggests that it
> > depends on MSR[DE] is cleared by the kernel. With the emulator I can see that
> > MSR[DE] is off quite often by just stopping at random times and looking at MSR so
> > it seems like the kernel is turning MSR[DE] off most of the time.
> > Anyone else having success debugging 3.3 with BDI2000?
> >
> > This is on a P2010(E500/BOOKE) CPU.
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
> >
>
> I debug using Freescale CodeWarrior and a USB tap, which also rely on
> MSR[DE] being set. I develop from the mainline & have a patch set that
> I just recently re-tweaked to support kernel debugging.
>
> If you want, I'll send you my set of patches for the kernel. They might
> be useful (not sure since I don't use BDI).
Thanks, that could be useful, however I just figured something out.
Changing
diff --git a/arch/powerpc/include/asm/reg_booke.h b/arch/powerpc/include/asm/reg_booke.h
index 500fe1d..0cb259b 100644
--- a/arch/powerpc/include/asm/reg_booke.h
+++ b/arch/powerpc/include/asm/reg_booke.h
@@ -37,7 +37,7 @@
#define MSR_KERNEL (MSR_ME|MSR_RI|MSR_IR|MSR_DR|MSR_CE)
#define MSR_USER (MSR_KERNEL|MSR_PR|MSR_EE)
#else
-#define MSR_KERNEL (MSR_ME|MSR_RI|MSR_CE)
+#define MSR_KERNEL (MSR_ME|MSR_RI|MSR_CE|MSR_DE)
#define MSR_USER (MSR_KERNEL|MSR_PR|MSR_EE)
#endif
Made it work(possible one should change MSR_USER too?)
Question now is why MSR_DE is not on by default? Especially since
BDI2000 is supported by the kernel(CONFIG_BDI_SWITCH=y) is on in my kernel?
Jocke
^ permalink raw reply related
* Re: [PATCH] powerpc: Clear RI and EE at the same time in system call exit
From: Scott Wood @ 2012-05-29 18:07 UTC (permalink / raw)
To: Anton Blanchard; +Cc: michael, paulus, linuxppc-dev
In-Reply-To: <20120529212010.0152a083@kryten>
On 05/29/2012 06:20 AM, Anton Blanchard wrote:
>
> In system call exit we currently clear RI and EE separately. An
> mtmsrd is a slow operation and we can save cycles by doing it all
> in one go.
>
> This does complicate things a bit - we have to be careful to restore
> RI if we branch out before returning to userspace.
>
> On a POWER7 with virtual cputime disabled this patch improves the
> null system call by 7%.
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
> ---
>
> Index: linux-build/arch/powerpc/kernel/entry_64.S
> ===================================================================
> --- linux-build.orig/arch/powerpc/kernel/entry_64.S 2012-05-28 18:23:33.374451416 +1000
> +++ linux-build/arch/powerpc/kernel/entry_64.S 2012-05-29 21:18:22.280934940 +1000
> @@ -197,7 +197,16 @@ syscall_exit:
> wrteei 0
> #else
> ld r10,PACAKMSR(r13)
> - mtmsrd r10,1
> + /*
> + * For performance reasons we clear RI the same time that we
> + * clear EE. We only need to clear RI just before we restore r13
> + * below, but batching it with EE saves us one expensive mtmsrd call.
> + * We have to be careful to restore RI if we branch anywhere from
> + * here (eg syscall_exit_work).
> + */
> + li r9,MSR_RI
> + andc r11,r10,r9
> + mtmsrd r11,1
> #endif /* CONFIG_PPC_BOOK3E */
>
> ld r9,TI_FLAGS(r12)
> @@ -214,17 +223,6 @@ BEGIN_FTR_SECTION
> END_FTR_SECTION_IFCLR(CPU_FTR_STCX_CHECKS_ADDRESS)
> andi. r6,r8,MSR_PR
> ld r4,_LINK(r1)
> - /*
> - * Clear RI before restoring r13. If we are returning to
> - * userspace and we take an exception after restoring r13,
> - * we end up corrupting the userspace r13 value.
> - */
> -#ifdef CONFIG_PPC_BOOK3S
> - /* No MSR:RI on BookE */
> - li r12,MSR_RI
> - andc r11,r10,r12
> - mtmsrd r11,1 /* clear MSR.RI */
> -#endif /* CONFIG_PPC_BOOK3S */
>
> beq- 1f
> ACCOUNT_CPU_USER_EXIT(r11, r12)
> @@ -271,6 +269,7 @@ syscall_enosys:
> b syscall_exit
>
> syscall_exit_work:
> + mtmsrd r10,1 /* Restore RI */
That mtmsrd needs an #ifdef CONFIG_PPC_BOOK3S
-Scott
^ permalink raw reply
* Re: ppc/sata-fsl: orphan config value: CONFIG_MPC8315_DS
From: Scott Wood @ 2012-05-29 18:02 UTC (permalink / raw)
To: Anthony Foiani
Cc: Robert P.J.Day, linuxppc-dev@lists.ozlabs.org, Li Yang-R58472,
Jeff Garzik, Adrian Bunk
In-Reply-To: <g7gvzbfhb.fsf@dworkin.scrye.com>
On 05/26/2012 01:53 AM, Anthony Foiani wrote:
> Li Yang-R58472 <r58472@freescale.com> writes:
>
>> Thanks for bringing [CONFIG_MPC8315_DS] up again. Looks like we do
>> have a problem here.
>
> My impression is that the simplest fix is Adrian's patch, which simply
> keys off CONFIG_MPC831x_RDB. It's not very satisfying, but I'll take
> "working" vs. "rare lockups at boot".
CONFIG_MPC831x_RDB doesn't mean that you're running on such a board,
only that the kernel supports those boards. It should be a runtime test.
-Scott
^ permalink raw reply
* RE: [linuxppc-release] [PATCH v5 1/5] powerpc/85xx: implement hardware timebase sync
From: Zhao Chenhui-B35336 @ 2012-05-29 12:20 UTC (permalink / raw)
To: galak@kernel.crashing.org
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org, Li Yang-R58472
In-Reply-To: <1336737235-15370-1-git-send-email-chenhui.zhao@freescale.com>
Hi Kumar,
There is no comment for these patches so far. Do you think these patches ca=
n be merged?
We really want these patches to be merged in this merge window.
Thanks.
Best Regards,
Chenhui
> -----Original Message-----
> From: Zhao Chenhui-B35336
> Sent: Friday, May 25, 2012 3:09 PM
> To: Wood Scott-B07421; galak@kernel.crashing.org
> Cc: Li Yang-R58472
> Subject: RE: [linuxppc-release] [PATCH v5 1/5] powerpc/85xx: implement ha=
rdware timebase sync
>=20
> Hi Scott and Kumar,
>=20
> Do you have comments for these patches?
>=20
> http://patchwork.ozlabs.org/patch/158484/
> http://patchwork.ozlabs.org/patch/158485/
> http://patchwork.ozlabs.org/patch/158487/
> http://patchwork.ozlabs.org/patch/158486/
> http://patchwork.ozlabs.org/patch/158488/
>=20
> Thanks.
>=20
> Best Regards,
> Chenhui
>=20
> > -----Original Message-----
> > From: linuxppc-release-bounces@linux.freescale.net [mailto:linuxppc-rel=
ease-
> > bounces@linux.freescale.net] On Behalf Of Zhao Chenhui-B35336
> > Sent: Friday, May 11, 2012 7:54 PM
> > To: linuxppc-dev@lists.ozlabs.org
> > Cc: Wood Scott-B07421; Li Yang-R58472; linux-kernel@vger.kernel.org; ga=
lak@kernel.crashing.org
> > Subject: [linuxppc-release] [PATCH v5 1/5] powerpc/85xx: implement hard=
ware timebase sync
> >
> > Do hardware timebase sync. Firstly, stop all timebases, and transfer
> > the timebase value of the boot core to the other core. Finally,
> > start all timebases.
> >
> > Only apply to dual-core chips, such as MPC8572, P2020, etc.
> >
> > Signed-off-by: Zhao Chenhui <chenhui.zhao@freescale.com>
> > Signed-off-by: Li Yang <leoli@freescale.com>
> > ---
> > arch/powerpc/include/asm/fsl_guts.h | 2 +
> > arch/powerpc/platforms/85xx/smp.c | 93 +++++++++++++++++++++++++++=
++++++--
> > 2 files changed, 91 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/powerpc/include/asm/fsl_guts.h b/arch/powerpc/include=
/asm/fsl_guts.h
> > index aa4c488..dd5ba2c 100644
> > --- a/arch/powerpc/include/asm/fsl_guts.h
> > +++ b/arch/powerpc/include/asm/fsl_guts.h
> > @@ -48,6 +48,8 @@ struct ccsr_guts {
> > __be32 dmuxcr; /* 0x.0068 - DMA Mux Control Register */
> > u8 res06c[0x70 - 0x6c];
> > __be32 devdisr; /* 0x.0070 - Device Disable Control */
> > +#define CCSR_GUTS_DEVDISR_TB1 0x00001000
> > +#define CCSR_GUTS_DEVDISR_TB0 0x00004000
> > __be32 devdisr2; /* 0x.0074 - Device Disable Control 2 */
> > u8 res078[0x7c - 0x78];
> > __be32 pmjcr; /* 0x.007c - 4 Power Management Jog Control Register =
*/
> > diff --git a/arch/powerpc/platforms/85xx/smp.c b/arch/powerpc/platforms=
/85xx/smp.c
> > index ff42490..6862dda 100644
> > --- a/arch/powerpc/platforms/85xx/smp.c
> > +++ b/arch/powerpc/platforms/85xx/smp.c
> > @@ -24,6 +24,7 @@
> > #include <asm/mpic.h>
> > #include <asm/cacheflush.h>
> > #include <asm/dbell.h>
> > +#include <asm/fsl_guts.h>
> >
> > #include <sysdev/fsl_soc.h>
> > #include <sysdev/mpic.h>
> > @@ -115,13 +116,70 @@ smp_85xx_kick_cpu(int nr)
> >
> > struct smp_ops_t smp_85xx_ops =3D {
> > .kick_cpu =3D smp_85xx_kick_cpu,
> > -#ifdef CONFIG_KEXEC
> > - .give_timebase =3D smp_generic_give_timebase,
> > - .take_timebase =3D smp_generic_take_timebase,
> > -#endif
> > };
> >
> > #ifdef CONFIG_KEXEC
> > +static struct ccsr_guts __iomem *guts;
> > +static u64 timebase;
> > +static int tb_req;
> > +static int tb_valid;
> > +
> > +static void mpc85xx_timebase_freeze(int freeze)
> > +{
> > + unsigned int mask;
> > +
> > + if (!guts)
> > + return;
> > +
> > + mask =3D CCSR_GUTS_DEVDISR_TB0 | CCSR_GUTS_DEVDISR_TB1;
> > + if (freeze)
> > + setbits32(&guts->devdisr, mask);
> > + else
> > + clrbits32(&guts->devdisr, mask);
> > +
> > + in_be32(&guts->devdisr);
> > +}
> > +
> > +static void mpc85xx_give_timebase(void)
> > +{
> > + unsigned long flags;
> > +
> > + local_irq_save(flags);
> > +
> > + while (!tb_req)
> > + barrier();
> > + tb_req =3D 0;
> > +
> > + mpc85xx_timebase_freeze(1);
> > + timebase =3D get_tb();
> > + mb();
> > + tb_valid =3D 1;
> > +
> > + while (tb_valid)
> > + barrier();
> > +
> > + mpc85xx_timebase_freeze(0);
> > +
> > + local_irq_restore(flags);
> > +}
> > +
> > +static void mpc85xx_take_timebase(void)
> > +{
> > + unsigned long flags;
> > +
> > + local_irq_save(flags);
> > +
> > + tb_req =3D 1;
> > + while (!tb_valid)
> > + barrier();
> > +
> > + set_tb(timebase >> 32, timebase & 0xffffffff);
> > + mb();
> > + tb_valid =3D 0;
> > +
> > + local_irq_restore(flags);
> > +}
> > +
> > atomic_t kexec_down_cpus =3D ATOMIC_INIT(0);
> >
> > void mpc85xx_smp_kexec_cpu_down(int crash_shutdown, int secondary)
> > @@ -228,6 +286,20 @@ smp_85xx_setup_cpu(int cpu_nr)
> > doorbell_setup_this_cpu();
> > }
> >
> > +#ifdef CONFIG_KEXEC
> > +static const struct of_device_id guts_ids[] =3D {
> > + { .compatible =3D "fsl,mpc8572-guts", },
> > + { .compatible =3D "fsl,mpc8560-guts", },
> > + { .compatible =3D "fsl,mpc8536-guts", },
> > + { .compatible =3D "fsl,p1020-guts", },
> > + { .compatible =3D "fsl,p1021-guts", },
> > + { .compatible =3D "fsl,p1022-guts", },
> > + { .compatible =3D "fsl,p1023-guts", },
> > + { .compatible =3D "fsl,p2020-guts", },
> > + {},
> > +};
> > +#endif
> > +
> > void __init mpc85xx_smp_init(void)
> > {
> > struct device_node *np;
> > @@ -249,6 +321,19 @@ void __init mpc85xx_smp_init(void)
> > smp_85xx_ops.cause_ipi =3D doorbell_cause_ipi;
> > }
> >
> > +#ifdef CONFIG_KEXEC
> > + np =3D of_find_matching_node(NULL, guts_ids);
> > + if (np) {
> > + guts =3D of_iomap(np, 0);
> > + smp_85xx_ops.give_timebase =3D mpc85xx_give_timebase;
> > + smp_85xx_ops.take_timebase =3D mpc85xx_take_timebase;
> > + of_node_put(np);
> > + } else {
> > + smp_85xx_ops.give_timebase =3D smp_generic_give_timebase;
> > + smp_85xx_ops.take_timebase =3D smp_generic_take_timebase;
> > + }
> > +#endif
> > +
> > smp_ops =3D &smp_85xx_ops;
> >
> > #ifdef CONFIG_KEXEC
> > --
> > 1.6.4.1
> >
> > _______________________________________________
> > linuxppc-release mailing list
> > linuxppc-release@linux.freescale.net
> > http://linux.freescale.net/mailman/listinfo/linuxppc-release
^ permalink raw reply
* MSR loses DE bit in 3.3, BDI2000 cant handle breakpoints?
From: Joakim Tjernlund @ 2012-05-29 12:00 UTC (permalink / raw)
To: linuxppc-dev
I cannot make simple break points using BDI2000 work in 3.3, abatro suggests that it
depends on MSR[DE] is cleared by the kernel. With the emulator I can see that
MSR[DE] is off quite often by just stopping at random times and looking at MSR so
it seems like the kernel is turning MSR[DE] off most of the time.
Anyone else having success debugging 3.3 with BDI2000?
This is on a P2010(E500/BOOKE) CPU.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox