Re: Help from Kernel Gurus needed!!!

Re: Help from Kernel Gurus needed!!!

[Kevin B. Hendricks]

Hi,

Nothing like answering your own question.  I never saw my post make it back
to me, but if anyone runs into the same problem here is my solution.  I
figured this out from looking at the stack inside a signal handler with gdb
so I may be wrong but this seems to work:

>From inside a signal handler, to check on old signal masks or register
contents right before the signal was delivered:


#include <asm/sigcontext.h>

    /* get the value of r1 (the stack pointer) */
    long * p;
    struct sigcontext_struct * scp;
    __asm__ ( "addi %0,1,0" : "=r" (p) : /* no inputs */ );
    /* follow it back up the chain */
    p = *p;
    /* from here the sigcontext struct is 64 bytes away */
    p = p + 16;
    scp = (struct sigcontext_struct *)p;

I hope this helps.  If it looks wrong to anyone out there please let me
know ASAP.

Thanks,

Kevin


----------------------------------------------------------
Kevin B. Hendricks
Associate Professor, Operations & Information Technology
School of Business, College of William & Mary
Williamsburg, VA 23187, kbhend@dogwood.tyler.wm.edu
http://business.tyler.wm.edu



[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Help from Kernel Gurus needed!!!

[David Edelsohn]

	If you are just trying to copy r1 into r0, why not use move
regsiter instead of add immediate as the following:

	__asm__ ("mr %0,1" : "=r" (p) : );

David

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Help from Kernel Gurus needed!!!

[Geert Uytterhoeven]

On Mon, 25 Jan 1999, David Edelsohn wrote:
> 	If you are just trying to copy r1 into r0, why not use move
> regsiter instead of add immediate as the following:
> 
> 	__asm__ ("mr %0,1" : "=r" (p) : );

Hehe, the clue is that IBM/Motorola didn't implement instructions that perform
operations that can be done in a different manner, too.

`mr' is just an alias for add with zero.

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Help from Kernel Gurus needed!!!

[David Edelsohn]

>>>>> Geert Uytterhoeven writes:

Geert> Hehe, the clue is that IBM/Motorola didn't implement instructions that perform
Geert> operations that can be done in a different manner, too.

Geert> `mr' is just an alias for add with zero.

	The point is that the extended mnemonic document the intent and
purpose of the operation.  This is for documentation, not correctness or
efficiency. 

David

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Help from Kernel Gurus needed!!!

[Gabriel Paubert]

On Mon, 25 Jan 1999, Geert Uytterhoeven wrote:

> 
> On Mon, 25 Jan 1999, David Edelsohn wrote:
> > 	If you are just trying to copy r1 into r0, why not use move
> > regsiter instead of add immediate as the following:
> > 
> > 	__asm__ ("mr %0,1" : "=r" (p) : );
> 
> Hehe, the clue is that IBM/Motorola didn't implement instructions that perform
> operations that can be done in a different manner, too.
> 
> `mr' is just an alias for add with zero.

No, mr %0,%1 is an alias for ori %0,%1,0 because addi does not work when
the source register is r0. OTOH, li and lis are aliases for addi and addis
with r0 as second operand, it is clearer in the POWER mnemonics where they
are called cal and cau for compute address {lower,upper} which directly 
shows that they use the same convention as the addressing mode noted 
as (rA|0) in the documentation.

	Greetings,
	Gabriel.


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Help - Kernel Panic - 2.2.0-final

[Bryan Christianson]

I am getting the the following panic in linuxppc-R4, with kernel 2.2.0-final.

The panic occurs when I use insmod (version 2.1.121) to load a driver that
I am working on. The statement in the module where it faults is

result = inl(base + offset)

where result is a u32 and base and offset have the values shown in the
following trace.

If there is someone that can shed any light on whats going on here I would
be really grateful. The installation is generic R4 apart from the upgrade
to the kernel and a more recent version modutils. The distributed modutils
was unable to resolve symbols and didn't even begin to load the driver.

Jan 24 20:04:57 linuxppc kernel: telsat: read_port: base = 0x00000400,
offset = 60
Jan 24 20:04:57 linuxppc kernel: Machine check in kernel mode.
Jan 24 20:04:57 linuxppc kernel: Caused by (from msr): regs c2a25ae0
Unknown values in msr
Jan 24 20:04:57 linuxppc kernel: NIP: C886117C XER: 00000000 LR: C8861168
REGS: c2a25ae0 TRAP: 0200
Jan 24 20:04:57 linuxppc kernel: MSR: 00009030 EE: 1 PR: 0 FP: 0 ME: 1
IR/DR: 11
Jan 24 20:04:57 linuxppc kernel: TASK = c2a24000[991] 'insmod' mm->pgd
c2ae3000 Last syscall: 128
Jan 24 20:04:57 linuxppc kernel: last math 00000000
Jan 24 20:04:57 linuxppc kernel: GPR00: FE00043C C2A25BD0 C2A24000 00000035
00000001 C01990E8 C01A0000 C00D109C
Jan 24 20:04:57 linuxppc kernel: GPR08: 00000000 FE000000 00000000 C2A25B00
C2A25B00 01851C0C 01850000 01850000
Jan 24 20:04:57 linuxppc kernel: GPR16: 01850000 01850000 00000001 01850000
00009032 02A25E80 00000000 C0003A8C
Jan 24 20:04:57 linuxppc kernel: GPR24: C0003844 00000000 00000070 00000000
0000003C FFFFFFFF C88758F8 00000040
Jan 24 20:04:57 linuxppc kernel: Call backtrace:
Jan 24 20:04:57 linuxppc kernel: C8861168 C8863404 C8863518 C88637B4
C886384C C00815B8 C00E3720
Jan 24 20:04:57 linuxppc kernel: C8863964 C0016920 C0003898 01850000
01803AA0 01804208 01800F9C
Jan 24 20:04:57 linuxppc kernel: 01800E78
Jan 24 20:04:57 linuxppc kernel: Instruction DUMP: 8129e054  7c1d4a14
7fa0042c <7c0006ac> 3c60c886  38633b78  7fa4eb78  4cc63182  480148a1
Jan 24 20:04:57 linuxppc kernel: Kernel panic: machine check

--
Bryan Christianson
email:		<mailto:bryanc@ihug.co.nz>
Home Page:	<http://crash.ihug.co.nz/~bryanc>


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Help from Kernel Gurus needed!!!

[Kevin B. Hendricks]

Hi,

I could really use some help from you kernel gurus out there.  In Sun's JDK
1.2 green_threads implementation, their signal handlers are passed a
pointer to a  context structure that allows them to see what the signal
mask was immediately before the signal was delivered.

We need to do the same thing in the ppc port.  So in a signal handler I
would like some way of knowing the address of the sigcontext structure
where the old mask is stored.

I have looked in arch/ppc/kernel/signal.c and I can find the place where
the structure is built, I just can't figure out a way to find it easily on
the stack.

This same info is easy to find on x86 since it is on the stack right before
the value of sig (the signal number) which is passed on the stack.

Any ideas here?  I could do a sigsetjmp to easily get the values of r1 and
lr if either of those can be used to find the location of the sigcontext
structure on the stack by working backwards.

Any help of ideas here would be greatly appreciated.

Thanks,

Kevin

----------------------------------------------------------
Kevin B. Hendricks
Associate Professor, Operations & Information Technology
School of Business, College of William & Mary
Williamsburg, VA 23187, kbhend@dogwood.tyler.wm.edu
http://business.tyler.wm.edu


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]