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.

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
?

Drew

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

Drew

--
YunQiang Su

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

...

It seems another case about Loongson Vs Cavium.
These packages seem buildable on Loongson while not on Cavium.

...

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

...

I guess it is a bug about Cavium machines...
Let's dig it.

Thanks YunQiang. Sounds like it warrants further investigation, so I've
filed Bug#940676 against golang-1.12-go.

Drew

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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?

--
Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://www.aurel32.net

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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?

--
Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://www.aurel32.net

--
YunQiang Su

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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!

Thanks!

Stephen

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Dec 26, 2019, at 10:20 PM, YunQiang Su <wzssyqa@gmail.com> wrote:

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?

Sorry, i should have clarified! Golang itself is built but many golang packages appear to fail to build in what I believe is the same problem…

Stephen
<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">On Dec 26, 2019, at 10:20 PM, YunQiang Su &lt;<a href="mailto:
wzssyqa@gmail.com" class="">wzssyqa@gmail.com</a>&gt; wrote:<br class=""><div><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style:
normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none;
display: inline !important;" class="">It seems that golang-1.13 can be built successfully, since Aurelien</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight:
normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><span style="caret-color: rgb(0, 0, 0); font-family:
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;
text-decoration: none; float: none; display: inline !important;" class="">disable hugepage on Cavium's build machine.</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-
weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><span style="caret-color: rgb(0, 0, 0); font-
family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width:
0px; text-decoration: none; float: none; display: inline !important;" class="">So, what's the problem now?</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight:
normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""></div></blockquote></div><br class=""><div class="">Sorry,
i should have clarified! &nbsp;Golang itself is built but many golang packages appear to fail to build in what I believe is the same problem…</div><div class=""><br class=""></div><div class="">Stephen</div></body></html>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Dec 26, 2019, at 10:26 PM, YunQiang Su <wzssyqa@gmail.com> wrote:

Stephen Gelman <ssgelm@debian.org> 于2019年12月27日周五 下午12:23写道：

On Dec 26, 2019, at 10:20 PM, YunQiang Su <wzssyqa@gmail.com> wrote:


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?


Sorry, i should have clarified! Golang itself is built but many golang packages appear to fail to build in what I believe is the same problem…

Can you give me some example. So I can have a try.
I have some search, while I cannot find the failures.

Stephen

--
YunQiang Su

Looking closer it appears that these are legitimate failures. Apparently many golang buildmodes are not supported under MIPS. We may need to look into fixing this in dh-golang, but regardless it seems the dh_golang team is in the clear here! :)

Stephen

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2019-12-27 12:20, YunQiang Su wrote:

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.

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 aurelien@aurel32.net http://www.aurel32.net

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)