* Re: self-modifying code in 2.6 kernel for ppc writes into readonly section
From: Michael Neuling @ 2008-08-18 19:19 UTC (permalink / raw)
To: Mihaela Grigore; +Cc: linuxppc-dev
In-Reply-To: <78ef7ce10808180901v6c694e63xefc37dd97485533@mail.gmail.com>
In message <78ef7ce10808180901v6c694e63xefc37dd97485533@mail.gmail.com> you wrote:
> Hello,
>
> First, I'm talkin about the 2.6.11 version. I know arch/ppc is gone in
> latest versions,
> but i assume the code is still the same and just moved to powerpc.
>
> There is a piece of code in the early initialization of the 2.6 kernel
> that identifies the cpu type and then tries to eliminate code that
> does not apply to the current cpu. This is done by writing nop's over
> sections of code that are not needed (do_cpu_ftr_fixups in
> arch/ppc/kernel/misc.S)
>
> When I try to run the kernel in a ppc emulator, I get a segmentation
> fault in do_cpu_ftr_fixups. From examining the section headers of the
> vmlinux, the text section is marked as readonly. The piece of code
> above mentioned is trying to write a nop to memory location inside the
> text section which is readonly, so that explains the sigsegv error.
Any segv in the emulator sounds like a bug in the emulator.
If the page really is marked read only, then writing to it should cause
a page fault.
> Since the kernel does run on boards with ppc cpu's, can somebody
> explain how come this is actually working ? Or if/where I am mistaking
> with my assumptions ?
>
> Thank you
>
> P.S. please add me in cc in a reply to this message
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
From: Scott Wood @ 2008-08-18 18:56 UTC (permalink / raw)
To: Steven Rostedt
Cc: Eran Liberty, Mathieu Desnoyers, linux-kernel, linuxppc-dev,
Steven Rostedt, Paul E. McKenney
In-Reply-To: <alpine.DEB.1.10.0808181445160.796@gandalf.stny.rr.com>
Steven Rostedt wrote:
> What syntax to do that with?
>
> lwz %1,0(%U2)
> stu %3, 0(%X2)
>
> I'm new to those. (and the above does not compile)
lwz%U2%X2 %1, %2
stw%U2%X2 %3, %2
>> Why stwu with an offset of zero,
>
> How else to do it? stwu %3, (%2) does not compile for me.
stw %3, 0(%2)
The "u" tells it to write the effective address back to %2 -- but with
an offset of zero, the effective address is unchanged.
-Scott
^ permalink raw reply
* Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
From: Eran Liberty @ 2008-08-18 18:25 UTC (permalink / raw)
To: Steven Rostedt
Cc: linuxppc-dev, Paul E. McKenney, Mathieu Desnoyers, linux-kernel,
rostedt
In-Reply-To: <48A9901B.1080900@redhat.com>
Steven Rostedt wrote:
> Eran Liberty wrote:
>> After compiling a kernel with ftrace I started to experience all
>> sorts of crashes.
>
> Just to make sure...
>
> ftrace enables markers too, and RCU has tracing with the markers. This
> may not be the problem, but I just want to eliminate as many variables
> as possible.
> Could you disable ftrace, but keep the markers on too. Also, could
> you enable ftrace again and turn on the FTRACE_STARTUP_TEST.
for the fun of it I took out all my propriety modules; so now its a non
tainted kernel.
Here is the matrix:
!FTRACE x !MARKERS => stable
!FTRACE x MARKERS => stable
FTRACE x !MARKERS => n/a (FTRACE forces MARKERS)
FTRACE x MARKERS => unstable
FTRACE x FTRACE_STARTUP_TEST x MARKERS => unstable + tests passed
Testing tracer sched_switch: PASSED
Testing tracer ftrace: PASSED
Testing dynamic ftrace: PASSED
Oops: Exception in kernel mode, sig: 11 [#1]
Exsw1600
Modules linked in:
NIP: c00bbb20 LR: c00bbb20 CTR: 00000000
REGS: dd5b1c50 TRAP: 0700 Not tainted (2.6.27-rc2)
MSR: 00029000 <EE,ME> CR: 24082282 XER: 20000000
TASK = ddcce060[1707] 'find' THREAD: dd5b0000
GPR00: 00000000 dd5b1d00 ddcce060 dd801180 dd5b1d68 dd5b1d58 dd80125b
100234ec
GPR08: c0800000 00019330 0000ffff dd5b1d20 24000288 100ad874 100936f8
1008a1d0
GPR16: 10083f80 dd5b1e2c dd5b1d68 fffffff4 c0380000 dd5b1d60 dd5b1d58
dd802084
GPR24: dc3d7700 dd802018 dd5b1d68 c0380000 dd801180 dd5b1d68 00000000
dd5b1d00
NIP [c00bbb20] d_lookup+0x40/0x90
LR [c00bbb20] d_lookup+0x40/0x90
Call Trace:
[dd5b1d00] [dd5b1d58] 0xdd5b1d58 (unreliable)
[dd5b1d20] [c00aebc4] do_lookup+0xe8/0x220
[dd5b1d50] [c00b0a80] __link_path_walk+0x5a4/0xd54
[dd5b1dc0] [c00b1288] path_walk+0x58/0xe0
[dd5b1df0] [c00b13f8] do_path_lookup+0x78/0x13c
[dd5b1e20] [c00b20f4] user_path_at+0x64/0xac
[dd5b1e90] [c00a9028] vfs_lstat_fd+0x34/0x74
[dd5b1ec0] [c00a90fc] vfs_lstat+0x30/0x48
[dd5b1ed0] [c00a9144] sys_lstat64+0x30/0x5c
[dd5b1f40] [c0010554] ret_from_syscall+0x0/0x3c
Instruction dump:
7c0802a6 bf61000c 3f60c038 7c3f0b78 90010024 7c7c1b78 7c9d2378 83db32a0
73c00001 7f83e378 7fa4eb78 4082002f <00000000> 2f830000 409e0030 801b32a0
---[ end trace 1eb8fd7adac2bb65 ]---
Liberty
^ permalink raw reply
* Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
From: Steven Rostedt @ 2008-08-18 18:50 UTC (permalink / raw)
To: Eran Liberty
Cc: linuxppc-dev, Steven Rostedt, Paul E. McKenney, Mathieu Desnoyers,
linux-kernel
In-Reply-To: <48A9BEA3.10906@extricom.com>
On Mon, 18 Aug 2008, Eran Liberty wrote:
> Steven Rostedt wrote:
> > Eran Liberty wrote:
> > > After compiling a kernel with ftrace I started to experience all sorts of
> > > crashes.
> >
> > Just to make sure...
> >
> > ftrace enables markers too, and RCU has tracing with the markers. This may
> > not be the problem, but I just want to eliminate as many variables as
> > possible.
> > Could you disable ftrace, but keep the markers on too. Also, could you
> > enable ftrace again and turn on the FTRACE_STARTUP_TEST.
>
> for the fun of it I took out all my propriety modules; so now its a non
> tainted kernel.
>
> Here is the matrix:
>
> !FTRACE x !MARKERS => stable
> !FTRACE x MARKERS => stable
> FTRACE x !MARKERS => n/a (FTRACE forces MARKERS)
> FTRACE x MARKERS => unstable
> FTRACE x FTRACE_STARTUP_TEST x MARKERS => unstable + tests passed
Thanks
>
> Testing tracer sched_switch: PASSED
> Testing tracer ftrace: PASSED
> Testing dynamic ftrace: PASSED
>
> Oops: Exception in kernel mode, sig: 11 [#1]
> Exsw1600
> Modules linked in:
> NIP: c00bbb20 LR: c00bbb20 CTR: 00000000
Could you load this into gdb for me and show me the output of:
gdb> li *0xc00bbb20
(Assuming you compiled with debuginfo on)
and...
gdb> disass 0xc00bbb20
> REGS: dd5b1c50 TRAP: 0700 Not tainted (2.6.27-rc2)
> MSR: 00029000 <EE,ME> CR: 24082282 XER: 20000000
> TASK = ddcce060[1707] 'find' THREAD: dd5b0000
> GPR00: 00000000 dd5b1d00 ddcce060 dd801180 dd5b1d68 dd5b1d58 dd80125b 100234ec
> GPR08: c0800000 00019330 0000ffff dd5b1d20 24000288 100ad874 100936f8 1008a1d0
> GPR16: 10083f80 dd5b1e2c dd5b1d68 fffffff4 c0380000 dd5b1d60 dd5b1d58 dd802084
> GPR24: dc3d7700 dd802018 dd5b1d68 c0380000 dd801180 dd5b1d68 00000000 dd5b1d00
> NIP [c00bbb20] d_lookup+0x40/0x90
> LR [c00bbb20] d_lookup+0x40/0x90
> Call Trace:
> [dd5b1d00] [dd5b1d58] 0xdd5b1d58 (unreliable)
> [dd5b1d20] [c00aebc4] do_lookup+0xe8/0x220
> [dd5b1d50] [c00b0a80] __link_path_walk+0x5a4/0xd54
> [dd5b1dc0] [c00b1288] path_walk+0x58/0xe0
> [dd5b1df0] [c00b13f8] do_path_lookup+0x78/0x13c
> [dd5b1e20] [c00b20f4] user_path_at+0x64/0xac
> [dd5b1e90] [c00a9028] vfs_lstat_fd+0x34/0x74
> [dd5b1ec0] [c00a90fc] vfs_lstat+0x30/0x48
> [dd5b1ed0] [c00a9144] sys_lstat64+0x30/0x5c
> [dd5b1f40] [c0010554] ret_from_syscall+0x0/0x3c
> Instruction dump:
> 7c0802a6 bf61000c 3f60c038 7c3f0b78 90010024 7c7c1b78 7c9d2378 83db32a0
> 73c00001 7f83e378 7fa4eb78 4082002f <00000000> 2f830000 409e0030 801b32a0
Ouch! we have a 00000000 instruction. I'm almost done with the new mcount
record for PPC (I have it done for ppc64, I'm just porting it to 32). I'm
thinking this new code may solve your issues too. I hate the daemon.
-- Steve
^ permalink raw reply
* Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
From: Steven Rostedt @ 2008-08-18 18:47 UTC (permalink / raw)
To: Scott Wood
Cc: Eran Liberty, Mathieu Desnoyers, linux-kernel, linuxppc-dev,
Steven Rostedt, Paul E. McKenney
In-Reply-To: <48A9AFA7.8080508@freescale.com>
On Mon, 18 Aug 2008, Scott Wood wrote:
> Mathieu Desnoyers wrote:
> > asm volatile (
> > "1: lwz %1, 0(%2)\n"
> > " cmpw %1, %5\n"
> > " bne 2f\n"
> > " stwu %3, 0(%2)\n"
> > "2:\n"
> > ".section .fixup, \"ax\"\n"
> > "3: li %0, 1\n"
> > " b 2b\n"
> > ".previous\n"
> > ".section __ex_table,\"a\"\n"
> > _ASM_ALIGN "\n"
> > _ASM_PTR "1b, 3b\n"
> > ".previous"
> > : "=r"(faulted), "=r"(replaced)
> > : "r"(ip), "r"(new),
> > "0"(faulted), "r"(old)
> > : "memory");
>
> Some (most likely unrelated) nits in the above inline asm:
>
> Should use a "b" constraint for %2, or you could get r0. Or, use an "m"
> constraint with %U2%X2 after the lwz/stw.
What syntax to do that with?
lwz %1,0(%U2)
stu %3, 0(%X2)
I'm new to those. (and the above does not compile)
> Why stwu with an offset of zero,
How else to do it? stwu %3, (%2) does not compile for me.
-- Steve
^ permalink raw reply
* Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
From: Mathieu Desnoyers @ 2008-08-18 18:41 UTC (permalink / raw)
To: Eran Liberty
Cc: linuxppc-dev, Steven Rostedt, Paul E. McKenney, linux-kernel,
rostedt
In-Reply-To: <48A9BEA3.10906@extricom.com>
* Eran Liberty (liberty@extricom.com) wrote:
> Steven Rostedt wrote:
>> Eran Liberty wrote:
>>> After compiling a kernel with ftrace I started to experience all sorts =
of=20
>>> crashes.
>>
>> Just to make sure...
>>
>> ftrace enables markers too, and RCU has tracing with the markers. This m=
ay=20
>> not be the problem, but I just want to eliminate as many variables as=20
>> possible.
>> Could you disable ftrace, but keep the markers on too. Also, could you=
=20
>> enable ftrace again and turn on the FTRACE_STARTUP_TEST.
>
> for the fun of it I took out all my propriety modules; so now its a non=
=20
> tainted kernel.
>
> Here is the matrix:
>
> !FTRACE x !MARKERS =3D> stable
> !FTRACE x MARKERS =3D> stable
> FTRACE x !MARKERS =3D> n/a (FTRACE forces MARKERS)
> FTRACE x MARKERS =3D> unstable
> FTRACE x FTRACE_STARTUP_TEST x MARKERS =3D> unstable + tests passed
>
> Testing tracer sched_switch: PASSED
> Testing tracer ftrace: PASSED
> Testing dynamic ftrace: PASSED
>
> Oops: Exception in kernel mode, sig: 11 [#1]
> Exsw1600
> Modules linked in:
> NIP: c00bbb20 LR: c00bbb20 CTR: 00000000
> REGS: dd5b1c50 TRAP: 0700 Not tainted (2.6.27-rc2)
> MSR: 00029000 <EE,ME> CR: 24082282 XER: 20000000
> TASK =3D ddcce060[1707] 'find' THREAD: dd5b0000
> GPR00: 00000000 dd5b1d00 ddcce060 dd801180 dd5b1d68 dd5b1d58 dd80125b=20
> 100234ec
> GPR08: c0800000 00019330 0000ffff dd5b1d20 24000288 100ad874 100936f8=20
> 1008a1d0
> GPR16: 10083f80 dd5b1e2c dd5b1d68 fffffff4 c0380000 dd5b1d60 dd5b1d58=20
> dd802084
> GPR24: dc3d7700 dd802018 dd5b1d68 c0380000 dd801180 dd5b1d68 00000000=20
> dd5b1d00
> NIP [c00bbb20] d_lookup+0x40/0x90
> LR [c00bbb20] d_lookup+0x40/0x90
> Call Trace:
> [dd5b1d00] [dd5b1d58] 0xdd5b1d58 (unreliable)
Can you check if, at some point during the system execution (starting
=66rom boot), 0xdd5b1d58 is an address where a module is loaded ? (the
module can be later unloaded, what I wonder is if this address would
appear to have had a loaded+unloaded module).
Actually, could you try to compile your kernel without "MODULE_UNLOAD" ?
Mathieu
> [dd5b1d20] [c00aebc4] do_lookup+0xe8/0x220
> [dd5b1d50] [c00b0a80] __link_path_walk+0x5a4/0xd54
> [dd5b1dc0] [c00b1288] path_walk+0x58/0xe0
> [dd5b1df0] [c00b13f8] do_path_lookup+0x78/0x13c
> [dd5b1e20] [c00b20f4] user_path_at+0x64/0xac
> [dd5b1e90] [c00a9028] vfs_lstat_fd+0x34/0x74
> [dd5b1ec0] [c00a90fc] vfs_lstat+0x30/0x48
> [dd5b1ed0] [c00a9144] sys_lstat64+0x30/0x5c
> [dd5b1f40] [c0010554] ret_from_syscall+0x0/0x3c
> Instruction dump:
> 7c0802a6 bf61000c 3f60c038 7c3f0b78 90010024 7c7c1b78 7c9d2378 83db32a0
> 73c00001 7f83e378 7fa4eb78 4082002f <00000000> 2f830000 409e0030 801b32a0
> ---[ end trace 1eb8fd7adac2bb65 ]---
>
> Liberty
>
>
--=20
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
^ permalink raw reply
* Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
From: Scott Wood @ 2008-08-18 18:29 UTC (permalink / raw)
To: Steven Rostedt
Cc: Eran Liberty, Mathieu Desnoyers, linux-kernel, linuxppc-dev,
Steven Rostedt, Paul E. McKenney
In-Reply-To: <alpine.DEB.1.10.0808181425090.796@gandalf.stny.rr.com>
Steven Rostedt wrote:
>> Should use a "b" constraint for %2, or you could get r0.
>
> I will make an updated patch.
>
>> Or, use an "m"
>> constraint with %U2%X2 after the lwz/stw.
>
> The 'b' seems easier ;-)
The advantage of the latter is that it allows GCC to choose indexed or
update instructions -- but that's merely an optimization. Switching to
"b" is enough to avoid the potential bug.
>> %1 also needs to be an early clobber.
>
> Not exactly sure what you mean by the above.
%1 is written to before some inputs are consumed, so you need to use
"=&r" rather than "=r" so that GCC won't use the same register for both.
-Scott
^ permalink raw reply
* Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
From: Steven Rostedt @ 2008-08-18 18:27 UTC (permalink / raw)
To: Scott Wood
Cc: Eran Liberty, Mathieu Desnoyers, linux-kernel, linuxppc-dev,
Steven Rostedt, Paul E. McKenney
In-Reply-To: <48A9AFA7.8080508@freescale.com>
On Mon, 18 Aug 2008, Scott Wood wrote:
> Mathieu Desnoyers wrote:
> > asm volatile (
> > "1: lwz %1, 0(%2)\n"
> > " cmpw %1, %5\n"
> > " bne 2f\n"
> > " stwu %3, 0(%2)\n"
> > "2:\n"
> > ".section .fixup, \"ax\"\n"
> > "3: li %0, 1\n"
> > " b 2b\n"
> > ".previous\n"
> > ".section __ex_table,\"a\"\n"
> > _ASM_ALIGN "\n"
> > _ASM_PTR "1b, 3b\n"
> > ".previous"
> > : "=r"(faulted), "=r"(replaced)
> > : "r"(ip), "r"(new),
> > "0"(faulted), "r"(old)
> > : "memory");
>
> Some (most likely unrelated) nits in the above inline asm:
Thanks,
>
> Should use a "b" constraint for %2, or you could get r0.
I will make an updated patch.
> Or, use an "m"
> constraint with %U2%X2 after the lwz/stw.
The 'b' seems easier ;-)
> Why stwu with an offset of zero,
> BTW?
Because it worked :-) Really, it has been a while since I did any PPC
assembly, and I didn't break out the old reference manuals to do this.
I simply looked at other asm code, and followed suit. I compiled and
tested it, and it worked. I did make a disclaimer about my rusty PPC
knowledge when I posted the code.
>
> %1 also needs to be an early clobber.
Not exactly sure what you mean by the above.
-- Steve
^ permalink raw reply
* Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
From: Scott Wood @ 2008-08-18 17:21 UTC (permalink / raw)
To: Mathieu Desnoyers
Cc: Eran Liberty, linux-kernel, rostedt, linuxppc-dev, Steven Rostedt,
Paul E. McKenney
In-Reply-To: <20080818154746.GA26835@Krystal>
Mathieu Desnoyers wrote:
> asm volatile (
> "1: lwz %1, 0(%2)\n"
> " cmpw %1, %5\n"
> " bne 2f\n"
> " stwu %3, 0(%2)\n"
> "2:\n"
> ".section .fixup, \"ax\"\n"
> "3: li %0, 1\n"
> " b 2b\n"
> ".previous\n"
> ".section __ex_table,\"a\"\n"
> _ASM_ALIGN "\n"
> _ASM_PTR "1b, 3b\n"
> ".previous"
> : "=r"(faulted), "=r"(replaced)
> : "r"(ip), "r"(new),
> "0"(faulted), "r"(old)
> : "memory");
Some (most likely unrelated) nits in the above inline asm:
Should use a "b" constraint for %2, or you could get r0. Or, use an "m"
constraint with %U2%X2 after the lwz/stw. Why stwu with an offset of
zero, BTW?
%1 also needs to be an early clobber.
-Scott
^ permalink raw reply
* Re: [PATCH 0/5] Relocatable 64-bit kernel using linker PIE support
From: Mohan Kumar M @ 2008-08-18 17:19 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18594.14443.340604.693747@cargo.ozlabs.ibm.com>
Hi Paul,
I can't boot zImage with your patches. I'm getting the following error
message from prom_init.c
Error: You can't boot a kdump kernel from OF!
This is due to the check:
if (PHYSICAL_START > 0)
prom_panic("Error: You can't boot a kdump kernel from OF!\n");
where PHYSICAL_START is kernstart_addr, and this variable needs to be
referred through RELOC macro
But even after commenting the above check, I am not able to boot zImage.
<snip boot message>
Building dt structure...
Device tree strings 0x0000000002ce4000 -> 0×0000000002ce5034
Device tree struct 0×0000000002ce6000 -> 0×0000000002cf0000
Calling quiesce …
returning from prom_init
<snip>
and the system hangs
It has CONFIG_RELOCATABLE set, (CONFIG_CRASH_DUMP is not set).
I even tried booting zImage through netboot, it also fails at the same
place.
If you need, I can give the .config I use.
Regards,
Mohan.
Paul Mackerras wrote:
> The following series of patches implement support for a relocatable
> kernel by building it as a position-independent executable (PIE).
> When the linker is given the -pie flag, it creates an executable that
> contains dynamic relocations which can be used to relocate the image
> at boot time for any desired base address. This patch series adds a
> CONFIG_RELOCATABLE config option for 64-bit which links the kernel
> with -pie and arranges to process the relocations in early boot.
>
> With the first 4 patches applied, a relocatable kernel will still copy
> itself down to real address 0. The last patch changes things so that
> a relocatable kernel will run wherever it was loaded. This last patch
> is pretty much just a proof of concept since it doesn't do anything to
> ensure appropriate alignment of the base address (the base address
> needs to be 16kB aligned). We probably want to work out whether we
> are a kdump kernel and run in-place if so, or copy down to 0 if not.
>
> Paul.
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
From: Mathieu Desnoyers @ 2008-08-18 17:04 UTC (permalink / raw)
To: Steven Rostedt
Cc: Paul E. McKenney, Eran Liberty, linux-kernel, rostedt,
linuxppc-dev
In-Reply-To: <48A99F51.8090504@redhat.com>
* Steven Rostedt (srostedt@redhat.com) wrote:
> Mathieu Desnoyers wrote:
>>
>> Steve ? I just noticed this :
>>
>>
>> ftrace_modify_code(unsigned long ip, unsigned char *old_code,
>> unsigned char *new_code)
>> {
>> unsigned replaced;
>> unsigned old = *(unsigned *)old_code;
>> unsigned new = *(unsigned *)new_code;
>> int faulted = 0;
>>
>> /*
>> * Note: Due to modules and __init, code can
>> * disappear and change, we need to protect against faulting
>> * as well as code changing.
>> *
>> * No real locking needed, this code is run through
>> * kstop_machine.
>> */
>> asm volatile (
>> "1: lwz %1, 0(%2)\n"
>> " cmpw %1, %5\n"
>> " bne 2f\n"
>> " stwu %3, 0(%2)\n"
>> "2:\n"
>> ".section .fixup, \"ax\"\n"
>> "3: li %0, 1\n"
>> " b 2b\n"
>> ".previous\n"
>> ".section __ex_table,\"a\"\n"
>> _ASM_ALIGN "\n"
>> _ASM_PTR "1b, 3b\n"
>> ".previous"
>> : "=r"(faulted), "=r"(replaced)
>> : "r"(ip), "r"(new),
>> "0"(faulted), "r"(old)
>> : "memory");
>>
>> if (replaced != old && replaced != new)
>> faulted = 2;
>>
>> if (!faulted)
>> flush_icache_range(ip, ip + 8);
>>
>> return faulted;
>> }
>>
>> What happens if you are really unlucky and get the following execution
>> sequence ?
>>
>>
>> Load module A at address 0xddfc3e00
>> Populate ftrace function table while the system runs
>> Unload module A
>> Load module B at address 0xddfc3e00
>> Activate ftrace
>> -> At that point, since there is another module loaded in the same
>> address space, it won't fault. If there happens to be an instruction
>> which looks exactly like the instruction we are replacing at the same
>> location, we are introducing a bug. True both on x86 ans powerpc...
>>
>>
>
> Hi Mathieu,
>
> Yep I know of this issue, and it is very unlikely it would happen. But
> that's not good enough, so this is why I did this:
>
> http://marc.info/?l=linux-kernel&m=121876928124384&w=2
> http://marc.info/?l=linux-kernel&m=121876938524523&w=2
>
> ;-)
>
> On powerpc it would be less likely an issue since the code segments are all
> 4 bytes aligned. And a call being replaced would be a call to mcount
> (relative jump). A call to mcount would be the same for both. Then again,
> we could be replacing a nop, but most likely that wouldn't hurt either,
> since nops are seldom used, and if we did call mcount, it would probably
> not hurt. But it would be an issue if Module B happen to put a data section
> that matched the code to jmp to mcount or a nop.
>
Ah, I did not see this one passing by :) That's the right solution
indeed. I guess it's not in 2.6.27-rc2/rc3 though ? I wonder if the
bug can be repeated with a module-free kernel ?
Mathieu
> -- Steve
>
--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
^ permalink raw reply
* RE: [PATCH] Linux Device Driver for Xilinx LL TEMAC 10/100/1000 EthernetNIC
From: Stephen Neuendorffer @ 2008-08-18 17:01 UTC (permalink / raw)
To: David H. Lynch Jr., linuxppc-embedded, netdev
In-Reply-To: <48A7B01C.2070403@dlasys.net>
> +static struct platform_driver temac_device_driver =3D {
> + .probe =3D temac_device_probe,
> + .remove =3D __devexit_p(temac_device_remove),
> + .suspend =3D NULL,
> + .resume =3D NULL,
> + .driver =3D {
> + .name =3D DRV_NAME,
> + .owner =3D THIS_MODULE,
> + },
> +};
I understand you're probably still using arch/ppc, but you'll need to
implement the of bindings as well. This can be done relatively easily
in parallel with a platform_device binding. (and you can probably get
alot of the code out of the xilinx LLTEMAC driver.
> diff --git a/include/linux/xilinx_devices.h
b/include/linux/xilinx_devices.h
> index 41ad421..79ca491 100755
> --- a/include/linux/xilinx_devices.h
> +++ b/include/linux/xilinx_devices.h
> @@ -94,7 +94,7 @@ struct xtemac_platform_data {
> #define XTEMAC_DMA_SGDMA 3 /* scatter gather DMA */
> #endif
> =
> -#if defined(CONFIG_XILINX_LLTEMAC)
> +#if defined(CONFIG_XILINX_LLTEMAC) || defined(CONFIG_XPS_LLTEMAC)
> /* LLTEMAC platform data */
> struct xlltemac_platform_data {
> u8 tx_csum;
You probably want to generate patches against mainline in the future...
Steve
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
From: Mathieu Desnoyers @ 2008-08-18 15:47 UTC (permalink / raw)
To: Steven Rostedt
Cc: Paul E. McKenney, Eran Liberty, linux-kernel, rostedt,
linuxppc-dev
In-Reply-To: <48A9901B.1080900@redhat.com>
* Steven Rostedt (srostedt@redhat.com) wrote:
> Eran Liberty wrote:
>> After compiling a kernel with ftrace I started to experience all sorts of
>> crashes.
>
> Just to make sure...
>
> ftrace enables markers too, and RCU has tracing with the markers. This may
> not be the problem, but I just want to eliminate as many variables as
> possible.
> Could you disable ftrace, but keep the markers on too. Also, could you
> enable ftrace again and turn on the FTRACE_STARTUP_TEST.
>
Steve ? I just noticed this :
ftrace_modify_code(unsigned long ip, unsigned char *old_code,
unsigned char *new_code)
{
unsigned replaced;
unsigned old = *(unsigned *)old_code;
unsigned new = *(unsigned *)new_code;
int faulted = 0;
/*
* Note: Due to modules and __init, code can
* disappear and change, we need to protect against faulting
* as well as code changing.
*
* No real locking needed, this code is run through
* kstop_machine.
*/
asm volatile (
"1: lwz %1, 0(%2)\n"
" cmpw %1, %5\n"
" bne 2f\n"
" stwu %3, 0(%2)\n"
"2:\n"
".section .fixup, \"ax\"\n"
"3: li %0, 1\n"
" b 2b\n"
".previous\n"
".section __ex_table,\"a\"\n"
_ASM_ALIGN "\n"
_ASM_PTR "1b, 3b\n"
".previous"
: "=r"(faulted), "=r"(replaced)
: "r"(ip), "r"(new),
"0"(faulted), "r"(old)
: "memory");
if (replaced != old && replaced != new)
faulted = 2;
if (!faulted)
flush_icache_range(ip, ip + 8);
return faulted;
}
What happens if you are really unlucky and get the following execution
sequence ?
Load module A at address 0xddfc3e00
Populate ftrace function table while the system runs
Unload module A
Load module B at address 0xddfc3e00
Activate ftrace
-> At that point, since there is another module loaded in the same
address space, it won't fault. If there happens to be an instruction
which looks exactly like the instruction we are replacing at the same
location, we are introducing a bug. True both on x86 ans powerpc...
Mathieu
> Thanks,
>
> -- Steve
>
>> I have a powerpc env which closly resemble mpc8548cds_defconfig.
>>
>> I have produced the crash in seconds by issuing:
>> > while [ 1 ] ; do find / > /dev/null ; echo . ; done
>>
>> Liberty
>>
>> here are some of the kernel crashes:
>> ---
>> ~ # find /proc/ -name kft
>> find: /proc/150/net/softnet_stat: No such file or direOops: Exception in
>> kernel mode, sig: 11 [#1]
>> Exsw1600
>> Modules linked in:
>> NIP: c00bd6fc LR: c00bd6fc CTR: 00000000
>> REGS: ddfc3d50 TRAP: 0700 Not tainted (2.6.27-rc2)
>> MSR: 00029000 <EE,ME> CR: 20002284 XER: 20000000
>> TASK = ddcccde0[1699] 'find' THREAD: ddfc2000
>> GPR00: 00000000 ddfc3e00 ddcccde0 dd895580 ddfc3e30 c00b5da0 ddfc3e90
>> 00000003
>> GPR08: c00ece54 00000370 00145505 00000003 80002282 100ad874 10083ca0
>> 10083cd8
>> GPR16: 10083cd0 00000008 00000000 c00b5da0 ddfc3f18 c00ece54 00000000
>> df465720
>> GPR24: d7431900 ddfc3e30 dd895580 c0380000 dd895580 ddfc3e30 00000000
>> ddfc3e00
>> NIP [c00bd6fc] d_lookup+0x40/0x90
>> LR [c00bd6fc] d_lookup+0x40/0x90
>> Call Trace:
>> [ddfc3e00] [c006ade4] rcu_process_callbacks+0x48/0x60 (unreliable)
>> [ddfc3e20] [c00eb514] proc_fill_cache+0x94/0x1b0
>> [ddfc3e80] [c00ef720] proc_task_readdir+0x294/0x3c4
>> [ddfc3ee0] [c00b60fc] vfs_readdir+0xb8/0xd8
>> [ddfc3f10] [c00b619c] sys_getdents64+0x80/0x104
>> [ddfc3f40] [c0010554] ret_from_syscall+0x0/0x3c
>> Instruction dump:
>> 7c0802a6 bf61000c 3f60c038 7c3f0b78 90010024 7c7c1b78 7c9d2378 83db52a0
>> 73c00001 7f83e378 7fa4eb78 4082002f <00000000> 2f830000 409e0030 801b52a0
>> ctory
>> ---[ end trace 6b059a7f5ba5a55a ]---
>>
>> ---
>>
>> Oops: Exception in kernel mode, sig: 11 [#1]
>> Exsw1600
>> Modules linked in: gplonly_api
>> NIP: c00bd6fc LR: c00bd6fc CTR: 00000000
>> REGS: df52dc40 TRAP: 0700 Not tainted (2.6.27-rc2)
>> MSR: 00029000 <EE,ME> CR: 20082422 XER: 20000000
>> TASK = ddc2e060[2294] 'eeprom' THREAD: df52c000
>> GPR00: 00000000 df52dcf0 ddc2e060 dd82c700 df52dd58 df52dd48 dd82c75e
>> 00000000
>> GPR08: c0800000 000311f0 0000ffff df52dd10 20002488 1001e75c 100b0000
>> 1008e90c
>> GPR16: bfd15a50 df52de6c df52dd58 fffffff4 c0380000 df52dd50 df52dd48
>> dd9303fc
>> GPR24: dc3a6800 dd930390 df52dd58 c0380000 dd82c700 df52dd58 00000006
>> df52dcf0
>> NIP [c00bd6fc] d_lookup+0x40/0x90
>> LR [c00bd6fc] d_lookup+0x40/0x90
>> Call Trace:
>> [df52dcf0] [df52dd48] 0xdf52dd48 (unreliable)
>> [df52dd10] [c00b07a0] do_lookup+0xe8/0x220
>> [df52dd40] [c00b222c] __link_path_walk+0x174/0xd54
>> [df52ddb0] [c00b2e64] path_walk+0x58/0xe0
>> [df52dde0] [c00b2fd4] do_path_lookup+0x78/0x13c
>> [df52de10] [c00b3f3c] __path_lookup_intent_open+0x68/0xdc
>> [df52de40] [c00b3fd8] path_lookup_open+0x28/0x40
>> [df52de50] [c00b4234] do_filp_open+0xa0/0x798
>> [df52df00] [c00a3b80] do_sys_open+0x70/0x114
>> [df52df30] [c00a3c98] sys_open+0x38/0x50
>> [df52df40] [c0010554] ret_from_syscall+0x0/0x3c
>> Instruction dump:
>> 7c0802a6 bf61000c 3f60c038 7c3f0b78 90010024 7c7c1b78 7c9d2378 83db52a0
>> 73c00001 7f83e378 7fa4eb78 4082002f <00000000> 2f830000 409e0030 801b52a0
>> om_version(Canno---[ end trace 0cef3c8cb49d09de ]---
>>
>> ---
>>
>> Oops: Exception in kernel mode, sig: 11 [#1]
>> Exsw1600
>> Modules linked in: bridge stp llc tun beacon_freescale(P) 80211(P)
>> shm_freescale(P) ath_remote_regs_freescale(P) exsw
>> load_local_fpga_freescale 8021q poe_fi
>> NIP: c00bd6fc LR: c00bd6fc CTR: 00000000
>> REGS: dd555c50 TRAP: 0700 Tainted: P (2.6.27-rc2)
>> MSR: 00029000 <EE,ME> CR: 24082282 XER: 20000000
>> TASK = df4669a0[4976] 'find' THREAD: dd554000
>> GPR00: 00000000 dd555d00 df4669a0 dd82ae00 dd555d68 dd555d58 dd82ae5b
>> 100234ec
>> GPR08: c0800000 0002dd0c 0000ffff dd555d20 24000288 100ad874 100936f8
>> 1008a1d0
>> GPR16: 10083f80 dd555e2c dd555d68 fffffff4 c0380000 dd555d60 dd555d58
>> dd9565d4
>> GPR24: dc3db480 dd956568 dd555d68 c0380000 dd82ae00 dd555d68 00000000
>> dd555d00
>> NIP [c00bd6fc] d_lookup+0x40/0x90
>> LR [c00bd6fc] d_lookup+0x40/0x90
>> Call Trace:
>> [dd555d00] [dd555d58] 0xdd555d58 (unreliable)
>> [dd555d20] [c00b07a0] do_lookup+0xe8/0x220
>> [dd555d50] [c00b265c] __link_path_walk+0x5a4/0xd54
>> [dd555dc0] [c00b2e64] path_walk+0x58/0xe0
>> [dd555df0] [c00b2fd4] do_path_lookup+0x78/0x13c
>> [dd555e20] [c00b3cd0] user_path_at+0x64/0xac
>> [dd555e90] [c00aac04] vfs_lstat_fd+0x34/0x74
>> [dd555ec0] [c00aacd8] vfs_lstat+0x30/0x48
>> [dd555ed0] [c00aad20] sys_lstat64+0x30/0x5c
>> [dd555f40] [c0010554] ret_from_syscall+0x0/0x3c
>> Instruction dump:
>> 7c0802a6 bf61000c 3f60c038 7c3f0b78 90010024 7c7c1b78 7c9d2378 83db52a0
>> 73c00001 7f83e378 7fa4eb78 4082002f <00000000> 2f830000 409e0030 801b52a0
>> 76/auxv
>> /proc/4---[ end trace 0deef0827ce9df4b ]---
>>
>> ---
>> Oops: Exception in kernel mode, sig: 11 [#1]
>> Exsw1600
>> Modules linked in: bridge stp llc tun beacon_freescale(P) 80211(P)
>> shm_freescale(P) ath_remote_regs_freescale(P) exsw
>> load_local_fpga_freescale 8021q poe_fi
>> NIP: c00bd6fc LR: c00bd6fc CTR: 00000000
>> REGS: d57e7c40 TRAP: 0700 Tainted: P (2.6.27-rc2)
>> MSR: 00029000 <EE,ME> CR: 24482482 XER: 20000000
>> TASK = db3cc940[2054] 'eapd' THREAD: d57e6000
>> GPR00: 00000000 d57e7cf0 db3cc940 dd82a500 d57e7d58 d57e7d48 dd82a55a
>> 00000000
>> GPR08: c0800000 00016c64 0000ffff d57e7d10 24422488 1008f700 4802cd38
>> 100763e8
>> GPR16: 4801d818 d57e7e6c d57e7d58 fffffff4 c0380000 d57e7d50 d57e7d48
>> dd956c74
>> GPR24: dc3db680 dd956c08 d57e7d58 c0380000 dd82a500 d57e7d58 00000000
>> d57e7cf0
>> NIP [c00bd6fc] d_lookup+0x40/0x90
>> LR [c00bd6fc] d_lookup+0x40/0x90
>> Call Trace:
>> [d57e7cf0] [d57e7d48] 0xd57e7d48 (unreliable)
>> [d57e7d10] [c00b07a0] do_lookup+0xe8/0x220
>> [d57e7d40] [c00b265c] __link_path_walk+0x5a4/0xd54
>> [d57e7db0] [c00b2e64] path_walk+0x58/0xe0
>> [d57e7de0] [c00b2fd4] do_path_lookup+0x78/0x13c
>> [d57e7e10] [c00b3f3c] __path_lookup_intent_open+0x68/0xdc
>> [d57e7e40] [c00b3fd8] path_lookup_open+0x28/0x40
>> [d57e7e50] [c00b4234] do_filp_open+0xa0/0x798
>> [d57e7f00] [c00a3b80] do_sys_open+0x70/0x114
>> [d57e7f30] [c00a3c98] sys_open+0x38/0x50
>> [d57e7f40] [c0010554] ret_from_syscall+0x0/0x3c
>> Instruction dump:
>> 7c0802a6 bf61000c 3f60c038 7c3f0b78 90010024 7c7c1b78 7c9d2378 83db52a0
>> 73c00001 7f83e378 7fa4eb78 4082002f <00000000> 2f830000 409e0030 801b52a0
>> ---[ end trace ffb4a6e37d78370a ]---
>>
>> ---
>> Oops: Exception in kernel mode, sig: 11 [#1]
>> Exsw1600
>> Modules linked in: bridge stp llc tun beacon_freescale(P) 80211(P)
>> shm_freescale(P) ath_remote_regs_freescale(P) exsw
>> load_local_fpga_freescale 8021q poe_fi
>> NIP: c00bd6fc LR: c00bd6fc CTR: c00bd6c8
>> REGS: decd5cf0 TRAP: 0700 Tainted: P (2.6.27-rc2)
>> MSR: 00029000 <EE,ME> CR: 22228882 XER: 20000000
>> TASK = d9f5a9a0[6897] 'sh' THREAD: decd4000
>> GPR00: 00000000 decd5da0 d9f5a9a0 dd801180 decd5de8 00000000 00000004
>> fffffff9
>> GPR08: fffffffa 00000000 00d5ca28 decd5d90 2ccc1686 100ad874 1fffb200
>> 00000000
>> GPR16: 007fff00 decd5ec4 00000008 c02fe298 00200200 00000000 c031aa34
>> decd5de8
>> GPR24: decd5df4 00001af2 dd507d00 c0380000 dd801180 decd5de8 00000000
>> decd5da0
>> NIP [c00bd6fc] d_lookup+0x40/0x90
>> LR [c00bd6fc] d_lookup+0x40/0x90
>> Call Trace:
>> [decd5dc0] [c00bd7d8] d_hash_and_lookup+0x8c/0xc4
>> [decd5de0] [c00ed728] proc_flush_task+0xb4/0x268
>> [decd5e40] [c0032894] release_task+0x6c/0x39c
>> [decd5e70] [c0033238] wait_consider_task+0x674/0x920
>> [decd5eb0] [c0033610] do_wait+0x12c/0x3d4
>> [decd5f20] [c0033954] sys_wait4+0x9c/0xe8
>> [decd5f40] [c0010554] ret_from_syscall+0x0/0x3c
>> Instruction dump:
>> 7c0802a6 bf61000c 3f60c038 7c3f0b78 90010024 7c7c1b78 7c9d2378 83db52a0
>> 73c00001 7f83e378 7fa4eb78 4082002f <00000000> 2f830000 409e0030 801b52a0
>> ---[ end trace 00106ff4ec3b9c22 ]---
>>
>>
>>
>>
>
--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
^ permalink raw reply
* [PATCH] POWERPC: duplicate test of MACIO_FLAG_SCCB_ON
From: roel kluin @ 2008-08-18 22:34 UTC (permalink / raw)
To: paulus, benh, linuxppc-dev, linux-kernel
untested, is it correct?
arch/powerpc/include/asm/pmac_feature.h:359:
#define MACIO_FLAG_SCCA_ON 0x00000001
#define MACIO_FLAG_SCCB_ON 0x00000002
---
duplicate test of MACIO_FLAG_SCCB_ON
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
diff --git a/arch/powerpc/platforms/powermac/feature.c b/arch/powerpc/platforms/powermac/feature.c
index 5169ecc..e6c0040 100644
--- a/arch/powerpc/platforms/powermac/feature.c
+++ b/arch/powerpc/platforms/powermac/feature.c
@@ -2677,7 +2677,7 @@ static void __init probe_one_macio(const char *name, const char *compat, int typ
macio_chips[i].of_node = node;
macio_chips[i].type = type;
macio_chips[i].base = base;
- macio_chips[i].flags = MACIO_FLAG_SCCB_ON | MACIO_FLAG_SCCB_ON;
+ macio_chips[i].flags = MACIO_FLAG_SCCA_ON | MACIO_FLAG_SCCB_ON;
macio_chips[i].name = macio_names[type];
revp = of_get_property(node, "revision-id", NULL);
if (revp)
^ permalink raw reply related
* Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
From: Steven Rostedt @ 2008-08-18 16:12 UTC (permalink / raw)
To: Mathieu Desnoyers
Cc: Paul E. McKenney, Eran Liberty, linux-kernel, rostedt,
linuxppc-dev
In-Reply-To: <20080818154746.GA26835@Krystal>
Mathieu Desnoyers wrote:
>
> Steve ? I just noticed this :
>
>
> ftrace_modify_code(unsigned long ip, unsigned char *old_code,
> unsigned char *new_code)
> {
> unsigned replaced;
> unsigned old = *(unsigned *)old_code;
> unsigned new = *(unsigned *)new_code;
> int faulted = 0;
>
> /*
> * Note: Due to modules and __init, code can
> * disappear and change, we need to protect against faulting
> * as well as code changing.
> *
> * No real locking needed, this code is run through
> * kstop_machine.
> */
> asm volatile (
> "1: lwz %1, 0(%2)\n"
> " cmpw %1, %5\n"
> " bne 2f\n"
> " stwu %3, 0(%2)\n"
> "2:\n"
> ".section .fixup, \"ax\"\n"
> "3: li %0, 1\n"
> " b 2b\n"
> ".previous\n"
> ".section __ex_table,\"a\"\n"
> _ASM_ALIGN "\n"
> _ASM_PTR "1b, 3b\n"
> ".previous"
> : "=r"(faulted), "=r"(replaced)
> : "r"(ip), "r"(new),
> "0"(faulted), "r"(old)
> : "memory");
>
> if (replaced != old && replaced != new)
> faulted = 2;
>
> if (!faulted)
> flush_icache_range(ip, ip + 8);
>
> return faulted;
> }
>
> What happens if you are really unlucky and get the following execution
> sequence ?
>
>
> Load module A at address 0xddfc3e00
> Populate ftrace function table while the system runs
> Unload module A
> Load module B at address 0xddfc3e00
> Activate ftrace
> -> At that point, since there is another module loaded in the same
> address space, it won't fault. If there happens to be an instruction
> which looks exactly like the instruction we are replacing at the same
> location, we are introducing a bug. True both on x86 ans powerpc...
>
>
Hi Mathieu,
Yep I know of this issue, and it is very unlikely it would happen. But
that's not good enough, so this is why I did this:
http://marc.info/?l=linux-kernel&m=121876928124384&w=2
http://marc.info/?l=linux-kernel&m=121876938524523&w=2
;-)
On powerpc it would be less likely an issue since the code segments are
all 4 bytes aligned. And a call being replaced would be a call to mcount
(relative jump). A call to mcount would be the same for both. Then
again, we could be replacing a nop, but most likely that wouldn't hurt
either, since nops are seldom used, and if we did call mcount, it would
probably not hurt. But it would be an issue if Module B happen to put a
data section that matched the code to jmp to mcount or a nop.
-- Steve
^ permalink raw reply
* self-modifying code in 2.6 kernel for ppc writes into readonly section
From: Mihaela Grigore @ 2008-08-18 16:01 UTC (permalink / raw)
To: linuxppc-dev
Hello,
First, I'm talkin about the 2.6.11 version. I know arch/ppc is gone in
latest versions,
but i assume the code is still the same and just moved to powerpc.
There is a piece of code in the early initialization of the 2.6 kernel
that identifies the cpu type and then tries to eliminate code that
does not apply to the current cpu. This is done by writing nop's over
sections of code that are not needed (do_cpu_ftr_fixups in
arch/ppc/kernel/misc.S)
When I try to run the kernel in a ppc emulator, I get a segmentation
fault in do_cpu_ftr_fixups. From examining the section headers of the
vmlinux, the text section is marked as readonly. The piece of code
above mentioned is trying to write a nop to memory location inside the
text section which is readonly, so that explains the sigsegv error.
Since the kernel does run on boards with ppc cpu's, can somebody
explain how come this is actually working ? Or if/where I am mistaking
with my assumptions ?
Thank you
P.S. please add me in cc in a reply to this message
^ permalink raw reply
* [PATCH] powerpc, scc: duplicate SCC_UHC_USBCEN
From: roel kluin @ 2008-08-18 22:06 UTC (permalink / raw)
To: kou.ishizaki, paulus, benh, linuxppc-dev, linux-kernel
untested, is it correct?
---
arch/powerpc/platforms/cell/celleb_scc.h:224:
#define SCC_UHC_USBEN 0x00010000
#define SCC_UHC_USBCEN 0x00020000
---
diff --git a/arch/powerpc/platforms/cell/celleb_scc_uhc.c b/arch/powerpc/platforms/cell/celleb_scc_uhc.c
index d63b720..b086f33 100644
--- a/arch/powerpc/platforms/cell/celleb_scc_uhc.c
+++ b/arch/powerpc/platforms/cell/celleb_scc_uhc.c
@@ -31,7 +31,7 @@
static inline int uhc_clkctrl_ready(u32 val)
{
- const u32 mask = SCC_UHC_USBCEN | SCC_UHC_USBCEN;
+ const u32 mask = SCC_UHC_USBCEN | SCC_UHC_USBEN;
return((val & mask) == mask);
}
^ permalink raw reply related
* Re: [PATCH V2] MPC52XX: Don't touch pipelining for MPC5200B
From: Grant Likely @ 2008-08-18 15:57 UTC (permalink / raw)
To: Wolfram Sang; +Cc: Arnd Bergmann, linuxppc-embedded
In-Reply-To: <20080818141831.GD4282@pengutronix.de>
On Mon, Aug 18, 2008 at 8:18 AM, Wolfram Sang <w.sang@pengutronix.de> wrote:
>
> MPC5200 needs to have pipelining disabled for ATA to work. MPC5200B does not.
> So, for the latter, don't touch the original setting from the bootloader.
>
> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Thanks Wolfram, I'll pick this one up.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Clock / Timebase / Bus Frequencies Help
From: Scott Wood @ 2008-08-18 15:59 UTC (permalink / raw)
To: richw@netcomuk.co.uk; +Cc: linuxppc-dev
In-Reply-To: <380-220088118115212377@M2W006.mail2web.com>
On Mon, Aug 18, 2008 at 07:52:12AM -0400, richw@netcomuk.co.uk wrote:
> We've got an 8347 based board very similar to the A&M asp8347. Core clock
> is 400MHz. Bus clock is 266666666Hz.
> According to the data sheet for the 8347, the decrementer clock runs at a
> quarter of the rate of the bus clock. I have two questions:
> In arch/powerpc/boot/redboot-83xx.c, the timebase clock is passed to
> dt_fixup_cpu_clocks() as bi_busfreq / 16. If I leave it like this, my
> system clock runs approximately 4 times too fast.
> Can anyone point me in the direction of an explanation for the div by 16
> rather than 4?
It's a bug, which I pointed out here:
http://ozlabs.org/pipermail/linuxppc-dev/2008-June/058704.html
> If I change the call to dt_fixup_cpu_clocks so that bi_busfreq/4 is passed
> in, then the clock runs more accurately. However, its still not correct.
> This gives a decrementer frequency of 66666666Hz, but if I hard code the
> value to 66000000Hz, the clock runs accurately.
> Can anyone shed any light on why the value passed in by the boot loader
> (redboot) seems to be inaccurate.
Redboot probably has the wrong crystal frequency hardcoded.
-Scott
^ permalink raw reply
* Re: [PATCH v2] powerpc: Improve message for vio bus entitlement panic
From: Robert Jennings @ 2008-08-18 15:34 UTC (permalink / raw)
To: Paul Mackerras, linuxppc-dev list, Benjamin Herrenschmidt
In-Reply-To: <20080815191205.GE20629@austin.ibm.com>
Add information regarding the available and required entitlement amounts
to the message displayed for the panic when insufficient entitlement is
provided at boot.
Signed-off-by: Robert Jennings <rcj@linux.vnet.ibm.com>
---
I had typed "Submitted-by" instead of "Signed-off-by" previously.
---
arch/powerpc/kernel/vio.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Index: b/arch/powerpc/kernel/vio.c
===================================================================
--- a/arch/powerpc/kernel/vio.c
+++ b/arch/powerpc/kernel/vio.c
@@ -899,7 +899,9 @@ static void vio_cmo_bus_init(void)
if (vio_cmo.reserve.size > vio_cmo.entitled) {
printk(KERN_ERR "%s: insufficient system entitlement\n",
__func__);
- panic("%s: Insufficient system entitlement", __func__);
+ panic("%s: Insufficient system entitlement. Available: %lu "
+ "Required: %lu", __func__, vio_cmo.entitled,
+ vio_cmo.reserve.size);
}
/* Set the remaining accounting variables */
^ permalink raw reply
* Re: [PATCH 1/3] gpiolib: make gpio_to_chip() public
From: Anton Vorontsov @ 2008-08-18 15:33 UTC (permalink / raw)
To: Laurent Pinchart
Cc: David Brownell, Greg Kroah-Hartman, linux-usb, linux-kernel,
linuxppc-dev, Li Yang, Timur Tabi
In-Reply-To: <200808181644.45480.laurentp@cse-semaphore.com>
On Mon, Aug 18, 2008 at 04:44:36PM +0200, Laurent Pinchart wrote:
> On Monday 18 August 2008, Anton Vorontsov wrote:
> > On Mon, Aug 18, 2008 at 03:58:46PM +0200, Laurent Pinchart wrote:
> > [...]
> > > > Not exactly. But you can do this way, if you need to preserve
> > > > a direction. What I did is a bit different though.
> > > >
> > > > qe_gpio_set_dedicated() actually just restores a mode that
> > > > firmware had set up, including direction (since direction could
> > > > be a part of dedicated configuration).
> > > >
> > > > That is, upon GPIO controller registration, we save all registers,
> > > > then driver can set up a pin to a GPIO mode via standard API, and
> > > > then it can _revert_ a pin to a dedicated function via
> > > > qe_gpio_set_dedicated() call. Dedicated function is specified by
> > > > the firmware (or board file), we're just restoring it.
> > >
> > > The semantic of the set_dedicated() operation needs to be clearly
> > > defined then.
> >
> > It is. We set up a dedicated function that firmware (or board file)
> > has configured.
>
> A comment in the source would help.
>
> > > I can live with this behaviour, but it might not be
> > > acceptable for everybody.
> >
> > For example?
> >
> > > Your patch requires the firmware to set a pin in dedicated mode at
> > > bootup in order to be used later in dedicated mode.
> >
> > Yes. On a PowerPC this is always true: firmware should set up PIO
> > config. Linux' board file could fixup the firmware though.
>
> That's not what I meant. What if the hardware requires to pin to be
> configured in GPIO mode with a fixed value until the SOC-specific
> driver that will drive the GPIO is loaded ? That's not possible
> with your API.
Yes, this isn't possible with this API. Because you can do this
with standard GPIO API! ;-)
Just call gpio_direction_*() in the board file, before probing the
hardware.
> Until a SOC peripheral is initialized by its associated Linux driver,
> the behaviour of a GPIO pin in dedicated mode will be undefined.
Huh?! Then all current software is simply broken: we're setting pinmux
config _prior_ to controller initialization.
> The firmware/board code will probably want to set the pin as a GPIO
> output with a fixed value until the driver initializes the hardware.
Probably? Do you have any such hardware?
> > Another option would be to add some argument to the set_dedicated
> > call, thus the software could specify arbitrary dedicated
> > function (thus no need to save/restore anything). But this would
> > be SOC-model specific, thus no driver can use this argument anyway.
>
> Drivers that require dedicated mode are SOC-specific anyway.
I didn't say "SOC-specific". I said "SOC-model specific", which
means that the driver would be not portable even across QE chips
(i.e. MPC8323 vs. MPC8360, you can assume that the "CLK12" function
is having same PAR/ODR/DAT/DIR bits).
> > > If, for some
> > > reason (driver not loaded, ...), no GPIO user shows up for that
> > > pin, it will stay configured in dedicated mode.
> >
> > Yes.
> >
> > > It might be better to set the PAR bit unconditionally in
> >
> > Why it might be better?
>
> Because, as explained a few lines down, the board initialization code
> will be able to configure a pin in a known state (PAR not set) at boot
> time until a driver requests the pin to be switched to dedicated mode.
You can do this as I described above. But prior to this, yes, you have
to configure the pins and let Linux save these values. There is no other
way to pass this information, unfortunately.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] powerpc: 85xx: TQM8548: DTS file fixes and cleanup
From: Kumar Gala @ 2008-08-18 15:29 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: Linuxppc-dev
In-Reply-To: <48A7E68D.8090405@grandegger.com>
On Aug 17, 2008, at 3:51 AM, Wolfgang Grandegger wrote:
> Due to the missing compatible property for the SOC, the MPC I2C
> buses are
> not found any more. This patch fixes this issue. Furthermore it
> corrects
> the name of the SOC node and adds the missing I2C node for the RTC.
>
> Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
> ---
> arch/powerpc/boot/dts/tqm8548-bigflash.dts | 8 +++++++-
> arch/powerpc/boot/dts/tqm8548.dts | 3 ++-
> 2 files changed, 9 insertions(+), 2 deletions(-)
applied.
- k
^ permalink raw reply
* Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
From: Steven Rostedt @ 2008-08-18 15:07 UTC (permalink / raw)
To: Eran Liberty
Cc: linuxppc-dev, Paul E. McKenney, Mathieu Desnoyers, linux-kernel,
rostedt
In-Reply-To: <48A92E15.2080709@extricom.com>
Eran Liberty wrote:
> After compiling a kernel with ftrace I started to experience all sorts
> of crashes.
Just to make sure...
ftrace enables markers too, and RCU has tracing with the markers. This
may not be the problem, but I just want to eliminate as many variables
as possible.
Could you disable ftrace, but keep the markers on too. Also, could you
enable ftrace again and turn on the FTRACE_STARTUP_TEST.
Thanks,
-- Steve
> I have a powerpc env which closly resemble mpc8548cds_defconfig.
>
> I have produced the crash in seconds by issuing:
> > while [ 1 ] ; do find / > /dev/null ; echo . ; done
>
> Liberty
>
> here are some of the kernel crashes:
> ---
> ~ # find /proc/ -name kft
> find: /proc/150/net/softnet_stat: No such file or direOops: Exception
> in kernel mode, sig: 11 [#1]
> Exsw1600
> Modules linked in:
> NIP: c00bd6fc LR: c00bd6fc CTR: 00000000
> REGS: ddfc3d50 TRAP: 0700 Not tainted (2.6.27-rc2)
> MSR: 00029000 <EE,ME> CR: 20002284 XER: 20000000
> TASK = ddcccde0[1699] 'find' THREAD: ddfc2000
> GPR00: 00000000 ddfc3e00 ddcccde0 dd895580 ddfc3e30 c00b5da0 ddfc3e90
> 00000003
> GPR08: c00ece54 00000370 00145505 00000003 80002282 100ad874 10083ca0
> 10083cd8
> GPR16: 10083cd0 00000008 00000000 c00b5da0 ddfc3f18 c00ece54 00000000
> df465720
> GPR24: d7431900 ddfc3e30 dd895580 c0380000 dd895580 ddfc3e30 00000000
> ddfc3e00
> NIP [c00bd6fc] d_lookup+0x40/0x90
> LR [c00bd6fc] d_lookup+0x40/0x90
> Call Trace:
> [ddfc3e00] [c006ade4] rcu_process_callbacks+0x48/0x60 (unreliable)
> [ddfc3e20] [c00eb514] proc_fill_cache+0x94/0x1b0
> [ddfc3e80] [c00ef720] proc_task_readdir+0x294/0x3c4
> [ddfc3ee0] [c00b60fc] vfs_readdir+0xb8/0xd8
> [ddfc3f10] [c00b619c] sys_getdents64+0x80/0x104
> [ddfc3f40] [c0010554] ret_from_syscall+0x0/0x3c
> Instruction dump:
> 7c0802a6 bf61000c 3f60c038 7c3f0b78 90010024 7c7c1b78 7c9d2378 83db52a0
> 73c00001 7f83e378 7fa4eb78 4082002f <00000000> 2f830000 409e0030 801b52a0
> ctory
> ---[ end trace 6b059a7f5ba5a55a ]---
>
> ---
>
> Oops: Exception in kernel mode, sig: 11 [#1]
> Exsw1600
> Modules linked in: gplonly_api
> NIP: c00bd6fc LR: c00bd6fc CTR: 00000000
> REGS: df52dc40 TRAP: 0700 Not tainted (2.6.27-rc2)
> MSR: 00029000 <EE,ME> CR: 20082422 XER: 20000000
> TASK = ddc2e060[2294] 'eeprom' THREAD: df52c000
> GPR00: 00000000 df52dcf0 ddc2e060 dd82c700 df52dd58 df52dd48 dd82c75e
> 00000000
> GPR08: c0800000 000311f0 0000ffff df52dd10 20002488 1001e75c 100b0000
> 1008e90c
> GPR16: bfd15a50 df52de6c df52dd58 fffffff4 c0380000 df52dd50 df52dd48
> dd9303fc
> GPR24: dc3a6800 dd930390 df52dd58 c0380000 dd82c700 df52dd58 00000006
> df52dcf0
> NIP [c00bd6fc] d_lookup+0x40/0x90
> LR [c00bd6fc] d_lookup+0x40/0x90
> Call Trace:
> [df52dcf0] [df52dd48] 0xdf52dd48 (unreliable)
> [df52dd10] [c00b07a0] do_lookup+0xe8/0x220
> [df52dd40] [c00b222c] __link_path_walk+0x174/0xd54
> [df52ddb0] [c00b2e64] path_walk+0x58/0xe0
> [df52dde0] [c00b2fd4] do_path_lookup+0x78/0x13c
> [df52de10] [c00b3f3c] __path_lookup_intent_open+0x68/0xdc
> [df52de40] [c00b3fd8] path_lookup_open+0x28/0x40
> [df52de50] [c00b4234] do_filp_open+0xa0/0x798
> [df52df00] [c00a3b80] do_sys_open+0x70/0x114
> [df52df30] [c00a3c98] sys_open+0x38/0x50
> [df52df40] [c0010554] ret_from_syscall+0x0/0x3c
> Instruction dump:
> 7c0802a6 bf61000c 3f60c038 7c3f0b78 90010024 7c7c1b78 7c9d2378 83db52a0
> 73c00001 7f83e378 7fa4eb78 4082002f <00000000> 2f830000 409e0030 801b52a0
> om_version(Canno---[ end trace 0cef3c8cb49d09de ]---
>
> ---
>
> Oops: Exception in kernel mode, sig: 11 [#1]
> Exsw1600
> Modules linked in: bridge stp llc tun beacon_freescale(P) 80211(P)
> shm_freescale(P) ath_remote_regs_freescale(P) exsw
> load_local_fpga_freescale 8021q poe_fi
> NIP: c00bd6fc LR: c00bd6fc CTR: 00000000
> REGS: dd555c50 TRAP: 0700 Tainted: P (2.6.27-rc2)
> MSR: 00029000 <EE,ME> CR: 24082282 XER: 20000000
> TASK = df4669a0[4976] 'find' THREAD: dd554000
> GPR00: 00000000 dd555d00 df4669a0 dd82ae00 dd555d68 dd555d58 dd82ae5b
> 100234ec
> GPR08: c0800000 0002dd0c 0000ffff dd555d20 24000288 100ad874 100936f8
> 1008a1d0
> GPR16: 10083f80 dd555e2c dd555d68 fffffff4 c0380000 dd555d60 dd555d58
> dd9565d4
> GPR24: dc3db480 dd956568 dd555d68 c0380000 dd82ae00 dd555d68 00000000
> dd555d00
> NIP [c00bd6fc] d_lookup+0x40/0x90
> LR [c00bd6fc] d_lookup+0x40/0x90
> Call Trace:
> [dd555d00] [dd555d58] 0xdd555d58 (unreliable)
> [dd555d20] [c00b07a0] do_lookup+0xe8/0x220
> [dd555d50] [c00b265c] __link_path_walk+0x5a4/0xd54
> [dd555dc0] [c00b2e64] path_walk+0x58/0xe0
> [dd555df0] [c00b2fd4] do_path_lookup+0x78/0x13c
> [dd555e20] [c00b3cd0] user_path_at+0x64/0xac
> [dd555e90] [c00aac04] vfs_lstat_fd+0x34/0x74
> [dd555ec0] [c00aacd8] vfs_lstat+0x30/0x48
> [dd555ed0] [c00aad20] sys_lstat64+0x30/0x5c
> [dd555f40] [c0010554] ret_from_syscall+0x0/0x3c
> Instruction dump:
> 7c0802a6 bf61000c 3f60c038 7c3f0b78 90010024 7c7c1b78 7c9d2378 83db52a0
> 73c00001 7f83e378 7fa4eb78 4082002f <00000000> 2f830000 409e0030 801b52a0
> 76/auxv
> /proc/4---[ end trace 0deef0827ce9df4b ]---
>
> ---
> Oops: Exception in kernel mode, sig: 11 [#1]
> Exsw1600
> Modules linked in: bridge stp llc tun beacon_freescale(P) 80211(P)
> shm_freescale(P) ath_remote_regs_freescale(P) exsw
> load_local_fpga_freescale 8021q poe_fi
> NIP: c00bd6fc LR: c00bd6fc CTR: 00000000
> REGS: d57e7c40 TRAP: 0700 Tainted: P (2.6.27-rc2)
> MSR: 00029000 <EE,ME> CR: 24482482 XER: 20000000
> TASK = db3cc940[2054] 'eapd' THREAD: d57e6000
> GPR00: 00000000 d57e7cf0 db3cc940 dd82a500 d57e7d58 d57e7d48 dd82a55a
> 00000000
> GPR08: c0800000 00016c64 0000ffff d57e7d10 24422488 1008f700 4802cd38
> 100763e8
> GPR16: 4801d818 d57e7e6c d57e7d58 fffffff4 c0380000 d57e7d50 d57e7d48
> dd956c74
> GPR24: dc3db680 dd956c08 d57e7d58 c0380000 dd82a500 d57e7d58 00000000
> d57e7cf0
> NIP [c00bd6fc] d_lookup+0x40/0x90
> LR [c00bd6fc] d_lookup+0x40/0x90
> Call Trace:
> [d57e7cf0] [d57e7d48] 0xd57e7d48 (unreliable)
> [d57e7d10] [c00b07a0] do_lookup+0xe8/0x220
> [d57e7d40] [c00b265c] __link_path_walk+0x5a4/0xd54
> [d57e7db0] [c00b2e64] path_walk+0x58/0xe0
> [d57e7de0] [c00b2fd4] do_path_lookup+0x78/0x13c
> [d57e7e10] [c00b3f3c] __path_lookup_intent_open+0x68/0xdc
> [d57e7e40] [c00b3fd8] path_lookup_open+0x28/0x40
> [d57e7e50] [c00b4234] do_filp_open+0xa0/0x798
> [d57e7f00] [c00a3b80] do_sys_open+0x70/0x114
> [d57e7f30] [c00a3c98] sys_open+0x38/0x50
> [d57e7f40] [c0010554] ret_from_syscall+0x0/0x3c
> Instruction dump:
> 7c0802a6 bf61000c 3f60c038 7c3f0b78 90010024 7c7c1b78 7c9d2378 83db52a0
> 73c00001 7f83e378 7fa4eb78 4082002f <00000000> 2f830000 409e0030 801b52a0
> ---[ end trace ffb4a6e37d78370a ]---
>
> ---
> Oops: Exception in kernel mode, sig: 11 [#1]
> Exsw1600
> Modules linked in: bridge stp llc tun beacon_freescale(P) 80211(P)
> shm_freescale(P) ath_remote_regs_freescale(P) exsw
> load_local_fpga_freescale 8021q poe_fi
> NIP: c00bd6fc LR: c00bd6fc CTR: c00bd6c8
> REGS: decd5cf0 TRAP: 0700 Tainted: P (2.6.27-rc2)
> MSR: 00029000 <EE,ME> CR: 22228882 XER: 20000000
> TASK = d9f5a9a0[6897] 'sh' THREAD: decd4000
> GPR00: 00000000 decd5da0 d9f5a9a0 dd801180 decd5de8 00000000 00000004
> fffffff9
> GPR08: fffffffa 00000000 00d5ca28 decd5d90 2ccc1686 100ad874 1fffb200
> 00000000
> GPR16: 007fff00 decd5ec4 00000008 c02fe298 00200200 00000000 c031aa34
> decd5de8
> GPR24: decd5df4 00001af2 dd507d00 c0380000 dd801180 decd5de8 00000000
> decd5da0
> NIP [c00bd6fc] d_lookup+0x40/0x90
> LR [c00bd6fc] d_lookup+0x40/0x90
> Call Trace:
> [decd5dc0] [c00bd7d8] d_hash_and_lookup+0x8c/0xc4
> [decd5de0] [c00ed728] proc_flush_task+0xb4/0x268
> [decd5e40] [c0032894] release_task+0x6c/0x39c
> [decd5e70] [c0033238] wait_consider_task+0x674/0x920
> [decd5eb0] [c0033610] do_wait+0x12c/0x3d4
> [decd5f20] [c0033954] sys_wait4+0x9c/0xe8
> [decd5f40] [c0010554] ret_from_syscall+0x0/0x3c
> Instruction dump:
> 7c0802a6 bf61000c 3f60c038 7c3f0b78 90010024 7c7c1b78 7c9d2378 83db52a0
> 73c00001 7f83e378 7fa4eb78 4082002f <00000000> 2f830000 409e0030 801b52a0
> ---[ end trace 00106ff4ec3b9c22 ]---
>
>
>
>
^ permalink raw reply
* Re: [PATCH 1/3] gpiolib: make gpio_to_chip() public
From: Laurent Pinchart @ 2008-08-18 14:44 UTC (permalink / raw)
To: avorontsov
Cc: David Brownell, Greg Kroah-Hartman, linux-usb, linux-kernel,
linuxppc-dev, Li Yang, Timur Tabi
In-Reply-To: <20080818143343.GA30812@oksana.dev.rtsoft.ru>
[-- Attachment #1: Type: text/plain, Size: 3210 bytes --]
On Monday 18 August 2008, Anton Vorontsov wrote:
> On Mon, Aug 18, 2008 at 03:58:46PM +0200, Laurent Pinchart wrote:
> [...]
> > > Not exactly. But you can do this way, if you need to preserve
> > > a direction. What I did is a bit different though.
> > >
> > > qe_gpio_set_dedicated() actually just restores a mode that
> > > firmware had set up, including direction (since direction could
> > > be a part of dedicated configuration).
> > >
> > > That is, upon GPIO controller registration, we save all registers,
> > > then driver can set up a pin to a GPIO mode via standard API, and
> > > then it can _revert_ a pin to a dedicated function via
> > > qe_gpio_set_dedicated() call. Dedicated function is specified by
> > > the firmware (or board file), we're just restoring it.
> >
> > The semantic of the set_dedicated() operation needs to be clearly
> > defined then.
>
> It is. We set up a dedicated function that firmware (or board file)
> has configured.
A comment in the source would help.
> > I can live with this behaviour, but it might not be
> > acceptable for everybody.
>
> For example?
>
> > Your patch requires the firmware to set a pin in dedicated mode at
> > bootup in order to be used later in dedicated mode.
>
> Yes. On a PowerPC this is always true: firmware should set up PIO
> config. Linux' board file could fixup the firmware though.
That's not what I meant. What if the hardware requires to pin to be configured in GPIO mode with a fixed value until the SOC-specific driver that will drive the GPIO is loaded ? That's not possible with your API.
Until a SOC peripheral is initialized by its associated Linux driver, the behaviour of a GPIO pin in dedicated mode will be undefined. The firmware/board code will probably want to set the pin as a GPIO output with a fixed value until the driver initializes the hardware.
> Another option would be to add some argument to the set_dedicated
> call, thus the software could specify arbitrary dedicated
> function (thus no need to save/restore anything). But this would
> be SOC-model specific, thus no driver can use this argument anyway.
Drivers that require dedicated mode are SOC-specific anyway.
> > If, for some
> > reason (driver not loaded, ...), no GPIO user shows up for that
> > pin, it will stay configured in dedicated mode.
>
> Yes.
>
> > It might be better to set the PAR bit unconditionally in
>
> Why it might be better?
Because, as explained a few lines down, the board initialization code will be able to configure a pin in a known state (PAR not set) at boot time until a driver requests the pin to be switched to dedicated mode.
> That way you may set up wrong _GPIO_
> mode, because you didn't set PAR bit (when PAR bit set
> DIR/ODR/DAT bits are losing their meanings).
>
> > qe_gpio_set_dedicated() instead of restoring its value. That way
> > the board initialization code could just set the DIR, DAT and ODR
> > bits for dedicated mode but still configure the pin in GPIO mode.
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH 1/3 v2] powerpc: make CMO paging space pool ID and page size available
From: Robert Jennings @ 2008-08-18 14:40 UTC (permalink / raw)
To: Paul Mackerras, linuxppc-dev list, Benjamin Herrenschmidt
In-Reply-To: <20080815190730.GB20629@austin.ibm.com>
During platform setup, save off the primary/secondary paging space pool IDs
and the page size. Added accessors in hvcall.h for these variables.
Signed-off-by: Robert Jennings <rcj@linux.vnet.ibm.com>
---
I wrote "Submitted-by" on the last patch for some strange reason, that't
the only thing changed here.
---
arch/powerpc/include/asm/hvcall.h | 21 +++++++++++++++++++++
arch/powerpc/platforms/pseries/setup.c | 28 ++++++++++++++++++++--------
2 files changed, 41 insertions(+), 8 deletions(-)
Index: b/arch/powerpc/include/asm/hvcall.h
===================================================================
--- a/arch/powerpc/include/asm/hvcall.h
+++ b/arch/powerpc/include/asm/hvcall.h
@@ -292,6 +292,27 @@ struct hvcall_mpp_data {
int h_get_mpp(struct hvcall_mpp_data *);
+#ifdef CONFIG_PPC_PSERIES
+extern int CMO_PrPSP;
+extern int CMO_SecPSP;
+extern unsigned long CMO_PageSize;
+
+static inline int cmo_get_primary_psp(void)
+{
+ return CMO_PrPSP;
+}
+
+static inline int cmo_get_secondary_psp(void)
+{
+ return CMO_SecPSP;
+}
+
+static inline unsigned long cmo_get_page_size(void)
+{
+ return CMO_PageSize;
+}
+#endif /* CONFIG_PPC_PSERIES */
+
#endif /* __ASSEMBLY__ */
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_HVCALL_H */
Index: b/arch/powerpc/platforms/pseries/setup.c
===================================================================
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -68,6 +68,9 @@
#include "plpar_wrappers.h"
#include "pseries.h"
+int CMO_PrPSP = -1;
+int CMO_SecPSP = -1;
+unsigned long CMO_PageSize = (ASM_CONST(1) << IOMMU_PAGE_SHIFT);
int fwnmi_active; /* TRUE if an FWNMI handler is present */
@@ -325,8 +328,7 @@ void pSeries_cmo_feature_init(void)
{
char *ptr, *key, *value, *end;
int call_status;
- int PrPSP = -1;
- int SecPSP = -1;
+ int page_order = IOMMU_PAGE_SHIFT;
pr_debug(" -> fw_cmo_feature_init()\n");
spin_lock(&rtas_data_buf_lock);
@@ -365,21 +367,31 @@ void pSeries_cmo_feature_init(void)
break;
}
- if (0 == strcmp(key, "PrPSP"))
- PrPSP = simple_strtol(value, NULL, 10);
+ if (0 == strcmp(key, "CMOPageSize"))
+ page_order = simple_strtol(value, NULL, 10);
+ else if (0 == strcmp(key, "PrPSP"))
+ CMO_PrPSP = simple_strtol(value, NULL, 10);
else if (0 == strcmp(key, "SecPSP"))
- SecPSP = simple_strtol(value, NULL, 10);
+ CMO_SecPSP = simple_strtol(value, NULL, 10);
value = key = ptr + 1;
}
ptr++;
}
- if (PrPSP != -1 || SecPSP != -1) {
+ /* Page size is returned as the power of 2 of the page size,
+ * convert to the page size in bytes before returning
+ */
+ CMO_PageSize = 1 << page_order;
+ pr_debug("CMO_PageSize = %lu\n", CMO_PageSize);
+
+ if (CMO_PrPSP != -1 || CMO_SecPSP != -1) {
pr_info("CMO enabled\n");
- pr_debug("CMO enabled, PrPSP=%d, SecPSP=%d\n", PrPSP, SecPSP);
+ pr_debug("CMO enabled, PrPSP=%d, SecPSP=%d\n", CMO_PrPSP,
+ CMO_SecPSP);
powerpc_firmware_features |= FW_FEATURE_CMO;
} else
- pr_debug("CMO not enabled, PrPSP=%d, SecPSP=%d\n", PrPSP, SecPSP);
+ pr_debug("CMO not enabled, PrPSP=%d, SecPSP=%d\n", CMO_PrPSP,
+ CMO_SecPSP);
spin_unlock(&rtas_data_buf_lock);
pr_debug(" <- fw_cmo_feature_init()\n");
}
----- End forwarded message -----
^ 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