Closed DuncanFrazer-zz closed 7 years ago
Needs to be assigned to Yi Laing
adding error info in the log, but in this case, unplug the eth cable + power reset the board can stop the problem (we thought only flash the board again can fix it)
[ 62.226397] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 64.210323] stmmaceth 18140000.ethernet eth0: Link is Up - 10Mbps/Full - flow control rx/tx [ 64.219862] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 64.475520] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 66.044632] ca8210 spi0.0: ca8210 was busy during attempted write [ 66.070185] ca8210 spi0.0: spi write retry 1... [ 66.090497] ca8210 spi0.0: ca8210 was busy during attempted write [ 66.110129] ca8210 spi0.0: spi write retry 1... [ 66.130299] ca8210 spi0.0: spi read failed, returned -50 [ 66.136735] ca8210 spi0.0: ca8210 was busy during attempted write [ 66.160140] ca8210 spi0.0: spi write retry 1... [ 66.450360] stmmaceth 18140000.ethernet eth0: Link is Up - 10Mbps/Full - flow control rx/tx [ 66.459897] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 66.714961] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 67.016167] ca8210 spi0.0: ca8210 was busy during attempted write [ 67.040153] ca8210 spi0.0: spi write retry 1... [ 68.050139] ca8210 spi0.0: Synchronous confirm timeout [ 68.055891] ca8210 spi0.0: error setting max be, MLME-SET.confirm status = 255 [ 68.690276] stmmaceth 18140000.ethernet eth0: Link is Up - 10Mbps/Full - flow control rx/tx [ 68.699819] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 68.926325] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 70.910309] stmmaceth 18140000.ethernet eth0: Link is Up - 10Mbps/Full - flow control rx/tx [ 70.919770] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
From my experience usually this is preceded by a failure to get a lock file set up when running fw_printenv. If you reboot the board to see if that fixes the problem with getting variables from the bootloader I've noticed that every time I get the eth0 link cycling error after the subsequent boot.
@nikhil-zinjurde-imgtec can we run a soak that confirms if this is the cascoda driver. Just remove the lowpan/cascoda init scripts so that the module is never loaded.
@Ham22 The soak test has not shown the up-down cycle issue, even on the TI board, after removing cascoda kmod package and the lowpan init script.
Aim of this ticket now is to retest with latest cascoda driver and ensure we have some more detailed information on where the issue is caused. If we're confident it is cascoda driver related, then raise a ticket with them.
Preliminary tests show that with the latest version of OpenWrt v0.10.6 and U-boot v1.0.2, the problem is no longer seen on both ca8210 and cc2520 based boards.
Repeated tests show that this issue is no longer seen or reproducible with the CreatorDev/OpenWrt v0.10.6 and CreatorDev/u-boot v1.0.2. So, closing this now
Sometimes when booting the networking settings take about 2 minutes to load. During that time the system makes multiple attempts at enabling both ethernet and wifi shown by proddata and uccp debug messages in the logs e.g: img/uccp420wlan/MCP_LOADER.ldr is loaded img/uccp420wlan/MAC_LOADER.ldr is loaded Initialising Proddata Deinitialising Proddata Deinitialising DeviceData Deinitialising UserOTPAccess
Eventually it brings up eth and wlan only (i.e. no lowpan), however seems to continuously switch between up & down states forever if an ethernet cable is plugged in.