[LEDE-DEV] UDP throughput caused kernel panic if configured bridge mode in /etc/config/network
Hi all, Recently I got below kernel panic when did UDP throughput test on NXP LS1043ARDB board. I configured the bridge mode in /etc/config/network. But if I used 'brctl' to configure the bridge mode, this issue would not happen. I also noticed almost all memory was consumed(about 700MB) when kernel crashed. Anyone have any idea about this? Thank you very much. root@LEDE:/etc/fmc/config# [ 263.981540] ksoftirqd/3: page allocation failure: order:0, mode:0x2080020 [ 263.988339] CPU: 3 PID: 19 Comm: ksoftirqd/3 Not tainted 4.4.52 #0 [ 263.994508] Hardware name: Freescale LS1043A [ 263.998767] Backtrace: [ 264.001213] [] (dump_backtrace) from [] (show_stack+0x18/0x1c) [ 264.008771] r7: r6: r5:6013 r4: [ 264.014435] [] (show_stack) from [] (dump_stack+0x84/0xa4) [ 264.021652] [] (dump_stack) from [] (warn_alloc_failed+0xf0/0x114) [ 264.029558] r5:02080020 r4: [ 264.033133] [] (warn_alloc_failed) from [] (__alloc_pages_nodemask+0x68c/0x6c0) [ 264.042166] r3: r2: [ 264.045735] r7:0030 r6:02080020 r5: r4:02080020 [ 264.051400] [] (__alloc_pages_nodemask) from [] (_dpa_bp_add_8_bufs+0x40/0x250) [ 264.060434] r10:c001db08 r9:ebc93d48 r8:ebf61650 r7:0003 r6:0004 r5:eb603c10 [ 264.068266] r4:8193f040 [ 264.070796] [] (_dpa_bp_add_8_bufs) from [] (dpaa_eth_refill_bpools+0x28/0x58) [ 264.079742] r10:eb09d480 r9:eb604a74 r8:ef1d9400 r7:eb09d000 r6:ebf61650 r5:ef1e0b44 [ 264.087577] r4:007f [ 264.090106] [] (dpaa_eth_refill_bpools) from [] (priv_rx_default_dqrr+0xd8/0x124) [ 264.099313] r7:eb09d000 r6:ebf61650 r5:ef1e0b44 r4:ef1e15e0 The /etc/config/network for bridge mode as below. config interface 'lan' option type 'bridge' option ifname 'eth2 eth6' option proto 'static' option ipaddr '192.168.1.1' option netmask '255.255.255.0' option ip6assign '60' brctl manual config as below. ifconfig eth2 up ifconfig eth6 up brctl addif br-lan eth6 brctl addif br-lan eth2 best regards, Yangbo Lu ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] FW: UDP throughput caused kernel panic if configured bridge mode in /etc/config/network
Hi John and Jo-Philipp, Have you ever got similar problem, or known any possible reason about this, or known anyone who probably know this? I just found much memory would be consumed if I configured board as bridge mode in /etc/config/network and did UDP throughput test. But using brctl to configure bridge mode didn't consume memory. Thank you very much. Best regards, Yangbo Lu > -Original Message- > From: Y.B. Lu > Sent: Thursday, April 13, 2017 1:24 PM > To: 'lede-dev@lists.infradead.org' > Subject: UDP throughput caused kernel panic if configured bridge mode in > /etc/config/network > > Hi all, > > Recently I got below kernel panic when did UDP throughput test on NXP > LS1043ARDB board. I configured the bridge mode in /etc/config/network. > But if I used 'brctl' to configure the bridge mode, this issue would not > happen. > I also noticed almost all memory was consumed(about 700MB) when kernel > crashed. > Anyone have any idea about this? Thank you very much. > > root@LEDE:/etc/fmc/config# [ 263.981540] ksoftirqd/3: page allocation > failure: order:0, mode:0x2080020 [ 263.988339] CPU: 3 PID: 19 Comm: > ksoftirqd/3 Not tainted 4.4.52 #0 [ 263.994508] Hardware name: Freescale > LS1043A [ 263.998767] Backtrace: > [ 264.001213] [] (dump_backtrace) from [] > (show_stack+0x18/0x1c) [ 264.008771] r7: r6: > r5:6013 r4: [ 264.014435] [] (show_stack) from > [] (dump_stack+0x84/0xa4) [ 264.021652] [] > (dump_stack) from [] (warn_alloc_failed+0xf0/0x114) > [ 264.029558] r5:02080020 r4: [ 264.033133] [] > (warn_alloc_failed) from [] (__alloc_pages_nodemask+0x68c/0x6c0) > [ 264.042166] r3: r2: > [ 264.045735] r7:0030 r6:02080020 r5: r4:02080020 > [ 264.051400] [] (__alloc_pages_nodemask) from [] > (_dpa_bp_add_8_bufs+0x40/0x250) [ 264.060434] r10:c001db08 r9:ebc93d48 > r8:ebf61650 r7:0003 r6:0004 r5:eb603c10 [ 264.068266] > r4:8193f040 [ 264.070796] [] (_dpa_bp_add_8_bufs) from > [] (dpaa_eth_refill_bpools+0x28/0x58) > [ 264.079742] r10:eb09d480 r9:eb604a74 r8:ef1d9400 r7:eb09d000 > r6:ebf61650 r5:ef1e0b44 [ 264.087577] r4:007f [ 264.090106] > [] (dpaa_eth_refill_bpools) from [] > (priv_rx_default_dqrr+0xd8/0x124) [ 264.099313] r7:eb09d000 r6:ebf61650 > r5:ef1e0b44 r4:ef1e15e0 > > The /etc/config/network for bridge mode as below. > config interface 'lan' > option type 'bridge' > option ifname 'eth2 eth6' > option proto 'static' > option ipaddr '192.168.1.1' > option netmask '255.255.255.0' > option ip6assign '60' > > brctl manual config as below. > ifconfig eth2 up > ifconfig eth6 up > brctl addif br-lan eth6 > brctl addif br-lan eth2 > > > > best regards, > Yangbo Lu ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] FW: UDP throughput caused kernel panic if configured bridge mode in /etc/config/network
Hi John, Thank you very much. But I still feel it's strange the crash didn't happen if used brctl to configure instead of /etc/config/network. Much memory(about 700MB) was consumed in UDP throughput test only when used /etc/config/network. As I know, both ls1043a with DPAA ethernet driver and ls1012a with ppfe ethernet driver had this issue. I think maybe I should focus on deep studying in /etc/config/network. But we had a deadline by this month to resolve it. Is there any possibility the issue was caused by OpenWrt? Thanks again. Best regards, Yangbo Lu > -Original Message- > From: John Crispin [mailto:j...@phrozen.org] > Sent: Monday, April 24, 2017 12:31 PM > To: Y.B. Lu; lede-dev@lists.infradead.org; j...@mein.io > Cc: Wes Li; Xiaobo Xie > Subject: Re: [LEDE-DEV] FW: UDP throughput caused kernel panic if > configured bridge mode in /etc/config/network > > Hi, > > this is most certainly a bug in the kernel. either the ethernet driver > blows up under load or some other memory allocation related bug. it is > very common for ethernet to kill boards under load by triggering bugs. > > John > > On 24/04/17 05:49, Y.B. Lu wrote: > > Hi John and Jo-Philipp, > > > > Have you ever got similar problem, or known any possible reason about > > this, or known anyone who probably know this? > > > > I just found much memory would be consumed if I configured board as > > bridge mode in /etc/config/network and did UDP throughput test. > > But using brctl to configure bridge mode didn't consume memory. > > > > Thank you very much. > > > > > > Best regards, > > Yangbo Lu > > > > > >> -Original Message- > >> From: Y.B. Lu > >> Sent: Thursday, April 13, 2017 1:24 PM > >> To: 'lede-dev@lists.infradead.org' > >> Subject: UDP throughput caused kernel panic if configured bridge mode > >> in /etc/config/network > >> > >> Hi all, > >> > >> Recently I got below kernel panic when did UDP throughput test on NXP > >> LS1043ARDB board. I configured the bridge mode in /etc/config/network. > >> But if I used 'brctl' to configure the bridge mode, this issue would > >> not happen. > >> I also noticed almost all memory was consumed(about 700MB) when > >> kernel crashed. > >> Anyone have any idea about this? Thank you very much. > >> > >> root@LEDE:/etc/fmc/config# [ 263.981540] ksoftirqd/3: page > >> allocation > >> failure: order:0, mode:0x2080020 [ 263.988339] CPU: 3 PID: 19 Comm: > >> ksoftirqd/3 Not tainted 4.4.52 #0 [ 263.994508] Hardware name: > >> Freescale LS1043A [ 263.998767] Backtrace: > >> [ 264.001213] [] (dump_backtrace) from [] > >> (show_stack+0x18/0x1c) [ 264.008771] r7: r6: > >> r5:6013 r4: [ 264.014435] [] (show_stack) from > >> [] (dump_stack+0x84/0xa4) [ 264.021652] [] > >> (dump_stack) from [] (warn_alloc_failed+0xf0/0x114) [ > >> 264.029558] r5:02080020 r4: [ 264.033133] [] > >> (warn_alloc_failed) from [] > >> (__alloc_pages_nodemask+0x68c/0x6c0) > >> [ 264.042166] r3: r2: [ 264.045735] r7:0030 > >> r6:02080020 r5: r4:02080020 [ 264.051400] [] > >> (__alloc_pages_nodemask) from [] > >> (_dpa_bp_add_8_bufs+0x40/0x250) [ 264.060434] r10:c001db08 > >> r9:ebc93d48 > >> r8:ebf61650 r7:0003 r6:0004 r5:eb603c10 [ 264.068266] > >> r4:8193f040 [ 264.070796] [] (_dpa_bp_add_8_bufs) from > >> [] (dpaa_eth_refill_bpools+0x28/0x58) > >> [ 264.079742] r10:eb09d480 r9:eb604a74 r8:ef1d9400 r7:eb09d000 > >> r6:ebf61650 r5:ef1e0b44 [ 264.087577] r4:007f [ 264.090106] > >> [] (dpaa_eth_refill_bpools) from [] > >> (priv_rx_default_dqrr+0xd8/0x124) [ 264.099313] r7:eb09d000 > >> r6:ebf61650 > >> r5:ef1e0b44 r4:ef1e15e0 > >> > >> The /etc/config/network for bridge mode as below. > >> config interface 'lan' > >> option type 'bridge' > >> option ifname 'eth2 eth6' > >> option proto 'static' > >> option ipaddr '192.168.1.1' > >> option netmask '255.255.255.0' > >> option ip6assign '60' > >> > >> brctl manual config as below. > >> ifconfig eth2 up > >> ifconfig eth6 up > >> brctl addif br-lan eth6 > >> brctl addif br-lan eth2 > >> > >> > >> > >> best regards, > >> Yangbo Lu > > ___ > > 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] FW: UDP throughput caused kernel panic if configured bridge mode in /etc/config/network
> -Original Message- > From: Yousong Zhou [mailto:yszhou4t...@gmail.com] > Sent: Monday, April 24, 2017 5:15 PM > To: Y.B. Lu > Cc: John Crispin; lede-dev@lists.infradead.org; j...@mein.io; Wes Li; > Xiaobo Xie > Subject: Re: [LEDE-DEV] FW: UDP throughput caused kernel panic if > configured bridge mode in /etc/config/network > > On 24 April 2017 at 15:39, Y.B. Lu wrote: > > Hi John, > > > > Thank you very much. > > > > But I still feel it's strange the crash didn't happen if used brctl to > configure instead of /etc/config/network. > > Much memory(about 700MB) was consumed in UDP throughput test only when > used /etc/config/network. > > > > As I know, both ls1043a with DPAA ethernet driver and ls1012a with ppfe > ethernet driver had this issue. > > I think maybe I should focus on deep studying in /etc/config/network. > But we had a deadline by this month to resolve it. > > > > Is there any possibility the issue was caused by OpenWrt? > > Thanks again. > > > > Most parts of /etc/config/network will be parsed and executed by netifd. > Comparing strace output of both brctl and netifd may reveal something > useful. > > The kernel is supposed to be resilient against whatever ways applications > may use its exposed userspace interface which is driver and device- > agnostic. If the driver fails, there is very likely an issue within the > driver itself. > > yousong [Lu Yangbo-B47093] Hi Yousong, thank you so much for your comments and suggestion. It's now very strange. The driver failed because of there was no enough memory. But this only happened with /etc/config/network bridge configure. Both ls1012a and ls1043a which had different ethernet drivers got this problem. I think your suggestion comparing strace output of both brctl and netifd probably is a good method. We will have a try. Thanks. - Yangbo Lu ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] FW: UDP throughput caused kernel panic if configured bridge mode in /etc/config/network
> -Original Message- > From: Ben Greear [mailto:gree...@candelatech.com] > Sent: Tuesday, April 25, 2017 12:03 AM > To: Y.B. Lu; John Crispin; lede-dev@lists.infradead.org; j...@mein.io > Cc: Wes Li; Xiaobo Xie > Subject: Re: [LEDE-DEV] FW: UDP throughput caused kernel panic if > configured bridge mode in /etc/config/network > > On 04/24/2017 12:39 AM, Y.B. Lu wrote: > > Hi John, > > > > Thank you very much. > > > > But I still feel it's strange the crash didn't happen if used brctl to > configure instead of /etc/config/network. > > Much memory(about 700MB) was consumed in UDP throughput test only when > used /etc/config/network. > > > > As I know, both ls1043a with DPAA ethernet driver and ls1012a with ppfe > ethernet driver had this issue. > > I think maybe I should focus on deep studying in /etc/config/network. > But we had a deadline by this month to resolve it. > > > > Is there any possibility the issue was caused by OpenWrt? > > Thanks again. > > > > > > > > Best regards, > > Yangbo Lu > > > >> -Original Message- > >> From: John Crispin [mailto:j...@phrozen.org] > >> Sent: Monday, April 24, 2017 12:31 PM > >> To: Y.B. Lu; lede-dev@lists.infradead.org; j...@mein.io > >> Cc: Wes Li; Xiaobo Xie > >> Subject: Re: [LEDE-DEV] FW: UDP throughput caused kernel panic if > >> configured bridge mode in /etc/config/network > >> > >> Hi, > >> > >> this is most certainly a bug in the kernel. either the ethernet > >> driver blows up under load or some other memory allocation related > >> bug. it is very common for ethernet to kill boards under load by > triggering bugs. > >> > >> John > >> > >> On 24/04/17 05:49, Y.B. Lu wrote: > >>> Hi John and Jo-Philipp, > >>> > >>> Have you ever got similar problem, or known any possible reason > >>> about this, or known anyone who probably know this? > >>> > >>> I just found much memory would be consumed if I configured board as > >>> bridge mode in /etc/config/network and did UDP throughput test. > >>> But using brctl to configure bridge mode didn't consume memory. > >>> > >>> Thank you very much. > >>> > >>> > >>> Best regards, > >>> Yangbo Lu > >>> > >>> > >>>> -Original Message- > >>>> From: Y.B. Lu > >>>> Sent: Thursday, April 13, 2017 1:24 PM > >>>> To: 'lede-dev@lists.infradead.org' > >>>> Subject: UDP throughput caused kernel panic if configured bridge > >>>> mode in /etc/config/network > >>>> > >>>> Hi all, > >>>> > >>>> Recently I got below kernel panic when did UDP throughput test on > >>>> NXP LS1043ARDB board. I configured the bridge mode in > /etc/config/network. > >>>> But if I used 'brctl' to configure the bridge mode, this issue > >>>> would not happen. > >>>> I also noticed almost all memory was consumed(about 700MB) when > >>>> kernel crashed. > >>>> Anyone have any idea about this? Thank you very much. > >>>> > >>>> root@LEDE:/etc/fmc/config# [ 263.981540] ksoftirqd/3: page > >>>> allocation > >>>> failure: order:0, mode:0x2080020 [ 263.988339] CPU: 3 PID: 19 Comm: > >>>> ksoftirqd/3 Not tainted 4.4.52 #0 [ 263.994508] Hardware name: > > This looks like just a warning...did the system really panic and stop > working? > [Lu Yangbo-B47093] Hi Ben, yes... The system crashed and reboot. It's obvious that memory was consumed so much in the UDP throughput test with /etc/configs/network bridge mode setting. I ran a script to execute 'free' command every 0.5 sec to observe that. > Thanks, > Ben > > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] LEDE layerscape hangs with squash rootfs on QSPI flash
Hi, (Resent the email since HTML format email was rejected by mailing list...) Has anyone seen below issue when LEDE started up. The system would hang when created jffs2 area. This issue occurred on QSPI flash on layerscape like ls1046ardb, but Nor flash worked fine with same rootfs like ls1043ardb. [2.298409] fsl-quadspi 155.quadspi: s25fl512s (65536 Kbytes) [2.304658] 9 cmdlinepart partitions found on MTD device 155.quadspi [2.311674] Creating 9 MTD partitions on "155.quadspi": [2.317676] 0x-0x0010 : "rcw" [2.327552] 0x0010-0x0030 : "u-boot" [2.337822] 0x0030-0x0040 : "u-boot-env" [2.348446] 0x0040-0x0090 : "reserved-1" [2.359001] 0x0090-0x0094 : "fman" [2.369017] 0x0094-0x00f0 : "reserved-2" [2.379597] 0x00f0-0x0100 : "dtb" [2.389523] 0x0100-0x0200 : "kernel" [2.399723] 0x0200-0x0400 : "rootfs" [2.409917] mtd: device 8 (rootfs) set to be root filesystem Actually jffs2 rootfs worked fine on QSPI flash, but we don't know why it failed with LEDE squashfs when create jffs2 area. Any suggestion to find out the root casue? Or any config may casue this issue? Appreciate your help. Best regards, Yangbo Lu ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] LEDE layerscape hangs with squash rootfs on QSPI flash
, entry count 65537 [1.746077] No QMan portals available! [1.750053] No USDPAA memory, no 'fsl,usdpaa-mem' in device-tree [1.756565] Advanced Linux Sound Architecture Driver Initialized. [1.763862] clocksource: Switched to clocksource arch_sys_counter [1.770444] VFS: Disk quotas dquot_6.6.0 [1.774505] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes) [1.781902] pnp: PnP ACPI: disabled [1.797064] NET: Registered protocol family 2 [1.802646] TCP established hash table entries: 8192 (order: 4, 65536 bytes) [1.810019] TCP bind hash table entries: 8192 (order: 5, 131072 bytes) [1.816870] TCP: Hash tables configured (established 8192 bind 8192) [1.823429] UDP hash table entries: 512 (order: 2, 16384 bytes) [1.829454] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes) [1.836051] NET: Registered protocol family 1 [1.840893] kvm [1]: 8-bit VMID [1.844101] kvm [1]: IDMAP page: 80ac2000 [1.848163] kvm [1]: HYP VA range: 8000: [1.854651] kvm [1]: Hyp mode initialized successfully [1.859876] kvm [1]: vgic-v2@1404000 [1.863523] kvm [1]: vgic interrupt IRQ1 [1.867494] kvm [1]: virtual timer IRQ4 [1.873364] audit: initializing netlink subsys (disabled) [1.879471] audit: type=2000 audit(1.764:1): initialized [1.884942] No memory allocated for crashlog [1.893594] workingset: timestamp_bits=44 max_order=18 bucket_order=0 [1.900661] squashfs: version 4.0 (2009/01/31) Phillip Lougher [1.906576] jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc. [1.916765] fuse init (API version 7.26) [1.920982] SGI XFS with security attributes, realtime, no debug enabled [1.943007] async_tx: api initialized (async) [1.947676] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 248) [1.959352] io scheduler noop registered [1.963406] io scheduler cfq registered (default) [1.969733] OF: PCI: host bridge /soc/pcie@340 ranges: [1.975920] OF: PCI:IO 0x41..0x41 -> 0x [1.982278] OF: PCI: MEM 0x404000..0x407fff -> 0x4000 [1.989037] layerscape-pcie 340.pcie: PCI host bridge to bus :00 [1.995939] pci_bus :00: root bus resource [bus 00-ff] [2.001498] pci_bus :00: root bus resource [io 0x-0x] [2.007758] pci_bus :00: root bus resource [mem 0x404000-0x407fff] (bus address [0x4000-0x7fff]) [2.018947] pci :00:00.0: BAR 6: assigned [mem 0x404000-0x4047ff pref] [2.026724] pci :00:00.0: PCI bridge to [bus 01] [2.032124] pcieport :00:00.0: Signaling PME through PCIe PME interrupt [2.041299] Freescale LS2 console driver [2.046047] fsl-ls2-console: device fsl_mc_console registered [2.052096] fsl-ls2-console: device fsl_aiop_console registered [2.058442] ftm-alarm 29d.ftm0: can't request region for resource [mem 0x01ee2140-0x01ee2143] [2.067460] ftm-alarm: probe of 29d.ftm0 failed with error -16 [2.074155] xenfs: not registering filesystem on non-xen platform [2.085584] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled [2.093854] console [ttyS0] disabled [2.098249] 21c0500.serial: ttyS0 at MMIO 0x21c0500 (irq = 15, base_baud = 7812500) is a 16550A [2.107200] console [ttyS0] enabled [2.107200] console [ttyS0] enabled [2.114300] bootconsole [uart8250] disabled [2.114300] bootconsole [uart8250] disabled [2.123746] Unable to detect cache hierarchy from DT for CPU 0 [2.205009] brd: module loaded [2.247051] loop: module loaded [2.251283] hisi_sas: driver version v1.6 [2.261239] ahci-qoriq 320.sata: AHCI 0001.0301 32 slots 1 ports 6 Gbps 0x1 impl platform mode [2.270608] ahci-qoriq 320.sata: flags: 64bit ncq sntf pm clo only pmp fbs pio slum part ccc sds apst [2.285436] scsi host0: ahci-qoriq [2.289339] ata1: SATA max UDMA/133 mmio [mem 0x0320-0x0320] port 0x100 irq 23 [2.298409] fsl-quadspi 155.quadspi: s25fl512s (65536 Kbytes) [2.304658] 9 cmdlinepart partitions found on MTD device 155.quadspi [2.311674] Creating 9 MTD partitions on "155.quadspi": [2.317676] 0x-0x0010 : "rcw" [2.327552] 0x0010-0x0030 : "u-boot" [2.337822] 0x0030-0x0040 : "u-boot-env" [2.348446] 0x0040-0x0090 : "reserved-1" [2.359001] 0x0090-0x0094 : "fman" [2.369017] 0x0094-0x00f0 : "reserved-2" [2.379597] 0x00f0-0x0100 : "dtb" [2.389523] 0x0100-0x0200 : "kernel" [2.399723] 0x0200-0x0400 : "rootfs" [2.409917] mtd: device 8 (rootfs) set to be root filesystem Best regards, Yangbo Lu &g
Re: [LEDE-DEV] layerscape build bot problem
Hi Hauke, I couldn’t open most links. But I think I got your point. I also find build issues of layerscape today. Let me generate patches to fix them next week. Thanks a lot. Best regards, Yangbo Lu > -Original Message- > From: Hauke Mehrtens [mailto:ha...@hauke-m.de] > Sent: 2017年12月21日 18:22 > To: Y.b. Lu > Cc: lede-dev@lists.infradead.org > Subject: layerscape build bot problem > > Hi Yangbo Lu, > > We see some build problem for the layerscape target sine some months: > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fphase > 1.builds.lede-project.org%2Fbuilders%2Flayerscape%252Farmv8_32b&data=0 > 2%7C01%7Cyangbo.lu%40nxp.com%7Ceb2522ea584447b310ca08d5485cc32a > %7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C636494485609185 > 958&sdata=3S9oSrldb06QIkSFw%2FwMeS3QBDGQ7ZGeFH91Xit5Xls%3D&rese > rved=0 > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fphase > 1.builds.lede-project.org%2Fbuilders%2Flayerscape%252Farmv8_64b&data=0 > 2%7C01%7Cyangbo.lu%40nxp.com%7Ceb2522ea584447b310ca08d5485cc32a > %7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C636494485609185 > 958&sdata=gdnYB5NVhEkWsgCVFjbYXjgo%2B%2BLQ6HC0f0DORDwPucc%3D& > reserved=0 > > I think I fixed one problem with the tar downloads here, see: > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.le > de-project.org%2Fe03eea8750095b9f733d2637fe70ba362478c12&data=02% > 7C01%7Cyangbo.lu%40nxp.com%7Ceb2522ea584447b310ca08d5485cc32a%7 > C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C636494485609185958 > &sdata=5X4%2BFe1oXhxJd6Z2oR1a9EyKMDzNhTsYnBRVWMcFQMs%3D&reser > ved=0 > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.le > de-project.org%2Fdda2229c52c78d177a417e261d3dd912f65101fe&data=02 > %7C01%7Cyangbo.lu%40nxp.com%7Ceb2522ea584447b310ca08d5485cc32a > %7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C636494485609185 > 958&sdata=0CyyxAelics4RvVkW0TSlb0LHSa3OJ0TmgPUWyiZ%2B8g%3D&reser > ved=0 > > One problem still exists, it seams to be that some build bots do not have > tclsh, > see this: > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fphase > 1.builds.lede-project.org%2Fbuilders%2Flayerscape%252Farmv8_32b%2Fbuild > s%2F122%2Fsteps%2Fimages%2Flogs%2Fstdio&data=02%7C01%7Cyangbo.lu > %40nxp.com%7Ceb2522ea584447b310ca08d5485cc32a%7C686ea1d3bc2b4c > 6fa92cd99c5c301635%7C0%7C1%7C636494485609185958&sdata=XkTYndG3 > Ujx2T%2BXqyedpC%2BK9a4wJG%2FMlfvNLZIMq6eg%3D&reserved=0 > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fphase > 1.builds.lede-project.org%2Fbuilders%2Flayerscape%252Farmv8_32b%2Fbuild > s%2F122%2Fsteps%2Fpkgbuild%2Flogs%2Fstdio&data=02%7C01%7Cyangbo.l > u%40nxp.com%7Ceb2522ea584447b310ca08d5485cc32a%7C686ea1d3bc2b4 > c6fa92cd99c5c301635%7C0%7C1%7C636494485609185958&sdata=btHCbPH > 4F9djUHQYYmQdd%2BHc73xN5M%2FsjYL8jngkizI%3D&reserved=0 > > > They have this problem: > > make[4]: Leaving directory > '/home/buildbot/slave-lede-local/layerscape_armv8_32b/build/build_dir/targ > et-arm_cortex-a15+neon-vfpv4_musl_eabi/ls-rcw-2017-09-26-6719b046-ls10 > 43ardb/ls-rcw-2017-09-26-6719b046/t1042d4rdb' > tclsh ./tools/byte_swap.tcl > ls1046ardb/RR_FFSSPPPH_1133_5559/rcw_1800_qspiboot.bin \ > ls1046ardb/RR_FFSSPPPH_1133_5559/rcw_1800_qspiboot_swap.bin 8 > make[3]: tclsh: Command not found > Makefile:11: recipe for target 'all' failed > make[3]: *** [all] Error 127 > > > Is it possible to make this build without the need of tclsh? > > Hauke ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] layerscape build bot problem
Hi Hauke, Created the pull request. Please help to review. https://github.com/lede-project/source/pull/1604 Thank you very much. Best regards, Yangbo Lu > -Original Message- > From: Y.b. Lu > Sent: 2017年12月22日 18:05 > To: 'Hauke Mehrtens' > Cc: lede-dev@lists.infradead.org > Subject: RE: layerscape build bot problem > > Hi Hauke, > > I couldn’t open most links. But I think I got your point. > I also find build issues of layerscape today. Let me generate patches to fix > them > next week. > > Thanks a lot. > > > Best regards, > Yangbo Lu > > > -Original Message- > > From: Hauke Mehrtens [mailto:ha...@hauke-m.de] > > Sent: 2017年12月21日 18:22 > > To: Y.b. Lu > > Cc: lede-dev@lists.infradead.org > > Subject: layerscape build bot problem > > > > Hi Yangbo Lu, > > > > We see some build problem for the layerscape target sine some months: > > > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fphas > > e > > > 1.builds.lede-project.org%2Fbuilders%2Flayerscape%252Farmv8_32b&data=0 > > > 2%7C01%7Cyangbo.lu%40nxp.com%7Ceb2522ea584447b310ca08d5485cc32a > > %7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C63649448560918 > 5 > > > 958&sdata=3S9oSrldb06QIkSFw%2FwMeS3QBDGQ7ZGeFH91Xit5Xls%3D&rese > > rved=0 > > > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fphas > > e > > > 1.builds.lede-project.org%2Fbuilders%2Flayerscape%252Farmv8_64b&data=0 > > > 2%7C01%7Cyangbo.lu%40nxp.com%7Ceb2522ea584447b310ca08d5485cc32a > > %7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C63649448560918 > 5 > > > 958&sdata=gdnYB5NVhEkWsgCVFjbYXjgo%2B%2BLQ6HC0f0DORDwPucc%3D& > > reserved=0 > > > > I think I fixed one problem with the tar downloads here, see: > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit > > .le > de-project.org%2Fe03eea8750095b9f733d2637fe70ba362478c12&data=02% > > > 7C01%7Cyangbo.lu%40nxp.com%7Ceb2522ea584447b310ca08d5485cc32a%7 > > > C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C636494485609185958 > > > &sdata=5X4%2BFe1oXhxJd6Z2oR1a9EyKMDzNhTsYnBRVWMcFQMs%3D&reser > > ved=0 > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit > > .le > > > de-project.org%2Fdda2229c52c78d177a417e261d3dd912f65101fe&data=02 > > %7C01%7Cyangbo.lu%40nxp.com%7Ceb2522ea584447b310ca08d5485cc32 > a > > %7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C63649448560918 > 5 > > > 958&sdata=0CyyxAelics4RvVkW0TSlb0LHSa3OJ0TmgPUWyiZ%2B8g%3D&reser > > ved=0 > > > > One problem still exists, it seams to be that some build bots do not > > have tclsh, see this: > > > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fphas > > e > > 1.builds.lede-project.org%2Fbuilders%2Flayerscape%252Farmv8_32b%2Fbuil > > d > s%2F122%2Fsteps%2Fimages%2Flogs%2Fstdio&data=02%7C01%7Cyangbo.lu > > %40nxp.com%7Ceb2522ea584447b310ca08d5485cc32a%7C686ea1d3bc2b4 > c > > > 6fa92cd99c5c301635%7C0%7C1%7C636494485609185958&sdata=XkTYndG3 > > Ujx2T%2BXqyedpC%2BK9a4wJG%2FMlfvNLZIMq6eg%3D&reserved=0 > > > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fphas > > e > > 1.builds.lede-project.org%2Fbuilders%2Flayerscape%252Farmv8_32b%2Fbuil > > d > s%2F122%2Fsteps%2Fpkgbuild%2Flogs%2Fstdio&data=02%7C01%7Cyangbo.l > > > u%40nxp.com%7Ceb2522ea584447b310ca08d5485cc32a%7C686ea1d3bc2b4 > > > c6fa92cd99c5c301635%7C0%7C1%7C636494485609185958&sdata=btHCbPH > > 4F9djUHQYYmQdd%2BHc73xN5M%2FsjYL8jngkizI%3D&reserved=0 > > > > > > They have this problem: > > > > make[4]: Leaving directory > > '/home/buildbot/slave-lede-local/layerscape_armv8_32b/build/build_dir/ > > targ > > > et-arm_cortex-a15+neon-vfpv4_musl_eabi/ls-rcw-2017-09-26-6719b046-ls10 > > 43ardb/ls-rcw-2017-09-26-6719b046/t1042d4rdb' > > tclsh ./tools/byte_swap.tcl > > ls1046ardb/RR_FFSSPPPH_1133_5559/rcw_1800_qspiboot.bin \ > > ls1046ardb/RR_FFSSPPPH_1133_5559/rcw_1800_qspiboot_swap.bin 8 > > make[3]: tclsh: Command not found > > Makefile:11: recipe for target 'all' failed > > make[3]: *** [all] Error 127 > > > > > > Is it possible to make this build without the need of tclsh? > > > > Hauke ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] layerscape: activate fpu feature
Hi Hauke, The layerscape maintainer info should be no problem. You just sent wrong email address to me. (cyangbo...@nxp.com) MAINTAINER:=Yangbo Lu I will cherry-pick this patch to our internal LEDE git tree. Test team will test all devices, and we will have a release on our github by end of January. https://github.com/qoriq-open-source/LEDE-source I will send related patches to community after release. Thanks a lot. Best regards, Yangbo Lu > -Original Message- > From: Hauke Mehrtens [mailto:ha...@hauke-m.de] > Sent: 2018年1月2日 0:04 > To: lede-dev@lists.infradead.org; Y.b. Lu > Subject: Re: [PATCH] layerscape: activate fpu feature > > Hi Yangbo Lu, > > Can you please test this patch on your hardware. > > > I send a mail to yangbo...@nxp.com who is listed as the current layerscape > maintainer, but it was rejected by your mail server: > > : host > nxp-com.mail.protection.outlook.com[213.199.154.170] said: 550 5.4.1 > [cyangbo...@nxp.com]: Recipient address rejected: Access denied > [DB5EUR01FT058.eop-EUR01.prod.protection.outlook.com] (in reply to RCPT > TO command) > > Are you the current maintainer? If so can you please send a patch to fix this > please. > > Hauke > > > On 01/01/2018 04:58 PM, Hauke Mehrtens wrote: > > The CPU sub type was set to a CPU version with FPU, but the FPU > > feature was not activated before, so a soft float toolchain was created. > > Activate also the FPU feature to create the correct toolchain. > > > > Signed-off-by: Hauke Mehrtens > > --- > > > > This probably fixes a problem, but I do not have any layerscape > > hardware, could someone please test this on real hardware and report > > back if it still works. > > > > A complete rebuild incl. toolchain is needed. > > > > target/linux/layerscape/Makefile | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/target/linux/layerscape/Makefile > > b/target/linux/layerscape/Makefile > > index 67da8449aa..bd91556ef4 100644 > > --- a/target/linux/layerscape/Makefile > > +++ b/target/linux/layerscape/Makefile > > @@ -10,7 +10,7 @@ BOARD:=layerscape > > BOARDNAME:=NXP Layerscape > > DEVICE_TYPE:=developerboard > > KERNEL_PATCHVER:=4.9 > > -FEATURES:=squashfs nand usb pcie gpio > > +FEATURES:=squashfs nand usb pcie gpio fpu > > SUBTARGETS:=armv8_64b armv8_32b > > MAINTAINER:=Yangbo Lu > > > > ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] layerscape: activate fpu feature
Hi Hauke, > -Original Message- > From: Hauke Mehrtens [mailto:ha...@hauke-m.de] > Sent: 2018年1月4日 4:47 > To: Y.b. Lu ; lede-dev@lists.infradead.org > Subject: Re: [PATCH] layerscape: activate fpu feature > > On 01/03/2018 04:21 AM, Y.b. Lu wrote: > > Hi Hauke, > > > > The layerscape maintainer info should be no problem. You just sent > > wrong email address to me. (cyangbo...@nxp.com) MAINTAINER:=Yangbo Lu > > > > Will you send a patch to update the Maintainer? [Y.b. Lu] I meant the maintainer was correct. You just sent email with wrong address :) > > > I will cherry-pick this patch to our internal LEDE git tree. Test team will > > test all > devices, and we will have a release on our github by end of January. > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit > > > hub.com%2Fqoriq-open-source%2FLEDE-source&data=02%7C01%7Cyangbo.lu > %40n > > > xp.com%7Ce1ecb397ca55445aaea408d552eb1e83%7C686ea1d3bc2b4c6fa92c > d99c5c > > > 301635%7C0%7C1%7C636506092143122970&sdata=7ZtgG18hvx24ocAc6iIn > 86j9P1hk > > HCksRkbOoQQnJnk%3D&reserved=0 > > John already merged this patch, see here: > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.le > de-project.org%2F%3Fp%3Dopenwrt%2Fopenwrt.git%3Ba%3Dcommitdiff%3Bh > %3D597de6904c39e02a8aa008f50ff19c6793117194&data=02%7C01%7Cyang > bo.lu%40nxp.com%7Ce1ecb397ca55445aaea408d552eb1e83%7C686ea1d3bc > 2b4c6fa92cd99c5c301635%7C0%7C1%7C636506092143122970&sdata=W3D > 0mjILpqw6yQwa%2FOd3xGbj%2BsA7GLMeVv3fJ1wvbEI%3D&reserved=0 > > Mathew McBride also tested this on his LS1043 board and did not notice any > problems. [Y.b. Lu] That's great. I will use the latest source code for our next release and will test all boards. > > Hauke > > > > > I will send related patches to community after release. > > Thanks a lot. > > > > > > Best regards, > > Yangbo Lu > > > > > >> -Original Message- > >> From: Hauke Mehrtens [mailto:ha...@hauke-m.de] > >> Sent: 2018年1月2日 0:04 > >> To: lede-dev@lists.infradead.org; Y.b. Lu > >> Subject: Re: [PATCH] layerscape: activate fpu feature > >> > >> Hi Yangbo Lu, > >> > >> Can you please test this patch on your hardware. > >> > >> > >> I send a mail to yangbo...@nxp.com who is listed as the current > >> layerscape maintainer, but it was rejected by your mail server: > >> > >> : host > >> nxp-com.mail.protection.outlook.com[213.199.154.170] said: 550 5.4.1 > >> [cyangbo...@nxp.com]: Recipient address rejected: Access denied > >> [DB5EUR01FT058.eop-EUR01.prod.protection.outlook.com] (in reply to > >> RCPT TO command) > >> > >> Are you the current maintainer? If so can you please send a patch to > >> fix this please. > >> > >> Hauke > >> > >> > >> On 01/01/2018 04:58 PM, Hauke Mehrtens wrote: > >>> The CPU sub type was set to a CPU version with FPU, but the FPU > >>> feature was not activated before, so a soft float toolchain was created. > >>> Activate also the FPU feature to create the correct toolchain. > >>> > >>> Signed-off-by: Hauke Mehrtens > >>> --- > >>> > >>> This probably fixes a problem, but I do not have any layerscape > >>> hardware, could someone please test this on real hardware and report > >>> back if it still works. > >>> > >>> A complete rebuild incl. toolchain is needed. > >>> > >>> target/linux/layerscape/Makefile | 2 +- > >>> 1 file changed, 1 insertion(+), 1 deletion(-) > >>> > >>> diff --git a/target/linux/layerscape/Makefile > >>> b/target/linux/layerscape/Makefile > >>> index 67da8449aa..bd91556ef4 100644 > >>> --- a/target/linux/layerscape/Makefile > >>> +++ b/target/linux/layerscape/Makefile > >>> @@ -10,7 +10,7 @@ BOARD:=layerscape > >>> BOARDNAME:=NXP Layerscape > >>> DEVICE_TYPE:=developerboard > >>> KERNEL_PATCHVER:=4.9 > >>> -FEATURES:=squashfs nand usb pcie gpio > >>> +FEATURES:=squashfs nand usb pcie gpio fpu > >>> SUBTARGETS:=armv8_64b armv8_32b > >>> MAINTAINER:=Yangbo Lu > >>> > >>> > > ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Layerscape package depending on libxml2
Hi John and Hauke, May I have your suggestion about an old problem? The pull request was merged leaving out fmc package. https://github.com/openwrt/openwrt/pull/724 I'd like to add this package fmc (frame manager configuration) for layerscape. However it depends on libxml2 package which is not in the base feed. Must install feeds to enable and build it. So I think I need some suggestion to find out a proper way to add this package. Thanks a lot. Best regards, Yangbo Lu ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Layerscape package depending on libxml2
Hi Michael, > -Original Message- > From: Michael Heimpold [mailto:m...@heimpold.de] > Sent: Wednesday, May 9, 2018 2:41 AM > To: lede-dev@lists.infradead.org; Xiaobo Xie > Cc: Y.b. Lu ; openwrt-de...@lists.openwrt.org; Hauke > Mehrtens ; John Crispin > Subject: Re: [LEDE-DEV] Layerscape package depending on libxml2 > > Hi, > > the mentioned PR included a few new packages. I don't know the layerscape > platform, so I just want to understand it: these packages are all necessary to > boot a "reasonable" > system? And this is true for fmc, too? [Y.b. Lu] fmc is an important userspace tool for layerscape which is frequently used and required by our key customers. Fmc build and usage depends on several packages. They are tclap, fmlib, and eth-config which I added in the PR. Both fmlib and eth-config are only for layerscape. > > Then one option would be to move libxml2 to "core openwrt". > > If not, it would be an alternative approach to move the not really important > packages to packages feed, and add the fmc package in the packages feed as > well. This way, the dependency to libxml2 is solved automatically and the > "core openwrt" stays as small as reasonable. > > Or should we avoid packages in the package feed which have a strong > platform dependency? [Y.b. Lu] Thanks a lot for your good suggestion. Actually I tend to move libxml2 to core openwrt. > > Just a few thoughts of mine, > Michael > > Am Dienstag, 8. Mai 2018, 08:44:27 CEST schrieb Y.b. Lu: > > Hi John and Hauke, > > > > May I have your suggestion about an old problem? The pull request was > merged leaving out fmc package. > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit > > > hub.com%2Fopenwrt%2Fopenwrt%2Fpull%2F724&data=02%7C01%7Cyangbo > .lu%40nx > > > p.com%7C5af09f423eb34c8479c508d5b5133b9d%7C686ea1d3bc2b4c6fa92c > d99c5c3 > > > 01635%7C0%7C1%7C636614016566713359&sdata=N2jlxMw2erh3uIjx1T%2F > nWfvWZBe > > Zjsz7ioGMDsbNP%2BE%3D&reserved=0 > > > > I'd like to add this package fmc (frame manager configuration) for > layerscape. > > However it depends on libxml2 package which is not in the base feed. Must > install feeds to enable and build it. > > So I think I need some suggestion to find out a proper way to add this > package. > > > > Thanks a lot. > > > > Best regards, > > Yangbo Lu > > > > ___ > > Lede-dev mailing list > > Lede-dev@lists.infradead.org > > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist > > > s.infradead.org%2Fmailman%2Flistinfo%2Flede-dev&data=02%7C01%7Cyangb > o. > > > lu%40nxp.com%7C5af09f423eb34c8479c508d5b5133b9d%7C686ea1d3bc2b > 4c6fa92cd99c5c301635%7C0%7C1%7C636614016566713359&sdata=BDODn > CrzqggSQgIx7%2B3y6zIFRb23T01nVATTSyKI3HU%3D&reserved=0 > > > ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Layerscape package depending on libxml2
Hi Micheal, > -Original Message- > From: Michael Heimpold [mailto:m...@heimpold.de] > Sent: Wednesday, May 9, 2018 6:29 PM > To: Y.b. Lu > Cc: lede-dev@lists.infradead.org; Xiaobo Xie ; > openwrt-de...@lists.openwrt.org; Hauke Mehrtens ; > John Crispin > Subject: Re: [LEDE-DEV] Layerscape package depending on libxml2 > > Hi, > > >> the mentioned PR included a few new packages. I don't know the > >> layerscape platform, so I just want to understand it: these packages > >> are all necessary to boot a "reasonable" > >> system? And this is true for fmc, too? > > > > [Y.b. Lu] fmc is an important userspace tool for layerscape which is > > frequently used and required by our key customers. > > my point is more whether it is absolutely not possible to boot up a layerscape > system without these tools/packages? [Y.b. Lu] It's just an user space tool. It isn’t required for booting up. > > Or to bring a somewhat constructed use-case: PHP7 is frequently used and > required by most of my customers - however, this does not justify to move > PHP7 to core openwrt. [Y.b. Lu] Understand. Either Core openwrt or feed is ok for me as long as there is a place to put it 😊 > > Don't get me wrong, I'm not a core developer and this are just a few > thoughts... [Y.b. Lu] Thank you all the same for your help. > > Michael > > > > Fmc build and usage depends on several packages. They are tclap, > > fmlib, and eth-config which I added in the PR. Both fmlib and > > eth-config are only for layerscape. > > > >> > >> Then one option would be to move libxml2 to "core openwrt". > >> > >> If not, it would be an alternative approach to move the not really > >> important packages to packages feed, and add the fmc package in the > >> packages feed as well. This way, the dependency to libxml2 is solved > >> automatically and the "core openwrt" stays as small as reasonable. > >> > >> Or should we avoid packages in the package feed which have a strong > >> platform dependency? > > > > [Y.b. Lu] Thanks a lot for your good suggestion. Actually I tend to > > move libxml2 to core openwrt. > > > ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
