Re: [parisc-linux] Re: schedule_tail

Re: [parisc-linux] Re: schedule_tail

[Alan Modra]

On Thu, 22 Feb 2001, Alan Modra wrote:

> First time in do_fork, I see
>  p = 0x14ff0000, current = 0x102cc000 (= init_task)
> 
> first call to ret_from_kernel_thread gives
>  r26 = 0x102cc000, r30 = 0x14ff0500, and called func = init
> 
> so that checks out OK.  Disassmbling schedule_tail doesn't show anything
> bad.
> 
>  copy r3,r1
>  copy sp,r3
>  stw,ma r1,0x40(sp)
>  ldw 0x28(r26),r19
>  depwi 0,27,1,r19
>  stw r19,0x28(r26)
>  ldo 0x40(r3),sp
>  bv (rp)
>  ldw,mb -0x40(sp),r3

This is really crazy (or I am).  I replaced the calls to schedule_tail
with a call to foo_schedule_tail, a local copy of the above without the
bit twiddling.  Still crashed.  OK, so maybe the stack is messed up.
Turn foo_schedule_tail into

foo_schedule_tail:
  bv (%rp)
  nop

It crashes!!  Remove the calls, and it's OK.  What????

Re: [parisc-linux] Re: schedule_tail

[Richard Hirst]

On Fri, Feb 23, 2001 at 01:28:36AM +1100, Alan Modra wrote:
> This is really crazy (or I am).  I replaced the calls to schedule_tail

This helps for me.  b,l disassembles as call, not b,l ...,rp:

===================================================================
RCS file: /home/cvs/parisc/linux/arch/parisc/kernel/entry.S,v
retrieving revision 1.72
diff -u -r1.72 entry.S
--- entry.S     2001/02/20 02:19:52     1.72
+++ entry.S     2001/02/22 14:33:43
@@ -509,7 +509,7 @@
 
        /* Call schedule_tail first though */
 
-       b,l     schedule_tail, %r2
+       bl      schedule_tail, %r2
        ldo     64(%r30), %r30
 
        ldo     -64(%r30), %r30
@@ -1790,7 +1790,7 @@
 
        /* Set the return value for the child */
 child_return:
-       b,l     schedule_tail, %r2
+       bl      schedule_tail, %r2
        ldo     64(%r30), %r30
 
        ldo     -64(%r30), %r30


Richard

Re: [parisc-linux] Re: schedule_tail

[Matthew Wilcox]

On Thu, Feb 22, 2001 at 02:43:31PM +0000, Richard Hirst wrote:
> On Fri, Feb 23, 2001 at 01:28:36AM +1100, Alan Modra wrote:
> > This is really crazy (or I am).  I replaced the calls to schedule_tail
> 
> This helps for me.  b,l disassembles as call, not b,l ...,rp:
> 
> ===================================================================
> RCS file: /home/cvs/parisc/linux/arch/parisc/kernel/entry.S,v
> retrieving revision 1.72
> diff -u -r1.72 entry.S
> --- entry.S     2001/02/20 02:19:52     1.72
> +++ entry.S     2001/02/22 14:33:43
> @@ -509,7 +509,7 @@
>  
>         /* Call schedule_tail first though */
>  
> -       b,l     schedule_tail, %r2
> +       bl      schedule_tail, %r2

This is crazy.  entry.S is .level 2.0.  bl is not a pa2.0 opcode, b,l is!
What is going on?!

Wait.  Is it...

`The word displacement is assembled from the w, w1, w2, and (when the
,L completer is specified with GR 2 as the link register) w3 fields in
the instruction.''

which, iirc is not available on pa1.1 processors.  So here's the crucial
difference.  Not 32-bit vs 64-bit.  Not SMP vs UP.  But pa1.1 vs 2.0.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] Warnings compiling the CVS kernel

[Helge Deller]

On Wednesday 21 February 2001 08:10, Rafael E. Herrera wrote:
>
> The compilation succeeds but the boot will crash here:
>
> [...]
> POSIX conformance testing by UNIFIX
>
>
> Dumping Stack from 14000000 to 14000240:
>
> Dumping Stack from 1026e000 to 1026e700:
[stack dump removed] 
> Kernel Fault: Code=15 regs=1026e4c0 (Addr=14000008)
>
>      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
> PSW: 00000000000001000000000000001110
> r0-3     00000000 102ea000 10102ba8 14000000
> r4-7     14000240 1023a800 00000000 00000002
> r8-11    19a10000 00000005 00000000 00000005
> r12-15   00000004 00000006 00000008 00000006
> r16-19   1026e080 00000002 00000000 102ea000
> r20-23   00000000 00000060 00000001 00000002
> r24-27   00000001 00000001 1027b484 10266000
> r28-31   0000002a 015752a0 1026e700 00000060
> sr0-3    00000000 00000000 00000000 00000000
> sr4-7    00000000 00000000 00000000 00000000
>
> IASQ: 00000000 00000000 IAOQ: 10102b10 10102b14
>  IIR: 0c701093    ISR: 00000000  IOR: 14000008
> ORIG_R28: 00000000

I have the same problem on a 715/64.
I tried to find the reason for that problem, but since I'm no professional in 
parisc-assembler I'm some kind of stuck here right now.

As far as I've tested, the following patch (HACK!) to 
ret_from_kernel_thread() against CVS head gets me at least to the 
init-process (where it then crashes).

diff -u -r1.72 entry.S
--- entry.S     2001/02/20 02:19:52     1.72
+++ entry.S     2001/02/22 00:18:13
@@ -509,10 +509,12 @@
 
        /* Call schedule_tail first though */
 
+#if 0
        b,l     schedule_tail, %r2
        ldo     64(%r30), %r30
 
        ldo     -64(%r30), %r30
+#endif
        LDREG   TASK_PT_GR26-TASK_SZ_ALGN(%r30), %r1
        LDREG   TASK_PT_GR25-TASK_SZ_ALGN(%r30), %r26
        ble     0(%sr7, %r1)

I know this is *NOT* the correct patch, but AFAIT this means that 
something on the stack (return adress or the pointer to struct task_struct 
*prev for schedule_tail ?) isn't set up properly for 32bit PA ?

I know, that this isn't much information, but maybe this can give someone 
here on the list a clue, where the problem could be ?

Thanks,
Helge

[parisc-linux] schedule_tail

[Alan Modra]

On Thu, 22 Feb 2001, Helge Deller wrote:

> As far as I've tested, the following patch (HACK!) to 
> ret_from_kernel_thread() against CVS head gets me at least to the 
> init-process (where it then crashes).

I ripped out this call to schedule_tail _and_ the other one in
child_return, and things are working again for me.  schedule_tail doesn't
do much on uniprocessor.  Most likely %r26 was wrong.  I'd like to know 
why the stack adjust before calling schedule_tail too.

Alan

[parisc-linux] Re: schedule_tail

[Matthew Wilcox]

On Thu, Feb 22, 2001 at 04:32:51PM +1100, Alan Modra wrote:
> On Thu, 22 Feb 2001, Helge Deller wrote:
> 
> > As far as I've tested, the following patch (HACK!) to 
> > ret_from_kernel_thread() against CVS head gets me at least to the 
> > init-process (where it then crashes).
> 
> I ripped out this call to schedule_tail _and_ the other one in
> child_return, and things are working again for me.  schedule_tail doesn't
> do much on uniprocessor.  Most likely %r26 was wrong.  I'd like to know 
> why the stack adjust before calling schedule_tail too.

It does a lot of important stuff on SMP though.  It does the stack adjust
before calling because the disassembled 32-bit SMP code looks like this:

101186f4 <schedule_tail>:
101186f4:       08 03 02 41     copy r3,r1
101186f8:       08 1e 02 43     copy sp,r3
101186fc:       6b c2 3f d9     stw rp,-14(sr0,sp)

and we don't want to trash what was below the sp.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] Re: schedule_tail

[Alan Modra]

On Wed, 21 Feb 2001, Matthew Wilcox wrote:

> It does a lot of important stuff on SMP though.

I'm not denying that :)

>  It does the stack adjust
> before calling because the disassembled 32-bit SMP code looks like this:
> 101186f4 <schedule_tail>:
> 101186f4:       08 03 02 41     copy r3,r1
> 101186f8:       08 1e 02 43     copy sp,r3
> 101186fc:       6b c2 3f d9     stw rp,-14(sr0,sp)
> 
> and we don't want to trash what was below the sp.

But this location is allowed to be modified by the callee, and I think you
already have a stack frame.

I wrote up some stuff on stack frames at
http://lists.parisc-linux.org/pipermail/parisc-linux/2001-February/011715.html

Alan

Re: [parisc-linux] Re: schedule_tail

[Alan Modra]

On Thu, 22 Feb 2001, Alan Modra wrote:

> I wrote up some stuff on stack frames at
> http://lists.parisc-linux.org/pipermail/parisc-linux/2001-February/011715.html

Which in looking at again, I realise is wrong.  :-(

The 64 bit "Outgoing Register Parameter Area" has eight entries, not four,
and the "Outgoing Stack Parameter Area" starts with arg word 8.

Re: [parisc-linux] Re: schedule_tail

[Matthew Wilcox]

On Thu, Feb 22, 2001 at 05:21:49PM +1100, Alan Modra wrote:
> But this location is allowed to be modified by the callee, and I think you
> already have a stack frame.

Umm... I'm not sure we always do.  It shouldn't be hard to arrange though.

> I wrote up some stuff on stack frames at
> http://lists.parisc-linux.org/pipermail/parisc-linux/2001-February/011715.html

thanks, i was going from the pdfs, but yours is easier to understand.
i don't quite see why it needs `ap' (%r29) to be assigned a value when
calling a function which has no arguments.

would a `call-c-function' macro make sense?

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] Re: schedule_tail

[Alan Modra]

On Wed, 21 Feb 2001, Matthew Wilcox wrote:

> On Thu, Feb 22, 2001 at 05:21:49PM +1100, Alan Modra wrote:
> > But this location is allowed to be modified by the callee, and I think you
> > already have a stack frame.
> 
> Umm... I'm not sure we always do.  It shouldn't be hard to arrange though.
> 
> > I wrote up some stuff on stack frames at
> > http://lists.parisc-linux.org/pipermail/parisc-linux/2001-February/011715.html
> 
> thanks, i was going from the pdfs, but yours is easier to understand.
> i don't quite see why it needs `ap' (%r29) to be assigned a value when
> calling a function which has no arguments.

No, it shouldn't be needed in that case.  It may be necessary in any of
the following cases:
a) the called function takes the address of one of it's args
b) has variable arguments
c) has more than 8 words of args (not always the same as more than 8 args)
d) needs to spill one of its args to the stack.
gcc ought to be able to convert a reference via %r29 to one via %r30, but
that doesn't work at the moment.

> would a `call-c-function' macro make sense?

Yes.