Re: [LEDE-DEV] 18.03/4 -> GCC 5 or 7
On 03/09/2018 01:56 PM, Matthias Schiffer wrote: > On 03/07/2018 06:49 PM, Lucian Cristian wrote: >> testing r6395-6c194078db on a ramips Ralink RT5350 with 4.14 and GCC 7.3 >> gives this error in luci >> >> daemon.err uhttpd[873]: /usr/bin/lua: /usr/lib/lua/luci/debug.lua:6: >> attempt to call a number value >> daemon.err uhttpd[873]: stack traceback: >> daemon.err uhttpd[873]: /usr/lib/lua/luci/debug.lua:6: in main chunk >> daemon.err uhttpd[873]: [C]: in function 'require' >> daemon.err uhttpd[873]: /usr/lib/lua/luci/util.lua:8: in main chunk >> daemon.err uhttpd[873]: [C]: in function 'require' >> daemon.err uhttpd[873]: /usr/lib/lua/luci/config.lua:4: in main chunk >> daemon.err uhttpd[873]: [C]: in function 'require' >> daemon.err uhttpd[873]: /usr/lib/lua/luci/cacheloader.lua:5: in main chunk >> daemon.err uhttpd[873]: [C]: in function 'require' >> daemon.err uhttpd[873]: /www/cgi-bin/luci:2: in main chunk >> daemon.err uhttpd[873]: [C]: ? > > > I was able to reproduce this on ar71xx. Minimal testcase: > >> s = 'foo' >> print(s:sub(2)) > > fails, while > >> print(s.sub(s, 2)) > > works correctly, even though the former is only syntactic sugar for the > latter. FWIW, type(s) correctly states that s is a string. Looking into it > now. > > Matthias Bug reported at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84790 Matthias signature.asc Description: OpenPGP digital signature ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] 18.03/4 -> GCC 5 or 7
On 03/07/2018 06:49 PM, Lucian Cristian wrote: > testing r6395-6c194078db on a ramips Ralink RT5350 with 4.14 and GCC 7.3 > gives this error in luci > > daemon.err uhttpd[873]: /usr/bin/lua: /usr/lib/lua/luci/debug.lua:6: > attempt to call a number value > daemon.err uhttpd[873]: stack traceback: > daemon.err uhttpd[873]: /usr/lib/lua/luci/debug.lua:6: in main chunk > daemon.err uhttpd[873]: [C]: in function 'require' > daemon.err uhttpd[873]: /usr/lib/lua/luci/util.lua:8: in main chunk > daemon.err uhttpd[873]: [C]: in function 'require' > daemon.err uhttpd[873]: /usr/lib/lua/luci/config.lua:4: in main chunk > daemon.err uhttpd[873]: [C]: in function 'require' > daemon.err uhttpd[873]: /usr/lib/lua/luci/cacheloader.lua:5: in main chunk > daemon.err uhttpd[873]: [C]: in function 'require' > daemon.err uhttpd[873]: /www/cgi-bin/luci:2: in main chunk > daemon.err uhttpd[873]: [C]: ? I was able to reproduce this on ar71xx. Minimal testcase: > s = 'foo' > print(s:sub(2)) fails, while > print(s.sub(s, 2)) works correctly, even though the former is only syntactic sugar for the latter. FWIW, type(s) correctly states that s is a string. Looking into it now. Matthias signature.asc Description: OpenPGP digital signature ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] 18.03/4 -> GCC 5 or 7
On 04.03.2018 17:15, Hauke Mehrtens wrote: On 02/16/2018 01:46 PM, John Crispin wrote: Hi, whats on the critical todo list for the upcoming release ? i still have a few minor things that I'll be adding shortly, apart from that I am currently not aware of any huge problems. the release will be a mix between 4.9 and 4.14 afaik !? I think the kernel situation is ok now and not blocking a release, we will have a mixed kernel 4.9 and 4.14 release. All important targets are on one of these two kernel versions by now. The patches for the gemini target will probably get included soon. Some targets will probably be updated from 4.9 to 4.14, but this is not blocking. What do we want to do with GCC 5.5 versus 7.3? GCC 5.5 is getting old, we have multiple problems with it, the big blocker for GCC 7 was just fixed upstream and we backported that fix. see: http://git.openwrt.org/25aaff9100065dba881be71b9dcab1e9cc8a7b5f The x86 and x86_64 architectures are already on GCC 7.3, the ARC architecture uses their own GCC fork based on version 7.X all other architectures are on GCC 5.5. We have the following problems with GCC 5.5: * U-Boot depends on GCC 6 or higher since version 2018.01 on ARM and ARM64 * GCC 5 and older are producing too big binaries, e.g. the SPL on the Allwinner A64 (sunxi, ARM64) is getting too big starting with U-Boot 2017.09 and does not fit into the SRAM any more, GCC 7 solves this problem. * busybox on the gemini target updated to kernel 4.14 does not work correctly. * GCC 5.5 only has out of tree fixes for Spectre, GCC 7.3 already has the retpoline fixes against Spectre included As the x86 target use GCC 7.3 now, there are multiple pull requests fixing some build problems in some packages with GCC 7. I am not aware of any regressions in GCC 7 compared to GCC 5. Changing the default compiler from GCC 5 to GCC 7 is no big problem, the problems are the regressions we are not aware of by now, if we change the default compiler for all architectures to GCC 7 we should probably wait 4 weeks before doing an RC release to be sure most of the runtime problems with GCC 7 are found. If we do the switch to GCC 7 I think we should also change binutils from 2.28 to 2.28.1 or 2.29.1. I found this problem with binutils 2.28 which was already fixed in 2.28.1: https://git.openwrt.org/bcd17ce9a3308accc30d99f4dd43f2062bb3fabc The minor versions contains more bugfixes. There is also a pull request for busybox 2.28.1 at github, this will probably also introduce some more regressions, so I am not sure if we should take it before or after the release. https://github.com/openwrt/openwrt/pull/733 I do not have a real opinion on this and I am probably the wrong person to judge this. I do not know what the status of the software fast path patches are, but they are looking interesting. My proposal would be to update all targets to GCC 7.3 and also use binutils 2.29.1 and musl 1.1.19. This change would be done as soon as possible and then we branch of end of March or beginning of April for 18.X and do a RC1 one week after creating the branch. Hauke ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev testing r6395-6c194078db on a ramips Ralink RT5350 with 4.14 and GCC 7.3 gives this error in luci daemon.err uhttpd[873]: /usr/bin/lua: /usr/lib/lua/luci/debug.lua:6: attempt to call a number value daemon.err uhttpd[873]: stack traceback: daemon.err uhttpd[873]: /usr/lib/lua/luci/debug.lua:6: in main chunk daemon.err uhttpd[873]: [C]: in function 'require' daemon.err uhttpd[873]: /usr/lib/lua/luci/util.lua:8: in main chunk daemon.err uhttpd[873]: [C]: in function 'require' daemon.err uhttpd[873]: /usr/lib/lua/luci/config.lua:4: in main chunk daemon.err uhttpd[873]: [C]: in function 'require' daemon.err uhttpd[873]: /usr/lib/lua/luci/cacheloader.lua:5: in main chunk daemon.err uhttpd[873]: [C]: in function 'require' daemon.err uhttpd[873]: /www/cgi-bin/luci:2: in main chunk daemon.err uhttpd[873]: [C]: ? Regards ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] 18.03/4 -> GCC 5 or 7
On Sun, Mar 4, 2018 at 7:15 AM, Hauke Mehrtens wrote: > On 02/16/2018 01:46 PM, John Crispin wrote: >> Hi, >> >> whats on the critical todo list for the upcoming release ? i still have >> a few minor things that I'll be adding shortly, apart from that I am >> currently not aware of any huge problems. the release will be a mix >> between 4.9 and 4.14 afaik !? > > I think the kernel situation is ok now and not blocking a release, we > will have a mixed kernel 4.9 and 4.14 release. All important targets are > on one of these two kernel versions by now. > The patches for the gemini target will probably get included soon. > Some targets will probably be updated from 4.9 to 4.14, but this is not > blocking. > > > What do we want to do with GCC 5.5 versus 7.3? > GCC 5.5 is getting old, we have multiple problems with it, the big > blocker for GCC 7 was just fixed upstream and we backported that fix. > see: http://git.openwrt.org/25aaff9100065dba881be71b9dcab1e9cc8a7b5f > The x86 and x86_64 architectures are already on GCC 7.3, the ARC > architecture uses their own GCC fork based on version 7.X all other > architectures are on GCC 5.5. Preliminary testing with GCC 7.3 reveals that it fixes the SATA data corruption issue on MIPS (at least ramips and ar71xx, possibly others). @dissent1 started seeing the issue after going back to 5.5 in his builds. Both GCC 5.5 and 7.3 fail with -O3, but that's beyond the scope of OpenWrt. > > We have the following problems with GCC 5.5: > * U-Boot depends on GCC 6 or higher since version 2018.01 on ARM and ARM64 > * GCC 5 and older are producing too big binaries, e.g. the SPL on the > Allwinner A64 (sunxi, ARM64) is getting too big starting with U-Boot > 2017.09 and does not fit into the SRAM any more, GCC 7 solves this problem. > * busybox on the gemini target updated to kernel 4.14 does not work > correctly. > * GCC 5.5 only has out of tree fixes for Spectre, GCC 7.3 already has > the retpoline fixes against Spectre included > > As the x86 target use GCC 7.3 now, there are multiple pull requests > fixing some build problems in some packages with GCC 7. > I am not aware of any regressions in GCC 7 compared to GCC 5. > Changing the default compiler from GCC 5 to GCC 7 is no big problem, the > problems are the regressions we are not aware of by now, if we change > the default compiler for all architectures to GCC 7 we should probably > wait 4 weeks before doing an RC release to be sure most of the runtime > problems with GCC 7 are found. > > If we do the switch to GCC 7 I think we should also change binutils from > 2.28 to 2.28.1 or 2.29.1. I found this problem with binutils 2.28 which > was already fixed in 2.28.1: > https://git.openwrt.org/bcd17ce9a3308accc30d99f4dd43f2062bb3fabc > The minor versions contains more bugfixes. > > > There is also a pull request for busybox 2.28.1 at github, this will > probably also introduce some more regressions, so I am not sure if we > should take it before or after the release. > https://github.com/openwrt/openwrt/pull/733 > I do not have a real opinion on this and I am probably the wrong person > to judge this. Likewise. I vote for getting it in. > > > I do not know what the status of the software fast path patches are, but > they are looking interesting. > > > My proposal would be to update all targets to GCC 7.3 and also use > binutils 2.29.1 and musl 1.1.19. This change would be done as soon as > possible and then we branch of end of March or beginning of April for > 18.X and do a RC1 one week after creating the branch. > > Hauke > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] 18.03/4 -> GCC 5 or 7
On 03/04/2018 04:40 PM, Felix Fietkau wrote: > On 2018-03-04 16:15, Hauke Mehrtens wrote: >> There is also a pull request for busybox 2.28.1 at github, this will >> probably also introduce some more regressions, so I am not sure if we >> should take it before or after the release. >> https://github.com/openwrt/openwrt/pull/733 >> I do not have a real opinion on this and I am probably the wrong person >> to judge this. > Anything useful in there? I haven't seen there anything useful, except support for some new MIPS ISAs, but I do not know if they ever will be relevant. binutils: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=binutils/NEWS;hb=refs/tags/binutils-2_30 gas: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=gas/NEWS;hb=refs/tags/binutils-2_30 ld: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=ld/NEWS;hb=refs/tags/binutils-2_30 >> I do not know what the status of the software fast path patches are, but >> they are looking interesting. > I think the flow offload support will be ready soon. So far it's looking > good aside from some issues with TCP connection timeout handling that > I'm going to deal with soon. We should make it clear that those patches > are still experimental though. > >> My proposal would be to update all targets to GCC 7.3 and also use >> binutils 2.29.1 and musl 1.1.19. This change would be done as soon as >> possible and then we branch of end of March or beginning of April for >> 18.X and do a RC1 one week after creating the branch. > Fine with me. I'll run some more test builds for various architectures. Hauke ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] 18.03/4 -> GCC 5 or 7
On 2018-03-04 16:15, Hauke Mehrtens wrote: > There is also a pull request for busybox 2.28.1 at github, this will > probably also introduce some more regressions, so I am not sure if we > should take it before or after the release. > https://github.com/openwrt/openwrt/pull/733 > I do not have a real opinion on this and I am probably the wrong person > to judge this. Anything useful in there? > I do not know what the status of the software fast path patches are, but > they are looking interesting. I think the flow offload support will be ready soon. So far it's looking good aside from some issues with TCP connection timeout handling that I'm going to deal with soon. We should make it clear that those patches are still experimental though. > My proposal would be to update all targets to GCC 7.3 and also use > binutils 2.29.1 and musl 1.1.19. This change would be done as soon as > possible and then we branch of end of March or beginning of April for > 18.X and do a RC1 one week after creating the branch. Fine with me. I'll run some more test builds for various architectures. - Felix ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] 18.03/4 -> GCC 5 or 7
On 02/16/2018 01:46 PM, John Crispin wrote: > Hi, > > whats on the critical todo list for the upcoming release ? i still have > a few minor things that I'll be adding shortly, apart from that I am > currently not aware of any huge problems. the release will be a mix > between 4.9 and 4.14 afaik !? I think the kernel situation is ok now and not blocking a release, we will have a mixed kernel 4.9 and 4.14 release. All important targets are on one of these two kernel versions by now. The patches for the gemini target will probably get included soon. Some targets will probably be updated from 4.9 to 4.14, but this is not blocking. What do we want to do with GCC 5.5 versus 7.3? GCC 5.5 is getting old, we have multiple problems with it, the big blocker for GCC 7 was just fixed upstream and we backported that fix. see: http://git.openwrt.org/25aaff9100065dba881be71b9dcab1e9cc8a7b5f The x86 and x86_64 architectures are already on GCC 7.3, the ARC architecture uses their own GCC fork based on version 7.X all other architectures are on GCC 5.5. We have the following problems with GCC 5.5: * U-Boot depends on GCC 6 or higher since version 2018.01 on ARM and ARM64 * GCC 5 and older are producing too big binaries, e.g. the SPL on the Allwinner A64 (sunxi, ARM64) is getting too big starting with U-Boot 2017.09 and does not fit into the SRAM any more, GCC 7 solves this problem. * busybox on the gemini target updated to kernel 4.14 does not work correctly. * GCC 5.5 only has out of tree fixes for Spectre, GCC 7.3 already has the retpoline fixes against Spectre included As the x86 target use GCC 7.3 now, there are multiple pull requests fixing some build problems in some packages with GCC 7. I am not aware of any regressions in GCC 7 compared to GCC 5. Changing the default compiler from GCC 5 to GCC 7 is no big problem, the problems are the regressions we are not aware of by now, if we change the default compiler for all architectures to GCC 7 we should probably wait 4 weeks before doing an RC release to be sure most of the runtime problems with GCC 7 are found. If we do the switch to GCC 7 I think we should also change binutils from 2.28 to 2.28.1 or 2.29.1. I found this problem with binutils 2.28 which was already fixed in 2.28.1: https://git.openwrt.org/bcd17ce9a3308accc30d99f4dd43f2062bb3fabc The minor versions contains more bugfixes. There is also a pull request for busybox 2.28.1 at github, this will probably also introduce some more regressions, so I am not sure if we should take it before or after the release. https://github.com/openwrt/openwrt/pull/733 I do not have a real opinion on this and I am probably the wrong person to judge this. I do not know what the status of the software fast path patches are, but they are looking interesting. My proposal would be to update all targets to GCC 7.3 and also use binutils 2.29.1 and musl 1.1.19. This change would be done as soon as possible and then we branch of end of March or beginning of April for 18.X and do a RC1 one week after creating the branch. Hauke ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] 18.03/4
Em 26/02/18 14:17, Hauke Mehrtens escreveu: On 02/26/2018 02:16 PM, Henrique de Moraes Holschuh wrote: FWIW, I had issues with the ath10k-firmware currently in OpenWRT master, it would crash with 100% reproducibly in TP-Link Archer C60v2 (there is already a PR open adding support for this device). These issues are fixed in the newest "stable" version of the ath10k firmware, which was uploaded to kernel.org::linux-firmware some days ago. Hi, does this pull request fix your problem: https://github.com/openwrt/openwrt/pull/744 It should fix it, yes. I have commented on the pull request. Thanks! -- Henrique de Moraes Holschuh Analista de Projetos Centro de Estudos e Pesquisas em Tecnologias de Redes e Operações (Ceptro.br) +55 11 5509-3537 R.:4023 INOC 22548*625 www.nic.br ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] 18.03/4
On 02/26/2018 02:16 PM, Henrique de Moraes Holschuh wrote: > FWIW, I had issues with the ath10k-firmware currently in OpenWRT master, > it would crash with 100% reproducibly in TP-Link Archer C60v2 (there is > already a PR open adding support for this device). > > These issues are fixed in the newest "stable" version of the ath10k > firmware, which was uploaded to kernel.org::linux-firmware some days ago. > Hi, does this pull request fix your problem: https://github.com/openwrt/openwrt/pull/744 Hauke ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] 18.03/4
FWIW, I had issues with the ath10k-firmware currently in OpenWRT master, it would crash with 100% reproducibly in TP-Link Archer C60v2 (there is already a PR open adding support for this device). These issues are fixed in the newest "stable" version of the ath10k firmware, which was uploaded to kernel.org::linux-firmware some days ago. -- Henrique de Moraes Holschuh ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] 18.03/4
On Fri, Feb 16, 2018 at 4:46 AM, John Crispin wrote: > Hi, > > whats on the critical todo list for the upcoming release ? i still have a > few minor things that I'll be adding shortly, apart from that I am currently > not aware of any huge problems. the release will be a mix between 4.9 and > 4.14 afaik !? The MIPS SATA thing is fairly critical IMO. I've personally reverted to 4.4 for all my MIPS devices because of it. The ramips MMC driver needs a fix so that it does not use HIGHMEM. Details here: https://github.com/neilbrown/linux/commit/dc97800015e66b29a4bb067b355cc2e2b6eb72cb . Not critical. > > John > > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] 18.03/4
Hi, whats on the critical todo list for the upcoming release ? i still have a few minor things that I'll be adding shortly, apart from that I am currently not aware of any huge problems. the release will be a mix between 4.9 and 4.14 afaik !? John ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev