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: Debian kernel boot failure on Alpha [was Re: systemd FTBFS]

[Michael Cree]

On Wed, Mar 29, 2017 at 01:41:29PM +0200, Frank Scheiner wrote:
> I have had a similar problem than you, i.e. no generic Linux kernel v4.x
> from Debian runs or ran on my Alpha gear (the newest one is a PWS 500au with
> EV56). 

I seem to recall the last working kernel is v4.2.  Interestingly the
Debian generic kernel boots my Titian variant alpha but not the XP1000.

> The older 3.16.x kernel worked without a problem on my machines though.
> Hence I thought that maybe something was changed in the v4.x kernels that
> made them incompatible with pre EV6 CPUs. 

The XP1000 is ev67 and the generic kernel fails to boot on it.

> There were some messages about
> enabling BWX (starting with [1]), but as it should still work with EV56 when
> enabled I wondered if my problems were related at all.
> 
> [1]: https://lists.debian.org/debian-alpha/2014/09/msg0.html
> 
> Mid of 2015 you wrote on [2] that you haven't yet enabled BWX,

I've managed to switch the defaults in gcc in a test run and started
a local repository rebuild to test it but it exposed a nasty bug in libc
so I couldn't continue to test.  That took some time to fix and I never
returned to exploring switching Debian Ports to using BWX.  My feeling is
that we should in fact do that considering that the i386 arch recently
dropped support for Intel chips that are more recent than the old-time
Alpha cpus we still support!

> Until recently I didn't have a reason to also try the SMP variant of the
> v4.x Linux kernels, but now that I have a DS20E and had the same problems
> with the generic Linux kernel v4.x from Debian I also tried the SMP variant
> on it.
> 
> And the SMP variant of the v4.x kernel just works (tested with
> "4.8.0.2-alpha-smp", "Debian 4.8.11-1" from 2016-12-02 to be exact).

Now that it is interesting!  The SMP kernel also boots on my XP1000.
The only downside to using an SMP kernel is extra allocations of per-cpu
data structures, and the loss of some optimised code that eject SMP
barriers.

I would be wary of using the Debian 4.9 kernel for any serious work on
Alpha. I presume it still has commit
0784672d05684de901fc2aa56150d7ea9a475a2d which leads to random
segfaults in user space on Alpha (and the occasional kernel OOPS).

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