BeagleBone Black: Ethernet transmits packets but does not receive them

Ok, more info:

If I plug into the 10/100/1000 Base-T port on the router, I can repeatedly hot-plug. The bold info below just shows how I have it connected. I get messages like:

BBB - GigE on router

[ 2605.699821] libphy: 4a101000.mdio:00 - Link is Down
[ 2606.517224] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 2615.266472] libphy: 4a101000.mdio:00 - Link is Up - 100/Full
[ 2615.266599] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

I tried next inserting a 10 Base-T hub into the link, again it reconnects as follows (yellow LED off as expected since not 100 connection):

BBB - 10 Base-T hub - GigE on router
[ 2534.629535] libphy: 4a101000.mdio:00 - Link is Down
[ 2534.743363] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 2547.407123] libphy: 4a101000.mdio:00 - Link is Up - 10/Half
[ 2547.407247] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

So, plugging instead in to one of the 100 Base-T ports on the router, it never reconnects - I get:

BBB - 100 Base-T on router
[ 2671.551383] libphy: 4a101000.mdio:00 - Link is Down
[ 2671.657297] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

BUT - if while in that mode, I insert the 10 Base-T hub in the link, it will reconnect - I get:

BBB - 10 Base-T hub - 100 Base-T on router
[ 2761.391537] libphy: 4a101000.mdio:00 - Link is Up - 10/Half
[ 2761.391662] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

So I know that it can connect to the 100 Base-T port on the router if I put a 10 Base-T hub in the way. I am just unsure what that means…

Going back to basics, if I boot while connected to the 100 Base-T port on the router, dmesg shows that it can connect to that port:

BBB - 100 Base-T on router
From boot with LAN connected
[ 23.445684] net eth0: initializing cpsw version 1.12 (0)
[ 23.447890] net eth0: phy found : id is : 0x7c0f1
[ 23.447909] libphy: PHY 4a101000.mdio:01 not found
[ 23.452960] net eth0: phy 4a101000.mdio:01 not found on slave 1
[ 23.481040] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 27.594331] libphy: 4a101000.mdio:00 - Link is Up - 100/Full
[ 27.594395] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

But after boot, if I unplug it, I get:

[ 340.879107] libphy: 4a101000.mdio:00 - Link is Down
[ 340.932015] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

And it will never reconnect however many times I hot-plug it.

BUT - if I plug it back in to the same router port but via the 10 Base-T hub, it reconnects:

[ 367.570844] libphy: 4a101000.mdio:00 - Link is Up - 10/Half
[ 367.570899] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

Does any of that give anyone a clue?

I am going to update the guys at the Beagle Hospital with this info too.

Based on my testing above, it seems likely that this is a software problem related to the control of the PHY. Since the problem appears in both the Angstrom release and the Ubuntu release, it seems likely to me at least that the problem lies in the TI CPSW driver code. I don’t know how I might progress this further at this time though so probably have to just live with it…

Can anyone else above who has seen this problem try a similar experiment to mine and see if their problem is also “cured” by inserting a 10 Base-T hub in the path?

Yeah, I think something’s definitely up with the driver. I have it plugged into a gigabit switch and router. It works fine, but I had to RMA one board. They found a short in the Ethernet chip.

-Tom

I have also seen this on BBW. I have also been unable to ping from U-Boot on occasions. Once the PHY chip gets into this state, no software can talk to it, so only a hard reset works. Gerald Coley has some good suggestions, but I have yet to pin it down. Please see the thread:

"BBB and BBW Ethernet problems" for details.

HTH

Dave.

You know something is wrong because when you do ifconfig eth0 down then up it never comes back up!

-Tom

Tom, the Beagle Hospital guys tell that this particular problem (ifconfig eth0 down etc) - “is a known issue for ifconfig that has been addressed”. They didn’t say how that had been addressed but I am guessing something is in the pipeline somewhere. I think it is a different problem though to the one here which seems on the surface to be related to connections on 100 Base-T ports…

Dave, I had previously read through your topic and while it does sound similar, I am not convinced it is the same. You indicate that the PHY has hung and cannot be cleared. In my recent post here, I have demonstrated that while I cannot connect directly to the 100 Base-T port, if I put a 10 Base-T hub in the line that I can connect again - i.e. the PHY had not hung, it was simply not able to connect for some unknown reason.

I agree there most probably are two problems. I think the symptoms are so similar, it is easy to cross-post :wink:

Hi eskimobob.

Can you ask the hospital guys how the issue has been addressed more specifically?

On the topic, I can echo similar issues. First, after I bring the interface up for the first time, I have to wait ~12s before the BBB can accept a DHCP OFFER. Bringing the interface up seems to intialize the PHY:
[ 6.113545] net eth0: initializing cpsw version 1.12 (0) |
[ 6.115769] net eth0: phy found : id is : 0x7c0f1
after which (after the delay) I can use ifup to connect. Using connman to bring up the interface gets a 169.x address initially, but by resetting the ipv4 method to dhcp I can have get an IP address, so I see a similar effect of the board not receiving DHCP OFFER.

Second I cannot reconnect after using ifdown to bring the interface down. However if I unplug and replug the cable while using connman, connman goes through the same status as startup on plugin - if I tell it to check dhcp again, it will connect.

I’m currently using the CLOUD9 GNOME Image 2013.05.20, fully upgraded through opkg, but I will try to test a later image tomorrow and see if the issue is fixed as the hospital guys say.

I suspect that in that instance they replaced a faulty PHY device. A bad part on the board. That is all they do. Replace bad parts.

I would however in your case, upgrade to a newer image.

If you think the board i s bad, request an RMA.

Gerald

Hi Gerald,
I have had problems with the SMSC LAN8710 auto MDI-X feature is buggy and would cause LAN connectivity problems similar to the ones noted above. For me disabling the auto MDI-X (feature!) solved these problems (see http://www.spinics.net/lists/netdev/msg218399.html for a patch for this problem).

Note that any patch has to make sure that auto-mdix disable bit is SET, this bit needs to be updated after soft/hard reset to the PHY cause the bit gets cleared.

Hope this helps
Hussein

OK. You will need to push the patch.

Gerald

Gerald, how can you tell on this forum, that everything is working fine?

At this moment, i have on the table different linux devices… BeagleBone black(4 pieces, different revisions), acme aria g25(4 pieces).
In aria g25 is similiar phy smsc lan8720, in beaglebone is lan8710. BOTH of this devices have problem, when there is device not supporting auto MDI/MDIX on the other side… So as Hussein said, it is software bug in smsc lan phy linux kernel module.

Symptoms:

  1. when there is no ethernet cable plugged in during boot, it is not possible to bring the link up after plugging the cable after boot.
  2. when you start ping - almost with fixed IP, pull out the ethernet cable, and plug it back within 5 seconds, everything is ok…
  3. when you start ping - almost with fixed IP, pull out the ethernet cable, and plug it back after 5 sedonds, the link will remain down…

So, i downloaded kernel source 3.11, used this patch: http://www.spinics.net/lists/netdev/msg218399.html
Instaled this kernel both to acme aria G25s, and BeagleBone blacks, every board works perfect!

Dňa štvrtok, 12. septembra 2013 20:49:25 UTC+2 Gerald napísal(-a):

I can tell from this forum that a lot of people have no issues.

I can also tell that some people have issues.

So, from that I can determine that there are variable and different environments that have an impact on the working condition of the Ethernet. We test Ethernet on every board that ships out so we know the HW works, it send ones and zeros. I also know as you have confirmed, that the HW is fine with the patched 3.11 kernel

If you want to use the 3.11 kernel then fine. I rely on the SW team to set the direction of the SW. If you have a complaint, then I would use your influence to convince the SW team to move to another kernel. However, I do know on the 3.11 kernel some things do not work. So, as long as Ethernet is the only feature you need then that should be OK. But, other things do not work. I hope none of those are needed.

Gerald

Hi Gerald,

What advice to get the Ethernet on the BBB to work properly?

I have 2 units purchased a couple of weeks back. Both behave the same as described above.

Thanks,
Steve

-This sounds to be either SW or Network related.

-It could be bad cable.

-It could be a DHCP server issue or a bad IP address such that the router does not know where to route messages.

-The fact it happens on two cards, makes it less likely to be a board issue.

-Make sure the Ethernet cable is plugged in before you power up the board.

-I have seen that if you have the USB cable connected and you have run the getting started stuff, the board decides to create its own DHCP server,. That can sometimes mess up the Ethernet. Make sure USB is unplugged from the PC and power up the board. Then ping the address as set by your DHCP sever to the assigned address.

Gerald

Hi Gerald,

-It could be bad cable.

Cable works with other equipment. And my BBB does sometimes successfully connect. I didn’t find a single consistent way to get it to connect every time.

-It could be a DHCP server issue or a bad IP address such that the router does not know where to route messages.

It seems to be the standard “transmits” and doesn’t receive. I can see the DHCP traffic transmitted but the BBB doesn’t receive the reply. We don’t see issues with our DHCP server in other circumstances and can see the DHCP server responding to the requests from the BBB.

Regards,
Steve

Hi Gerald,

Further input on this bootstrap problem on the BBB eth0:

First test:

a) I connected the eth0 interface to my Mac using an Apple USB<->100bt adapter.
b) Powered up the BBB.

Result was that the BBB successfully requested and received an IP via DHCP on eth0, and I was able to ssh in.
I tested a number of times with success every time.

Second test:

a) I connected eth eth0 interface to our office LAN Netgear GSM7248 switch with 1000bt ports.
b) Powered up the BBB
c) BBB did not acquire an IP
d) Connected usb to the BBB and ssh’ed in via 192.168.7.2.
e) “ifconfig” showed that the eth0 interface had a 169.254 address (169.254.37.137/16 to be specific).
f) I then did “ifup eth0” and the BBB immediately was successful to get an IP.

I have the “logread” kernel log from boot up which I append:

Jan 1 00:00:03 beaglebone user.notice kernel: [ 0.000000] Linux version 3.8.13 (koen@rrMBP) (gcc version 4.7.3 20130205 (prerelease) (Linaro GCC 4.7-2013.02-01) ) #1 SMP Thu Sep 12 10:27:06 CEST 2013
Jan 1 00:00:03 beaglebone user.warn kernel: [ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=50c5387d
Jan 1 00:00:03 beaglebone user.warn kernel: [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Jan 1 00:00:03 beaglebone user.info kernel: [ 0.000000] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone
Jan 1 00:00:03 beaglebone user.warn kernel: [ 0.000000] Memory policy: ECC disabled, Data cache writeback
Jan 1 00:00:03 beaglebone user.info kernel: [ 0.000000] AM335X ES1.0 (neon )
Jan 1 00:00:03 beaglebone user.info kernel: [ 0.000000] PERCPU: Embedded 8 pages/cpu @c0b34000 s9408 r8192 d15168 u32768
Jan 1 00:00:03 beaglebone user.warn kernel: [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 129792
Jan 1 00:00:03 beaglebone user.notice kernel: [ 0.000000] Kernel command line: console=ttyO0,115200n8 quiet drm.debug=7 root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait
Jan 1 00:00:03 beaglebone user.info kernel: [ 0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Jan 1 00:00:04 beaglebone user.notice kernel: [ 0.000000] __ex_table already sorted, skipping sort
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.000000] allocated 1048576 bytes of page_cgroup
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.000000] please try ‘cgroup_disable=memory’ option if you don’t want memory cgroups
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.000000] Memory: 511MB = 511MB total
Jan 1 00:00:04 beaglebone user.notice kernel: [ 0.000000] Memory: 510296k/510296k available, 13992k reserved, 0K highmem
Jan 1 00:00:04 beaglebone user.notice kernel: [ 0.000000] Virtual kernel memory layout:
Jan 1 00:00:04 beaglebone user.notice kernel: [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
Jan 1 00:00:04 beaglebone user.notice kernel: [ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
Jan 1 00:00:04 beaglebone user.notice kernel: [ 0.000000] vmalloc : 0xe0800000 - 0xff000000 ( 488 MB)
Jan 1 00:00:04 beaglebone user.notice kernel: [ 0.000000] lowmem : 0xc0000000 - 0xe0000000 ( 512 MB)
Jan 1 00:00:04 beaglebone user.notice kernel: [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
Jan 1 00:00:04 beaglebone user.notice kernel: [ 0.000000] modules : 0xbf800000 - 0xbfe00000 ( 6 MB)
Jan 1 00:00:04 beaglebone user.notice kernel: [ 0.000000] .text : 0xc0008000 - 0xc060fc28 (6176 kB)
Jan 1 00:00:04 beaglebone user.notice kernel: [ 0.000000] .init : 0xc0610000 - 0xc06524c0 ( 266 kB)
Jan 1 00:00:04 beaglebone user.notice kernel: [ 0.000000] .data : 0xc0654000 - 0xc06c9fa0 ( 472 kB)
Jan 1 00:00:04 beaglebone user.notice kernel: [ 0.000000] .bss : 0xc06c9fa0 - 0xc0723d3c ( 360 kB)
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.000000] Hierarchical RCU implementation.
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.000000] RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=1.
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.000000] NR_IRQS:16 nr_irqs:16 16
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.000000] IRQ: Found an INTC at 0xfa200000 (revision 5.0) with 128 interrupts
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.000000] Total of 128 interrupts on 1 active controller
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.000000] OMAP clockevent source: GPTIMER1 at 24000000 Hz
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.000000] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.000000] OMAP clocksource: GPTIMER2 at 24000000 Hz
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.000000] Console: colour dummy device 80x30
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.000362] Calibrating delay loop… 545.07 BogoMIPS (lpj=531968)
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.015428] pid_max: default: 32768 minimum: 301
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.015664] Security Framework initialized
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.015757] Mount-cache hash table entries: 512
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.026347] Initializing cgroup subsys cpuacct
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.026382] Initializing cgroup subsys memory
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.026446] Initializing cgroup subsys blkio
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.026583] CPU: Testing write buffer coherency: ok
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.027119] CPU0: thread -1, cpu 0, socket -1, mpidr 0
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.027253] Setting up static identity map for 0x8038a5e0 - 0x8038a62c
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.028566] Brought up 1 CPUs
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.028591] SMP: Total of 1 processors activated (545.07 BogoMIPS).
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.029889] devtmpfs: initialized
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.094652] pinctrl core: initialized pinctrl subsystem
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.094867] rstctl core: initialized rstctl subsystem
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.095365] regulator-dummy: no parameters
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.095926] NET: Registered protocol family 16
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.096781] DMA: preallocated 256 KiB pool for atomic coherent allocations
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.106882] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568
Jan 1 00:00:04 beaglebone user.warn kernel: [ 0.107701] platform 49000000.edma: alias fck already exists
Jan 1 00:00:04 beaglebone user.warn kernel: [ 0.107735] platform 49000000.edma: alias fck already exists
Jan 1 00:00:04 beaglebone daemon.info avahi-daemon[140]: Found user ‘avahi’ (UID 998) and group ‘avahi’ (GID 996).
Jan 1 00:00:04 beaglebone user.warn kernel: [ 0.107762] platform 49000000.edma: alias fck already exists
Jan 1 00:00:04 beaglebone daemon.info avahi-daemon[140]: Successfully dropped root privileges.
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.109079] OMAP GPIO hardware version 0.1
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.113781] gpio-rctrl rstctl.4: loaded OK
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.119396] hw-breakpoint: debug architecture 0x4 unsupported.
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.121528] cpsw.0: No hwaddr in dt. Using c8:a0:30:b9:8c:ec from efuse
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.121560] cpsw.1: No hwaddr in dt. Using c8:a0:30:b9:8c:ee from efuse
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.137018] bio: create slab at 0
Jan 1 00:00:04 beaglebone daemon.info avahi-daemon[140]: avahi-daemon 0.6.31 starting up.
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.149066] edma-dma-engine edma-dma-engine.0: TI EDMA DMA engine driver
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.149502] vmmcsd_fixed: 3300 mV
Jan 1 00:00:04 beaglebone user.notice kernel: [ 0.152417] SCSI subsystem initialized
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.152837] usbcore: registered new interface driver usbfs
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.152949] usbcore: registered new interface driver hub
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.153225] usbcore: registered new device driver usb
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.155287] omap_i2c 44e0b000.i2c: bus 0 rev0.11 at 400 kHz
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.156817] input: tps65217_pwr_but as /devices/ocp.3/44e0b000.i2c/i2c-0/0-0024/input/input0
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.159042] DCDC1: at 1500 mV
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.160253] vdd_mpu: 925 ↔ 1325 mV at 1100 mV
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.161358] vdd_core: 925 ↔ 1150 mV at 1100 mV
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.162504] LDO1: at 1800 mV
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.163598] LDO2: at 3300 mV
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.165572] LDO3: 1800 mV
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.166746] LDO4: at 3300 mV
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.167743] tps65217 0-0024: TPS65217 ID 0xe version 1.2
Jan 1 00:00:04 beaglebone user.warn kernel: [ 0.168479] omap_i2c 44e0b000.i2c: unable to select pin group
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.169186] omap_i2c 4819c000.i2c: bus 1 rev0.11 at 100 kHz
Jan 1 00:00:04 beaglebone user.warn kernel: [ 0.171508] omap_i2c 4819c000.i2c: unable to select pin group
Jan 1 00:00:04 beaglebone daemon.info connmand[127]: Connection Manager version 1.4
Jan 1 00:00:04 beaglebone daemon.info avahi-daemon[140]: Successfully called chroot().
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.171800] media: Linux media interface: v0.10
Jan 1 00:00:04 beaglebone daemon.info avahi-daemon[140]: Successfully dropped remaining capabilities.
Jan 1 00:00:04 beaglebone user.info kernel: [ 0.171902] Linux video capture interface: v2.00
Jan 1 00:00:05 beaglebone daemon.info avahi-daemon[140]: Loading service file /services/cloud9-avahi.service.
Jan 1 00:00:05 beaglebone user.info kernel: [ 0.172044] pps_core: LinuxPPS API ver. 1 registered
Jan 1 00:00:05 beaglebone daemon.info avahi-daemon[140]: Loading service file /services/gateone-avahi.service.