Hi all,

    I met some serious problems when hacking linux on powerpc. Any
help would be appreciated. Please bear with the long description here
as I want to be as clear as possible.

    I am working on a Power6 running fedora 12, kernel version
2.6.32.23-170. The purpose is to test some ideas that fine tunes
thread scheduling.

    I added a new field "unsigned long my_priority" to the end of
thread_struct (arch/powerpc/include/asm/processor.h)

    I can access this field through my newly added system calls by
referring to current->thread.my_priority. Everything was fine, the
modified kernel boots, and I can set and read my_priority via system
calls. (I haven't changed the scheduling as of now).

    So I moved on and tried to to access my_priority in the assembly
syscall handler. It's in arch/powerpc/kernel/exception_64s.S

    Here is original codelet:

    . = 0xc00
     HMT_MEDIUM
     cmpdi   r0,0x1ebe
     beq-    1f
....

    Here is my first modification:

        . = 0xc00
        HMT_MEDIUM

        mfspr   r13, SPRN_SPRG_PACA // read paca of the current cpu
        ld      r10, PACACURRENT(r13)   // paca->__current
        li       r12, 18                              // just a test,
try to set priority to 18
        std    r12, (THREAD+336)(r13)    // paca->__current-

my_priority is 336 bytes further down)

        cmpdi   r0,0x1ebe
        beq-    1f
....

    My kernel will not boot with the four new instructions!

   Then I tried to identify what problem is, so I change the code to
the following:

        . = 0xc00
1.        HMT_MEDIUM

2.        cmpdi   r0, 324                             // okay, will
only touch it in syscall 324. This is a new sys call that I added to
the kernel
3.        bne not_sys_call_324

4.        mfspr   r13, SPRN_SPRG_PACA // read paca of the current cpu
5.        ld      r3, PACACURRENT(r13)   // r3 = paca->__current
6.        ld      r4, (THREAD+336)(r3)    // r3+THREAD is paca-

                                                    //  so I expect r4
= paca->__current->thead.my_priority,

not_sys_call_324:
        cmpdi   r0,0x1ebe
        beq-    1f
....

    This time, the system boots - since no one will do syscall 324 and
trigger my code.

    syscall 324, written in C,  just printk the two parameters (passed
via r3 and r4) as well as 'current', and does nothing else.

    Then I tested syscall 324 from a user program. to my surprise, /
var/log/messages shows that

    r3, when passed into the syscall handler, becomes "0x570daee0",
while current is "0xc0000001570daee0".

    the syscall also complained that  "ld      r4, (THREAD+336)(r3) "
caused a "Bad kernel stack pointer"

    Here are my questions:

    1. When the 64-bit __current is truncated to 32-bits when I load
it in line 5?   right when it's loaded, or is it possible that r3
still has 64 bits, but when passed into syscall 324, it is truncated?

     2. could this be the reason that my first mod failed to boot?

Many thanks in advance

Bo Hong