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. So, what's the problem now? Aurelien suggest that we can try to disable hugepage in the src:linux package. do you mean about this? > > Thanks! > > Stephen -- YunQiang Su
