Re: Go builds failing on mips64el
Stephen Gelman <ssgelm@debian.org> 于2019年12月27日周五 下午12:06写道：
>
> On Sep 21, 2019, at 4:20 AM, Aurelien Jarno <aurelien@aurel32.net> wrote:
> >
> > On 2019-09-21 10:21, YunQiang Su wrote:
> >> Aurelien Jarno <aurelien@aurel32.net> 于2019年9月20日周五 下午11:36写道：
> >>>
> >>> On 2019-09-18 20:58, YunQiang Su wrote:
> >>>> Drew Parsons <dparsons@debian.org> 于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
> > aurelien@aurel32.net 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
Reply to: