On 2019-12-27 12:20, YunQiang Su wrote: > Stephen Gelman <[email protected]> 于2019年12月27日周五 下午12:06写道： > > > > On Sep 21, 2019, at 4:20 AM, Aurelien Jarno <[email protected]> wrote: > > > > > > On 2019-09-21 10:21, YunQiang Su wrote: > > >> Aurelien Jarno <[email protected]> 于2019年9月20日周五 下午11:36写道： > > >>> > > >>> On 2019-09-18 20:58, YunQiang Su wrote: > > >>>> Drew Parsons <[email protected]> 于2019年9月17日周二 上午11:28写道： > > >>>>> > > >>>>> go builds (dh_auto_build invoking /usr/bin/go -> golang-1.12-go) are > > >>>>> failing consistently on mip64el. I'm seeing the error in > > >>>>> golang-github-anacrolix-dms and rclone but I think other packages are > > >>>>> affected. > > >>>>> > > >>>>> All builds fail on mip64el. mipsel is also intermittently affected, > > >>>>> but > > >>>>> a giveback gets a successful build. The mipsel pattern suggests that > > >>>>> builds fail on mipsel-manda-03, while succeeding on eberlin and > > >>>>> mipsel-aql-01. > > >>>>> > > >>>> > > >>>> It seems another case about Loongson Vs Cavium. > > >>>> These packages seem buildable on Loongson while not on Cavium. > > >>>> > > >>>>> The package providing /usr/lib/go-1.12/bin/go, golang-1.12-go > > >>>>> (golang-1.12), built successfully 25 days ago. > > >>>>> > > >>>>> dms logs are at > > >>>>> https://buildd.debian.org/status/logs.php?pkg=golang-github-anacrolix-dms&arch=mips64el > > >>>>> e.g. > > >>>>> https://buildd.debian.org/status/fetch.php?pkg=golang-github-anacrolix-dms&arch=mips64el&ver=1.0.0-2&stamp=1568632405&raw=0 > > >>>>> > > >>>>> Log snippets: > > >>>>> dh_auto_build -a -O--buildsystem=golang > > >>>>> signal 10 received but handler not on signal stack > > >>>>> fatal error: non-Go code set up signal handler without SA_ONSTACK flag > > >>>>> > > >>>>> runtime stack: > > >>>>> runtime: unexpected return pc for runtime.sigtramp called from > > >>>>> 0xffffee4560 > > >>>>> stack: frame={sp:0xc000009c88, fp:0xc000009cd0} > > >>>>> stack=[0xc000001be8,0xc000009fe8) > > >>>>> 000000c000009b88: 000000c000000480 0000000120037ad4 > > >>>>> <runtime.throw+108> > > >>>>> 000000c000009b98: 000000c000009ba0 000000012005380c > > >>>>> <runtime.sigNotOnStack+172> > > >>>>> 000000c000009ba8: 000000c000009bb0 0000000120069a50 > > >>>>> <runtime.throw.func1+0> > > >>>>> 000000c000009bb8: 000000012065dd02 0000000000000039 > > >>>>> 000000c000009bc8: 0000000120052a44 <runtime.sigtrampgo+700> > > >>>>> 000000012065dd02 > > >>>>> 000000c000009bd8: 0000000000000039 000000012006e4cc > > >>>>> <runtime.sigtramp+84> > > >>>>> ... > > >>>>> runtime.sigtramp(0x0, 0x0, 0x800000000a, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, > > >>>>> 0x0, ...) > > >>>>> /usr/lib/go-1.12/src/runtime/sys_linux_mips64x.s:254 +0x54 > > >>>>> > > >>>>> goroutine 17 [syscall, locked to thread]: > > >>>>> runtime.goexit() > > >>>>> /usr/lib/go-1.12/src/runtime/asm_mips64x.s:646 +0x4 > > >>>>> fp=0xc000058fe0 > > >>>>> sp=0xc000058fe0 pc=0x12006da1c > > >>>>> > > >>>>> goroutine 1 [running, locked to thread]: > > >>>>> goroutine running on other thread; stack unavailable > > >>>>> > > >>>>> goroutine 20 [syscall]: > > >>>>> os/signal.signal_recv(0x0) > > >>>>> /usr/lib/go-1.12/src/runtime/sigqueue.go:139 +0x150 > > >>>>> os/signal.loop() > > >>>>> /usr/lib/go-1.12/src/os/signal/signal_unix.go:23 +0x34 > > >>>>> created by os/signal.init.0 > > >>>>> /usr/lib/go-1.12/src/os/signal/signal_unix.go:29 +0x54 > > >>>>> cd obj-mips64el-linux-gnuabi64 && go install > > >>>>> -gcflags=all=\"-trimpath=/<<PKGBUILDDIR>>/obj-mips64el-linux-gnuabi64/src\" > > >>>>> -asmflags=all=\"-trimpath=/<<PKGBUILDDIR>>/obj-mips64el-linux-gnuabi64/src\" > > >>>>> -v -p 4 > > >>>>> dh_auto_build: cd obj-mips64el-linux-gnuabi64 && go install > > >>>>> -gcflags=all=\"-trimpath=/<<PKGBUILDDIR>>/obj-mips64el-linux-gnuabi64/src\" > > >>>>> -asmflags=all=\"-trimpath=/<<PKGBUILDDIR>>/obj-mips64el-linux-gnuabi64/src\" > > >>>>> -v -p 4 died with signal 10 > > >>>>> make: *** [debian/rules:4: build-arch] Error 255 > > >>>>> dpkg-buildpackage: error: debian/rules build-arch subprocess returned > > >>>>> exit status 2 > > >>>>> > > >>>>> > > >>>>> Is the bug already known and understood, or should a bug be filed > > >>>>> against golang-1.12? > > >>>>> Or does golang-1.12 just need a rebuild against glibc 2.29 or > > >>>>> something > > >>>>> ? > > >>>> > > >>>> I guess it is a bug about Cavium machines... > > >>>> Let's dig it. > > >>> > > >>> I noticed that golang-1.12 has actually been built on Loongson machines. > > >>> Could it be a page size issue (4K vs 16K), which prevent golang built on > > >>> one CPU to be executed on another one? > > >>> > > >> > > >> rich ask that whether we can disable hugepage on all Cavium machines? > > > > > > I just tried to disable transparent huge pages on a Cavium machine and > > > it indeed works. Do you have any idea what is the issue? Has it been > > > reported upstream? Note that the Loongson machine also have transparent > > > huge pages enabled. > > > > > > The proper way to fix that is probably to disable transparent huge pages > > > (or at least to disable them by default) in the kernel package (both > > > stable and sid) so that it also fixes the issue for our users. > > > > > > -- > > > Aurelien Jarno GPG: 4096R/1DDD8C9B > > > [email protected] http://www.aurel32.net > > > > It seems that work stopped on this one… Are there thoughts from anyone > > about Aurelien’s suggestion above? Alternatively does anyone have any > > other ideas how to fix this? It’s unfortunate that at this point every go > > package seems to fail to build now on both mipsel and mips64el. I’m more > > than happy to help out if someone can point me in the right direction! > > It seems that golang-1.13 can be built successfully, since Aurelien > disable hugepage on Cavium's build machine.
To be clear we haven't disabled hugepages on Cavium-based buildds. Instead I added that commit to the stable kernel: https://salsa.debian.org/kernel-team/linux/commit/9397b7ea0ebebe54ead63da74cd43031694043c8 -- Aurelien Jarno GPG: 4096R/1DDD8C9B [email protected] http://www.aurel32.net
