All of lore.kernel.org
 help / color / mirror / Atom feed
* [ALPHA][2.5.7x] Problems with execve assembly rewriting
@ 2003-06-26 19:40 Marc Zyngier
  2003-06-26 21:15 ` Richard Henderson
  2003-06-27 20:22 ` Willy Tarreau
  0 siblings, 2 replies; 4+ messages in thread
From: Marc Zyngier @ 2003-06-26 19:40 UTC (permalink / raw)
  To: rth; +Cc: linux-kernel

Richard,

A few releases ago, Alpha's implementation of execve was rewritten
entirely in assembly.  Since then, the Jensen is unable to boot
(crashes as soon as it reaches userland).

This is the latest BK :

<quote>
Unable to handle kernel paging request at virtual address 5345432039323a38
swapper(1): Oops 0
pc = [<fffffc0000496080>]  ra = [<fffffc0000499e60>]  ps = 0000    Not tainted
Using defaults from ksymoops -t elf64-alpha -a alpha
v0 = fffffc0003fbbdd8  t0 = 00000000616d2820  t1 = 0000000033372e35
t2 = 000000006920676e  t3 = 5345432039323a34  t4 = fffffc0003fbbec0
t5 = fffffc0003fbbec0  t6 = 0000000000000003  t7 = fffffc0003fb8000
s0 = ffffffffde11f2c7  s1 = 000000003f7f1ae7  s2 = ffffffffd1ca0615
s3 = fffffffff3b8134e  s4 = fffffc0000581b60  s5 = 0000000000000000
s6 = fffffc00005229e9
a0 = fffffc00005229e9  a1 = fffffffff3b8134e  a2 = 000000003f7f1ae7
a3 = 0000000000000000  a4 = 000000000001c200  a5 = 0000000000000000
t8 = 0000000000000000  t9 = fffffc0003fc3700  t10= 0000000000002800
t11= 0000000000002580  pv = fffffc0000495fe0  at = 0000000000000001
gp = fffffc00005ad198  sp = fffffc0003fbbad8
Trace:fffffc0000499e60 fffffc0000376468 fffffc00003776ec fffffc0000323b0c fffffc00003134fc fffffc0000348dd0 fffffc0000349124 fffffc00003490a0 fffffc0000318558 fffffc0000318790 fffffc0000442c50 fffffc0000443b68 fffffc000033200c fffffc000032cf38 fffffc0000318244 fffffc0000318ca8 fffffc0000319260 fffffc00003101e8 fffffc0000313448 
Code: 401f000e  e5400098  4189000c  b53e0048  a48f00d8  b7fe0040 <a0240004> e4200058 


>>RA;  fffffc0000499e60 <skb_checksum_help+50/120>

>>PC;  fffffc0000496080 <skb_checksum+a0/360>   <=====

Trace; fffffc0000499e60 <skb_checksum_help+50/120>
Trace; fffffc0000376468 <open_exec+28/150>
Trace; fffffc00003776ec <do_execve+3c/280>
Trace; fffffc0000323b0c <schedule+2cc/4f0>
Trace; fffffc00003134fc <execve+4c/80>
Trace; fffffc0000348dd0 <rmqueue_bulk+a0/d0>
Trace; fffffc0000349124 <buffered_rmqueue+184/1a0>
Trace; fffffc00003490a0 <buffered_rmqueue+100/1a0>
Trace; fffffc0000318558 <setup_irq+f8/120>
Trace; fffffc0000318790 <request_irq+c0/130>
Trace; fffffc0000442c50 <serial8250_interrupt+0/140>
Trace; fffffc0000443b68 <serial8250_set_termios+348/450>
Trace; fffffc000033200c <update_process_times+5c/80>
Trace; fffffc000032cf38 <do_softirq+138/150>
Trace; fffffc0000318244 <handle_IRQ_event+74/f0>
Trace; fffffc0000318ca8 <handle_irq+188/1d0>
Trace; fffffc0000319260 <do_entInt+c0/150>
Trace; fffffc00003101e8 <init+108/1b0>
Trace; fffffc0000313448 <kernel_thread+28/90>

Code;  fffffc0000496068 <skb_checksum+88/360>
0000000000000000 <_PC>:
Code;  fffffc0000496068 <skb_checksum+88/360>
   0:   0e 00 1f 40       addl v0,zero,s5
Code;  fffffc000049606c <skb_checksum+8c/360>
   4:   98 00 40 e5       beq  s1,268 <_PC+0x268>
Code;  fffffc0000496070 <skb_checksum+90/360>
   8:   0c 00 89 41       addl s3,s0,s3
Code;  fffffc0000496074 <skb_checksum+94/360>
   c:   48 00 3e b5       stq  s0,72(sp)
Code;  fffffc0000496078 <skb_checksum+98/360>
  10:   d8 00 8f a4       ldq  t3,216(fp)
Code;  fffffc000049607c <skb_checksum+9c/360>
  14:   40 00 fe b7       stq  zero,64(sp)
Code;  fffffc0000496080 <skb_checksum+a0/360>   <=====
  18:   04 00 24 a0       ldl  t0,4(t3)   <=====
Code;  fffffc0000496084 <skb_checksum+a4/360>
  1c:   58 00 20 e4       beq  t0,180 <_PC+0x180>
</quote>

The stack looks quite messy (what is skb_checksum doing here ?), but
execve caught my eyes... Excluding the whole execve rewriting
change-set let the system boot without any problem.

Let me know if I can do something to help debugging the thing.

Regards,

        M.
-- 
Places change, faces change. Life is so very strange.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [ALPHA][2.5.7x] Problems with execve assembly rewriting
  2003-06-26 19:40 [ALPHA][2.5.7x] Problems with execve assembly rewriting Marc Zyngier
@ 2003-06-26 21:15 ` Richard Henderson
  2003-06-27 20:22 ` Willy Tarreau
  1 sibling, 0 replies; 4+ messages in thread
From: Richard Henderson @ 2003-06-26 21:15 UTC (permalink / raw)
  To: Marc Zyngier; +Cc: linux-kernel

On Thu, Jun 26, 2003 at 09:40:57PM +0200, Marc Zyngier wrote:
> Let me know if I can do something to help debugging the thing.

Check gp for the binary and verify that it's wrong.

What binutils version are you using?


r~

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [ALPHA][2.5.7x] Problems with execve assembly rewriting
  2003-06-26 19:40 [ALPHA][2.5.7x] Problems with execve assembly rewriting Marc Zyngier
  2003-06-26 21:15 ` Richard Henderson
@ 2003-06-27 20:22 ` Willy Tarreau
  2003-06-27 22:42   ` Marc Zyngier
  1 sibling, 1 reply; 4+ messages in thread
From: Willy Tarreau @ 2003-06-27 20:22 UTC (permalink / raw)
  To: Marc Zyngier; +Cc: rth, linux-kernel

Hi !

On Thu, Jun 26, 2003 at 09:40:57PM +0200, Marc Zyngier wrote:
> Unable to handle kernel paging request at virtual address 5345432039323a38

This address is really messy since it's purely ASCII : "SEC 92:8"

> t0 = 00000000616d2820  t1 = 0000000033372e35
ASCII here : "am( " and here "37.5"

> t2 = 000000006920676e  t3 = 5345432039323a34
and here : "i gn" and here too "SEC 92:4"

So it may result from some garbage being used as a pointer, or a char * being
jumped to.

Just my .02 euros,
Willy


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [ALPHA][2.5.7x] Problems with execve assembly rewriting
  2003-06-27 20:22 ` Willy Tarreau
@ 2003-06-27 22:42   ` Marc Zyngier
  0 siblings, 0 replies; 4+ messages in thread
From: Marc Zyngier @ 2003-06-27 22:42 UTC (permalink / raw)
  To: Willy Tarreau; +Cc: rth, linux-kernel

>>>>> "Willy" == Willy Tarreau <willy@w.ods.org> writes:

Willy> So it may result from some garbage being used as a pointer, or
Willy> a char * being jumped to.

Well, problem was in fact a broken binutils package. Upgrading to
2.13.90.0.18 let the system boot fine, while 2.13.90.0.10 leads to
this strange crash...

     M.
-- 
Places change, faces change. Life is so very strange.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2003-06-27 22:29 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-06-26 19:40 [ALPHA][2.5.7x] Problems with execve assembly rewriting Marc Zyngier
2003-06-26 21:15 ` Richard Henderson
2003-06-27 20:22 ` Willy Tarreau
2003-06-27 22:42   ` Marc Zyngier

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.