Re: current toolchain on Alpha is crap?

[Bob Tracy]

On Tue, Apr 11, 2017 at 06:12:32PM +1200, Michael Cree wrote:
> > > commit e811f8794673153858eac86448d827002e50ac0a
> > > Author: Michael Cree 
> > > Date:   Wed Feb 8 13:49:02 2017 +1300
> > > 
> > > alpha: fix link errors in user_copy().
> > 
> > Missed both the above.
> 
> This one attached.  It might help with your relocation problems.

Ah...  I recognize this one as part of the "alphalib" patch set.
Already applied.

--Bob

Re: current toolchain on Alpha is crap?

[Michael Cree]

On Mon, Apr 10, 2017 at 10:42:42PM -0500, Bob Tracy wrote:
> On Mon, Apr 10, 2017 at 09:42:50PM +1200, Michael Cree wrote:
> > On Sun, Apr 09, 2017 at 07:47:55PM -0500, Bob Tracy wrote:
> > > Both my 4.10 and recent 4.11-rc5 builds fail to boot/run properly. 
> > 
> > Just built 4.10.9 for DP264 and that boots fine on the XP1000.
> > 
> > I have the following four extra commits on my kernel:
> > 
> > commit 635891340c8a48f2746f501530454df8881f1ec9
> > Author: Michael Cree 
> > Date:   Mon Apr 10 20:58:02 2017 +1200
> > 
> > Revert "mm/compaction.c: fix zoneindex in kcompactd()"
> 
> Never saw this one, which means I probably wasn't paying attention.
> Found the original patch from 2016 and did a "patch -R": it applied
> against 4.11.0-rc6 with a small bit of fuzz, but seems correct by
> inspection.

Good, you definitely want it.  Have you been seeing the occasional
segfault in user space in software such as dpkg, tar, install, cp,
etc?  If so, it is fixed by the above revert.

> > commit 4ace6a63e6c7a545e5921ec340a7c93a0ac0b02f
> > Author: Richard Henderson 
> > Date:   Wed Jul 30 11:42:31 2014 -1000
> > 
> > alpha: Remove "strange" OSF/1 fork semantics

You don't need this one.  It is only helps on an SMP system.

> > commit e811f8794673153858eac86448d827002e50ac0a
> > Author: Michael Cree 
> > Date:   Wed Feb 8 13:49:02 2017 +1300
> > 
> > alpha: fix link errors in user_copy().
> 
> Missed both the above.

This one attached.  It might help with your relocation problems.

Cheers
Michael.
>From e811f8794673153858eac86448d827002e50ac0a Mon Sep 17 00:00:00 2001
From: Michael Cree 
Date: Wed, 8 Feb 2017 13:49:02 +1300
Subject: [PATCH 1/4] alpha: fix link errors in user_copy().

---
 arch/alpha/include/asm/uaccess.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/alpha/include/asm/uaccess.h b/arch/alpha/include/asm/uaccess.h
index 94f587535dee..d9f2bbc642c2 100644
--- a/arch/alpha/include/asm/uaccess.h
+++ b/arch/alpha/include/asm/uaccess.h
@@ -344,7 +344,7 @@ __asm__ __volatile__("1: stb %r2,%1\n"\
 /* This little bit of silliness is to get the GP loaded for a function
that ordinarily wouldn't.  Otherwise we could have it done by the macro
directly, which can be optimized the linker.  */
-#ifdef MODULE
+#if 1
 #define __module_address(sym)		"r"(sym),
 #define __module_call(ra, arg, sym)	"jsr $" #ra ",(%" #arg ")," #sym
 #else
-- 
2.11.0

Re: current toolchain on Alpha is crap?

[Bob Tracy]

On Mon, Apr 10, 2017 at 09:42:50PM +1200, Michael Cree wrote:
> On Sun, Apr 09, 2017 at 07:47:55PM -0500, Bob Tracy wrote:
> > Both my 4.10 and recent 4.11-rc5 builds fail to boot/run properly. 
> 
> Just built 4.10.9 for DP264 and that boots fine on the XP1000.
> 
> I have the following four extra commits on my kernel:
> 
> commit 058948f6ea70eb910c7602c9ce96c075913ff924
> Author: Michael Cree 
> Date:   Fri Feb 10 21:17:22 2017 +1300
> 
> alpha: Shift library routines into own alphalib linker section

Still running with this one locally.

> commit 635891340c8a48f2746f501530454df8881f1ec9
> Author: Michael Cree 
> Date:   Mon Apr 10 20:58:02 2017 +1200
> 
> Revert "mm/compaction.c: fix zoneindex in kcompactd()"

Never saw this one, which means I probably wasn't paying attention.
Found the original patch from 2016 and did a "patch -R": it applied
against 4.11.0-rc6 with a small bit of fuzz, but seems correct by
inspection.

> commit 4ace6a63e6c7a545e5921ec340a7c93a0ac0b02f
> Author: Richard Henderson 
> Date:   Wed Jul 30 11:42:31 2014 -1000
> 
> alpha: Remove "strange" OSF/1 fork semantics
>
> (...)
> 
> commit e811f8794673153858eac86448d827002e50ac0a
> Author: Michael Cree 
> Date:   Wed Feb 8 13:49:02 2017 +1300
> 
> alpha: fix link errors in user_copy().

Missed both the above.

Trying a 4.11.0-rc6 build with the "mm/compaction.c" revert in place.
May have to instrument "arch/alpha/kernel/module.c" to get a better
idea what's going on.

--Bob

Re: current toolchain on Alpha is crap?

[Michael Cree]

On Sun, Apr 09, 2017 at 07:47:55PM -0500, Bob Tracy wrote:
> Both my 4.10 and recent 4.11-rc5 builds fail to boot/run properly. 

Just built 4.10.9 for DP264 and that boots fine on the XP1000.

I have the following four extra commits on my kernel:

commit 058948f6ea70eb910c7602c9ce96c075913ff924
Author: Michael Cree 
Date:   Fri Feb 10 21:17:22 2017 +1300

alpha: Shift library routines into own alphalib linker section

This addresses vmlinux ld BRADDR relocation errors on Alpha that
appeared at some point after the 4.8.0 release.  This is based on
a patchset first provided and tested by Bob Tracy that in turn
were based on a suggestion by Helge Deller , with
significant input from Maciej W. Rozycki 
and Matt Turner .

Approach is to define a new "alphalib" section for all the
Alpha-specific library functions to be linked into the final
vmlinux.

Also delete some extraneous white space at end of lines while we
are at it.

commit 635891340c8a48f2746f501530454df8881f1ec9
Author: Michael Cree 
Date:   Mon Apr 10 20:58:02 2017 +1200

Revert "mm/compaction.c: fix zoneindex in kcompactd()"

This reverts commit 0784672d05684de901fc2aa56150d7ea9a475a2d.

Because it leads to random segfaults in user space on the
Alpha platform.

commit 4ace6a63e6c7a545e5921ec340a7c93a0ac0b02f
Author: Richard Henderson 
Date:   Wed Jul 30 11:42:31 2014 -1000

alpha: Remove "strange" OSF/1 fork semantics

The assignment to regs->r20 kills the original tls_val input
to the clone syscall, which means that clone can no longer be
restarted with the original inputs.

We could, perhaps, retain this result for true fork, but OSF/1
compatibility is no longer important.  Note that glibc has never
used the r20 result value, instead always testing r0 vs 0 to
determine the child/parent status.

This failure can be seen in the glibc nptl/tst-eintr* tests.

Reported-by: Michael Cree 
Signed-off-by: Richard Henderson 

commit e811f8794673153858eac86448d827002e50ac0a
Author: Michael Cree 
Date:   Wed Feb 8 13:49:02 2017 +1300

alpha: fix link errors in user_copy().

Cheers
Michael.

Re: current toolchain on Alpha is crap?

[Michael Cree]

On Sun, Apr 09, 2017 at 07:47:55PM -0500, Bob Tracy wrote:
> Well, maybe the subject line is a bit over the top, but there's either
> an element of truth to it, or the kernel developers have seriously
> screwed things up in a fundamental way for kernels on Alpha after 4.9.
> 
> Both my 4.10 and recent 4.11-rc5 builds fail to boot/run properly. 

I haven't tried 4.10 yet.  I'm still running 4.9 and admittedly have
a number of patches applied to upstream, two of which are to fix
relocation errors at link time, but I think you are already aware of
those patches.

>  That being
> said, a kernel build on the PWS-433au is an overnight-plus-a-bit-longer
> proposition that I'd like to avoid if there's another way to figure out
> what's going on.

Install the alpha cross-compiler on an amd64 machine.  I have
gcc-6-alpha-linux-gnu installed and can build an alpha kernel in
three minutes or so.

Cheers
Michael

Re: current toolchain on Alpha is crap?

[Bob Tracy]

On Sun, Apr 09, 2017 at 07:47:55PM -0500, Bob Tracy wrote:
> (...)
> Both my 4.10 and recent 4.11-rc5 builds fail to boot/run properly.  The
> console spews an endless stream of "unix: Unknown relocation: 1" errors
> on each attempt to load any module.  I think I saw several messages to
> the effect of "exec unknown format" as well.

More info...  The error message originates in "arch/alpha/kernel/module.c",
and the "unix" string is due to trying to load the "net/unix/unix.ko"
module.  Also saw the module load error for "ipv6.ko" and *many* others.

I seem to recall upstream messing around with stricter module checking.
There are reports of people using the "nvidia" binary driver being stuck
at 4.9 because of the associated recent kernel changes.

The "file" command doesn't report anything unusual with respect to the
relocation type for any of the modules, so I'm feeling a bit better
about the integrity of the toolchain used for the builds.  I suppose
it's possible that Alpha got overlooked when the module handling changes
were implemented.

--Bob

current toolchain on Alpha is crap?

[Bob Tracy]

Well, maybe the subject line is a bit over the top, but there's either
an element of truth to it, or the kernel developers have seriously
screwed things up in a fundamental way for kernels on Alpha after 4.9.

Both my 4.10 and recent 4.11-rc5 builds fail to boot/run properly.  The
console spews an endless stream of "unix: Unknown relocation: 1" errors
on each attempt to load any module.  I think I saw several messages to
the effect of "exec unknown format" as well.

Here's the current toolchain info:

gcc version 6.3.0 20170321 (Debian 6.3.0-11)
GNU ld (GNU Binutils for Debian) 2.28

Rebooting on 4.9 restores things to a sane state.

Is anyone else "out there" having better luck?  I'll probably end up
having to recreate the 4.9 tree and build it with the current toolchain
to eliminate the tools as the cause of what I'm seeing.  That being
said, a kernel build on the PWS-433au is an overnight-plus-a-bit-longer
proposition that I'd like to avoid if there's another way to figure out
what's going on.

Thanks.

--Bob