Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reboot command sometimes causes eth0 to cycle between up & down #37

Closed
DuncanFrazer-zz opened this issue Oct 21, 2016 · 8 comments
Closed

Comments

@DuncanFrazer-zz
Copy link

DuncanFrazer-zz commented Oct 21, 2016

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.

@DuncanFrazer-zz
Copy link
Author

Needs to be assigned to Yi Laing

@yi-liang
Copy link

yi-liang commented Nov 8, 2016

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

@mtusnio
Copy link
Member

mtusnio commented Nov 21, 2016

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.

@Ham22
Copy link
Member

Ham22 commented Nov 29, 2016

@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.

@nikhil-zinjurde-imgtec
Copy link

@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.

@Shpinkso
Copy link

Shpinkso commented Dec 2, 2016

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.

@nikhil-zinjurde-imgtec
Copy link

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.

@nikhil-zinjurde-imgtec
Copy link

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

@nikhil-zinjurde-imgtec nikhil-zinjurde-imgtec removed their assignment Dec 8, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants