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
// test, try to set priority to 18
std r12, (THREAD+336)(r10)
// __current->theread.my_priority
// r10 is __current
// thread is THREAD down
// my_priority is 336 bytes further down
cmpdi r0,0x1ebe
beq- 1f
....
This first mod 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
3. bne not_sys_call_324
// okay, will only touch my_prioity in syscall 324.
// This is a new sys call that I added
4. mfspr r13, SPRN_SPRG_PACA
// r13 = paca
5. ld r3, PACACURRENT(r13)
// r3 = paca->__current
6. ld r4, (THREAD+336)(r3)
// r3 is __current
// thread is THREAD down from __current
// my_priority is 336 bytes further down,
// 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?
(that I was trying to modify a wrong memory address)
3. Is there a kernel debugger for powerpc linux?
I also posted to comp.os.linux.powerpc, but that group seems to
be relatively quieter recently, so I am posting it here.:0
Many thanks in advance
Bo Hong
--
You received this message because you are subscribed to the Linux Users Group.
To post a message, send email to [email protected]
To unsubscribe, send email to [email protected]
For more options, visit our group at
http://groups.google.com/group/linuxusersgroup
