[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#960674: golang-go: "fatal error: gc_trigger underflow" on mipsel



Control: clone -1 -2
Control: reassign -2 src:linux 4.19.118-1
Control: found -2 5.4.6-1
Control: notforwarded -2
Control: severity -2 serious
Control: retitle -2 Please revert CONFIG_MIPS_O32_FP64_SUPPORT change

On Fri, May 29, 2020 at 11:03:14PM +0200, Aurelien Jarno wrote:
> On 2020-05-28 09:04, YunQiang Su wrote:
> > Adrian Bunk <bunk@debian.org> 于2020年5月21日周四 下午3:40写道:
> > > On Thu, May 21, 2020 at 06:41:34AM +0800, YunQiang Su wrote:
> > > > Adrian Bunk <bunk@debian.org> 于2020年5月21日周四 上午4:44写道:
> > > > > On Tue, May 19, 2020 at 11:43:30AM +0800, Shengjing Zhu wrote:
> > > > > >
> > > > > > FTR, after giving back golang-1.14 mipsel several times, it's finally
> > > > > > built, by a longson builder.
> > > > > > So I guess it only occurs on octeon. Since the porterbox eller is also
> > > > > > octeon, it also can't build any go program.
> > > > >
> > > > > On eller golang-1.14 fails to build both in sid and buster chroots.
> > > > >
> > > > > golang-1.11 also fails to build in a buster chroot with floating point
> > > > > test errors.
> > > > >
> > > > > golang-1.14 gets unbroken by GOMIPS=softfloat.
> > > > >
> > > > > The only kernel configuration change on eller in the buster point
> > > > > release is CONFIG_MIPS_O32_FP64_SUPPORT=y, everything observed would
> > > > > make sense if the problem is that golang-1.11 and golang-1.14 are
> > > > > not compatible with CONFIG_MIPS_O32_FP64_SUPPORT.
> > > >
> > > > It is just support O32_FP64. I don't expect it will have any effect.
> > > > Since currently, the toolchain/libraries are all FPXX.
> > >
> > > Only the gcc/binutils toolchain/libraries or also the Go toolchain?
> > 
> > you are right. the current golang still output FP32 object...
> > So, we think that it is buggy.
> > 
> > Since Loongson CPU has some strange behaviour, it even can work...
> > Let's try to patch golang to support FPXX or FP64.
> > 
> > https://github.com/golang/go/issues/39289
> 
> That's probably a solution for bullseye/sid, however we can't backport
> such changes and rebuild the go world in buster. I therefore think that
> for buster the kernel change has to be reverted.

What is clear at this point is that the kernel change should be reverted
in buster since it causes a regression (including build failures on 
buildds). I am cloning this bug for a revert in the kernel of
https://salsa.debian.org/kernel-team/linux/-/commit/947fbc66183d022fe3de7871dfb262d2b87af826

I am marking the version in bullseye as found since we might run into 
the same problem again when buster DSAs will be built on machines 
running the bullseye kernel after the release of bullseye. It might be 
possible to mitigate this problem (e.g. in the kernel or by keeping some 
buildd running with the buster kernel), but without an open bug this 
issue might get forgotten and then resurface after the bullseye release.

> Aurelien

cu
Adrian


Reply to: