Bug#962485: Please revert CONFIG_MIPS_O32_FP64_SUPPORT change mipsel
On Thu, Mar 25, 2021 at 03:00:06PM +0800, YunQiang Su wrote: > YunQiang Su 于2021年2月20日周六 下午2:19写道： > > https://lore.kernel.org/linux-mips/20210220061635.9976-1-yunqiang...@cipunited.com/T/#u > > This patch for kernel can fix this problem. > > Let's wait for the reply of kernel upstream community. > the newest version of this patch: > https://patchwork.kernel.org/project/linux-mips/patch/20210322015902.18451-1-yunqiang...@cipunited.com/ > Is it possible for Debian's kernel to apply this patch? Get it applied via sta...@kernel.org. And please fix your MUA to not produce TOFU. Bastian -- Killing is stupid; useless! -- McCoy, "A Private Little War", stardate 4211.8
Bug#962485: Please revert CONFIG_MIPS_O32_FP64_SUPPORT change mipsel
YunQiang Su 于2021年2月20日周六 下午2:19写道： > > https://lore.kernel.org/linux-mips/20210220061635.9976-1-yunqiang...@cipunited.com/T/#u > This patch for kernel can fix this problem. > > Let's wait for the reply of kernel upstream community. > the newest version of this patch: https://patchwork.kernel.org/project/linux-mips/patch/20210322015902.18451-1-yunqiang...@cipunited.com/ Is it possible for Debian's kernel to apply this patch? > Bastian Blank 于2021年2月11日周四 下午2:57写道： > > > > Moin > > > > On Thu, Feb 11, 2021 at 10:15:02AM +0800, YunQiang Su wrote: > > > > Could the mips porters comment on this? Given that we're close to the > > > > release > > > > of bullseye, I'm not convinced it's a good idea to change this now. > > > > This option is also a dependency of several types of CPU support. So it > > might not be feasable to disable. > > > > > Yes. It will be a problem to run with buster's golang program on > > > bullseys's kernel. > > > Let's have another way to get this problem sloved without revert this > > > changes. > > > > Sure, by discontinuing support for go on mips for example. > > > > > Maybe detect the golang applications and run them in FP32 mode? > > > > The kernel already does. But it seems go decided to set the FPXX marker > > on it's objects. See https://github.com/golang/go/issues/39435 > > > > Bastian > > > > -- > > Captain's Log, star date 21:34.5... > >
Bug#962485: Please revert CONFIG_MIPS_O32_FP64_SUPPORT change mipsel
https://lore.kernel.org/linux-mips/20210220061635.9976-1-yunqiang...@cipunited.com/T/#u This patch for kernel can fix this problem. Let's wait for the reply of kernel upstream community. Bastian Blank 于2021年2月11日周四 下午2:57写道： > > Moin > > On Thu, Feb 11, 2021 at 10:15:02AM +0800, YunQiang Su wrote: > > > Could the mips porters comment on this? Given that we're close to the > > > release > > > of bullseye, I'm not convinced it's a good idea to change this now. > > This option is also a dependency of several types of CPU support. So it > might not be feasable to disable. > > > Yes. It will be a problem to run with buster's golang program on > > bullseys's kernel. > > Let's have another way to get this problem sloved without revert this > > changes. > > Sure, by discontinuing support for go on mips for example. > > > Maybe detect the golang applications and run them in FP32 mode? > > The kernel already does. But it seems go decided to set the FPXX marker > on it's objects. See https://github.com/golang/go/issues/39435 > > Bastian > > -- > Captain's Log, star date 21:34.5... >
Bug#962485: Please revert CONFIG_MIPS_O32_FP64_SUPPORT change mipsel
Moin On Thu, Feb 11, 2021 at 10:15:02AM +0800, YunQiang Su wrote: > > Could the mips porters comment on this? Given that we're close to the > > release > > of bullseye, I'm not convinced it's a good idea to change this now. This option is also a dependency of several types of CPU support. So it might not be feasable to disable. > Yes. It will be a problem to run with buster's golang program on > bullseys's kernel. > Let's have another way to get this problem sloved without revert this changes. Sure, by discontinuing support for go on mips for example. > Maybe detect the golang applications and run them in FP32 mode? The kernel already does. But it seems go decided to set the FPXX marker on it's objects. See https://github.com/golang/go/issues/39435 Bastian -- Captain's Log, star date 21:34.5...
Bug#962485: Please revert CONFIG_MIPS_O32_FP64_SUPPORT change mipsel
Ivo De Decker 于2021年2月9日周二 下午9:45写道： > > Hi, > > On Mon, Jun 08, 2020 at 08:15:38PM +0300, Adrian Bunk wrote: > > On Fri, May 29, 2020 at 11:03:14PM +0200, Aurelien Jarno wrote: > > > On 2020-05-28 09:04, YunQiang Su wrote: > > > > Adrian Bunk 于2020年5月21日周四 下午3:40写道： > > > > > On Thu, May 21, 2020 at 06:41:34AM +0800, YunQiang Su wrote: > > > > > > Adrian Bunk 于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. > > Could the mips porters comment on this? Given that we're close to the release > of bullseye, I'm not convinced it's a good idea to change this now. Yes. It will be a problem to run with buster's golang program on bullseys's kernel. Let's have another way to get this problem sloved without revert this changes. Maybe detect the golang applications and run them in FP32 mode? > > Cheers, > > Ivo > >
Bug#962485: Please revert CONFIG_MIPS_O32_FP64_SUPPORT change mipsel
Hi, On Mon, Jun 08, 2020 at 08:15:38PM +0300, Adrian Bunk wrote: > On Fri, May 29, 2020 at 11:03:14PM +0200, Aurelien Jarno wrote: > > On 2020-05-28 09:04, YunQiang Su wrote: > > > Adrian Bunk 于2020年5月21日周四 下午3:40写道： > > > > On Thu, May 21, 2020 at 06:41:34AM +0800, YunQiang Su wrote: > > > > > Adrian Bunk 于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. Could the mips porters comment on this? Given that we're close to the release of bullseye, I'm not convinced it's a good idea to change this now. Cheers, Ivo
