Re: current toolchain on Alpha is crap?
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?
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?
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?
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?
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?
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