Re: [parisc-linux] head.S: a small typo

Re: [parisc-linux] head.S: a small typo

[Joel Soete]

Hello Dave,

> 
> >         nop             /* 8 */
> > -#endif
> 
> The arch document (page F-4) says that you only need 7 instructions
> between ssm and rsm.
> 
Yes for the following bacth (this time with 64bits included on b2k only n=
ot
yet for d380 sorry next step)

That said it works also (32 bit up and smp, 64bit up)
the same if I replace .align 256 by 128 no pb
(btw I disasemble the resulting kernel text and this code seems to be onl=
y
called once and very early)

btw I don't more understand why the following ifdef (in the same head.S):=

#ifdef __LP64__ /* move to psw.h? */   
#define         PSW_BITS        PSW_Q+PSW_I+PSW_D+PSW_P+PSW_R
#else
#define         PSW_BITS        PSW_SM_Q
#endif

Oth I still have thousand of detailed questions but started to the main o=
ne:
your concern in a previous mail;
if I well understand it's located in 2 places in pacache.S and one would
be in:
[snip]
        .align  128

        .export disable_sr_hashing_asm,code

disable_sr_hashing_asm:
        .proc
        .callinfo NO_CALLS
        .entry

        /* Switch to real mode */

        ssm             0, %r0                  /* relied upon translatio=
n!
*/
        nop
        nop
        nop
        nop
        nop
        nop
        nop

        rsm             (PSW_SM_Q|PSW_SM_I), %r0 /* disable Q&I to load t=
he
iia queue */
        ldil            L%REAL_MODE_PSW, %r1
        ldo             R%REAL_MODE_PSW(%r1), %r1
        mtctl           %r1, %cr22
        mtctl           %r0, %cr17              /* Clear IIASQ tail */
        mtctl           %r0, %cr17              /* Clear IIASQ head */
        ldil            L%PA(1f), %r1
        ldo             R%PA(1f)(%r1), %r1
        mtctl           %r1, %cr18              /* IIAOQ head */
        rfi
        nop

1:      cmpib,=3D,n       SRHASH_PCXST, %r26,srdis_pcxs
        cmpib,=3D,n       SRHASH_PCXL, %r26,srdis_pcxl
        cmpib,=3D,n       SRHASH_PA20, %r26,srdis_pa20
        b,n             srdis_done
[snip]
srdis_done:

        /* Switch back to virtual mode */

        rsm             PSW_SM_Q, %r0           /* clear Q bit to load ii=
a
queue */
        ldil            L%KERNEL_PSW, %r1
        ldo             R%KERNEL_PSW(%r1), %r1
        mtctl           %r1, %cr22
        mtctl           %r0, %cr17              /* Clear IIASQ tail */
        mtctl           %r0, %cr17              /* Clear IIASQ head */
        ldil            L%(2f), %r1
        ldo             R%(2f)(%r1), %r1
        mtctl           %r1, %cr18              /* IIAOQ head */
        ldo             4(%r1), %r1
        mtctl           %r1, %cr18              /* IIAOQ tail */
        rfi
        nop

2:      bv              %r0(%r2)
        nop
        .exit
[snip]

Always if I well understand this last srdis_done would looks like:
srdis_done:


        /* Switch back to virtual mode */

        ssm             0, %r0                  /* relied upon translatio=
n!
*/
        nop
        nop
        nop
        nop
        nop
        nop
        nop

        rsm             PSW_SM_Q, %r0           /* clear Q bit to load ii=
a
queue */
        ldil            L%KERNEL_PSW, %r1
        ldo             R%KERNEL_PSW(%r1), %r1
        mtctl           %r1, %cr22
        mtctl           %r0, %cr17              /* Clear IIASQ tail */
        mtctl           %r0, %cr17              /* Clear IIASQ head */
[snip]

Thanks in advance,
    Joel


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

Re: [parisc-linux] head.S: a small typo

[John David Anglin]

> btw I don't more understand why the following ifdef (in the same head.S):
> #ifdef __LP64__ /* move to psw.h? */   
> #define         PSW_BITS        PSW_Q+PSW_I+PSW_D+PSW_P+PSW_R
> #else
> #define         PSW_BITS        PSW_SM_Q
> #endif

I also don't understand the difference between the 32 and 64 bit cases.
There's probably a reason to turn off I, D, P and R in these sequences.
For example, a flush instruction cache instruction with the D bit set
affects the relied upon translation.  So, the question would be why the
bits are not turned off in the 32-bit case.  It may be because the PDCs
differ in their handling of these bits.  I'm pretty sure that the 64-bit
define would work in the 32-bit case.  The bits are only off through to
the rfi which then sets new bits.

The bits for the 64-bit case probably should be written using the "PSW_SM"
defines.  There's no difference for the Q, I, D, P and R bits but the SM
defines are for the "sm" instructions.

>         b,n             srdis_done
> [snip]

I believe that you should align srdis_done as follows:

	.align 128

You would then need to add a branch and nop to get there.

> srdis_done:
> 
> 
>         /* Switch back to virtual mode */
> 
>         ssm             0, %r0                  /* relied upon translation!
> */
>         nop
>         nop
>         nop
>         nop
>         nop
>         nop
>         nop
> 
>         rsm             PSW_SM_Q, %r0           /* clear Q bit to load iia
> queue */
>         ldil            L%KERNEL_PSW, %r1
>         ldo             R%KERNEL_PSW(%r1), %r1
>         mtctl           %r1, %cr22
>         mtctl           %r0, %cr17              /* Clear IIASQ tail */
>         mtctl           %r0, %cr17              /* Clear IIASQ head */
> [snip]
> 
> Thanks in advance,
>     Joel
> 
> 
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
> 


-- 
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

Re: [parisc-linux] head.S: a small typo

[Joel Soete]

Hello Dave, Grant,

John David Anglin wrote:
>>btw I don't more understand why the following ifdef (in the same head.S):
>>#ifdef __LP64__ /* move to psw.h? */   
>>#define         PSW_BITS        PSW_Q+PSW_I+PSW_D+PSW_P+PSW_R
>>#else
>>#define         PSW_BITS        PSW_SM_Q
>>#endif
> 
> 
> I also don't understand the difference between the 32 and 64 bit cases.
> There's probably a reason to turn off I, D, P and R in these sequences.
> For example, a flush instruction cache instruction with the D bit set
> affects the relied upon translation.  So, the question would be why the
> bits are not turned off in the 32-bit case.  It may be because the PDCs
> differ in their handling of these bits.  I'm pretty sure that the 64-bit
> define would work in the 32-bit case.  The bits are only off through to
> the rfi which then sets new bits.
> 
> The bits for the 64-bit case probably should be written using the "PSW_SM"
> defines.  There's no difference for the Q, I, D, P and R bits but the SM
> defines are for the "sm" instructions.
> 
Yes, as mentioned elsewhere (ssm/rsm ggg's patch) it works on all of my config (b180, d380 32bit smp)

> 
>>        b,n             srdis_done
>>[snip]
> 
> 
> I believe that you should align srdis_done as follows:
> 
> 	.align 128
> 
mmm is there importance in the order of:
	.align 128
	.text
rfi_virt2real:

later this is the contrary:
	.text
	.align 128
rfi_real2virt:

(from real2.S :-) )

> You would then need to add a branch and nop to get there.
> 
But I mainly come back here with the fact that 64bit kernel works fine while
its 32 bit twin panicing on same hw (b2k e.g.):
(to test ggg patch I run again my stress loop during about 20h on b2k with
the 64bit kernel without any pb ;-)

as far as I remember cffc() is only 32bit stuff so this patch would make
sense imho:
--- arch/parisc/kernel/parisc_ksyms.c.Orig      2005-04-28 14:39:07.000000000 +0200
+++ arch/parisc/kernel/parisc_ksyms.c   2005-04-28 14:18:23.000000000 +0200
@@ -160,8 +160,10 @@
  EXPORT_SYMBOL(__lshrdi3);
  EXPORT_SYMBOL(__muldi3);

+#ifndef CONFIG_64BIT
  asmlinkage void * __canonicalize_funcptr_for_compare(void *);
  EXPORT_SYMBOL(__canonicalize_funcptr_for_compare);
+#endif /* CONFIG_64BIT */

  #ifdef __LP64__
  extern void __divdi3(void);
--- arch/parisc/kernel/real2.S.Orig     2005-04-28 14:39:29.000000000 +0200
+++ arch/parisc/kernel/real2.S  2005-04-28 14:20:31.000000000 +0200
@@ -288,7 +272,7 @@
         bv,n    0(%rp)
         nop

-
+#ifndef CONFIG_64BIT
         .export __canonicalize_funcptr_for_compare
         .text
         /* http://lists.parisc-linux.org/hypermail/parisc-linux/10916.html
@@ -296,9 +280,6 @@
         **      comparing function pointers.
         */
  __canonicalize_funcptr_for_compare:
-#ifdef __LP64__
-       bve (%r2)
-#else
         bv %r0(%r2)
-#endif
         copy %r26,%r28
+#endif /* CONFIG_64BIT */
====<>====
(compile fine)

mmm, could it be the diff I was looking for between 32 and 64bit ?

For the moment, it is the most important diff that could explain me those
so different behaviour?

well iirc this last hunk is not more than:

typedef int (*fptr_t) (void);
unsigned int
__canonicalize_funcptr_for_compare (fptr)
      fptr_t fptr;
{
     return (unsigned int) fptr;
}

this form could help me to add some printk() to check the fptr containt?
(or may be a WARN_ON() to collect stack tree?)

But that would just give me addresses; how would I be able to check if a fcnt_ptr comparison is erronious?

Another thought: could it be some kind of border effect due to an additonal branch in 32bit (not present in 64bit)?

# grep canoni vmlinux-2.6.12-rc3-pa1-050425.dmp
10111b8c <__canonicalize_funcptr_for_compare>:
101265e8: e8 55 0b 3d  b,l 10111b8c <__canonicalize_funcptr_for_compare>,rp
101265f8: e8 55 0b 1d  b,l 10111b8c <__canonicalize_funcptr_for_compare>,rp
101327f8: e8 4f 07 1d  b,l 10111b8c <__canonicalize_funcptr_for_compare>,rp
10132804: e8 4f 07 05  b,l 10111b8c <__canonicalize_funcptr_for_compare>,rp
10132e80: e8 4f 1a 09  b,l 10111b8c <__canonicalize_funcptr_for_compare>,rp
10132e8c: e8 4f 19 f1  b,l 10111b8c <__canonicalize_funcptr_for_compare>,rp
10133308: e8 4f 10 f9  b,l 10111b8c <__canonicalize_funcptr_for_compare>,rp
10133314: e8 4f 10 e1  b,l 10111b8c <__canonicalize_funcptr_for_compare>,rp
1013335c: e8 4f 10 51  b,l 10111b8c <__canonicalize_funcptr_for_compare>,rp
10133368: e8 4f 10 39  b,l 10111b8c <__canonicalize_funcptr_for_compare>,rp
101340d4: e8 4e 15 65  b,l 10111b8c <__canonicalize_funcptr_for_compare>,rp
101340e0: e8 4e 15 4d  b,l 10111b8c <__canonicalize_funcptr_for_compare>,rp
10134100: e8 4e 15 0d  b,l 10111b8c <__canonicalize_funcptr_for_compare>,rp
1013410c: e8 4e 14 f5  b,l 10111b8c <__canonicalize_funcptr_for_compare>,rp
10134268: e8 4e 12 3d  b,l 10111b8c <__canonicalize_funcptr_for_compare>,rp
10134274: e8 4e 12 25  b,l 10111b8c <__canonicalize_funcptr_for_compare>,rp
1013487c: e8 4e 06 15  b,l 10111b8c <__canonicalize_funcptr_for_compare>,rp
10134888: e8 4e 05 fd  b,l 10111b8c <__canonicalize_funcptr_for_compare>,rp
1013583c: e8 4e 06 91  b,l 10111b8c <__canonicalize_funcptr_for_compare>,rp
10135848: e8 4e 06 79  b,l 10111b8c <__canonicalize_funcptr_for_compare>,rp
1013d7f8: e8 4a 07 19  b,l 10111b8c <__canonicalize_funcptr_for_compare>,rp
1013d804: e8 4a 07 01  b,l 10111b8c <__canonicalize_funcptr_for_compare>,rp
1013dab4: e8 4a 01 a1  b,l 10111b8c <__canonicalize_funcptr_for_compare>,rp
1013dac0: e8 4a 01 89  b,l 10111b8c <__canonicalize_funcptr_for_compare>,rp
103bd7b0 <__ksymtab___canonicalize_funcptr_for_compare>:
103c1f24 <__kstrtab___canonicalize_funcptr_for_compare>:

yet another thought: is there any mean to inline this, to check this other hypothesis?

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] head.S: a small typo

[John David Anglin]

> mmm is there importance in the order of:
> 	.align 128
> 	.text
> rfi_virt2real:

Yes, put the .align after the .text.  You want to align the following
text.

> But I mainly come back here with the fact that 64bit kernel works fine while
> its 32 bit twin panicing on same hw (b2k e.g.):
> (to test ggg patch I run again my stress loop during about 20h on b2k with
> the 64bit kernel without any pb ;-)
> 
> as far as I remember cffc() is only 32bit stuff so this patch would make

Yes.  You don't need it in 64-bit code.  Regarding cffc, GCC 4.0
has a fix as to when canonicalization is done.  In 4.0 and later,
canonicalization is only done when both sides of are function
pointers.

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

Re: [parisc-linux] head.S: a small typo

[Joel Soete]

> -- Original Message --
> To: soete.joel@tiscali.be (Joel Soete)
> Date: Thu, 28 Apr 2005 13:52:11 -0400 (EDT)
> From: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
> Cc: grundler@parisc-linux.org, parisc-linux@lists.parisc-linux.org
> Subject: Re: [parisc-linux] head.S: a small typo
> 
> 
> > mmm is there importance in the order of:
> > 	.align 128
> > 	.text
> > rfi_virt2real:
> 
> Yes, put the .align after the .text.  You want to align the following
> text.
> 
ah my memory is not so bad ;-) (thanks)

> > But I mainly come back here with the fact that 64bit kernel works fin=
e
> while
> > its 32 bit twin panicing on same hw (b2k e.g.):
> > (to test ggg patch I run again my stress loop during about 20h on b2k=

with
> > the 64bit kernel without any pb ;-)
> > 
> > as far as I remember cffc() is only 32bit stuff so this patch would m=
ake
> 
> Yes.  You don't need it in 64-bit code.  Regarding cffc, GCC 4.0
> has a fix as to when canonicalization is done.  In 4.0 and later,
> canonicalization is only done when both sides of are function
> pointers.
> 
Cool, I will so either try to learn more on the status of deb pkg (gcc_sn=
apshot)
or use lfs procedure (just need more patience) ;-)

I will advise obviously :)

Thanks for all,
    Joel
 


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

Re: [parisc-linux] head.S: a small typo

[Joel Soete]

Hi Dave, Grant,

John David Anglin wrote:
>>mmm is there importance in the order of:
>>	.align 128
>>	.text
>>rfi_virt2real:
> 
> 
> Yes, put the .align after the .text.  You want to align the following
> text.
> 
Here is the patch so:
--- arch/parisc/kernel/real2.S.Orig     2005-01-08 16:58:49.000000000 +0100
+++ arch/parisc/kernel/real2.S  2005-05-01 15:45:32.000000000 +0200
@@ -143,8 +143,8 @@
  /* rfi_virt2real() and rfi_real2virt() could perhaps be adapted for
   * more general-purpose use by the several places which need RFIs
   */
-       .align 128
         .text
+       .align 128
  rfi_virt2real:
         /* switch to real mode... */
         ssm             0,0             /* See "relied upon translation" */
====<>====

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

Re: [parisc-linux] head.S: a small typo

[Kyle McMartin]

On Tue, Apr 26, 2005 at 07:36:43PM +0200, Joel Soete wrote:
> (btw I disasemble the resulting kernel text and this code seems to be only
> called once and very early)
> 

This is the kernel entry point from the bootloader. It sets things up then 
jumps to init/main.c:start_kernel().

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

Re: [parisc-linux] head.S: a small typo

[John David Anglin]

> It was why ifdef __LP64__ of align_rfi

This is point 2 on page F-4 and F-5 of the arch.

#ifdef __LP64__ /* move to psw.h? */
#define         PSW_BITS        PSW_Q+PSW_I+PSW_D+PSW_P+PSW_R
#else
#define         PSW_BITS        PSW_SM_Q
#endif

$rfi:
        /* turn off troublesome PSW bits */
	rsm             PSW_BITS,%r0

	/* kernel PSW:
	 *  - no interruptions except HPMC and TOC (which are handled by PDC)
	 *  - Q bit set (IODC / PDC interruptions)
	 *  - big-endian
	 *  - virtually mapped
	 */

The above code turns off the Q bit in both 32 and 64 bit kernels.  Thus,
it's not clear why this is only needed in a 64-bit kernel.  Indeed pacache.S
uses this sequence.  The comment seems to imply that at one time the Q
bit was set in this code.

The clearing rsm can't be within 8 instructions of a page boundary.  Thus,
it seems the alignment of 256 can be reduced to 128 in head.S.  We also
seem to have one more nop than needed.

The alignment of 128 used for flush_tlb_all_local and disable_sr_hashing_asm
might be too small.  For example, the second rsm in disable_sr_hashing_asm
is 31 instructions after the first.

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

[parisc-linux] head.S: a small typo

[Joel Soete]

Hi all,

I just noticed this small typo:
--- arch/parisc/kernel/head.S.Orig      2005-04-20 18:46:57.000000000 +02=
00
+++ arch/parisc/kernel/head.S   2005-04-21 08:28:11.000000000 +0200
@@ -260,7 +260,7 @@
 
        .align          256
 aligned_rfi:
-       ssm             0,0
+       ssm             0, %r0
        nop             /* 1 */
        nop             /* 2 */
        nop             /* 3 */
=3D=3D=3D=3D<>=3D=3D=3D=3D

Hth,
    Joel

PS: is there some insterest in some white space cleanup in those *.S 


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

Re: [parisc-linux] head.S: a small typo

[Grant Grundler]

On Thu, Apr 21, 2005 at 08:39:13AM +0200, Joel Soete wrote:
> -       ssm             0,0
> +       ssm             0, %r0

Joel,
Amusing you should just fix one...

grundler <509>pwd
/usr/src/linux-2.6/arch/parisc/kernel
grundler <510>fgrep ssm *.S | fgrep 0,0 | wc -l
337

Caveat: 334 of those are in perf_asm.S which isn't functional.

I'm not inclined to change the remaining three since the assembler
obviously accepts it.

> PS: is there some insterest in some white space cleanup in those *.S

Hrm...not from me.
My priorities are:
o getting pa8800 stable (latest kernels still occasionally segfaults.)
o get MPT/Fusion driver working on parisc (HPMCs on IOC reset)
o MSI support on parisc.
o stable ad1889 (workstation audio)
o FX-E support (ok, that's wishful thinking now...)

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

Re: [parisc-linux] head.S: a small typo

[Joel Soete]

> -- Original Message --
> Date: Fri, 22 Apr 2005 00:36:49 -0600
> From: Grant Grundler <grundler@parisc-linux.org>
> To: Joel Soete <soete.joel@tiscali.be>
> Cc: parisc-linux@lists.parisc-linux.org
> Subject: Re: [parisc-linux] head.S: a small typo
> 
> 
> On Thu, Apr 21, 2005 at 08:39:13AM +0200, Joel Soete wrote:
> > -       ssm             0,0
> > +       ssm             0, %r0
> 
> Joel,
> Amusing you should just fix one...
> 
Just investigate one file at  a time ;-)

> grundler <509>pwd
> /usr/src/linux-2.6/arch/parisc/kernel
> grundler <510>fgrep ssm *.S | fgrep 0,0 | wc -l
> 337
> 
Do you want I prepare other patches too ?

> Caveat: 334 of those are in perf_asm.S which isn't functional.
> 
> I'm not inclined to change the remaining three since the assembler
> obviously accepts it.
Yes curiously?

> 
> > PS: is there some insterest in some white space cleanup in those *.S
> 
> Hrm...not from me.
> My priorities are:
> o getting pa8800 stable (latest kernels still occasionally segfaults.)
Isn't it related to the generic pb encounter elsewhere?
(all my system 32bit mainly make from time to time panic: that was in fac=
t
what I was trying to study, when interruptions are enabled and disabled (=
PSW
I bit if I well understand?)...) 

> o get MPT/Fusion driver working on parisc (HPMCs on IOC reset)
> o MSI support on parisc.
> o stable ad1889 (workstation audio)
> o FX-E support (ok, that's wishful thinking now...)
> 
Ah you finaly found some doc ?

Thanks,
    Joel


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

Re: [parisc-linux] head.S: a small typo

[Grant Grundler]

On Fri, Apr 22, 2005 at 06:04:03PM +0200, Joel Soete wrote:
> > grundler <509>pwd
> > /usr/src/linux-2.6/arch/parisc/kernel
> > grundler <510>fgrep ssm *.S | fgrep 0,0 | wc -l
> > 337
>
> Do you want I prepare other patches too ?

No, but thanks anyway.

> > My priorities are:
> > o getting pa8800 stable (latest kernels still occasionally segfaults.)
>
> Isn't it related to the generic pb encounter elsewhere?
> (all my system 32bit mainly make from time to time panic: that was in fact
> what I was trying to study, when interruptions are enabled and disabled (PSW
> I bit if I well understand?)...)

I don't know but I'm skeptical it's generic core issue.
If it were generic, I would expect to see similar symptoms on ia64
and x86 and I don't.

> > o get MPT/Fusion driver working on parisc (HPMCs on IOC reset)
> > o MSI support on parisc.
> > o stable ad1889 (workstation audio)
> > o FX-E support (ok, that's wishful thinking now...)
>
> Ah you finaly found some doc ?

No...just the GPL'd FX/5 and FX/10 drivers that have been available
for a long time but don't seem to be sufficient to write a new driver
for parisc.

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