Re: [parisc-linux] c3k panics

Re: [parisc-linux] c3k panics

[Joel Soete]

Hello Randolph,

>
> > #ifndef CONFIG_64BIT
> >         .macro fixup_branch,lbl
> >         b           \lbl
> >         .endm
> > #else
> >         .macro fixup_branch,lbl
> >         ldil        L%\lbl, %r1
> >         ldo         R%\lbl(%r1), %r1
> >         bv,n        %r0(%r1)
> >         .endm
> > #endif
>
> These two do the same thing. The 32-bit version is simpler because we
> can rely on the linker to do fixups for us if the branch is too far
> away. The 64-bit version always uses a long branch sequence to avoid
> stub issues with the 64-bit toolchain. In the C code I have simply not
> done this (micro-)optimization.
>
Ok clear but still confused why 32bit branch doesn't nullify the insn
in delay slot like did 64bit?

btw one more thing confusing me: the third fixup_branch macro definition
in lusercopy.S:
[snip]
         .macro fixup_branch,lbl
         ldil        L%\lbl, %r1
         ldo         R%\lbl(%r1), %r1
         bv          %r0(%r1)
         .endm

This time just bv not bv,n ?
I presume that's needed because here that's user space but couldn't we ha=
ve
2 macro name (e.g a k_fixup_br, us_fixup_br)  to avoid this confusion?

Thanks again,
    Joel


_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] c3k panics

[Randolph Chung]

> Ok clear but still confused why 32bit branch doesn't nullify the insn
> in delay slot like did 64bit?

it's a bug, but fortunately that copy of the fixup_branch macro (in
syscall.S) isn't actually used ;-) I'll remove it.

> btw one more thing confusing me: the third fixup_branch macro definition
> in lusercopy.S:
> [snip]
>          .macro fixup_branch,lbl
>          ldil        L%\lbl, %r1
>          ldo         R%\lbl(%r1), %r1
>          bv          %r0(%r1)
>          .endm
> 
> This time just bv not bv,n ?

Yes, if you look at where the macro is used you will see that there is
an instruction in the delay slot for the branch that should be executed.

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] c3k panics

[Joel Soete]

> 
> 
> > Ok clear but still confused why 32bit branch doesn't nullify the insn=

> > in delay slot like did 64bit?
> 
> it's a bug, but fortunately that copy of the fixup_branch macro (in
> syscall.S) isn't actually used ;-) I'll remove it.
> 
mmm, it seems that I am ongoing to become blind (to miss that ?)
ah no this the night (no idea where stand this dmaned bug) but I was just=

blind by a pocket torch thinking it would be a star :_(
 
> > btw one more thing confusing me: the third fixup_branch macro definit=
ion
> > in lusercopy.S:
> > [snip]
> >          .macro fixup_branch,lbl
> >          ldil        L%\lbl, %r1
> >          ldo         R%\lbl(%r1), %r1
> >          bv          %r0(%r1)
> >          .endm
> > 
> > This time just bv not bv,n ?
> 
> Yes, if you look at where the macro is used you will see that there is
> an instruction in the delay slot for the branch that should be executed=
.
> 
Cool :-)

Thanks,
    Joel


_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] c3k panics

[John David Anglin]

> > > Ok clear but still confused why 32bit branch doesn't nullify the insn
> > > in delay slot like did 64bit?
> > 
> > it's a bug, but fortunately that copy of the fixup_branch macro (in
> > syscall.S) isn't actually used ;-) I'll remove it.
> > 
> mmm, it seems that I am ongoing to become blind (to miss that ?)
> ah no this the night (no idea where stand this dmaned bug) but I was just
> blind by a pocket torch thinking it would be a star :_(

I believe that there's likely more than one bug.  After working around
the memory management bug, I tried a number of gcc builds.  Two crashes
occurred as previously reported.  I also had a third crash.  In this
one, the TOC IIA Offset value pointed into "userspace".  These all
occurred with only a few hours of running time.

I then switched from vmlinux-2.6.11-pa4-c3000_defconfig to
vmlinux-2.6.8.1-pa11-c3000_defconfig.  This kernel seems ok.  It's
survived one binutils and three full gcc builds.  However, there are
seven fails in the libstdc++ testsuite that don't occur with 2.6.11.
On the otherhand, I'm seeing a few Java processes not terminate with
2.6.11-pa4.  This problem doesn't seem to be present in 2.6.8.1-pa11
and Grant's 64-bit version of 2.6.11-pa4 on gsyprf11.

I'm going to try a few more kernels to see if it's possible to isolate
the change that introduced the problem.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Some other cleanup [Was: [parisc-linux] c3k panics]

[Joel Soete]

Hello Randolph,


Randolph Chung wrote:
>>Ok clear but still confused why 32bit branch doesn't nullify the insn
>>in delay slot like did 64bit?
> 
> 
> it's a bug, but fortunately that copy of the fixup_branch macro (in
> syscall.S) isn't actually used ;-) I'll remove it.
> 
> 
Just in the hope of help here are some cleanup:
	o at a place there was 2 enbraced #ifdef CONFIG_PA20,
	o in #else /* !CONFIG_PA20 */ ... #endif , afaik there are few chance that __LP64__ (aka CONFIG_64BIT)?
	o the (micro)-optimization we spoke previoulsy
	o here above syscall.S
--- arch/parisc/kernel/unaligned.c.Orig	2005-06-05 19:18:19.000000000 +0200
+++ arch/parisc/kernel/unaligned.c	2005-06-05 20:17:47.000000000 +0200
@@ -39,10 +39,15 @@
  #define RFMT "%08lx"
  #endif

+#ifndef	CONFIG_64BIT
+#define FIXUP_BRANCH(lbl) \
+	"\tb,n " #lbl "\n"
+#else
  #define FIXUP_BRANCH(lbl) \
  	"\tldil L%%" #lbl ", %%r1\n"			\
  	"\tldo R%%" #lbl "(%%r1), %%r1\n"		\
  	"\tbv,n %%r0(%%r1)\n"
+#endif

  /* 1111 1100 0000 0000 0001 0011 1100 0000 */
  #define OPCODE1(a,b,c)	((a)<<26|(b)<<12|(c)<<6)
@@ -213,6 +218,7 @@

  	return ret;
  }
+
  static int emulate_ldd(struct pt_regs *regs, int toreg, int flop)
  {
  	unsigned long saddr = regs->ior;
@@ -254,7 +260,7 @@
  	: "=r" (val), "=r" (ret)
  	: "0" (val), "r" (saddr), "r" (regs->isr)
  	: "r19", "r20" );
-#else
+#else	/* !CONFIG_PA20 */
      {
  	unsigned long valh=0,vall=0;
  	__asm__ __volatile__  (
@@ -275,22 +281,16 @@
  	FIXUP_BRANCH(4b)
  "	.previous\n"
  "	.section __ex_table,\"aw\"\n"
-#ifdef __LP64__
-"	.dword	1b,5b\n"
-"	.dword  2b,5b\n"
-"	.dword	3b,5b\n"
-#else
  "	.word	1b,5b\n"
  "	.word	2b,5b\n"
  "	.word	3b,5b\n"
-#endif
  "	.previous\n"
  	: "=r" (valh), "=r" (vall), "=r" (ret)
  	: "0" (valh), "1" (vall), "r" (saddr), "r" (regs->isr)
  	: "r19", "r20" );
  	val=((__u64)valh<<32)|(__u64)vall;
      }
-#endif
+#endif	/* !CONFIG_PA20 */

  	DPRINTF("val = 0x%llx\n", val);

@@ -393,6 +393,7 @@

  	return 0;
  }
+
  static int emulate_std(struct pt_regs *regs, int frreg, int flop)
  {
  	__u64 val;
@@ -451,7 +452,7 @@
  	: "=r" (ret)
  	: "r" (val), "r" (regs->ior), "r" (regs->isr)
  	: "r19", "r20", "r21", "r22", "r1" );
-#else
+#else	/* !CONFIG_PA20 */
      {
  	unsigned long valh=(val>>32),vall=(val&0xffffffffl);
  	__asm__ __volatile__ (
@@ -479,25 +480,17 @@
  	FIXUP_BRANCH(6b)
  "	.previous\n"
  "	.section __ex_table,\"aw\"\n"
-#ifdef __LP64__
-"	.dword	1b,7b\n"
-"	.dword  2b,7b\n"
-"	.dword	3b,7b\n"
-"	.dword  4b,7b\n"
-"	.dword  5b,7b\n"
-#else
  "	.word	1b,7b\n"
  "	.word	2b,7b\n"
  "	.word	3b,7b\n"
  "	.word	4b,7b\n"
  "	.word  	5b,7b\n"
-#endif
  "	.previous\n"
  	: "=r" (ret)
  	: "r" (valh), "r" (vall), "r" (regs->ior), "r" (regs->isr)
  	: "r19", "r20", "r21", "r1" );
      }
-#endif
+#endif	/* !CONFIG_PA20 */

  	return ret;
  }
@@ -683,14 +676,12 @@
  		ret = emulate_std(regs, R2(regs->iir),1);
  		break;

-#ifdef CONFIG_PA20
  	case OPCODE_LDD_L:
  		ret = emulate_ldd(regs, R2(regs->iir),0);
  		break;
  	case OPCODE_STD_L:
  		ret = emulate_std(regs, R2(regs->iir),0);
  		break;
-#endif
  	}
  #endif
  	switch (regs->iir & OPCODE3_MASK)
@@ -774,8 +765,7 @@
   * now, so we only check for PA1.1 encodings at this point.
   */

-int
-check_unaligned(struct pt_regs *regs)
+int check_unaligned(struct pt_regs *regs)
  {
  	unsigned long align_mask;

--- arch/parisc/kernel/syscall.S.Orig	2005-06-05 19:52:36.000000000 +0200
+++ arch/parisc/kernel/syscall.S	2005-06-05 19:57:15.000000000 +0200
@@ -23,23 +23,7 @@
  	 */
  #define KILL_INSN	break	0,0

-#ifdef CONFIG_64BIT
-	.level          2.0w
-#else
-	.level		1.1
-#endif
-
-#ifndef CONFIG_64BIT
-	.macro fixup_branch,lbl
-	b	    \lbl
-	.endm
-#else
-	.macro fixup_branch,lbl
-	ldil	    L%\lbl, %r1
-	ldo	    R%\lbl(%r1), %r1
-	bv,n        %r0(%r1)
-	.endm
-#endif
+	.level		LEVEL

  	.text

--- arch/parisc/lib/lusercopy.S.Orig	2005-06-05 19:36:55.000000000 +0200
+++ arch/parisc/lib/lusercopy.S	2005-06-05 20:02:51.000000000 +0200
@@ -54,9 +54,13 @@
  	.endm

  	.macro fixup_branch lbl
-	ldil	    L%\lbl, %r1
-	ldo	    R%\lbl(%r1), %r1
-	bv          %r0(%r1)
+#ifndef CONFIG_64BIT
+	b		\lbl
+#else
+	ldil		L%\lbl, %r1
+	ldo		R%\lbl(%r1), %r1
+	bv		%r0(%r1)
+#endif
  	.endm

  	/*
====<>====

Thanks,
	Joel
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux