BeagleBone Black: Ethernet transmits packets but does not receive them

[n***@public.gmane.org]

I'm having a strange problem with my new BeagleBone black: I can transmit
packets from the Ethernet port but not receive them.

When using DHCP, I can see (via a sniffer) the DHCP DISCOVER packet sent
from the 'bone (via a network sniffer). I can see my DHCP server (dnsmasq
2.59 on stock Ubuntu 12.04 LTS 64-bit server) send a DHCP OFFER. But the
'bone acts like it never hears the offer; it just sends out more DISCOVERs
at intervals. (The same DHCP server is working fine for dozens of clients
from various vendors. There are plenty of leases left in the pool.)

If I set a static address and try to ping something, I see the 'bone send
an ARP who-has, I see the target reply with an ARP is-at, but the 'bone
just keeps ARP-ing, and never gets an entry in its ARP table.

In the ifconfig output, the eth0 interface shows 0 packets received and 0
errors. (The number transmitted is non-0.) Nothing suspicious in the dmesg
output that I can see.

I've repeated the tests with both the latest Angstrom and with Ubuntu
booted off an SD card. Same results. I've tried two different cables, and
two different ports on two different Ethernet switches from different
vendors. (All ports and cables verified to work fine with my laptop.)

One interesting observation: the port seems to always end up on 10Mbps,
even when plugged into 100Mbps- (or gigabit-) capable ports. So, it looks
like autonegotiation isn't working either.

I'm running on a 2A 5.00V regulated bench supply, and the DC looks clean on
the o-scope.

Other 'bone functions (USB host, USB target, HDMI, LEDs) all seem to work
fine.

I'm starting to suspect a hardware problem (busted PHY or magnetics;
incomplete or bridged trace).

Any suggestions for stuff I should try before I RMA the poor little guy?
(I'm an experienced Linux user and reasonably competent electronics
hobbyist, if that matters.)

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[Gerald Coley]

Request an RMA.

Gerald


On Mon, Jun 10, 2013 at 10:23 AM, <necronomipad-***@public.gmane.org> wrote:

> I'm having a strange problem with my new BeagleBone black: I can transmit
> packets from the Ethernet port but not receive them.
>
> When using DHCP, I can see (via a sniffer) the DHCP DISCOVER packet sent
> from the 'bone (via a network sniffer). I can see my DHCP server (dnsmasq
> 2.59 on stock Ubuntu 12.04 LTS 64-bit server) send a DHCP OFFER. But the
> 'bone acts like it never hears the offer; it just sends out more DISCOVERs
> at intervals. (The same DHCP server is working fine for dozens of clients
> from various vendors. There are plenty of leases left in the pool.)
>
> If I set a static address and try to ping something, I see the 'bone send
> an ARP who-has, I see the target reply with an ARP is-at, but the 'bone
> just keeps ARP-ing, and never gets an entry in its ARP table.
>
> In the ifconfig output, the eth0 interface shows 0 packets received and 0
> errors. (The number transmitted is non-0.) Nothing suspicious in the dmesg
> output that I can see.
>
> I've repeated the tests with both the latest Angstrom and with Ubuntu
> booted off an SD card. Same results. I've tried two different cables, and
> two different ports on two different Ethernet switches from different
> vendors. (All ports and cables verified to work fine with my laptop.)
>
> One interesting observation: the port seems to always end up on 10Mbps,
> even when plugged into 100Mbps- (or gigabit-) capable ports. So, it looks
> like autonegotiation isn't working either.
>
> I'm running on a 2A 5.00V regulated bench supply, and the DC looks clean
> on the o-scope.
>
> Other 'bone functions (USB host, USB target, HDMI, LEDs) all seem to work
> fine.
>
> I'm starting to suspect a hardware problem (busted PHY or magnetics;
> incomplete or bridged trace).
>
> Any suggestions for stuff I should try before I RMA the poor little guy?
> (I'm an experienced Linux user and reasonably competent electronics
> hobbyist, if that matters.)
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>



--
Gerald

gerald-hcmAuCOw+vXj4SYmN/***@public.gmane.org
g-coley1-***@public.gmane.org
http://beagleboard.org/
http://circuitco.com/support/

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[rfengr-kFCvZ5XHPypvBvnq28/]

I'm also having the same issue. It was working, then stopped after a few
hours. Tried the stock Linux, Ubuntu, and Debian. It's a hardware issue.
Mine is going back to Newark. See posts here for same problem:

http://comments.gmane.org/gmane.comp.hardware.beagleboard.user/45372



On Monday, June 10, 2013 10:23:32 AM UTC-5, necron...-***@public.gmane.org wrote:
>
> I'm having a strange problem with my new BeagleBone black: I can transmit
> packets from the Ethernet port but not receive them.
>
> When using DHCP, I can see (via a sniffer) the DHCP DISCOVER packet sent
> from the 'bone (via a network sniffer). I can see my DHCP server (dnsmasq
> 2.59 on stock Ubuntu 12.04 LTS 64-bit server) send a DHCP OFFER. But the
> 'bone acts like it never hears the offer; it just sends out more DISCOVERs
> at intervals. (The same DHCP server is working fine for dozens of clients
> from various vendors. There are plenty of leases left in the pool.)
>
> If I set a static address and try to ping something, I see the 'bone send
> an ARP who-has, I see the target reply with an ARP is-at, but the 'bone
> just keeps ARP-ing, and never gets an entry in its ARP table.
>
> In the ifconfig output, the eth0 interface shows 0 packets received and 0
> errors. (The number transmitted is non-0.) Nothing suspicious in the dmesg
> output that I can see.
>
> I've repeated the tests with both the latest Angstrom and with Ubuntu
> booted off an SD card. Same results. I've tried two different cables, and
> two different ports on two different Ethernet switches from different
> vendors. (All ports and cables verified to work fine with my laptop.)
>
> One interesting observation: the port seems to always end up on 10Mbps,
> even when plugged into 100Mbps- (or gigabit-) capable ports. So, it looks
> like autonegotiation isn't working either.
>
> I'm running on a 2A 5.00V regulated bench supply, and the DC looks clean
> on the o-scope.
>
> Other 'bone functions (USB host, USB target, HDMI, LEDs) all seem to work
> fine.
>
> I'm starting to suspect a hardware problem (busted PHY or magnetics;
> incomplete or bridged trace).
>
> Any suggestions for stuff I should try before I RMA the poor little guy?
> (I'm an experienced Linux user and reasonably competent electronics
> hobbyist, if that matters.)
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[Gerald Coley]

Would you be willing to request an RMA and have us look at it to see if it
really a HW issue?

Gerald



On Wed, Jun 12, 2013 at 6:20 PM, <rfengr-kFCvZ5XHPypvBvnq28/***@public.gmane.org> wrote:

> I'm also having the same issue. It was working, then stopped after a few
> hours. Tried the stock Linux, Ubuntu, and Debian. It's a hardware issue.
> Mine is going back to Newark. See posts here for same problem:
>
> http://comments.gmane.org/gmane.comp.hardware.beagleboard.user/45372
>
>
>
> On Monday, June 10, 2013 10:23:32 AM UTC-5, necron...-***@public.gmane.org wrote:
>>
>> I'm having a strange problem with my new BeagleBone black: I can transmit
>> packets from the Ethernet port but not receive them.
>>
>> When using DHCP, I can see (via a sniffer) the DHCP DISCOVER packet sent
>> from the 'bone (via a network sniffer). I can see my DHCP server (dnsmasq
>> 2.59 on stock Ubuntu 12.04 LTS 64-bit server) send a DHCP OFFER. But the
>> 'bone acts like it never hears the offer; it just sends out more DISCOVERs
>> at intervals. (The same DHCP server is working fine for dozens of clients
>> from various vendors. There are plenty of leases left in the pool.)
>>
>> If I set a static address and try to ping something, I see the 'bone send
>> an ARP who-has, I see the target reply with an ARP is-at, but the 'bone
>> just keeps ARP-ing, and never gets an entry in its ARP table.
>>
>> In the ifconfig output, the eth0 interface shows 0 packets received and 0
>> errors. (The number transmitted is non-0.) Nothing suspicious in the dmesg
>> output that I can see.
>>
>> I've repeated the tests with both the latest Angstrom and with Ubuntu
>> booted off an SD card. Same results. I've tried two different cables, and
>> two different ports on two different Ethernet switches from different
>> vendors. (All ports and cables verified to work fine with my laptop.)
>>
>> One interesting observation: the port seems to always end up on 10Mbps,
>> even when plugged into 100Mbps- (or gigabit-) capable ports. So, it looks
>> like autonegotiation isn't working either.
>>
>> I'm running on a 2A 5.00V regulated bench supply, and the DC looks clean
>> on the o-scope.
>>
>> Other 'bone functions (USB host, USB target, HDMI, LEDs) all seem to work
>> fine.
>>
>> I'm starting to suspect a hardware problem (busted PHY or magnetics;
>> incomplete or bridged trace).
>>
>> Any suggestions for stuff I should try before I RMA the poor little guy?
>> (I'm an experienced Linux user and reasonably competent electronics
>> hobbyist, if that matters.)
>>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>



--
Gerald

gerald-hcmAuCOw+vXj4SYmN/***@public.gmane.org
g-coley1-***@public.gmane.org
http://beagleboard.org/
http://circuitco.com/support/

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[Gerald Coley]

Or would you be willing to work with me to find a solution for this issue?
There is a simple test to prove out your theory if you are interested.

Gerald



On Wed, Jun 12, 2013 at 6:29 PM, Gerald Coley <gerald-hcmAuCOw+vXj4SYmN/***@public.gmane.org>wrote:

> Would you be willing to request an RMA and have us look at it to see if it
> really a HW issue?
>
> Gerald
>
>
>
> On Wed, Jun 12, 2013 at 6:20 PM, <rfengr-kFCvZ5XHPypvBvnq28/***@public.gmane.org> wrote:
>
>> I'm also having the same issue. It was working, then stopped after a few
>> hours. Tried the stock Linux, Ubuntu, and Debian. It's a hardware issue.
>> Mine is going back to Newark. See posts here for same problem:
>>
>> http://comments.gmane.org/gmane.comp.hardware.beagleboard.user/45372
>>
>>
>>
>> On Monday, June 10, 2013 10:23:32 AM UTC-5, necron...-***@public.gmane.org wrote:
>>>
>>> I'm having a strange problem with my new BeagleBone black: I can
>>> transmit packets from the Ethernet port but not receive them.
>>>
>>> When using DHCP, I can see (via a sniffer) the DHCP DISCOVER packet sent
>>> from the 'bone (via a network sniffer). I can see my DHCP server (dnsmasq
>>> 2.59 on stock Ubuntu 12.04 LTS 64-bit server) send a DHCP OFFER. But the
>>> 'bone acts like it never hears the offer; it just sends out more DISCOVERs
>>> at intervals. (The same DHCP server is working fine for dozens of clients
>>> from various vendors. There are plenty of leases left in the pool.)
>>>
>>> If I set a static address and try to ping something, I see the 'bone
>>> send an ARP who-has, I see the target reply with an ARP is-at, but the
>>> 'bone just keeps ARP-ing, and never gets an entry in its ARP table.
>>>
>>> In the ifconfig output, the eth0 interface shows 0 packets received and
>>> 0 errors. (The number transmitted is non-0.) Nothing suspicious in the
>>> dmesg output that I can see.
>>>
>>> I've repeated the tests with both the latest Angstrom and with Ubuntu
>>> booted off an SD card. Same results. I've tried two different cables, and
>>> two different ports on two different Ethernet switches from different
>>> vendors. (All ports and cables verified to work fine with my laptop.)
>>>
>>> One interesting observation: the port seems to always end up on 10Mbps,
>>> even when plugged into 100Mbps- (or gigabit-) capable ports. So, it looks
>>> like autonegotiation isn't working either.
>>>
>>> I'm running on a 2A 5.00V regulated bench supply, and the DC looks clean
>>> on the o-scope.
>>>
>>> Other 'bone functions (USB host, USB target, HDMI, LEDs) all seem to
>>> work fine.
>>>
>>> I'm starting to suspect a hardware problem (busted PHY or magnetics;
>>> incomplete or bridged trace).
>>>
>>> Any suggestions for stuff I should try before I RMA the poor little guy?
>>> (I'm an experienced Linux user and reasonably competent electronics
>>> hobbyist, if that matters.)
>>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>
>
> --
> Gerald
>
> gerald-hcmAuCOw+vXj4SYmN/***@public.gmane.org
> g-coley1-***@public.gmane.org
> http://beagleboard.org/
> http://circuitco.com/support/
>



--
Gerald

gerald-hcmAuCOw+vXj4SYmN/***@public.gmane.org
g-coley1-***@public.gmane.org
http://beagleboard.org/
http://circuitco.com/support/

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[Kathryn Adeney]

I am having a very similar issue and very reproducible on different boards,
builds, etc. When I deliberately take down eth0 it will not come back
except with a reboot. At this point wireshark shows traffic to/from the
BBB (eg from udhcpc -i eth0) but RX and TX stats displayed by ifconfig are
frozen, and the 'bone doesn't answer the dhcp offers. I think the problem
is eth0 and not the dhcp (because the rx stats should increase as other
broadcast traffic goes by, for example).

I have seen this on:
- Two different BBBs
- Three LInux builds (emmc image it shipped with, 3.8.11, the latest
3.8.13 from http://downloads.angstrom-distribution.org/demo/beaglebone/ booting
from SD card, and a Debian demo build (3.8.13-bone20).
- 5V1A power supply to barrel connector OR USB power
I have the FTDI cable.

Example console stuff from Angstrom 3.8.13 build (with //my comments):

// after boot, eth0 comes up automatically:

Angstrom v2012.12 - Kernel 3.8.13

beaglebone login: root
Last login: Sat Jan 1 00:00:18 UTC 2000 on ttyO0
***@beaglebone:~# ifconfig eth0
eth0 Link encap:Ethernet HWaddr C8:A0:30:B6:B0:AB
inet addr:10.10.10.100 Bcast:10.10.10.255 Mask:255.255.255.0
inet6 addr: fe80::caa0:30ff:feb6:b0ab/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:14 errors:0 dropped:0 overruns:0 frame:0
TX packets:44 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2570 (2.5 KiB) TX bytes:9448 (9.2 KiB)
Interrupt:56

***@beaglebone:~# ping 10.10.10.106
PING 10.10.10.106 (10.10.10.106) 56(84) bytes of data.
64 bytes from 10.10.10.106: icmp_req=1 ttl=64 time=0.449 ms
64 bytes from 10.10.10.106: icmp_req=2 ttl=64 time=0.288 ms
^C
--- 10.10.10.106 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.288/0.368/0.449/0.082 ms

// eth0-related dmesg lines after boot:

***@beaglebone:~# dmesg | tail -12
[ 12.211067] gs_open: ttyGS0 (dc8a3000,dce6db00)
[ 12.211194] gs_close: ttyGS0 (dc8a3000,dce6db00) ...
[ 12.211209] gs_close: ttyGS0 (dc8a3000,dce6db00) done!
[ 12.214983] gs_open: ttyGS0 (dc8a3000,dce6d140)
[ 12.319882] net eth0: initializing cpsw version 1.12 (0)
[ 12.322457] net eth0: phy found : id is : 0x7c0f1
[ 12.322483] libphy: PHY 4a101000.mdio:01 not found
[ 12.327568] net eth0: phy 4a101000.mdio:01 not found on slave 1
[ 12.358016] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 15.399053] libphy: 4a101000.mdio:00 - Link is Up - 100/Full
[ 15.399115] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 36.335658] EXT4-fs (mmcblk0p2): re-mounted. Opts: commit=0
***@beaglebone:~#

// now take it down using ifconfig and note the TX and RX stats
***@beaglebone:~# ifconfig eth0 down
***@beaglebone:~# ifconfig -a eth0
eth0 Link encap:Ethernet HWaddr C8:A0:30:B6:B0:AB
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:41 errors:0 dropped:4 overruns:0 frame:0
TX packets:69 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:5864 (5.7 KiB) TX bytes:12058 (11.7 KiB)
Interrupt:56

// bring it back up. TX and RX stats stay fixed.
// (Note I think the mdio:01 not found logs are a red herring, maybe
// relating the the slave 01 that is not present?)

***@beaglebone:~# ifconfig eth0 up
[ 92.786057] libphy: PHY 4a101000.mdio:01 not found
[ 92.791129] net eth0: phy 4a101000.mdio:01 not found on slave 1
***@beaglebone:~# ifconfig eth0
eth0 Link encap:Ethernet HWaddr C8:A0:30:B6:B0:AB
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:41 errors:0 dropped:4 overruns:0 frame:0
TX packets:69 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:5864 (5.7 KiB) TX bytes:12058 (11.7 KiB)
Interrupt:56

// udhcpc generates traffic on the wire - DISCOVER broadcast and OFFER
unicast to 'bone.
// BUT 'bone does not answer, and RX and TX counters stay frozen

***@beaglebone:~# udhcpc -i eth0
udhcpc (v1.20.2) started
Sending discover...
Sending discover...
Sending discover...
^C
***@beaglebone:~# ifconfig eth0
eth0 Link encap:Ethernet HWaddr C8:A0:30:B6:B0:AB
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:41 errors:0 dropped:4 overruns:0 frame:0
TX packets:69 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:5864 (5.7 KiB) TX bytes:12058 (11.7 KiB)
Interrupt:56

// additional dmesgs generated by eth0 down and up cmds:

***@beaglebone:~# dmesg | tail
[ 59.915139] EXT4-fs (mmcblk1p2): recovery complete
[ 59.915176] EXT4-fs (mmcblk1p2): mounted filesystem with ordered data
mode. Opts: (null)
[ 70.522126] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 92.782650] net eth0: initializing cpsw version 1.12 (0)
[ 92.786025] net eth0: phy found : id is : 0x7c0f1
[ 92.786057] libphy: PHY 4a101000.mdio:01 not found
[ 92.791129] net eth0: phy 4a101000.mdio:01 not found on slave 1
[ 92.802369] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 94.793621] libphy: 4a101000.mdio:00 - Link is Up - 100/Full
[ 94.793680] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

On the Debian image I used ifdown and ifup and tried also
/etc/init.d/network restart but got the same results.
I also tried cycling up/down quickly a few times, and slowly.

It recovers after reboot from the command line or hard reboot.

This all worked fine on the Beaglebone Whites. Also had those running in
promiscuous mode which may now be broken but that might be another thread.
From the schematics it looks like there are no changes at all to the
ethernet hardware, so guess it has to be in the Linux 3.8 drivers.
Anyone heard of any fixes, available or in progress? I am a Linux Noob so
could be looking in the wrong places.

Thanks,
Kathryn

>
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[rfengr-kFCvZ5XHPypvBvnq28/]

> I requested an RMA from Newark, but they never sent me one, just refunded
> my credit card. Do you want me to mail it to you?
>
>
>
> On Wed, Jun 12, 2013 at 6:29 PM, Gerald Coley <ger...-hcmAuCOw+vXj4SYmN/***@public.gmane.org<javascript:>
> > wrote:
>
>> Would you be willing to request an RMA and have us look at it to see if
>> it really a HW issue?
>>
>> Gerald
>>
>>
>>
>> On Wed, Jun 12, 2013 at 6:20 PM, <rfe...-kFCvZ5XHPypvBvnq28/***@public.gmane.org <javascript:>>wrote:
>>
>>> I'm also having the same issue. It was working, then stopped after a
>>> few hours. Tried the stock Linux, Ubuntu, and Debian. It's a hardware
>>> issue. Mine is going back to Newark. See posts here for same problem:
>>>
>>> http://comments.gmane.org/gmane.comp.hardware.beagleboard.user/45372
>>>
>>>
>>>
>>> On Monday, June 10, 2013 10:23:32 AM UTC-5, necron...-***@public.gmane.org wrote:
>>>>
>>>> I'm having a strange problem with my new BeagleBone black: I can
>>>> transmit packets from the Ethernet port but not receive them.
>>>>
>>>> When using DHCP, I can see (via a sniffer) the DHCP DISCOVER packet
>>>> sent from the 'bone (via a network sniffer). I can see my DHCP server
>>>> (dnsmasq 2.59 on stock Ubuntu 12.04 LTS 64-bit server) send a DHCP OFFER.
>>>> But the 'bone acts like it never hears the offer; it just sends out more
>>>> DISCOVERs at intervals. (The same DHCP server is working fine for dozens of
>>>> clients from various vendors. There are plenty of leases left in the pool.)
>>>>
>>>> If I set a static address and try to ping something, I see the 'bone
>>>> send an ARP who-has, I see the target reply with an ARP is-at, but the
>>>> 'bone just keeps ARP-ing, and never gets an entry in its ARP table.
>>>>
>>>> In the ifconfig output, the eth0 interface shows 0 packets received and
>>>> 0 errors. (The number transmitted is non-0.) Nothing suspicious in the
>>>> dmesg output that I can see.
>>>>
>>>> I've repeated the tests with both the latest Angstrom and with Ubuntu
>>>> booted off an SD card. Same results. I've tried two different cables, and
>>>> two different ports on two different Ethernet switches from different
>>>> vendors. (All ports and cables verified to work fine with my laptop.)
>>>>
>>>> One interesting observation: the port seems to always end up on 10Mbps,
>>>> even when plugged into 100Mbps- (or gigabit-) capable ports. So, it looks
>>>> like autonegotiation isn't working either.
>>>>
>>>> I'm running on a 2A 5.00V regulated bench supply, and the DC looks
>>>> clean on the o-scope.
>>>>
>>>> Other 'bone functions (USB host, USB target, HDMI, LEDs) all seem to
>>>> work fine.
>>>>
>>>> I'm starting to suspect a hardware problem (busted PHY or magnetics;
>>>> incomplete or bridged trace).
>>>>
>>>> Any suggestions for stuff I should try before I RMA the poor little
>>>> guy? (I'm an experienced Linux user and reasonably competent electronics
>>>> hobbyist, if that matters.)
>>>>
>>> --
>>> For more options, visit http://beagleboard.org/discuss
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "BeagleBoard" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to beagleboard...-/***@public.gmane.org <javascript:>.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>>
>>
>>
>>
>> --
>> Gerald
>>
>> ger...-hcmAuCOw+vXj4SYmN/***@public.gmane.org <javascript:>
>> g-co...-***@public.gmane.org <javascript:>
>> http://beagleboard.org/
>> http://circuitco.com/support/
>>
>
>
>
> --
> Gerald
>
> ger...-hcmAuCOw+vXj4SYmN/***@public.gmane.org <javascript:>
> g-co...-***@public.gmane.org <javascript:>
> http://beagleboard.org/
> http://circuitco.com/support/
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[Gerald Coley]

http://circuitco.com/support/index.php?title=BeagleBoneBlack#RMA_Support

Gerald


On Sat, Jun 15, 2013 at 11:25 AM, <rfengr-kFCvZ5XHPypvBvnq28/***@public.gmane.org> wrote:

>
> I requested an RMA from Newark, but they never sent me one, just refunded
>> my credit card. Do you want me to mail it to you?
>>
>>
>>
>> On Wed, Jun 12, 2013 at 6:29 PM, Gerald Coley <ger...-hcmAuCOw+vXj4SYmN/***@public.gmane.org>wrote:
>>
>>> Would you be willing to request an RMA and have us look at it to see if
>>> it really a HW issue?
>>>
>>> Gerald
>>>
>>>
>>>
>>> On Wed, Jun 12, 2013 at 6:20 PM, <rfe...-kFCvZ5XHPypvBvnq28/***@public.gmane.org> wrote:
>>>
>>>> I'm also having the same issue. It was working, then stopped after a
>>>> few hours. Tried the stock Linux, Ubuntu, and Debian. It's a hardware
>>>> issue. Mine is going back to Newark. See posts here for same problem:
>>>>
>>>> http://comments.gmane.org/**gmane.comp.hardware.**
>>>> beagleboard.user/45372<http://comments.gmane.org/gmane.comp.hardware.beagleboard.user/45372>
>>>>
>>>>
>>>>
>>>> On Monday, June 10, 2013 10:23:32 AM UTC-5, necron...-***@public.gmane.org wrote:
>>>>>
>>>>> I'm having a strange problem with my new BeagleBone black: I can
>>>>> transmit packets from the Ethernet port but not receive them.
>>>>>
>>>>> When using DHCP, I can see (via a sniffer) the DHCP DISCOVER packet
>>>>> sent from the 'bone (via a network sniffer). I can see my DHCP server
>>>>> (dnsmasq 2.59 on stock Ubuntu 12.04 LTS 64-bit server) send a DHCP OFFER.
>>>>> But the 'bone acts like it never hears the offer; it just sends out more
>>>>> DISCOVERs at intervals. (The same DHCP server is working fine for dozens of
>>>>> clients from various vendors. There are plenty of leases left in the pool.)
>>>>>
>>>>> If I set a static address and try to ping something, I see the 'bone
>>>>> send an ARP who-has, I see the target reply with an ARP is-at, but the
>>>>> 'bone just keeps ARP-ing, and never gets an entry in its ARP table.
>>>>>
>>>>> In the ifconfig output, the eth0 interface shows 0 packets received
>>>>> and 0 errors. (The number transmitted is non-0.) Nothing suspicious in the
>>>>> dmesg output that I can see.
>>>>>
>>>>> I've repeated the tests with both the latest Angstrom and with Ubuntu
>>>>> booted off an SD card. Same results. I've tried two different cables, and
>>>>> two different ports on two different Ethernet switches from different
>>>>> vendors. (All ports and cables verified to work fine with my laptop.)
>>>>>
>>>>> One interesting observation: the port seems to always end up on
>>>>> 10Mbps, even when plugged into 100Mbps- (or gigabit-) capable ports. So, it
>>>>> looks like autonegotiation isn't working either.
>>>>>
>>>>> I'm running on a 2A 5.00V regulated bench supply, and the DC looks
>>>>> clean on the o-scope.
>>>>>
>>>>> Other 'bone functions (USB host, USB target, HDMI, LEDs) all seem to
>>>>> work fine.
>>>>>
>>>>> I'm starting to suspect a hardware problem (busted PHY or magnetics;
>>>>> incomplete or bridged trace).
>>>>>
>>>>> Any suggestions for stuff I should try before I RMA the poor little
>>>>> guy? (I'm an experienced Linux user and reasonably competent electronics
>>>>> hobbyist, if that matters.)
>>>>>
>>>> --
>>>> For more options, visit http://beagleboard.org/discuss
>>>> ---
>>>> You received this message because you are subscribed to the Google
>>>> Groups "BeagleBoard" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to beagleboard...@**googlegroups.com.
>>>>
>>>> For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>>>> .
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Gerald
>>>
>>> ger...-hcmAuCOw+vXj4SYmN/***@public.gmane.org
>>> g-co...-***@public.gmane.org
>>> http://beagleboard.org/
>>> http://circuitco.com/support/
>>>
>>
>>
>>
>> --
>> Gerald
>>
>> ger...-hcmAuCOw+vXj4SYmN/***@public.gmane.org
>> g-co...-***@public.gmane.org
>> http://beagleboard.org/
>> http://circuitco.com/support/
>>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>



--
Gerald

gerald-hcmAuCOw+vXj4SYmN/***@public.gmane.org
g-coley1-***@public.gmane.org
http://beagleboard.org/
http://circuitco.com/support/

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[rfengr-kFCvZ5XHPypvBvnq28/]

I submitted an RMA request at that link, but nothing happens after I click
submit. Maybe I'll get an email confirmation.

On Saturday, June 15, 2013 8:08:33 PM UTC-5, Gerald wrote:
>
> http://circuitco.com/support/index.php?title=BeagleBoneBlack#RMA_Support
>
> Gerald
>
>
> On Sat, Jun 15, 2013 at 11:25 AM, <rfe...-kFCvZ5XHPypvBvnq28/***@public.gmane.org <javascript:>>wrote:
>
>>
>> I requested an RMA from Newark, but they never sent me one, just refunded
>>> my credit card. Do you want me to mail it to you?
>>>
>>>
>>>
>>> On Wed, Jun 12, 2013 at 6:29 PM, Gerald Coley <ger...-hcmAuCOw+vXj4SYmN/***@public.gmane.org>wrote:
>>>
>>>> Would you be willing to request an RMA and have us look at it to see if
>>>> it really a HW issue?
>>>>
>>>> Gerald
>>>>
>>>>
>>>>
>>>> On Wed, Jun 12, 2013 at 6:20 PM, <rfe...-kFCvZ5XHPypvBvnq28/***@public.gmane.org> wrote:
>>>>
>>>>> I'm also having the same issue. It was working, then stopped after a
>>>>> few hours. Tried the stock Linux, Ubuntu, and Debian. It's a hardware
>>>>> issue. Mine is going back to Newark. See posts here for same problem:
>>>>>
>>>>> http://comments.gmane.org/**gmane.comp.hardware.**
>>>>> beagleboard.user/45372<http://comments.gmane.org/gmane.comp.hardware.beagleboard.user/45372>
>>>>>
>>>>>
>>>>>
>>>>> On Monday, June 10, 2013 10:23:32 AM UTC-5, necron...-***@public.gmane.org wrote:
>>>>>>
>>>>>> I'm having a strange problem with my new BeagleBone black: I can
>>>>>> transmit packets from the Ethernet port but not receive them.
>>>>>>
>>>>>> When using DHCP, I can see (via a sniffer) the DHCP DISCOVER packet
>>>>>> sent from the 'bone (via a network sniffer). I can see my DHCP server
>>>>>> (dnsmasq 2.59 on stock Ubuntu 12.04 LTS 64-bit server) send a DHCP OFFER.
>>>>>> But the 'bone acts like it never hears the offer; it just sends out more
>>>>>> DISCOVERs at intervals. (The same DHCP server is working fine for dozens of
>>>>>> clients from various vendors. There are plenty of leases left in the pool.)
>>>>>>
>>>>>> If I set a static address and try to ping something, I see the 'bone
>>>>>> send an ARP who-has, I see the target reply with an ARP is-at, but the
>>>>>> 'bone just keeps ARP-ing, and never gets an entry in its ARP table.
>>>>>>
>>>>>> In the ifconfig output, the eth0 interface shows 0 packets received
>>>>>> and 0 errors. (The number transmitted is non-0.) Nothing suspicious in the
>>>>>> dmesg output that I can see.
>>>>>>
>>>>>> I've repeated the tests with both the latest Angstrom and with Ubuntu
>>>>>> booted off an SD card. Same results. I've tried two different cables, and
>>>>>> two different ports on two different Ethernet switches from different
>>>>>> vendors. (All ports and cables verified to work fine with my laptop.)
>>>>>>
>>>>>> One interesting observation: the port seems to always end up on
>>>>>> 10Mbps, even when plugged into 100Mbps- (or gigabit-) capable ports. So, it
>>>>>> looks like autonegotiation isn't working either.
>>>>>>
>>>>>> I'm running on a 2A 5.00V regulated bench supply, and the DC looks
>>>>>> clean on the o-scope.
>>>>>>
>>>>>> Other 'bone functions (USB host, USB target, HDMI, LEDs) all seem to
>>>>>> work fine.
>>>>>>
>>>>>> I'm starting to suspect a hardware problem (busted PHY or magnetics;
>>>>>> incomplete or bridged trace).
>>>>>>
>>>>>> Any suggestions for stuff I should try before I RMA the poor little
>>>>>> guy? (I'm an experienced Linux user and reasonably competent electronics
>>>>>> hobbyist, if that matters.)
>>>>>>
>>>>> --
>>>>> For more options, visit http://beagleboard.org/discuss
>>>>> ---
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "BeagleBoard" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to beagleboard...@**googlegroups.com.
>>>>>
>>>>> For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>>>>> .
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Gerald
>>>>
>>>> ger...-hcmAuCOw+vXj4SYmN/***@public.gmane.org
>>>> g-co...-***@public.gmane.org
>>>> http://beagleboard.org/
>>>> http://circuitco.com/support/
>>>>
>>>
>>>
>>>
>>> --
>>> Gerald
>>>
>>> ger...-hcmAuCOw+vXj4SYmN/***@public.gmane.org
>>> g-co...-***@public.gmane.org
>>> http://beagleboard.org/
>>> http://circuitco.com/support/
>>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard...-/***@public.gmane.org <javascript:>.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>
>
> --
> Gerald
>
> ger...-hcmAuCOw+vXj4SYmN/***@public.gmane.org <javascript:>
> g-co...-***@public.gmane.org <javascript:>
> http://beagleboard.org/
> http://circuitco.com/support/
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[Gerald Coley]

It have not seen it come through. Enter all the information requested into
an email and send that to rma-hcmAuCOw+vU6XaHZLq/leuG/***@public.gmane.org

Gerald


On Thu, Jun 20, 2013 at 9:30 PM, <rfengr-kFCvZ5XHPypvBvnq28/***@public.gmane.org> wrote:

> I submitted an RMA request at that link, but nothing happens after I click
> submit. Maybe I'll get an email confirmation.
>
>
> On Saturday, June 15, 2013 8:08:33 PM UTC-5, Gerald wrote:
>
>> http://circuitco.com/support/**index.php?title=**
>> BeagleBoneBlack#RMA_Support<http://circuitco.com/support/index.php?title=BeagleBoneBlack#RMA_Support>
>>
>> Gerald
>>
>>
>> On Sat, Jun 15, 2013 at 11:25 AM, <rfe...-kFCvZ5XHPypvBvnq28/***@public.gmane.org> wrote:
>>
>>>
>>> I requested an RMA from Newark, but they never sent me one, just
>>>> refunded my credit card. Do you want me to mail it to you?
>>>>
>>>>
>>>>
>>>> On Wed, Jun 12, 2013 at 6:29 PM, Gerald Coley <ger...-hcmAuCOw+vXj4SYmN/***@public.gmane.org>wrote:
>>>>
>>>>> Would you be willing to request an RMA and have us look at it to see
>>>>> if it really a HW issue?
>>>>>
>>>>> Gerald
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Jun 12, 2013 at 6:20 PM, <rfe...-kFCvZ5XHPypvBvnq28/***@public.gmane.org> wrote:
>>>>>
>>>>>> I'm also having the same issue. It was working, then stopped after a
>>>>>> few hours. Tried the stock Linux, Ubuntu, and Debian. It's a hardware
>>>>>> issue. Mine is going back to Newark. See posts here for same problem:
>>>>>>
>>>>>> http://comments.gmane.org/**gman**e.comp.hardware.**beagleboard.**
>>>>>> user/45372<http://comments.gmane.org/gmane.comp.hardware.beagleboard.user/45372>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Monday, June 10, 2013 10:23:32 AM UTC-5, necron...-Re5JQEeQqe8M+***@public.gmane.org:
>>>>>>>
>>>>>>> I'm having a strange problem with my new BeagleBone black: I can
>>>>>>> transmit packets from the Ethernet port but not receive them.
>>>>>>>
>>>>>>> When using DHCP, I can see (via a sniffer) the DHCP DISCOVER packet
>>>>>>> sent from the 'bone (via a network sniffer). I can see my DHCP server
>>>>>>> (dnsmasq 2.59 on stock Ubuntu 12.04 LTS 64-bit server) send a DHCP OFFER.
>>>>>>> But the 'bone acts like it never hears the offer; it just sends out more
>>>>>>> DISCOVERs at intervals. (The same DHCP server is working fine for dozens of
>>>>>>> clients from various vendors. There are plenty of leases left in the pool.)
>>>>>>>
>>>>>>> If I set a static address and try to ping something, I see the 'bone
>>>>>>> send an ARP who-has, I see the target reply with an ARP is-at, but the
>>>>>>> 'bone just keeps ARP-ing, and never gets an entry in its ARP table.
>>>>>>>
>>>>>>> In the ifconfig output, the eth0 interface shows 0 packets received
>>>>>>> and 0 errors. (The number transmitted is non-0.) Nothing suspicious in the
>>>>>>> dmesg output that I can see.
>>>>>>>
>>>>>>> I've repeated the tests with both the latest Angstrom and with
>>>>>>> Ubuntu booted off an SD card. Same results. I've tried two different
>>>>>>> cables, and two different ports on two different Ethernet switches from
>>>>>>> different vendors. (All ports and cables verified to work fine with my
>>>>>>> laptop.)
>>>>>>>
>>>>>>> One interesting observation: the port seems to always end up on
>>>>>>> 10Mbps, even when plugged into 100Mbps- (or gigabit-) capable ports. So, it
>>>>>>> looks like autonegotiation isn't working either.
>>>>>>>
>>>>>>> I'm running on a 2A 5.00V regulated bench supply, and the DC looks
>>>>>>> clean on the o-scope.
>>>>>>>
>>>>>>> Other 'bone functions (USB host, USB target, HDMI, LEDs) all seem to
>>>>>>> work fine.
>>>>>>>
>>>>>>> I'm starting to suspect a hardware problem (busted PHY or magnetics;
>>>>>>> incomplete or bridged trace).
>>>>>>>
>>>>>>> Any suggestions for stuff I should try before I RMA the poor little
>>>>>>> guy? (I'm an experienced Linux user and reasonably competent electronics
>>>>>>> hobbyist, if that matters.)
>>>>>>>
>>>>>> --
>>>>>> For more options, visit http://beagleboard.org/discuss
>>>>>> ---
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "BeagleBoard" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>> send an email to beagleboard...@**googlegroups.**com.
>>>>>>
>>>>>> For more options, visit https://groups.google.com/**grou**ps/opt_out<https://groups.google.com/groups/opt_out>
>>>>>> .
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Gerald
>>>>>
>>>>> ger...-hcmAuCOw+vXj4SYmN/***@public.gmane.org
>>>>> g-co...-***@public.gmane.org
>>>>> http://beagleboard.org/
>>>>> http://circuitco.com/support/
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Gerald
>>>>
>>>> ger...-hcmAuCOw+vXj4SYmN/***@public.gmane.org
>>>> g-co...-***@public.gmane.org
>>>> http://beagleboard.org/
>>>> http://circuitco.com/support/
>>>>
>>> --
>>> For more options, visit http://beagleboard.org/discuss
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "BeagleBoard" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to beagleboard...@**googlegroups.com.
>>> For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>>> .
>>>
>>>
>>>
>>
>>
>>
>> --
>> Gerald
>>
>> ger...-hcmAuCOw+vXj4SYmN/***@public.gmane.org
>> g-co...-***@public.gmane.org
>> http://beagleboard.org/
>> http://circuitco.com/support/
>>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>



--
Gerald

gerald-hcmAuCOw+vXj4SYmN/***@public.gmane.org
g-coley1-***@public.gmane.org
http://beagleboard.org/
http://circuitco.com/support/

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[rfengr-kFCvZ5XHPypvBvnq28/]

OK sent in the RMA request (S/N 019132935333). The web form didn't work
since I have no email client installed on my lab PC.

On Thursday, June 20, 2013 9:34:13 PM UTC-5, Gerald wrote:
>
> It have not seen it come through. Enter all the information requested into
> an email and send that to r...-hcmAuCOw+vU6XaHZLq/***@public.gmane.org <javascript:>.
>
> Gerald
>
>
> On Thu, Jun 20, 2013 at 9:30 PM, <rfe...-kFCvZ5XHPypvBvnq28/***@public.gmane.org <javascript:>>wrote:
>
>> I submitted an RMA request at that link, but nothing happens after I
>> click submit. Maybe I'll get an email confirmation.
>>
>>
>> On Saturday, June 15, 2013 8:08:33 PM UTC-5, Gerald wrote:
>>
>>> http://circuitco.com/support/**index.php?title=**
>>> BeagleBoneBlack#RMA_Support<http://circuitco.com/support/index.php?title=BeagleBoneBlack#RMA_Support>
>>>
>>> Gerald
>>>
>>>
>>> On Sat, Jun 15, 2013 at 11:25 AM, <rfe...-kFCvZ5XHPypvBvnq28/***@public.gmane.org> wrote:
>>>
>>>>
>>>> I requested an RMA from Newark, but they never sent me one, just
>>>>> refunded my credit card. Do you want me to mail it to you?
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Jun 12, 2013 at 6:29 PM, Gerald Coley <ger...-hcmAuCOw+vXj4SYmN/***@public.gmane.org>wrote:
>>>>>
>>>>>> Would you be willing to request an RMA and have us look at it to see
>>>>>> if it really a HW issue?
>>>>>>
>>>>>> Gerald
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Jun 12, 2013 at 6:20 PM, <rfe...-kFCvZ5XHPypvBvnq28/***@public.gmane.org> wrote:
>>>>>>
>>>>>>> I'm also having the same issue. It was working, then stopped after
>>>>>>> a few hours. Tried the stock Linux, Ubuntu, and Debian. It's a hardware
>>>>>>> issue. Mine is going back to Newark. See posts here for same problem:
>>>>>>>
>>>>>>> http://comments.gmane.org/**gman**e.comp.hardware.**beagleboard.**
>>>>>>> user/45372<http://comments.gmane.org/gmane.comp.hardware.beagleboard.user/45372>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Monday, June 10, 2013 10:23:32 AM UTC-5, necron...-Re5JQEeQqe8M+***@public.gmane.org:
>>>>>>>>
>>>>>>>> I'm having a strange problem with my new BeagleBone black: I can
>>>>>>>> transmit packets from the Ethernet port but not receive them.
>>>>>>>>
>>>>>>>> When using DHCP, I can see (via a sniffer) the DHCP DISCOVER packet
>>>>>>>> sent from the 'bone (via a network sniffer). I can see my DHCP server
>>>>>>>> (dnsmasq 2.59 on stock Ubuntu 12.04 LTS 64-bit server) send a DHCP OFFER.
>>>>>>>> But the 'bone acts like it never hears the offer; it just sends out more
>>>>>>>> DISCOVERs at intervals. (The same DHCP server is working fine for dozens of
>>>>>>>> clients from various vendors. There are plenty of leases left in the pool.)
>>>>>>>>
>>>>>>>> If I set a static address and try to ping something, I see the
>>>>>>>> 'bone send an ARP who-has, I see the target reply with an ARP is-at, but
>>>>>>>> the 'bone just keeps ARP-ing, and never gets an entry in its ARP table.
>>>>>>>>
>>>>>>>> In the ifconfig output, the eth0 interface shows 0 packets received
>>>>>>>> and 0 errors. (The number transmitted is non-0.) Nothing suspicious in the
>>>>>>>> dmesg output that I can see.
>>>>>>>>
>>>>>>>> I've repeated the tests with both the latest Angstrom and with
>>>>>>>> Ubuntu booted off an SD card. Same results. I've tried two different
>>>>>>>> cables, and two different ports on two different Ethernet switches from
>>>>>>>> different vendors. (All ports and cables verified to work fine with my
>>>>>>>> laptop.)
>>>>>>>>
>>>>>>>> One interesting observation: the port seems to always end up on
>>>>>>>> 10Mbps, even when plugged into 100Mbps- (or gigabit-) capable ports. So, it
>>>>>>>> looks like autonegotiation isn't working either.
>>>>>>>>
>>>>>>>> I'm running on a 2A 5.00V regulated bench supply, and the DC looks
>>>>>>>> clean on the o-scope.
>>>>>>>>
>>>>>>>> Other 'bone functions (USB host, USB target, HDMI, LEDs) all seem
>>>>>>>> to work fine.
>>>>>>>>
>>>>>>>> I'm starting to suspect a hardware problem (busted PHY or
>>>>>>>> magnetics; incomplete or bridged trace).
>>>>>>>>
>>>>>>>> Any suggestions for stuff I should try before I RMA the poor little
>>>>>>>> guy? (I'm an experienced Linux user and reasonably competent electronics
>>>>>>>> hobbyist, if that matters.)
>>>>>>>>
>>>>>>> --
>>>>>>> For more options, visit http://beagleboard.org/discuss
>>>>>>> ---
>>>>>>> You received this message because you are subscribed to the Google
>>>>>>> Groups "BeagleBoard" group.
>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>> send an email to beagleboard...@**googlegroups.**com.
>>>>>>>
>>>>>>> For more options, visit https://groups.google.com/**grou**ps/opt_out<https://groups.google.com/groups/opt_out>
>>>>>>> .
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Gerald
>>>>>>
>>>>>> ger...-hcmAuCOw+vXj4SYmN/***@public.gmane.org
>>>>>> g-co...-***@public.gmane.org
>>>>>> http://beagleboard.org/
>>>>>> http://circuitco.com/support/
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Gerald
>>>>>
>>>>> ger...-hcmAuCOw+vXj4SYmN/***@public.gmane.org
>>>>> g-co...-***@public.gmane.org
>>>>> http://beagleboard.org/
>>>>> http://circuitco.com/support/
>>>>>
>>>> --
>>>> For more options, visit http://beagleboard.org/discuss
>>>> ---
>>>> You received this message because you are subscribed to the Google
>>>> Groups "BeagleBoard" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to beagleboard...@**googlegroups.com.
>>>> For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>>>> .
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Gerald
>>>
>>> ger...-hcmAuCOw+vXj4SYmN/***@public.gmane.org
>>> g-co...-***@public.gmane.org
>>> http://beagleboard.org/
>>> http://circuitco.com/support/
>>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard...-/***@public.gmane.org <javascript:>.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>
>
> --
> Gerald
>
> ger...-hcmAuCOw+vXj4SYmN/***@public.gmane.org <javascript:>
> g-co...-***@public.gmane.org <javascript:>
> http://beagleboard.org/
> http://circuitco.com/support/
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[Gerald Coley]

RMA received. Should be approved by Monday.

Gerald



On Fri, Jun 21, 2013 at 9:33 PM, <rfengr-kFCvZ5XHPypvBvnq28/***@public.gmane.org> wrote:

> OK sent in the RMA request (S/N 019132935333). The web form didn't work
> since I have no email client installed on my lab PC.
>
> On Thursday, June 20, 2013 9:34:13 PM UTC-5, Gerald wrote:
>>
>> It have not seen it come through. Enter all the information requested
>> into an email and send that to r...-hcmAuCOw+vU6XaHZLq/leuG/***@public.gmane.org
>>
>> Gerald
>>
>>
>> On Thu, Jun 20, 2013 at 9:30 PM, <rfe...-kFCvZ5XHPypvBvnq28/***@public.gmane.org> wrote:
>>
>>> I submitted an RMA request at that link, but nothing happens after I
>>> click submit. Maybe I'll get an email confirmation.
>>>
>>>
>>> On Saturday, June 15, 2013 8:08:33 PM UTC-5, Gerald wrote:
>>>
>>>> http://circuitco.com/support/**i**ndex.php?title=**BeagleBoneBlack**
>>>> #RMA_Support<http://circuitco.com/support/index.php?title=BeagleBoneBlack#RMA_Support>
>>>>
>>>> Gerald
>>>>
>>>>
>>>> On Sat, Jun 15, 2013 at 11:25 AM, <rfe...-kFCvZ5XHPypvBvnq28/***@public.gmane.org> wrote:
>>>>
>>>>>
>>>>> I requested an RMA from Newark, but they never sent me one, just
>>>>>> refunded my credit card. Do you want me to mail it to you?
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Jun 12, 2013 at 6:29 PM, Gerald Coley <ger...-hcmAuCOw+vXj4SYmN/***@public.gmane.org
>>>>>> > wrote:
>>>>>>
>>>>>>> Would you be willing to request an RMA and have us look at it to see
>>>>>>> if it really a HW issue?
>>>>>>>
>>>>>>> Gerald
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Jun 12, 2013 at 6:20 PM, <rfe...-kFCvZ5XHPypvBvnq28/***@public.gmane.org> wrote:
>>>>>>>
>>>>>>>> I'm also having the same issue. It was working, then stopped after
>>>>>>>> a few hours. Tried the stock Linux, Ubuntu, and Debian. It's a hardware
>>>>>>>> issue. Mine is going back to Newark. See posts here for same problem:
>>>>>>>>
>>>>>>>> http://comments.gmane.org/**gman****e.comp.hardware.**beagleboard.*
>>>>>>>> *us**er/45372<http://comments.gmane.org/gmane.comp.hardware.beagleboard.user/45372>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Monday, June 10, 2013 10:23:32 AM UTC-5, necron...-Re5JQEeQqe8M+***@public.gmane.org:
>>>>>>>>>
>>>>>>>>> I'm having a strange problem with my new BeagleBone black: I can
>>>>>>>>> transmit packets from the Ethernet port but not receive them.
>>>>>>>>>
>>>>>>>>> When using DHCP, I can see (via a sniffer) the DHCP DISCOVER
>>>>>>>>> packet sent from the 'bone (via a network sniffer). I can see my DHCP
>>>>>>>>> server (dnsmasq 2.59 on stock Ubuntu 12.04 LTS 64-bit server) send a DHCP
>>>>>>>>> OFFER. But the 'bone acts like it never hears the offer; it just sends out
>>>>>>>>> more DISCOVERs at intervals. (The same DHCP server is working fine for
>>>>>>>>> dozens of clients from various vendors. There are plenty of leases left in
>>>>>>>>> the pool.)
>>>>>>>>>
>>>>>>>>> If I set a static address and try to ping something, I see the
>>>>>>>>> 'bone send an ARP who-has, I see the target reply with an ARP is-at, but
>>>>>>>>> the 'bone just keeps ARP-ing, and never gets an entry in its ARP table.
>>>>>>>>>
>>>>>>>>> In the ifconfig output, the eth0 interface shows 0 packets
>>>>>>>>> received and 0 errors. (The number transmitted is non-0.) Nothing
>>>>>>>>> suspicious in the dmesg output that I can see.
>>>>>>>>>
>>>>>>>>> I've repeated the tests with both the latest Angstrom and with
>>>>>>>>> Ubuntu booted off an SD card. Same results. I've tried two different
>>>>>>>>> cables, and two different ports on two different Ethernet switches from
>>>>>>>>> different vendors. (All ports and cables verified to work fine with my
>>>>>>>>> laptop.)
>>>>>>>>>
>>>>>>>>> One interesting observation: the port seems to always end up on
>>>>>>>>> 10Mbps, even when plugged into 100Mbps- (or gigabit-) capable ports. So, it
>>>>>>>>> looks like autonegotiation isn't working either.
>>>>>>>>>
>>>>>>>>> I'm running on a 2A 5.00V regulated bench supply, and the DC looks
>>>>>>>>> clean on the o-scope.
>>>>>>>>>
>>>>>>>>> Other 'bone functions (USB host, USB target, HDMI, LEDs) all seem
>>>>>>>>> to work fine.
>>>>>>>>>
>>>>>>>>> I'm starting to suspect a hardware problem (busted PHY or
>>>>>>>>> magnetics; incomplete or bridged trace).
>>>>>>>>>
>>>>>>>>> Any suggestions for stuff I should try before I RMA the poor
>>>>>>>>> little guy? (I'm an experienced Linux user and reasonably competent
>>>>>>>>> electronics hobbyist, if that matters.)
>>>>>>>>>
>>>>>>>> --
>>>>>>>> For more options, visit http://beagleboard.org/discuss
>>>>>>>> ---
>>>>>>>> You received this message because you are subscribed to the Google
>>>>>>>> Groups "BeagleBoard" group.
>>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>>> send an email to beagleboard...@**googlegroups.**co**m.
>>>>>>>>
>>>>>>>> For more options, visit https://groups.google.com/**grou****
>>>>>>>> ps/opt_out <https://groups.google.com/groups/opt_out>.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Gerald
>>>>>>>
>>>>>>> ger...-hcmAuCOw+vXj4SYmN/***@public.gmane.org
>>>>>>> g-co...-***@public.gmane.org
>>>>>>> http://beagleboard.org/
>>>>>>> http://circuitco.com/support/
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Gerald
>>>>>>
>>>>>> ger...-hcmAuCOw+vXj4SYmN/***@public.gmane.org
>>>>>> g-co...-***@public.gmane.org
>>>>>> http://beagleboard.org/
>>>>>> http://circuitco.com/support/
>>>>>>
>>>>> --
>>>>> For more options, visit http://beagleboard.org/discuss
>>>>> ---
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "BeagleBoard" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to beagleboard...@**googlegroups.**com.
>>>>> For more options, visit https://groups.google.com/**grou**ps/opt_out<https://groups.google.com/groups/opt_out>
>>>>> .
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Gerald
>>>>
>>>> ger...-hcmAuCOw+vXj4SYmN/***@public.gmane.org
>>>> g-co...-***@public.gmane.org
>>>> http://beagleboard.org/
>>>> http://circuitco.com/support/
>>>>
>>> --
>>> For more options, visit http://beagleboard.org/discuss
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "BeagleBoard" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to beagleboard...@**googlegroups.com.
>>> For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>>> .
>>>
>>>
>>>
>>
>>
>>
>> --
>> Gerald
>>
>> ger...-hcmAuCOw+vXj4SYmN/***@public.gmane.org
>> g-co...-***@public.gmane.org
>> http://beagleboard.org/
>> http://circuitco.com/support/
>>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>



--
Gerald

gerald-hcmAuCOw+vXj4SYmN/***@public.gmane.org
g-coley1-***@public.gmane.org
http://beagleboard.org/
http://circuitco.com/support/

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[rfengr-kFCvZ5XHPypvBvnq28/]

I submitted the paperwork to Newark for a RMA, but they never sent me an
RMA, just refunded my credit card. Oh well! Do you want me to send the
thing to you?

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[Kathryn Adeney]

I see a similar issue on my Beaglebone Black. eth0 comes up initially but
if I take it down it won't come back without a reboot. When it is in this
state, Wireshark can see packets coming to and from the BBB on the wire,
but TX and RX stats displayed in ifconfig do not increase.

I have tried this with:
- two different BBBs,
- three different Linux 3.8 loads (the 3.8.11 it shipped with, 3.8.13
(2013-06-06, booting from SD), and a Debian demo image (3.8.13-bone20).
- 5V1A supply or USB power.
- I have the serial FTDI cable.

Example:

--- after boot (just the eth0 dmesg shown): ----

***@beaglebone:~# dmesg
... // just the eth -related ones (I think)
[ 12.843873] net eth0: initializing cpsw version 1.12 (0)
[ 12.848216] net eth0: phy found : id is : 0x7c0f1
[ 12.848248] libphy: PHY 4a101000.mdio:01 not found
[ 12.853364] net eth0: phy 4a101000.mdio:01 not found on slave 1
[ 12.920613] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 15.926429] libphy: 4a101000.mdio:00 - Link is Up - 100/Full
[ 15.926491] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

// eth0 did dhcp and came up automatically

***@beaglebone:~# ifconfig eth0
eth0 Link encap:Ethernet HWaddr C8:A0:30:B6:B0:AB
inet addr:10.10.10.100 Bcast:10.10.10.255 Mask:255.255.255.0
inet6 addr: fe80::caa0:30ff:feb6:b0ab/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:16 errors:0 dropped:1 overruns:0 frame:0
TX packets:41 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2421 (2.3 KiB) TX bytes:5349 (5.2 KiB)
Interrupt:56

// take it down.

***@beaglebone:~# ifconfig eth0 down
***@beaglebone:~# ifconfig -a eth0
eth0 Link encap:Ethernet HWaddr C8:A0:30:B6:B0:AB
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:21 errors:0 dropped:1 overruns:0 frame:0
TX packets:47 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3119 (3.0 KiB) TX bytes:5841 (5.7 KiB)
Interrupt:56

// take it back up.
// TX and RX stop incrementing, even though when we do
// udhcpc we can see traffic to and from the bone on the wire!.
// ( note I think the libphy messages about mdio:01 are a red herring,
// relating to the not-present second slave port?? )

***@beaglebone:~# ifconfig eth0 up
[ 46.543648] libphy: PHY 4a101000.mdio:01 not found

[ 46.548717] net eth0: phy 4a101000.mdio:01 not found on slave 1
***@beaglebone:~#
***@beaglebone:~# ifconfig eth0
eth0 Link encap:Ethernet HWaddr C8:A0:30:B6:B0:AB
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:21 errors:0 dropped:1 overruns:0 frame:0
TX packets:47 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3119 (3.0 KiB) TX bytes:5841 (5.7 KiB)
Interrupt:56

***@beaglebone:~# udhcpc -i eth0
udhcpc (v1.20.2) started
Sending discover...
Sending discover...
Sending discover...
Sending discover...
Sending discover...
Sending discover...
^C
***@beaglebone:~# ifconfig eth0
eth0 Link encap:Ethernet HWaddr C8:A0:30:B6:B0:AB
inet addr:169.254.66.231 Bcast:169.254.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:21 errors:0 dropped:1 overruns:0 frame:0
TX packets:47 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3119 (3.0 KiB) TX bytes:5841 (5.7 KiB)
Interrupt:56

// new dmesg after ifconfig eth0 down and then ifconfig eth0 up:

[ 250.747282] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

[ 264.214253] net eth0: initializing cpsw version 1.12 (0)

[ 264.217970] net eth0: phy found : id is : 0x7c0f1

[ 264.218000] libphy: PHY 4a101000.mdio:01 not found

[ 264.223112] net eth0: phy 4a101000.mdio:01 not found on slave 1

[ 264.234179] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

[ 266.223290] libphy: 4a101000.mdio:00 - Link is Up - 100/Full

[ 266.223348] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

When testing it with the debian image I also tried

network restart /etc/init.d/network restart, same results.

I have found eth0 is very stable on the Beaglebone White and from the
schematic nothing has changed, so I am wondering about the driver changes
under 3.8 kernel ... but can't find any known issues or patches or
anything. Linux Noob so maybe looking in the wrong places.

Thanks -

Kathryn.


--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[Dale Schaafsma]

I can reproduce this behavior as well...note that I'm not on the 2013-06-06
image, but on the 2013.05.27 (I'm waiting to upgrade to 2013.06.17).
Initially I suspected that this was due to interaction with connman (which
is quite poorly documented) however I'm not so sure.

In short, if "ifconfig eth0 down" is ever run, reboot is required to
recover the ethernet port (even disconnecting/reconnecting the cable won't
recover the port)
Also it behaves as the OP and Kathryn noted (transmit counted in ifconfig
counts, but no rx counts).

So perhaps there's a software bug here? maybe something is not
re-configured properly after "ifconfig eth0 up" or some power management
interaction?

FWIW, the following will disconnect/reconnect without issues..but note the
interface is not marked down.
Connman flags are: * = favorite, A = autoconnect, R = ready, O = online

***@beaglebone:~# /usr/lib/connman/test/test-connman services
* AO Wired { ethernet_c8a030aec6a8_cable }
***@beaglebone:~# /usr/lib/connman/test/test-connman disconnect
ethernet_c8a030aec6a8_cable
***@beaglebone:~# ifconfig eth0
eth0 Link encap:Ethernet HWaddr C8:A0:30:AE:C6:A8
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:13 errors:0 dropped:0 overruns:0 frame:0
TX packets:51 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2317 (2.2 KiB) TX bytes:10628 (10.3 KiB)
Interrupt:56

***@beaglebone:~# /usr/lib/connman/test/test-connman state
System is idle
***@beaglebone:~# /usr/lib/connman/test/test-connman services
* A Wired { ethernet_c8a030aec6a8_cable }
***@beaglebone:~# /usr/lib/connman/test/test-connman connect
ethernet_c8a030aec
6a8_cable
***@beaglebone:~# /usr/lib/connman/test/test-connman services
* AO Wired { ethernet_c8a030aec6a8_cable }
***@beaglebone:~# ifconfig eth0
eth0 Link encap:Ethernet HWaddr C8:A0:30:AE:C6:A8
inet addr:192.168.3.200 Bcast:192.168.3.255 Mask:255.255.255.0
inet6 addr: fe80::caa0:30ff:feae:c6a8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:26 errors:0 dropped:0 overruns:0 frame:0
TX packets:98 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4634 (4.5 KiB) TX bytes:20521 (20.0 KiB)
Interrupt:56

***@beaglebone:~# ping 192.168.3.1
PING 192.168.3.1 (192.168.3.1) 56(84) bytes of data.
64 bytes from 192.168.3.1: icmp_req=1 ttl=64 time=0.275 ms




-Dale


On Thursday, June 13, 2013 11:27:09 AM UTC-5, Kathryn Adeney wrote:
>
> I see a similar issue on my Beaglebone Black. eth0 comes up initially but
> if I take it down it won't come back without a reboot. When it is in this
> state, Wireshark can see packets coming to and from the BBB on the wire,
> but TX and RX stats displayed in ifconfig do not increase.
>
> I have tried this with:
> - two different BBBs,
> - three different Linux 3.8 loads (the 3.8.11 it shipped with, 3.8.13
> (2013-06-06, booting from SD), and a Debian demo image (3.8.13-bone20).
> - 5V1A supply or USB power.
> - I have the serial FTDI cable.
>
> Example:
>
> --- after boot (just the eth0 dmesg shown): ----
>
> ***@beaglebone:~# dmesg
> ... // just the eth -related ones (I think)
> [ 12.843873] net eth0: initializing cpsw version 1.12 (0)
> [ 12.848216] net eth0: phy found : id is : 0x7c0f1
> [ 12.848248] libphy: PHY 4a101000.mdio:01 not found
> [ 12.853364] net eth0: phy 4a101000.mdio:01 not found on slave 1
> [ 12.920613] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
> [ 15.926429] libphy: 4a101000.mdio:00 - Link is Up - 100/Full
> [ 15.926491] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>
> // eth0 did dhcp and came up automatically
>
> ***@beaglebone:~# ifconfig eth0
> eth0 Link encap:Ethernet HWaddr C8:A0:30:B6:B0:AB
> inet addr:10.10.10.100 Bcast:10.10.10.255 Mask:255.255.255.0
> inet6 addr: fe80::caa0:30ff:feb6:b0ab/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:16 errors:0 dropped:1 overruns:0 frame:0
> TX packets:41 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:2421 (2.3 KiB) TX bytes:5349 (5.2 KiB)
> Interrupt:56
>
> // take it down.
>
> ***@beaglebone:~# ifconfig eth0 down
> ***@beaglebone:~# ifconfig -a eth0
> eth0 Link encap:Ethernet HWaddr C8:A0:30:B6:B0:AB
> BROADCAST MULTICAST MTU:1500 Metric:1
> RX packets:21 errors:0 dropped:1 overruns:0 frame:0
> TX packets:47 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:3119 (3.0 KiB) TX bytes:5841 (5.7 KiB)
> Interrupt:56
>
> // take it back up.
> // TX and RX stop incrementing, even though when we do
> // udhcpc we can see traffic to and from the bone on the wire!.
> // ( note I think the libphy messages about mdio:01 are a red herring,
> // relating to the not-present second slave port?? )
>
> ***@beaglebone:~# ifconfig eth0 up
> [ 46.543648] libphy: PHY 4a101000.mdio:01 not found
>
> [ 46.548717] net eth0: phy 4a101000.mdio:01 not found on slave 1
> ***@beaglebone:~#
> ***@beaglebone:~# ifconfig eth0
> eth0 Link encap:Ethernet HWaddr C8:A0:30:B6:B0:AB
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:21 errors:0 dropped:1 overruns:0 frame:0
> TX packets:47 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:3119 (3.0 KiB) TX bytes:5841 (5.7 KiB)
> Interrupt:56
>
> ***@beaglebone:~# udhcpc -i eth0
> udhcpc (v1.20.2) started
> Sending discover...
> Sending discover...
> Sending discover...
> Sending discover...
> Sending discover...
> Sending discover...
> ^C
> ***@beaglebone:~# ifconfig eth0
> eth0 Link encap:Ethernet HWaddr C8:A0:30:B6:B0:AB
> inet addr:169.254.66.231 Bcast:169.254.255.255 Mask:255.255.0.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:21 errors:0 dropped:1 overruns:0 frame:0
> TX packets:47 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:3119 (3.0 KiB) TX bytes:5841 (5.7 KiB)
> Interrupt:56
>
> // new dmesg after ifconfig eth0 down and then ifconfig eth0 up:
>
> [ 250.747282] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
>
> [ 264.214253] net eth0: initializing cpsw version 1.12 (0)
>
> [ 264.217970] net eth0: phy found : id is : 0x7c0f1
>
> [ 264.218000] libphy: PHY 4a101000.mdio:01 not found
>
> [ 264.223112] net eth0: phy 4a101000.mdio:01 not found on slave 1
>
> [ 264.234179] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
>
> [ 266.223290] libphy: 4a101000.mdio:00 - Link is Up - 100/Full
>
> [ 266.223348] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>
> When testing it with the debian image I also tried
>
> network restart /etc/init.d/network restart, same results.
>
> I have found eth0 is very stable on the Beaglebone White and from the
> schematic nothing has changed, so I am wondering about the driver changes
> under 3.8 kernel ... but can't find any known issues or patches or
> anything. Linux Noob so maybe looking in the wrong places.
>
> Thanks -
>
> Kathryn.
>
>
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[PLyttle]

Similar story here.
running Arch, Ethernet connnects once with DHCP (both dhcpcd and dhclient),
either at boot or when plugged in (using netctl-ifplugd). after replugging,
or down - up no more received packets.
the same configuration on a raspberry pi works without a hitch (off course
the raspi is armv6l and kernel 3.6.11 (no device tree)). I don't think I
made a configuration error.

running Arch, kernel 3.8.13-bone21 (home built) and kernel 3.8.13-3 (stock)
same behavior on both
It is clearly not limited to one distro.

LP


On Wednesday, June 19, 2013 9:27:40 PM UTC+2, Dale Schaafsma wrote:
>
> I can reproduce this behavior as well...note that I'm not on the
> 2013-06-06 image, but on the 2013.05.27 (I'm waiting to upgrade to
> 2013.06.17).
> Initially I suspected that this was due to interaction with connman (which
> is quite poorly documented) however I'm not so sure.
>
> In short, if "ifconfig eth0 down" is ever run, reboot is required to
> recover the ethernet port (even disconnecting/reconnecting the cable won't
> recover the port)
> Also it behaves as the OP and Kathryn noted (transmit counted in ifconfig
> counts, but no rx counts).
>
> So perhaps there's a software bug here? maybe something is not
> re-configured properly after "ifconfig eth0 up" or some power management
> interaction?
>
> FWIW, the following will disconnect/reconnect without issues..but note the
> interface is not marked down.
> Connman flags are: * = favorite, A = autoconnect, R = ready, O = online
>
> ***@beaglebone:~# /usr/lib/connman/test/test-connman services
> * AO Wired { ethernet_c8a030aec6a8_cable }
> ***@beaglebone:~# /usr/lib/connman/test/test-connman disconnect
> ethernet_c8a030aec6a8_cable
> ***@beaglebone:~# ifconfig eth0
> eth0 Link encap:Ethernet HWaddr C8:A0:30:AE:C6:A8
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:13 errors:0 dropped:0 overruns:0 frame:0
> TX packets:51 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:2317 (2.2 KiB) TX bytes:10628 (10.3 KiB)
> Interrupt:56
>
> ***@beaglebone:~# /usr/lib/connman/test/test-connman state
> System is idle
> ***@beaglebone:~# /usr/lib/connman/test/test-connman services
> * A Wired { ethernet_c8a030aec6a8_cable }
> ***@beaglebone:~# /usr/lib/connman/test/test-connman connect
> ethernet_c8a030aec
> 6a8_cable
> ***@beaglebone:~# /usr/lib/connman/test/test-connman services
> * AO Wired { ethernet_c8a030aec6a8_cable }
> ***@beaglebone:~# ifconfig eth0
> eth0 Link encap:Ethernet HWaddr C8:A0:30:AE:C6:A8
> inet addr:192.168.3.200 Bcast:192.168.3.255 Mask:255.255.255.0
> inet6 addr: fe80::caa0:30ff:feae:c6a8/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:26 errors:0 dropped:0 overruns:0 frame:0
> TX packets:98 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:4634 (4.5 KiB) TX bytes:20521 (20.0 KiB)
> Interrupt:56
>
> ***@beaglebone:~# ping 192.168.3.1
> PING 192.168.3.1 (192.168.3.1) 56(84) bytes of data.
> 64 bytes from 192.168.3.1: icmp_req=1 ttl=64 time=0.275 ms
>
>
>
>
> -Dale
>
>
> On Thursday, June 13, 2013 11:27:09 AM UTC-5, Kathryn Adeney wrote:
>>
>> I see a similar issue on my Beaglebone Black. eth0 comes up initially
>> but if I take it down it won't come back without a reboot. When it is in
>> this state, Wireshark can see packets coming to and from the BBB on the
>> wire, but TX and RX stats displayed in ifconfig do not increase.
>>
>> I have tried this with:
>> - two different BBBs,
>> - three different Linux 3.8 loads (the 3.8.11 it shipped with, 3.8.13
>> (2013-06-06, booting from SD), and a Debian demo image (3.8.13-bone20).
>> - 5V1A supply or USB power.
>> - I have the serial FTDI cable.
>>
>> Example:
>>
>> --- after boot (just the eth0 dmesg shown): ----
>>
>> ***@beaglebone:~# dmesg
>> ... // just the eth -related ones (I think)
>> [ 12.843873] net eth0: initializing cpsw version 1.12 (0)
>> [ 12.848216] net eth0: phy found : id is : 0x7c0f1
>> [ 12.848248] libphy: PHY 4a101000.mdio:01 not found
>> [ 12.853364] net eth0: phy 4a101000.mdio:01 not found on slave 1
>> [ 12.920613] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
>> [ 15.926429] libphy: 4a101000.mdio:00 - Link is Up - 100/Full
>> [ 15.926491] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>>
>> // eth0 did dhcp and came up automatically
>>
>> ***@beaglebone:~# ifconfig eth0
>> eth0 Link encap:Ethernet HWaddr C8:A0:30:B6:B0:AB
>> inet addr:10.10.10.100 Bcast:10.10.10.255 Mask:255.255.255.0
>> inet6 addr: fe80::caa0:30ff:feb6:b0ab/64 Scope:Link
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> RX packets:16 errors:0 dropped:1 overruns:0 frame:0
>> TX packets:41 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:1000
>> RX bytes:2421 (2.3 KiB) TX bytes:5349 (5.2 KiB)
>> Interrupt:56
>>
>> // take it down.
>>
>> ***@beaglebone:~# ifconfig eth0 down
>> ***@beaglebone:~# ifconfig -a eth0
>> eth0 Link encap:Ethernet HWaddr C8:A0:30:B6:B0:AB
>> BROADCAST MULTICAST MTU:1500 Metric:1
>> RX packets:21 errors:0 dropped:1 overruns:0 frame:0
>> TX packets:47 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:1000
>> RX bytes:3119 (3.0 KiB) TX bytes:5841 (5.7 KiB)
>> Interrupt:56
>>
>> // take it back up.
>> // TX and RX stop incrementing, even though when we do
>> // udhcpc we can see traffic to and from the bone on the wire!.
>> // ( note I think the libphy messages about mdio:01 are a red herring,
>> // relating to the not-present second slave port?? )
>>
>> ***@beaglebone:~# ifconfig eth0 up
>> [ 46.543648] libphy: PHY 4a101000.mdio:01 not found
>>
>> [ 46.548717] net eth0: phy 4a101000.mdio:01 not found on slave 1
>> ***@beaglebone:~#
>> ***@beaglebone:~# ifconfig eth0
>> eth0 Link encap:Ethernet HWaddr C8:A0:30:B6:B0:AB
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> RX packets:21 errors:0 dropped:1 overruns:0 frame:0
>> TX packets:47 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:1000
>> RX bytes:3119 (3.0 KiB) TX bytes:5841 (5.7 KiB)
>> Interrupt:56
>>
>> ***@beaglebone:~# udhcpc -i eth0
>> udhcpc (v1.20.2) started
>> Sending discover...
>> Sending discover...
>> Sending discover...
>> Sending discover...
>> Sending discover...
>> Sending discover...
>> ^C
>> ***@beaglebone:~# ifconfig eth0
>> eth0 Link encap:Ethernet HWaddr C8:A0:30:B6:B0:AB
>> inet addr:169.254.66.231 Bcast:169.254.255.255
>> Mask:255.255.0.0
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> RX packets:21 errors:0 dropped:1 overruns:0 frame:0
>> TX packets:47 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:1000
>> RX bytes:3119 (3.0 KiB) TX bytes:5841 (5.7 KiB)
>> Interrupt:56
>>
>> // new dmesg after ifconfig eth0 down and then ifconfig eth0 up:
>>
>> [ 250.747282] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
>>
>> [ 264.214253] net eth0: initializing cpsw version 1.12 (0)
>>
>> [ 264.217970] net eth0: phy found : id is : 0x7c0f1
>>
>> [ 264.218000] libphy: PHY 4a101000.mdio:01 not found
>>
>> [ 264.223112] net eth0: phy 4a101000.mdio:01 not found on slave 1
>>
>> [ 264.234179] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
>>
>> [ 266.223290] libphy: 4a101000.mdio:00 - Link is Up - 100/Full
>>
>> [ 266.223348] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>>
>> When testing it with the debian image I also tried
>>
>> network restart /etc/init.d/network restart, same results.
>>
>> I have found eth0 is very stable on the Beaglebone White and from the
>> schematic nothing has changed, so I am wondering about the driver changes
>> under 3.8 kernel ... but can't find any known issues or patches or
>> anything. Linux Noob so maybe looking in the wrong places.
>>
>> Thanks -
>>
>> Kathryn.
>>
>>
>>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[nemanja]

PLyttle,

I'm having the exact same issue with those kernels. I tried RCN's Ubuntu
and Debian images and both have the issue, and another with my own custom
kernel based on that one. Unplugging the ethernet for >30 seconds and
plugging back in makes it no longer work, and doing ifconfig eth0 down,
then up and it never works, dhclient can't get another IP.
But it does work on startup the once, like you said.

I'm not sure it is a hardware issue though because it happens on both of my
rev A5A BBB boards with Ubuntu/Debian but NOT with the Angstrom image, that
one seems to come back up with Ethernet no problem.

On Wednesday, June 19, 2013 3:54:21 PM UTC-5, PLyttle wrote:
>
> Similar story here.
> running Arch, Ethernet connnects once with DHCP (both dhcpcd and
> dhclient), either at boot or when plugged in (using netctl-ifplugd). after
> replugging, or down - up no more received packets.
> the same configuration on a raspberry pi works without a hitch (off course
> the raspi is armv6l and kernel 3.6.11 (no device tree)). I don't think I
> made a configuration error.
>
> running Arch, kernel 3.8.13-bone21 (home built) and kernel 3.8.13-3
> (stock) same behavior on both
> It is clearly not limited to one distro.
>
> LP
>
>
> On Wednesday, June 19, 2013 9:27:40 PM UTC+2, Dale Schaafsma wrote:
>>
>> I can reproduce this behavior as well...note that I'm not on the
>> 2013-06-06 image, but on the 2013.05.27 (I'm waiting to upgrade to
>> 2013.06.17).
>> Initially I suspected that this was due to interaction with connman
>> (which is quite poorly documented) however I'm not so sure.
>>
>> In short, if "ifconfig eth0 down" is ever run, reboot is required to
>> recover the ethernet port (even disconnecting/reconnecting the cable won't
>> recover the port)
>> Also it behaves as the OP and Kathryn noted (transmit counted in ifconfig
>> counts, but no rx counts).
>>
>> So perhaps there's a software bug here? maybe something is not
>> re-configured properly after "ifconfig eth0 up" or some power management
>> interaction?
>>
>> FWIW, the following will disconnect/reconnect without issues..but note
>> the interface is not marked down.
>> Connman flags are: * = favorite, A = autoconnect, R = ready, O = online
>>
>> ***@beaglebone:~# /usr/lib/connman/test/test-connman services
>> * AO Wired { ethernet_c8a030aec6a8_cable }
>> ***@beaglebone:~# /usr/lib/connman/test/test-connman disconnect
>> ethernet_c8a030aec6a8_cable
>> ***@beaglebone:~# ifconfig eth0
>> eth0 Link encap:Ethernet HWaddr C8:A0:30:AE:C6:A8
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> RX packets:13 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:51 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:1000
>> RX bytes:2317 (2.2 KiB) TX bytes:10628 (10.3 KiB)
>> Interrupt:56
>>
>> ***@beaglebone:~# /usr/lib/connman/test/test-connman state
>> System is idle
>> ***@beaglebone:~# /usr/lib/connman/test/test-connman services
>> * A Wired { ethernet_c8a030aec6a8_cable }
>> ***@beaglebone:~# /usr/lib/connman/test/test-connman connect
>> ethernet_c8a030aec
>> 6a8_cable
>> ***@beaglebone:~# /usr/lib/connman/test/test-connman services
>> * AO Wired { ethernet_c8a030aec6a8_cable }
>> ***@beaglebone:~# ifconfig eth0
>> eth0 Link encap:Ethernet HWaddr C8:A0:30:AE:C6:A8
>> inet addr:192.168.3.200 Bcast:192.168.3.255 Mask:255.255.255.0
>> inet6 addr: fe80::caa0:30ff:feae:c6a8/64 Scope:Link
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> RX packets:26 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:98 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:1000
>> RX bytes:4634 (4.5 KiB) TX bytes:20521 (20.0 KiB)
>> Interrupt:56
>>
>> ***@beaglebone:~# ping 192.168.3.1
>> PING 192.168.3.1 (192.168.3.1) 56(84) bytes of data.
>> 64 bytes from 192.168.3.1: icmp_req=1 ttl=64 time=0.275 ms
>>
>>
>>
>>
>> -Dale
>>
>>
>> On Thursday, June 13, 2013 11:27:09 AM UTC-5, Kathryn Adeney wrote:
>>>
>>> I see a similar issue on my Beaglebone Black. eth0 comes up initially
>>> but if I take it down it won't come back without a reboot. When it is in
>>> this state, Wireshark can see packets coming to and from the BBB on the
>>> wire, but TX and RX stats displayed in ifconfig do not increase.
>>>
>>> I have tried this with:
>>> - two different BBBs,
>>> - three different Linux 3.8 loads (the 3.8.11 it shipped with, 3.8.13
>>> (2013-06-06, booting from SD), and a Debian demo image (3.8.13-bone20).
>>> - 5V1A supply or USB power.
>>> - I have the serial FTDI cable.
>>>
>>> Example:
>>>
>>> --- after boot (just the eth0 dmesg shown): ----
>>>
>>> ***@beaglebone:~# dmesg
>>> ... // just the eth -related ones (I think)
>>> [ 12.843873] net eth0: initializing cpsw version 1.12 (0)
>>> [ 12.848216] net eth0: phy found : id is : 0x7c0f1
>>> [ 12.848248] libphy: PHY 4a101000.mdio:01 not found
>>> [ 12.853364] net eth0: phy 4a101000.mdio:01 not found on slave 1
>>> [ 12.920613] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
>>> [ 15.926429] libphy: 4a101000.mdio:00 - Link is Up - 100/Full
>>> [ 15.926491] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>>>
>>> // eth0 did dhcp and came up automatically
>>>
>>> ***@beaglebone:~# ifconfig eth0
>>> eth0 Link encap:Ethernet HWaddr C8:A0:30:B6:B0:AB
>>> inet addr:10.10.10.100 Bcast:10.10.10.255 Mask:255.255.255.0
>>> inet6 addr: fe80::caa0:30ff:feb6:b0ab/64 Scope:Link
>>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>>> RX packets:16 errors:0 dropped:1 overruns:0 frame:0
>>> TX packets:41 errors:0 dropped:0 overruns:0 carrier:0
>>> collisions:0 txqueuelen:1000
>>> RX bytes:2421 (2.3 KiB) TX bytes:5349 (5.2 KiB)
>>> Interrupt:56
>>>
>>> // take it down.
>>>
>>> ***@beaglebone:~# ifconfig eth0 down
>>> ***@beaglebone:~# ifconfig -a eth0
>>> eth0 Link encap:Ethernet HWaddr C8:A0:30:B6:B0:AB
>>> BROADCAST MULTICAST MTU:1500 Metric:1
>>> RX packets:21 errors:0 dropped:1 overruns:0 frame:0
>>> TX packets:47 errors:0 dropped:0 overruns:0 carrier:0
>>> collisions:0 txqueuelen:1000
>>> RX bytes:3119 (3.0 KiB) TX bytes:5841 (5.7 KiB)
>>> Interrupt:56
>>>
>>> // take it back up.
>>> // TX and RX stop incrementing, even though when we do
>>> // udhcpc we can see traffic to and from the bone on the wire!.
>>> // ( note I think the libphy messages about mdio:01 are a red herring,
>>> // relating to the not-present second slave port?? )
>>>
>>> ***@beaglebone:~# ifconfig eth0 up
>>> [ 46.543648] libphy: PHY 4a101000.mdio:01 not found
>>>
>>> [ 46.548717] net eth0: phy 4a101000.mdio:01 not found on slave 1
>>> ***@beaglebone:~#
>>> ***@beaglebone:~# ifconfig eth0
>>> eth0 Link encap:Ethernet HWaddr C8:A0:30:B6:B0:AB
>>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>>> RX packets:21 errors:0 dropped:1 overruns:0 frame:0
>>> TX packets:47 errors:0 dropped:0 overruns:0 carrier:0
>>> collisions:0 txqueuelen:1000
>>> RX bytes:3119 (3.0 KiB) TX bytes:5841 (5.7 KiB)
>>> Interrupt:56
>>>
>>> ***@beaglebone:~# udhcpc -i eth0
>>> udhcpc (v1.20.2) started
>>> Sending discover...
>>> Sending discover...
>>> Sending discover...
>>> Sending discover...
>>> Sending discover...
>>> Sending discover...
>>> ^C
>>> ***@beaglebone:~# ifconfig eth0
>>> eth0 Link encap:Ethernet HWaddr C8:A0:30:B6:B0:AB
>>> inet addr:169.254.66.231 Bcast:169.254.255.255
>>> Mask:255.255.0.0
>>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>>> RX packets:21 errors:0 dropped:1 overruns:0 frame:0
>>> TX packets:47 errors:0 dropped:0 overruns:0 carrier:0
>>> collisions:0 txqueuelen:1000
>>> RX bytes:3119 (3.0 KiB) TX bytes:5841 (5.7 KiB)
>>> Interrupt:56
>>>
>>> // new dmesg after ifconfig eth0 down and then ifconfig eth0 up:
>>>
>>> [ 250.747282] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
>>>
>>> [ 264.214253] net eth0: initializing cpsw version 1.12 (0)
>>>
>>> [ 264.217970] net eth0: phy found : id is : 0x7c0f1
>>>
>>> [ 264.218000] libphy: PHY 4a101000.mdio:01 not found
>>>
>>> [ 264.223112] net eth0: phy 4a101000.mdio:01 not found on slave 1
>>>
>>> [ 264.234179] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
>>>
>>> [ 266.223290] libphy: 4a101000.mdio:00 - Link is Up - 100/Full
>>>
>>> [ 266.223348] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>>>
>>> When testing it with the debian image I also tried
>>>
>>> network restart /etc/init.d/network restart, same results.
>>>
>>> I have found eth0 is very stable on the Beaglebone White and from the
>>> schematic nothing has changed, so I am wondering about the driver changes
>>> under 3.8 kernel ... but can't find any known issues or patches or
>>> anything. Linux Noob so maybe looking in the wrong places.
>>>
>>> Thanks -
>>>
>>> Kathryn.
>>>
>>>
>>>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[Robert Nelson]

On Mon, Jun 24, 2013 at 11:47 AM, nemanja <nemik-***@public.gmane.org> wrote:
> PLyttle,
>
> I'm having the exact same issue with those kernels. I tried RCN's Ubuntu and
> Debian images and both have the issue, and another with my own custom kernel
> based on that one. Unplugging the ethernet for >30 seconds and plugging back
> in makes it no longer work, and doing ifconfig eth0 down, then up and it
> never works, dhclient can't get another IP.
> But it does work on startup the once, like you said.
>
> I'm not sure it is a hardware issue though because it happens on both of my
> rev A5A BBB boards with Ubuntu/Debian but NOT with the Angstrom image, that
> one seems to come back up with Ethernet no problem.

I believe it's a problem in the cpsw ethernet driver.. As the
beaglebone (classic) seems to have the same issue with v3.8.x, where
it worked fine with the old v3.2.x board tree..

Regards,

--
Robert Nelson
http://www.rcn-ee.com/

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[nemanja]

Thank you Robert, that would make sense.
I suspected there may be problems with the SMSC LAN8710 driver and tried
this patch: http://www.spinics.net/lists/netdev/msg218399.html on the
3.8.13-22 kernel (newest pull from git) but it did not appear to fix it.

On Monday, June 24, 2013 11:51:55 AM UTC-5, RobertCNelson wrote:
>
> On Mon, Jun 24, 2013 at 11:47 AM, nemanja <ne...-***@public.gmane.org <javascript:>>
> wrote:
> > PLyttle,
> >
> > I'm having the exact same issue with those kernels. I tried RCN's Ubuntu
> and
> > Debian images and both have the issue, and another with my own custom
> kernel
> > based on that one. Unplugging the ethernet for >30 seconds and plugging
> back
> > in makes it no longer work, and doing ifconfig eth0 down, then up and it
> > never works, dhclient can't get another IP.
> > But it does work on startup the once, like you said.
> >
> > I'm not sure it is a hardware issue though because it happens on both of
> my
> > rev A5A BBB boards with Ubuntu/Debian but NOT with the Angstrom image,
> that
> > one seems to come back up with Ethernet no problem.
>
> I believe it's a problem in the cpsw ethernet driver.. As the
> beaglebone (classic) seems to have the same issue with v3.8.x, where
> it worked fine with the old v3.2.x board tree..
>
> Regards,
>
> --
> Robert Nelson
> http://www.rcn-ee.com/
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[nemanja]

I guess the driver isn't fully supported by the kernel? According
to http://processors.wiki.ti.com/index.php/AM335x_CPSW_(Ethernet)_Driver's_Guide
I should be able to change things like Interrupt Pacing, but it says it is
not supported:
"
***@arm:~$ sudo ethtool -C eth0 rx-usecs 500
Cannot get device coalesce settings: Operation not supported
"


On Monday, June 24, 2013 12:55:07 PM UTC-5, nemanja wrote:
>
> Thank you Robert, that would make sense.
> I suspected there may be problems with the SMSC LAN8710 driver and tried
> this patch: http://www.spinics.net/lists/netdev/msg218399.html on the
> 3.8.13-22 kernel (newest pull from git) but it did not appear to fix it.
>
> On Monday, June 24, 2013 11:51:55 AM UTC-5, RobertCNelson wrote:
>>
>> On Mon, Jun 24, 2013 at 11:47 AM, nemanja <ne...-***@public.gmane.org> wrote:
>> > PLyttle,
>> >
>> > I'm having the exact same issue with those kernels. I tried RCN's
>> Ubuntu and
>> > Debian images and both have the issue, and another with my own custom
>> kernel
>> > based on that one. Unplugging the ethernet for >30 seconds and plugging
>> back
>> > in makes it no longer work, and doing ifconfig eth0 down, then up and
>> it
>> > never works, dhclient can't get another IP.
>> > But it does work on startup the once, like you said.
>> >
>> > I'm not sure it is a hardware issue though because it happens on both
>> of my
>> > rev A5A BBB boards with Ubuntu/Debian but NOT with the Angstrom image,
>> that
>> > one seems to come back up with Ethernet no problem.
>>
>> I believe it's a problem in the cpsw ethernet driver.. As the
>> beaglebone (classic) seems to have the same issue with v3.8.x, where
>> it worked fine with the old v3.2.x board tree..
>>
>> Regards,
>>
>> --
>> Robert Nelson
>> http://www.rcn-ee.com/
>>
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[nemanja]

I did notice one more curious thing. Sometimes after I unplug and plug the
Ethernet cable back in and cannot ping the BBB, if I connect the USB to
establish the USB gadget ethernet, it forces the other one to come back up
and respond.

If I do this over and over a few times, it eventually stops working, but
for a couple of tries, it did somehow force the main PHY to recover.

On Monday, June 24, 2013 1:06:43 PM UTC-5, nemanja wrote:
>
> I guess the driver isn't fully supported by the kernel? According to
> http://processors.wiki.ti.com/index.php/AM335x_CPSW_(Ethernet)_Driver's_Guide I should be able to change things like Interrupt Pacing, but it says it is
> not supported:
> "
> ***@arm:~$ sudo ethtool -C eth0 rx-usecs 500
> Cannot get device coalesce settings: Operation not supported
> "
>
>
> On Monday, June 24, 2013 12:55:07 PM UTC-5, nemanja wrote:
>>
>> Thank you Robert, that would make sense.
>> I suspected there may be problems with the SMSC LAN8710 driver and tried
>> this patch: http://www.spinics.net/lists/netdev/msg218399.html on the
>> 3.8.13-22 kernel (newest pull from git) but it did not appear to fix it.
>>
>> On Monday, June 24, 2013 11:51:55 AM UTC-5, RobertCNelson wrote:
>>>
>>> On Mon, Jun 24, 2013 at 11:47 AM, nemanja <ne...-***@public.gmane.org> wrote:
>>> > PLyttle,
>>> >
>>> > I'm having the exact same issue with those kernels. I tried RCN's
>>> Ubuntu and
>>> > Debian images and both have the issue, and another with my own custom
>>> kernel
>>> > based on that one. Unplugging the ethernet for >30 seconds and
>>> plugging back
>>> > in makes it no longer work, and doing ifconfig eth0 down, then up and
>>> it
>>> > never works, dhclient can't get another IP.
>>> > But it does work on startup the once, like you said.
>>> >
>>> > I'm not sure it is a hardware issue though because it happens on both
>>> of my
>>> > rev A5A BBB boards with Ubuntu/Debian but NOT with the Angstrom image,
>>> that
>>> > one seems to come back up with Ethernet no problem.
>>>
>>> I believe it's a problem in the cpsw ethernet driver.. As the
>>> beaglebone (classic) seems to have the same issue with v3.8.x, where
>>> it worked fine with the old v3.2.x board tree..
>>>
>>> Regards,
>>>
>>> --
>>> Robert Nelson
>>> http://www.rcn-ee.com/
>>>
>>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[PLyttle]

I compiled a kernel with the cpsw driver as a module. This needs fixing of
the davinci_cpdma.c source, because it does not export the symbols
GPL(cpdma_ctlr_int_ctrl); GPL(cpdma_ctlr_eoi); GPL(cpdma_control_set).
Fortunately Internet is a big help here :-)

when booting in this new kernel with netctl for eth0 enabled (standard
dynamic profile)
modprobe ti_cpsw
netctl start eth0

everything works normally even unplugging and replugging the RJ-45 cable
re-initiates the network (improvement here)

netctl stop eth0 stops the interface without apparent mishap, but when
followed by netctl start eth0 no more received packets, which shows up as a
failed dhcp lease attempt and netctl-ET31U/T6GptTDjBF/***@public.gmane.org entering a failed state.

The reason why I attempted a modular driver was to try to unload the module
at this point an reload it to see if that would re-create a working
interface, but this results in a kernel bug
[ 1734.862884] kernel BUG at
net/core/dev.c:6286!
[ 1734.867528] Internal error: Oops - BUG: 0 [#1] ARM

and a segment error upon reboot.
Unable to handle kernel NULL pointer dereference at virtual address 00000000

I saved the stack trace if someone is interested.

LP





On Monday, June 24, 2013 6:51:55 PM UTC+2, RobertCNelson wrote:
>
> On Mon, Jun 24, 2013 at 11:47 AM, nemanja <ne...-***@public.gmane.org <javascript:>>
> wrote:
> > PLyttle,
> >
> > I'm having the exact same issue with those kernels. I tried RCN's Ubuntu
> and
> > Debian images and both have the issue, and another with my own custom
> kernel
> > based on that one. Unplugging the ethernet for >30 seconds and plugging
> back
> > in makes it no longer work, and doing ifconfig eth0 down, then up and it
> > never works, dhclient can't get another IP.
> > But it does work on startup the once, like you said.
> >
> > I'm not sure it is a hardware issue though because it happens on both of
> my
> > rev A5A BBB boards with Ubuntu/Debian but NOT with the Angstrom image,
> that
> > one seems to come back up with Ethernet no problem.
>
> I believe it's a problem in the cpsw ethernet driver.. As the
> beaglebone (classic) seems to have the same issue with v3.8.x, where
> it worked fine with the old v3.2.x board tree..
>
> Regards,
>
> --
> Robert Nelson
> http://www.rcn-ee.com/
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[eskimobob]

I have found the same issue and there is another separate discussion about
this in the group (see thread here<https://groups.google.com/d/msg/beagleboard/Nm92te1YI-o/T95Mqw5b0xcJ>).
I'd been thinking it was a problem with connman but after reading this
thread, it seems that it is something more fundamental.

My findings:
1) If I boot without LAN cable attached then LAN is never available even
after plugging LAN in.
2) If after booting with LAN attached, I unplug LAN for a few seconds then
plug back in, the connection is re-established providing I add
"Restart=on-failure" and "RestartSec=5" to the connman service
control/launch file.
3) If after booting with LAN attached, I unplug LAN for more than 5
seconds, the connman service restarts but then the connection can never be
re-established without reboot.

Happy to try things if suggestions are offered :-)

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[Thomas Laskowski]

It scares me how quiet this group has been about this topic. Isn't anyone
else experiencing this issue out there? We're considering switching to the
original Beaglebone, because we are running out of time on our project.
Does anyone know if the original Beaglebone is stable? Thanks,

-Tom

On Monday, 10 June 2013 11:23:32 UTC-4, necron...-***@public.gmane.org wrote:
>
> I'm having a strange problem with my new BeagleBone black: I can transmit
> packets from the Ethernet port but not receive them.
>
> When using DHCP, I can see (via a sniffer) the DHCP DISCOVER packet sent
> from the 'bone (via a network sniffer). I can see my DHCP server (dnsmasq
> 2.59 on stock Ubuntu 12.04 LTS 64-bit server) send a DHCP OFFER. But the
> 'bone acts like it never hears the offer; it just sends out more DISCOVERs
> at intervals. (The same DHCP server is working fine for dozens of clients
> from various vendors. There are plenty of leases left in the pool.)
>
> If I set a static address and try to ping something, I see the 'bone send
> an ARP who-has, I see the target reply with an ARP is-at, but the 'bone
> just keeps ARP-ing, and never gets an entry in its ARP table.
>
> In the ifconfig output, the eth0 interface shows 0 packets received and 0
> errors. (The number transmitted is non-0.) Nothing suspicious in the dmesg
> output that I can see.
>
> I've repeated the tests with both the latest Angstrom and with Ubuntu
> booted off an SD card. Same results. I've tried two different cables, and
> two different ports on two different Ethernet switches from different
> vendors. (All ports and cables verified to work fine with my laptop.)
>
> One interesting observation: the port seems to always end up on 10Mbps,
> even when plugged into 100Mbps- (or gigabit-) capable ports. So, it looks
> like autonegotiation isn't working either.
>
> I'm running on a 2A 5.00V regulated bench supply, and the DC looks clean
> on the o-scope.
>
> Other 'bone functions (USB host, USB target, HDMI, LEDs) all seem to work
> fine.
>
> I'm starting to suspect a hardware problem (busted PHY or magnetics;
> incomplete or bridged trace).
>
> Any suggestions for stuff I should try before I RMA the poor little guy?
> (I'm an experienced Linux user and reasonably competent electronics
> hobbyist, if that matters.)
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[Gerald Coley]

I have had no issues in this area. I cannot make it
fail, Unplugging and plugging it in won't fail. I am not sure what needs to
be fixed if it keeps working. Ethernet HW is the exact same as the
BeagleBone.

You have two options. Request and RMA and let us look at it, If the HW has
a failure we will fix it. If not, then we can tell you and and see what
might be wrong on your end.

Second option is to do nothing and see what others may fine.

I know we got one board in with is issue on an RMA. Worked fine.

Gerald



On Tue, Jul 16, 2013 at 4:24 PM, Thomas Laskowski <tlaskows-***@public.gmane.org>wrote:

> It scares me how quiet this group has been about this topic. Isn't anyone
> else experiencing this issue out there? We're considering switching to the
> original Beaglebone, because we are running out of time on our project.
> Does anyone know if the original Beaglebone is stable? Thanks,
>
>
> -Tom
>
> On Monday, 10 June 2013 11:23:32 UTC-4, necron...-***@public.gmane.org wrote:
>
>> I'm having a strange problem with my new BeagleBone black: I can transmit
>> packets from the Ethernet port but not receive them.
>>
>> When using DHCP, I can see (via a sniffer) the DHCP DISCOVER packet sent
>> from the 'bone (via a network sniffer). I can see my DHCP server (dnsmasq
>> 2.59 on stock Ubuntu 12.04 LTS 64-bit server) send a DHCP OFFER. But the
>> 'bone acts like it never hears the offer; it just sends out more DISCOVERs
>> at intervals. (The same DHCP server is working fine for dozens of clients
>> from various vendors. There are plenty of leases left in the pool.)
>>
>> If I set a static address and try to ping something, I see the 'bone send
>> an ARP who-has, I see the target reply with an ARP is-at, but the 'bone
>> just keeps ARP-ing, and never gets an entry in its ARP table.
>>
>> In the ifconfig output, the eth0 interface shows 0 packets received and 0
>> errors. (The number transmitted is non-0.) Nothing suspicious in the dmesg
>> output that I can see.
>>
>> I've repeated the tests with both the latest Angstrom and with Ubuntu
>> booted off an SD card. Same results. I've tried two different cables, and
>> two different ports on two different Ethernet switches from different
>> vendors. (All ports and cables verified to work fine with my laptop.)
>>
>> One interesting observation: the port seems to always end up on 10Mbps,
>> even when plugged into 100Mbps- (or gigabit-) capable ports. So, it looks
>> like autonegotiation isn't working either.
>>
>> I'm running on a 2A 5.00V regulated bench supply, and the DC looks clean
>> on the o-scope.
>>
>> Other 'bone functions (USB host, USB target, HDMI, LEDs) all seem to work
>> fine.
>>
>> I'm starting to suspect a hardware problem (busted PHY or magnetics;
>> incomplete or bridged trace).
>>
>> Any suggestions for stuff I should try before I RMA the poor little guy?
>> (I'm an experienced Linux user and reasonably competent electronics
>> hobbyist, if that matters.)
>>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[Thomas Laskowski]

Thank you for your input, Gerard. I don't understand how it works for you
guys. I am using a gigabit switch and a gigabit router, but the board
always boots with 10 base T. The 100 base T light is off. I don't know
what to do, requesting an RMA doesn't seem to make sense, because it will
probably work for you.

-Tom

On Tuesday, 16 July 2013 17:29:03 UTC-4, Gerald wrote:
>
> I have had no issues in this area. I cannot make it
> fail, Unplugging and plugging it in won't fail. I am not sure what needs to
> be fixed if it keeps working. Ethernet HW is the exact same as the
> BeagleBone.
>
> You have two options. Request and RMA and let us look at it, If the HW has
> a failure we will fix it. If not, then we can tell you and and see what
> might be wrong on your end.
>
> Second option is to do nothing and see what others may fine.
>
> I know we got one board in with is issue on an RMA. Worked fine.
>
> Gerald
>
>
>
> On Tue, Jul 16, 2013 at 4:24 PM, Thomas Laskowski <tlas...-***@public.gmane.org<javascript:>
> > wrote:
>
>> It scares me how quiet this group has been about this topic. Isn't
>> anyone else experiencing this issue out there? We're considering switching
>> to the original Beaglebone, because we are running out of time on our
>> project. Does anyone know if the original Beaglebone is stable? Thanks,
>>
>>
>> -Tom
>>
>> On Monday, 10 June 2013 11:23:32 UTC-4, necron...-***@public.gmane.org wrote:
>>
>>> I'm having a strange problem with my new BeagleBone black: I can
>>> transmit packets from the Ethernet port but not receive them.
>>>
>>> When using DHCP, I can see (via a sniffer) the DHCP DISCOVER packet sent
>>> from the 'bone (via a network sniffer). I can see my DHCP server (dnsmasq
>>> 2.59 on stock Ubuntu 12.04 LTS 64-bit server) send a DHCP OFFER. But the
>>> 'bone acts like it never hears the offer; it just sends out more DISCOVERs
>>> at intervals. (The same DHCP server is working fine for dozens of clients
>>> from various vendors. There are plenty of leases left in the pool.)
>>>
>>> If I set a static address and try to ping something, I see the 'bone
>>> send an ARP who-has, I see the target reply with an ARP is-at, but the
>>> 'bone just keeps ARP-ing, and never gets an entry in its ARP table.
>>>
>>> In the ifconfig output, the eth0 interface shows 0 packets received and
>>> 0 errors. (The number transmitted is non-0.) Nothing suspicious in the
>>> dmesg output that I can see.
>>>
>>> I've repeated the tests with both the latest Angstrom and with Ubuntu
>>> booted off an SD card. Same results. I've tried two different cables, and
>>> two different ports on two different Ethernet switches from different
>>> vendors. (All ports and cables verified to work fine with my laptop.)
>>>
>>> One interesting observation: the port seems to always end up on 10Mbps,
>>> even when plugged into 100Mbps- (or gigabit-) capable ports. So, it looks
>>> like autonegotiation isn't working either.
>>>
>>> I'm running on a 2A 5.00V regulated bench supply, and the DC looks clean
>>> on the o-scope.
>>>
>>> Other 'bone functions (USB host, USB target, HDMI, LEDs) all seem to
>>> work fine.
>>>
>>> I'm starting to suspect a hardware problem (busted PHY or magnetics;
>>> incomplete or bridged trace).
>>>
>>> Any suggestions for stuff I should try before I RMA the poor little guy?
>>> (I'm an experienced Linux user and reasonably competent electronics
>>> hobbyist, if that matters.)
>>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard...-/***@public.gmane.org <javascript:>.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[Gerald Coley]

It may. It may not. We have had a couple of PHYs go bad. Go ahead and
request the RMA.

Gerald



On Tue, Jul 16, 2013 at 4:53 PM, Thomas Laskowski <tlaskows-***@public.gmane.org>wrote:

> Thank you for your input, Gerard. I don't understand how it works for you
> guys. I am using a gigabit switch and a gigabit router, but the board
> always boots with 10 base T. The 100 base T light is off. I don't know
> what to do, requesting an RMA doesn't seem to make sense, because it will
> probably work for you.
>
> -Tom
>
>
> On Tuesday, 16 July 2013 17:29:03 UTC-4, Gerald wrote:
>
>> I have had no issues in this area. I cannot make it
>> fail, Unplugging and plugging it in won't fail. I am not sure what needs to
>> be fixed if it keeps working. Ethernet HW is the exact same as the
>> BeagleBone.
>>
>> You have two options. Request and RMA and let us look at it, If the HW
>> has a failure we will fix it. If not, then we can tell you and and see what
>> might be wrong on your end.
>>
>> Second option is to do nothing and see what others may fine.
>>
>> I know we got one board in with is issue on an RMA. Worked fine.
>>
>> Gerald
>>
>>
>>
>> On Tue, Jul 16, 2013 at 4:24 PM, Thomas Laskowski <tlas...-***@public.gmane.org>wrote:
>>
>>> It scares me how quiet this group has been about this topic. Isn't
>>> anyone else experiencing this issue out there? We're considering switching
>>> to the original Beaglebone, because we are running out of time on our
>>> project. Does anyone know if the original Beaglebone is stable? Thanks,
>>>
>>>
>>> -Tom
>>>
>>> On Monday, 10 June 2013 11:23:32 UTC-4, necron...-***@public.gmane.org wrote:
>>>
>>>> I'm having a strange problem with my new BeagleBone black: I can
>>>> transmit packets from the Ethernet port but not receive them.
>>>>
>>>> When using DHCP, I can see (via a sniffer) the DHCP DISCOVER packet
>>>> sent from the 'bone (via a network sniffer). I can see my DHCP server
>>>> (dnsmasq 2.59 on stock Ubuntu 12.04 LTS 64-bit server) send a DHCP OFFER.
>>>> But the 'bone acts like it never hears the offer; it just sends out more
>>>> DISCOVERs at intervals. (The same DHCP server is working fine for dozens of
>>>> clients from various vendors. There are plenty of leases left in the pool.)
>>>>
>>>> If I set a static address and try to ping something, I see the 'bone
>>>> send an ARP who-has, I see the target reply with an ARP is-at, but the
>>>> 'bone just keeps ARP-ing, and never gets an entry in its ARP table.
>>>>
>>>> In the ifconfig output, the eth0 interface shows 0 packets received and
>>>> 0 errors. (The number transmitted is non-0.) Nothing suspicious in the
>>>> dmesg output that I can see.
>>>>
>>>> I've repeated the tests with both the latest Angstrom and with Ubuntu
>>>> booted off an SD card. Same results. I've tried two different cables, and
>>>> two different ports on two different Ethernet switches from different
>>>> vendors. (All ports and cables verified to work fine with my laptop.)
>>>>
>>>> One interesting observation: the port seems to always end up on 10Mbps,
>>>> even when plugged into 100Mbps- (or gigabit-) capable ports. So, it looks
>>>> like autonegotiation isn't working either.
>>>>
>>>> I'm running on a 2A 5.00V regulated bench supply, and the DC looks
>>>> clean on the o-scope.
>>>>
>>>> Other 'bone functions (USB host, USB target, HDMI, LEDs) all seem to
>>>> work fine.
>>>>
>>>> I'm starting to suspect a hardware problem (busted PHY or magnetics;
>>>> incomplete or bridged trace).
>>>>
>>>> Any suggestions for stuff I should try before I RMA the poor little
>>>> guy? (I'm an experienced Linux user and reasonably competent electronics
>>>> hobbyist, if that matters.)
>>>>
>>> --
>>> For more options, visit http://beagleboard.org/discuss
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "BeagleBoard" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to beagleboard...@**googlegroups.com.
>>>
>>> For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>>> .
>>>
>>>
>>>
>>
>> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[Charles Steinkuehler]

X-Received: by 10.49.16.163 with SMTP id h3mr192416qed.24.1374012665047;
Tue, 16 Jul 2013 15:11:05 -0700 (PDT)
X-BeenThere: beagleboard-/***@public.gmane.org
Received: by 10.49.0.66 with SMTP id 2ls485262qec.47.gmail; Tue, 16 Jul 2013
15:11:04 -0700 (PDT)
X-Received: by 10.59.5.72 with SMTP id ck8mr753018ved.35.1374012664383;
Tue, 16 Jul 2013 15:11:04 -0700 (PDT)
Received: from dukecmmtar04.coxmail.com (dukecmmtar04.coxmail.com. [68.99.120.47])
by gmr-mx.google.com with ESMTP id c28si467684qck.1.2013.07.16.15.11.04
for <beagleboard-/***@public.gmane.org>;
Tue, 16 Jul 2013 15:11:04 -0700 (PDT)
Received-SPF: neutral (google.com: 68.99.120.47 is neither permitted nor denied by best guess record for domain of charles-***@public.gmane.org) client-ip=68.99.120.47;
Received: from dukecmimpo02.coxmail.com ([68.99.120.135])
by dukecmmtar04.coxmail.com
(InterMail vM.8.01.05.06 201-2260-151-112-20120208) with ESMTP
id <20130716221104.OBVW932.dukecmmtar04.coxmail.com-***@public.gmane.org>
for <beagleboard-/***@public.gmane.org>;
Tue, 16 Jul 2013 18:11:04 -0400
Received: from mail.steinkuehler.net ([70.184.225.181])
by dukecmimpo02.coxmail.com with bizsmtp
id 1AB31m0063vTAEW01AB3DZ; Tue, 16 Jul 2013 18:11:03 -0400
Received: (qmail 28286 invoked from network); 16 Jul 2013 17:11:03 -0500
Received: from 222.ks.newtek.dhcp (HELO ?10.34.1.222?) (charles-***@public.gmane.org)
by mail.steinkuehler.net with SMTP; 16 Jul 2013 17:11:03 -0500
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
In-Reply-To: <68d1eb4d-72ad-42ed-a806-37946193fbed-/***@public.gmane.org>
X-Enigmail-Version: 1.5.1
X-Original-Sender: charles-***@public.gmane.org
X-Original-Authentication-Results: gmr-mx.google.com; spf=neutral
(google.com: 68.99.120.47 is neither permitted nor denied by best guess
record for domain of charles-***@public.gmane.org) smtp.mail=charles-***@public.gmane.org
Precedence: list
Mailing-list: list beagleboard-/***@public.gmane.org; contact beagleboard+owners-/***@public.gmane.org
List-ID: <beagleboard.googlegroups.com>
X-Google-Group-Id: 1035534660134
List-Post: <http://groups.google.com/group/beagleboard/post>, <mailto:beagleboard-/***@public.gmane.org>
List-Help: <http://groups.google.com/support/>, <mailto:beagleboard+help-/***@public.gmane.org>
List-Archive: <http://groups.google.com/group/beagleboard>
Sender: beagleboard-/***@public.gmane.org
List-Subscribe: <http://groups.google.com/group/beagleboard/subscribe>, <mailto:beagleboard+subscribe-/***@public.gmane.org>
List-Unsubscribe: <http://groups.google.com/group/beagleboard/subscribe>, <mailto:googlegroups-manage+1035534660134+unsubscribe-/***@public.gmane.org>
Archived-At: <http://permalink.gmane.org/gmane.comp.hardware.beagleboard.user/50116>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 7/16/2013 4:53 PM, Thomas Laskowski wrote:
> Thank you for your input, Gerard. I don't understand how it works
> for you guys. I am using a gigabit switch and a gigabit router,
> but the board always boots with 10 base T. The 100 base T light is
> off. I don't know what to do, requesting an RMA doesn't seem to
> make sense, because it will probably work for you.

I am seeing some issues here. I do get a 100 MBit link, but I see
issues sometimes on reboot and when trying to reestablish link.

I'm virtually certain it is not a hardware issue...it "feels" like a
reset issue with the device driver, but I haven't had time to try and
track down the issue. For instance, occasionally DHCP will fail to
acquire a lease and the ethernet will be 'wedged' and not work. Of
interest is the phy is reset when the startup scripts launch the dhcp
client and if things are working properly I get a "link status up"
message from the kernel after the first DHCP packet was transmitted.
When DHCP fails, I don't get the link up message and I get the "no Rx
packets" behavior you describe.

Of course, I'm running Debian with a Xenomai patched kernel, so
despite the fact that I think the issue is related to the port of the
AM335x Ethernet driver to the 3.8 kernel, the "official" BeagleBone
folks are going to ignore any issues I have because I'm so far "off
the reservation".

I suspect you had good results with your BBW (as I did) because it's
running the 3.2 kernel.

I fully support the decision to use the 3.8 Kernel on the BeagleBone
Black, but it is definitely still a bit rough around the edges. I
also understand there might be a bit of back-story that explains why
the 3.8 stuff was not in better shape when the 'Black shipped, but
it's just heresay. :)

- --
Charles Steinkuehler
charles-***@public.gmane.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlHlxPMACgkQLywbqEHdNFyAoACgxylOmCKVFv3MaEl/qnNdJR4v
ZM4AoMdQcmJlNzIfmNYww4ipicg6pdGq
=SdvX
-----END PGP SIGNATURE-----

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[Gerald Coley]

We will be watching for the Eskimbob board!

Gerald



On Tue, Jul 16, 2013 at 5:10 PM, Charles Steinkuehler <
charles-***@public.gmane.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 7/16/2013 4:53 PM, Thomas Laskowski wrote:
> > Thank you for your input, Gerard. I don't understand how it works
> > for you guys. I am using a gigabit switch and a gigabit router,
> > but the board always boots with 10 base T. The 100 base T light is
> > off. I don't know what to do, requesting an RMA doesn't seem to
> > make sense, because it will probably work for you.
>
> I am seeing some issues here. I do get a 100 MBit link, but I see
> issues sometimes on reboot and when trying to reestablish link.
>
> I'm virtually certain it is not a hardware issue...it "feels" like a
> reset issue with the device driver, but I haven't had time to try and
> track down the issue. For instance, occasionally DHCP will fail to
> acquire a lease and the ethernet will be 'wedged' and not work. Of
> interest is the phy is reset when the startup scripts launch the dhcp
> client and if things are working properly I get a "link status up"
> message from the kernel after the first DHCP packet was transmitted.
> When DHCP fails, I don't get the link up message and I get the "no Rx
> packets" behavior you describe.
>
> Of course, I'm running Debian with a Xenomai patched kernel, so
> despite the fact that I think the issue is related to the port of the
> AM335x Ethernet driver to the 3.8 kernel, the "official" BeagleBone
> folks are going to ignore any issues I have because I'm so far "off
> the reservation".
>
> I suspect you had good results with your BBW (as I did) because it's
> running the 3.2 kernel.
>
> I fully support the decision to use the 3.8 Kernel on the BeagleBone
> Black, but it is definitely still a bit rough around the edges. I
> also understand there might be a bit of back-story that explains why
> the 3.8 stuff was not in better shape when the 'Black shipped, but
> it's just heresay. :)
>
> - --
> Charles Steinkuehler
> charles-***@public.gmane.org
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlHlxPMACgkQLywbqEHdNFyAoACgxylOmCKVFv3MaEl/qnNdJR4v
> ZM4AoMdQcmJlNzIfmNYww4ipicg6pdGq
> =SdvX
> -----END PGP SIGNATURE-----
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[Thomas Laskowski]

Sorry Gerald, I think I accidentally replied directly to you...

On Tuesday, 16 July 2013 18:29:55 UTC-4, Gerald wrote:
>
> We will be watching for the Eskimbob board!
>
> Gerald
>
>
>
> On Tue, Jul 16, 2013 at 5:10 PM, Charles Steinkuehler <
> cha...-***@public.gmane.org <javascript:>> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 7/16/2013 4:53 PM, Thomas Laskowski wrote:
>> > Thank you for your input, Gerard. I don't understand how it works
>> > for you guys. I am using a gigabit switch and a gigabit router,
>> > but the board always boots with 10 base T. The 100 base T light is
>> > off. I don't know what to do, requesting an RMA doesn't seem to
>> > make sense, because it will probably work for you.
>>
>> I am seeing some issues here. I do get a 100 MBit link, but I see
>> issues sometimes on reboot and when trying to reestablish link.
>>
>> I'm virtually certain it is not a hardware issue...it "feels" like a
>> reset issue with the device driver, but I haven't had time to try and
>> track down the issue. For instance, occasionally DHCP will fail to
>> acquire a lease and the ethernet will be 'wedged' and not work. Of
>> interest is the phy is reset when the startup scripts launch the dhcp
>> client and if things are working properly I get a "link status up"
>> message from the kernel after the first DHCP packet was transmitted.
>> When DHCP fails, I don't get the link up message and I get the "no Rx
>> packets" behavior you describe.
>>
>> Of course, I'm running Debian with a Xenomai patched kernel, so
>> despite the fact that I think the issue is related to the port of the
>> AM335x Ethernet driver to the 3.8 kernel, the "official" BeagleBone
>> folks are going to ignore any issues I have because I'm so far "off
>> the reservation".
>>
>> I suspect you had good results with your BBW (as I did) because it's
>> running the 3.2 kernel.
>>
>> I fully support the decision to use the 3.8 Kernel on the BeagleBone
>> Black, but it is definitely still a bit rough around the edges. I
>> also understand there might be a bit of back-story that explains why
>> the 3.8 stuff was not in better shape when the 'Black shipped, but
>> it's just heresay. :)
>>
>> - --
>> Charles Steinkuehler
>> cha...-***@public.gmane.org <javascript:>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.11 (MingW32)
>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>
>> iEYEARECAAYFAlHlxPMACgkQLywbqEHdNFyAoACgxylOmCKVFv3MaEl/qnNdJR4v
>> ZM4AoMdQcmJlNzIfmNYww4ipicg6pdGq
>> =SdvX
>> -----END PGP SIGNATURE-----
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard...-/***@public.gmane.org <javascript:>.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[Gerald Coley]

Sounds good. Keep us updated!

Gerald



On Tue, Jul 16, 2013 at 6:03 PM, Thomas Laskowski <tlaskows-***@public.gmane.org>wrote:

> Sorry Gerald, I think I accidentally replied directly to you...
>
>
> On Tuesday, 16 July 2013 18:29:55 UTC-4, Gerald wrote:
>
>> We will be watching for the Eskimbob board!
>>
>> Gerald
>>
>>
>>
>> On Tue, Jul 16, 2013 at 5:10 PM, Charles Steinkuehler <
>> cha...-***@public.gmane.org> wrote:
>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 7/16/2013 4:53 PM, Thomas Laskowski wrote:
>>> > Thank you for your input, Gerard. I don't understand how it works
>>> > for you guys. I am using a gigabit switch and a gigabit router,
>>> > but the board always boots with 10 base T. The 100 base T light is
>>> > off. I don't know what to do, requesting an RMA doesn't seem to
>>> > make sense, because it will probably work for you.
>>>
>>> I am seeing some issues here. I do get a 100 MBit link, but I see
>>> issues sometimes on reboot and when trying to reestablish link.
>>>
>>> I'm virtually certain it is not a hardware issue...it "feels" like a
>>> reset issue with the device driver, but I haven't had time to try and
>>> track down the issue. For instance, occasionally DHCP will fail to
>>> acquire a lease and the ethernet will be 'wedged' and not work. Of
>>> interest is the phy is reset when the startup scripts launch the dhcp
>>> client and if things are working properly I get a "link status up"
>>> message from the kernel after the first DHCP packet was transmitted.
>>> When DHCP fails, I don't get the link up message and I get the "no Rx
>>> packets" behavior you describe.
>>>
>>> Of course, I'm running Debian with a Xenomai patched kernel, so
>>> despite the fact that I think the issue is related to the port of the
>>> AM335x Ethernet driver to the 3.8 kernel, the "official" BeagleBone
>>> folks are going to ignore any issues I have because I'm so far "off
>>> the reservation".
>>>
>>> I suspect you had good results with your BBW (as I did) because it's
>>> running the 3.2 kernel.
>>>
>>> I fully support the decision to use the 3.8 Kernel on the BeagleBone
>>> Black, but it is definitely still a bit rough around the edges. I
>>> also understand there might be a bit of back-story that explains why
>>> the 3.8 stuff was not in better shape when the 'Black shipped, but
>>> it's just heresay. :)
>>>
>>> - --
>>> Charles Steinkuehler
>>> cha...-***@public.gmane.org
>>>
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.11 (MingW32)
>>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>>
>>> iEYEARECAAYFAlHlxPMACgkQLywbqE**HdNFyAoACgxylOmCKVFv3MaEl/**qnNdJR4v
>>> ZM4AoMdQcmJlNzIfmNYww4ipicg6pd**Gq
>>> =SdvX
>>> -----END PGP SIGNATURE-----
>>>
>>> --
>>> For more options, visit http://beagleboard.org/discuss
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "BeagleBoard" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to beagleboard...@**googlegroups.com.
>>>
>>> For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>>> .
>>>
>>>
>>>
>> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[Thomas Laskowski]

The "bad" board is indeed bad. I flashed the latest Angstrom image onto
eMMC and it fails the cable unplug test. The other board works fine so far.

-Tom

On Tuesday, 16 July 2013 19:14:00 UTC-4, Gerald wrote:
>
> Sounds good. Keep us updated!
>
> Gerald
>
>
>
> On Tue, Jul 16, 2013 at 6:03 PM, Thomas Laskowski <tlas...-***@public.gmane.org<javascript:>
> > wrote:
>
>> Sorry Gerald, I think I accidentally replied directly to you...
>>
>>
>> On Tuesday, 16 July 2013 18:29:55 UTC-4, Gerald wrote:
>>
>>> We will be watching for the Eskimbob board!
>>>
>>> Gerald
>>>
>>>
>>>
>>> On Tue, Jul 16, 2013 at 5:10 PM, Charles Steinkuehler <
>>> cha...-***@public.gmane.org> wrote:
>>>
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> On 7/16/2013 4:53 PM, Thomas Laskowski wrote:
>>>> > Thank you for your input, Gerard. I don't understand how it works
>>>> > for you guys. I am using a gigabit switch and a gigabit router,
>>>> > but the board always boots with 10 base T. The 100 base T light is
>>>> > off. I don't know what to do, requesting an RMA doesn't seem to
>>>> > make sense, because it will probably work for you.
>>>>
>>>> I am seeing some issues here. I do get a 100 MBit link, but I see
>>>> issues sometimes on reboot and when trying to reestablish link.
>>>>
>>>> I'm virtually certain it is not a hardware issue...it "feels" like a
>>>> reset issue with the device driver, but I haven't had time to try and
>>>> track down the issue. For instance, occasionally DHCP will fail to
>>>> acquire a lease and the ethernet will be 'wedged' and not work. Of
>>>> interest is the phy is reset when the startup scripts launch the dhcp
>>>> client and if things are working properly I get a "link status up"
>>>> message from the kernel after the first DHCP packet was transmitted.
>>>> When DHCP fails, I don't get the link up message and I get the "no Rx
>>>> packets" behavior you describe.
>>>>
>>>> Of course, I'm running Debian with a Xenomai patched kernel, so
>>>> despite the fact that I think the issue is related to the port of the
>>>> AM335x Ethernet driver to the 3.8 kernel, the "official" BeagleBone
>>>> folks are going to ignore any issues I have because I'm so far "off
>>>> the reservation".
>>>>
>>>> I suspect you had good results with your BBW (as I did) because it's
>>>> running the 3.2 kernel.
>>>>
>>>> I fully support the decision to use the 3.8 Kernel on the BeagleBone
>>>> Black, but it is definitely still a bit rough around the edges. I
>>>> also understand there might be a bit of back-story that explains why
>>>> the 3.8 stuff was not in better shape when the 'Black shipped, but
>>>> it's just heresay. :)
>>>>
>>>> - --
>>>> Charles Steinkuehler
>>>> cha...-***@public.gmane.org
>>>>
>>>> -----BEGIN PGP SIGNATURE-----
>>>> Version: GnuPG v1.4.11 (MingW32)
>>>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>>>
>>>> iEYEARECAAYFAlHlxPMACgkQLywbqE**HdNFyAoACgxylOmCKVFv3MaEl/**qnNdJR4v
>>>> ZM4AoMdQcmJlNzIfmNYww4ipicg6pd**Gq
>>>> =SdvX
>>>> -----END PGP SIGNATURE-----
>>>>
>>>> --
>>>> For more options, visit http://beagleboard.org/discuss
>>>> ---
>>>> You received this message because you are subscribed to the Google
>>>> Groups "BeagleBoard" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to beagleboard...@**googlegroups.com.
>>>>
>>>> For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>>>> .
>>>>
>>>>
>>>>
>>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard...-/***@public.gmane.org <javascript:>.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[eskimobob]

Just had an email to say that the Beagle Hospital has now received my RMA
board and are going to run it through some tests.
I'm hoping they find a software issue that can be fixed because I have two
more BBBs here that exhibit the same problem.

On Tuesday, 16 July 2013 23:29:55 UTC+1, Gerald wrote:
>
> We will be watching for the Eskimbob board!
>
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[Gerald Coley]

Hospital only handles HW issues and repairs any damaged or failed parts.You
won't be seeing any SW solutions from the hospital.

Gerald



On Thu, Jul 25, 2013 at 11:04 AM, eskimobob <martinberriman-***@public.gmane.org>wrote:

> Just had an email to say that the Beagle Hospital has now received my RMA
> board and are going to run it through some tests.
> I'm hoping they find a software issue that can be fixed because I have two
> more BBBs here that exhibit the same problem.
>
> On Tuesday, 16 July 2013 23:29:55 UTC+1, Gerald wrote:
>>
>> We will be watching for the Eskimbob board!
>>
>> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[eskimobob]

Thanks Gerald, that makes sense. I had hoped therefore that they would at
least recreate the problem and say it was either hardware or software
however I have just heard:

"Since the software in your unit is 2013-06-20, we have run our production
tests on it without reflashing its eMMC. Everything is working fine. We
also performed manual ping and iperf tests on that unit and re-created your
failure scenarios (hot plugging Ethernet cable on start up, removing and
hot plugging). We haven't seen anything unusual so far. It is now in
Ethernet burn-in test. We will keep you updated as we find out anything
new."

Based on that feedback, it seems likely that they will not see the problem.
That leads me to wonder again whether it has something to do with my setup
- e.g. router.
Can anyone think of any other useful tests I can suggest to them that might
reveal the problem? I intend checking that when removing the LAN, they are
waiting at least 5 secs before hot plugging. Also I will suggest they try
ifdown eth0 followed by ifup eth0.

Martin


On Thursday, 25 July 2013 18:44:10 UTC+1, Gerald wrote:
>
> Hospital only handles HW issues and repairs any damaged or failed
> parts.You won't be seeing any SW solutions from the hospital.
>
> Gerald
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[Gerald Coley]

That is what I see as well. It could eb a protocol issue or as you say
something in your setup. Maybe try and simplify the scenario, like
connecting it to a PC. No network, fix the IP address and see how it looks.

Gerald



On Fri, Jul 26, 2013 at 5:29 PM, eskimobob <martinberriman-***@public.gmane.org> wrote:

> Thanks Gerald, that makes sense. I had hoped therefore that they would at
> least recreate the problem and say it was either hardware or software
> however I have just heard:
>
> "Since the software in your unit is 2013-06-20, we have run our production
> tests on it without reflashing its eMMC. Everything is working fine. We
> also performed manual ping and iperf tests on that unit and re-created your
> failure scenarios (hot plugging Ethernet cable on start up, removing and
> hot plugging). We haven't seen anything unusual so far. It is now in
> Ethernet burn-in test. We will keep you updated as we find out anything
> new."
>
> Based on that feedback, it seems likely that they will not see the
> problem. That leads me to wonder again whether it has something to do with
> my setup - e.g. router.
> Can anyone think of any other useful tests I can suggest to them that
> might reveal the problem? I intend checking that when removing the LAN,
> they are waiting at least 5 secs before hot plugging. Also I will suggest
> they try ifdown eth0 followed by ifup eth0.
>
> Martin
>
>
> On Thursday, 25 July 2013 18:44:10 UTC+1, Gerald wrote:
>>
>> Hospital only handles HW issues and repairs any damaged or failed
>> parts.You won't be seeing any SW solutions from the hospital.
>>
>> Gerald
>>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[eskimobob]

Only just getting time to play with this again...

In order to try out Gerald's suggestions, I set it to static IP using Derek
Molloy's blog instructions (here<http://derekmolloy.ie/set-ip-address-to-be-static-on-the-beaglebone-black/>).
Note: I'm still testing for the moment on my router. I was surprised to
find that unplugging the LAN, waiting more than 10 seconds then
hot-plugging it resulted in automatic reconnection to the router, something
I have never seen before.

Ok, I thought it must be something weird when configured to use dhcp
instead of static address. I therefore used set-ipv4-method to change back
to dhcp but found that no matter what, I could not connect to my network.

Although it had clearly set the mode to dhcp, I could not find out how to
use connman to remove the nameservers that I had set. I therefore edited
the settings file manually to remove the nameserver info then rebooted.
Now, it comes up in dhcp mode and connects happily to my router time and
again regardless of how many times I unplug and hot-plug the LAN cable :-/

Something is apparently different - but what!
Off to do some more investigation.

On Saturday, 27 July 2013 02:20:38 UTC+1, Gerald wrote:
>
> That is what I see as well. It could eb a protocol issue or as you say
> something in your setup. Maybe try and simplify the scenario, like
> connecting it to a PC. No network, fix the IP address and see how it looks.
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[nemanja]

Exactly eskimobob, that's what I see too. Switching between static and DHCP
usually requires a restart of the networking interfaces and service. That's
what always kills it for me and explains why it worked when you rebooted.
But doing it while BBB is running causes the networking portion to fail.

On Monday, July 29, 2013 2:40:37 PM UTC-5, eskimobob wrote:
>
> Only just getting time to play with this again...
>
> In order to try out Gerald's suggestions, I set it to static IP using
> Derek Molloy's blog instructions (here<http://derekmolloy.ie/set-ip-address-to-be-static-on-the-beaglebone-black/>).
> Note: I'm still testing for the moment on my router. I was surprised to
> find that unplugging the LAN, waiting more than 10 seconds then
> hot-plugging it resulted in automatic reconnection to the router, something
> I have never seen before.
>
> Ok, I thought it must be something weird when configured to use dhcp
> instead of static address. I therefore used set-ipv4-method to change back
> to dhcp but found that no matter what, I could not connect to my network.
>
> Although it had clearly set the mode to dhcp, I could not find out how to
> use connman to remove the nameservers that I had set. I therefore edited
> the settings file manually to remove the nameserver info then rebooted.
> Now, it comes up in dhcp mode and connects happily to my router time and
> again regardless of how many times I unplug and hot-plug the LAN cable :-/
>
> Something is apparently different - but what!
> Off to do some more investigation.
>
> On Saturday, 27 July 2013 02:20:38 UTC+1, Gerald wrote:
>>
>> That is what I see as well. It could eb a protocol issue or as you say
>> something in your setup. Maybe try and simplify the scenario, like
>> connecting it to a PC. No network, fix the IP address and see how it looks.
>>
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[eskimobob]

After pulling my hair out trying to get back to the "not-working"
situation, I came to the conclusion that something else must have changed
in my setup. It turns out that my router has 3 x 10/100 LAN ports and 1 x
10/100/1000 LAN port. Between my previous testing and my subsequent tests
to try a static IP, I had changed the port that the BBB LAN cable was
attached to.

I have now confirmed that when connecting to the 10/100 port, I see the
problem but when connecting to the 10/100/1000 port, I see absolutely no
problem whatsoever.

I am going to do some more investigation this morning but at least now I
have something to focus on and I can reliably recreate the problem and
reliably remove the problem.

My plan is to try fitting a 10/100 switch between the working port and the
BBB to see if that affects things. If anyone has any further suggestions
for things to try that might help resolve what is causing this, please
shout...


On Monday, 29 July 2013 23:44:25 UTC+1, nemanja wrote:
>
> Exactly eskimobob, that's what I see too. Switching between static and
> DHCP usually requires a restart of the networking interfaces and service.
> That's what always kills it for me and explains why it worked when you
> rebooted. But doing it while BBB is running causes the networking portion
> to fail.
>
> On Monday, July 29, 2013 2:40:37 PM UTC-5, eskimobob wrote:
>>
>> Only just getting time to play with this again...
>>
>> In order to try out Gerald's suggestions, I set it to static IP using
>> Derek Molloy's blog instructions (here<http://derekmolloy.ie/set-ip-address-to-be-static-on-the-beaglebone-black/>).
>> Note: I'm still testing for the moment on my router. I was surprised to
>> find that unplugging the LAN, waiting more than 10 seconds then
>> hot-plugging it resulted in automatic reconnection to the router, something
>> I have never seen before.
>>
>> Ok, I thought it must be something weird when configured to use dhcp
>> instead of static address. I therefore used set-ipv4-method to change back
>> to dhcp but found that no matter what, I could not connect to my network.
>>
>> Although it had clearly set the mode to dhcp, I could not find out how to
>> use connman to remove the nameservers that I had set. I therefore edited
>> the settings file manually to remove the nameserver info then rebooted.
>> Now, it comes up in dhcp mode and connects happily to my router time and
>> again regardless of how many times I unplug and hot-plug the LAN cable :-/
>>
>> Something is apparently different - but what!
>> Off to do some more investigation.
>>
>> On Saturday, 27 July 2013 02:20:38 UTC+1, Gerald wrote:
>>>
>>> That is what I see as well. It could eb a protocol issue or as you say
>>> something in your setup. Maybe try and simplify the scenario, like
>>> connecting it to a PC. No network, fix the IP address and see how it looks.
>>>
>>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[eskimobob]

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.

>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[eskimobob]

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?

>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[Thomas Laskowski]

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

On Wednesday, 31 July 2013 06:34:20 UTC-4, eskimobob wrote:
>
> 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?
>
>>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[David Lambert]

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.


On 13-07-31 06:21 AM, Thomas Laskowski wrote:
> 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
>
> On Wednesday, 31 July 2013 06:34:20 UTC-4, eskimobob wrote:
>
> 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?
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google
> Groups "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[Thomas Laskowski]

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

-Tom

On Wednesday, 31 July 2013 09:40:37 UTC-4, David wrote:
>
> 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.
>
>
> On 13-07-31 06:21 AM, Thomas Laskowski wrote:
>
> 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
>
> On Wednesday, 31 July 2013 06:34:20 UTC-4, eskimobob wrote:
>>
>> 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?
>>
>>> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard...-/***@public.gmane.org <javascript:>.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[eskimobob]

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.

On Wednesday, 31 July 2013 16:14:51 UTC+1, Thomas Laskowski wrote:
>
> You know something is wrong because when you do ifconfig eth0 down then up
> it never comes back up!
>
> -Tom
>
> On Wednesday, 31 July 2013 09:40:37 UTC-4, David wrote:
>>
>> 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.
>>
>>
>> On 13-07-31 06:21 AM, Thomas Laskowski wrote:
>>
>> 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
>>
>> On Wednesday, 31 July 2013 06:34:20 UTC-4, eskimobob wrote:
>>>
>>> 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?
>>>
>>>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard...-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>>
>>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[David Lambert]

On 13-07-31 10:31 AM, eskimobob wrote:
> 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 ;)
>
> On Wednesday, 31 July 2013 16:14:51 UTC+1, Thomas Laskowski wrote:
>
> You know something is wrong because when you do ifconfig eth0 down
> then up it never comes back up!
>
> -Tom
>
> On Wednesday, 31 July 2013 09:40:37 UTC-4, David wrote:
>
> 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.
>
>
> On 13-07-31 06:21 AM, Thomas Laskowski wrote:
>> 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
>>
>> On Wednesday, 31 July 2013 06:34:20 UTC-4, eskimobob wrote:
>>
>> 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?
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the
>> Google Groups "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from
>> it, send an email to beagleboard...-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google
> Groups "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[a***@public.gmane.org]

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.

On Wednesday, July 31, 2013 8:31:31 AM UTC-7, eskimobob wrote:
>
> 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.
>
> On Wednesday, 31 July 2013 16:14:51 UTC+1, Thomas Laskowski wrote:
>>
>> You know something is wrong because when you do ifconfig eth0 down then
>> up it never comes back up!
>>
>> -Tom
>>
>> On Wednesday, 31 July 2013 09:40:37 UTC-4, David wrote:
>>>
>>> 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.
>>>
>>>
>>> On 13-07-31 06:21 AM, Thomas Laskowski wrote:
>>>
>>> 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
>>>
>>> On Wednesday, 31 July 2013 06:34:20 UTC-4, eskimobob wrote:
>>>>
>>>> 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?
>>>>
>>>>> --
>>> For more options, visit http://beagleboard.org/discuss
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "BeagleBoard" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to beagleboard...-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>>
>>>
>>>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[Gerald Coley]

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


On Wed, Aug 28, 2013 at 8:08 PM, <alex.hurley3-***@public.gmane.org> wrote:

> 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.
>
>
> On Wednesday, July 31, 2013 8:31:31 AM UTC-7, eskimobob wrote:
>>
>> 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.
>>
>> On Wednesday, 31 July 2013 16:14:51 UTC+1, Thomas Laskowski wrote:
>>>
>>> You know something is wrong because when you do ifconfig eth0 down then
>>> up it never comes back up!
>>>
>>> -Tom
>>>
>>> On Wednesday, 31 July 2013 09:40:37 UTC-4, David wrote:
>>>>
>>>> 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.
>>>>
>>>>
>>>> On 13-07-31 06:21 AM, Thomas Laskowski wrote:
>>>>
>>>> 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
>>>>
>>>> On Wednesday, 31 July 2013 06:34:20 UTC-4, eskimobob wrote:
>>>>>
>>>>> 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?
>>>>>
>>>>>> --
>>>> For more options, visit http://beagleboard.org/discuss
>>>> ---
>>>> You received this message because you are subscribed to the Google
>>>> Groups "BeagleBoard" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to ***@googlegroups.**com.
>>>> For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>>>> .
>>>>
>>>>
>>>>
>>>>
>>>> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
> For more options, visit https://groups.google.com/groups/opt_out.
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[h***@public.gmane.org]

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

On Thursday, August 29, 2013 4:29:01 AM UTC+3, Gerald wrote:
>
> 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
>
>
> On Wed, Aug 28, 2013 at 8:08 PM, <alex.h...-***@public.gmane.org <javascript:>>wrote:
>
>> 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.
>>
>>
>> On Wednesday, July 31, 2013 8:31:31 AM UTC-7, eskimobob wrote:
>>>
>>> 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.
>>>
>>> On Wednesday, 31 July 2013 16:14:51 UTC+1, Thomas Laskowski wrote:
>>>>
>>>> You know something is wrong because when you do ifconfig eth0 down then
>>>> up it never comes back up!
>>>>
>>>> -Tom
>>>>
>>>> On Wednesday, 31 July 2013 09:40:37 UTC-4, David wrote:
>>>>>
>>>>> 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.
>>>>>
>>>>>
>>>>> On 13-07-31 06:21 AM, Thomas Laskowski wrote:
>>>>>
>>>>> 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
>>>>>
>>>>> On Wednesday, 31 July 2013 06:34:20 UTC-4, eskimobob wrote:
>>>>>>
>>>>>> 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?
>>>>>>
>>>>>>> --
>>>>> For more options, visit http://beagleboard.org/discuss
>>>>> ---
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "BeagleBoard" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to ***@googlegroups.**com.
>>>>> For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>>>>> .
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard...-/***@public.gmane.org <javascript:>.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[Gerald Coley]

OK. You will need to push the patch.

Gerald


On Thu, Sep 12, 2013 at 1:32 PM, <houssam.ramlaoui-***@public.gmane.org> wrote:

> 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
>
>
> On Thursday, August 29, 2013 4:29:01 AM UTC+3, Gerald wrote:
>
>> 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
>>
>>
>> On Wed, Aug 28, 2013 at 8:08 PM, <alex.h...-***@public.gmane.org> wrote:
>>
>>> 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.
>>>
>>>
>>> On Wednesday, July 31, 2013 8:31:31 AM UTC-7, eskimobob wrote:
>>>>
>>>> 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.
>>>>
>>>> On Wednesday, 31 July 2013 16:14:51 UTC+1, Thomas Laskowski wrote:
>>>>>
>>>>> You know something is wrong because when you do ifconfig eth0 down
>>>>> then up it never comes back up!
>>>>>
>>>>> -Tom
>>>>>
>>>>> On Wednesday, 31 July 2013 09:40:37 UTC-4, David wrote:
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>>
>>>>>> On 13-07-31 06:21 AM, Thomas Laskowski wrote:
>>>>>>
>>>>>> 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
>>>>>>
>>>>>> On Wednesday, 31 July 2013 06:34:20 UTC-4, eskimobob wrote:
>>>>>>>
>>>>>>> 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?
>>>>>>>
>>>>>>>> --
>>>>>> For more options, visit http://beagleboard.org/discuss
>>>>>> ---
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "BeagleBoard" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>> send an email to ***@googlegroups.**co**m.
>>>>>> For more options, visit https://groups.google.com/**grou**ps/opt_out<https://groups.google.com/groups/opt_out>
>>>>>> .
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>> For more options, visit http://beagleboard.org/discuss
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "BeagleBoard" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to beagleboard...@**googlegroups.com.
>>> For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>>> .
>>>
>>
>> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
> For more options, visit https://groups.google.com/groups/opt_out.
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[s***@public.gmane.org]

On Wednesday, 18 September 2013 17:49:12 UTC+2, Gerald wrote:
>
> I can tell from this forum that a lot of people have no issues.
>
> I can also tell that some people have issues.
>
>
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


--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[Gerald Coley]

-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



On Sat, Nov 2, 2013 at 2:47 PM, <steve-***@public.gmane.org> wrote:

>
>
> On Wednesday, 18 September 2013 17:49:12 UTC+2, Gerald wrote:
>>
>> I can tell from this forum that a lot of people have no issues.
>>
>> I can also tell that some people have issues.
>>
>>
> 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
>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
> For more options, visit https://groups.google.com/groups/opt_out.
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[s***@public.gmane.org]

Hi Gerald,


On Saturday, 2 November 2013 23:37:29 UTC+2, Gerald wrote:
>
>
> -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


--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[s***@public.gmane.org]

On Sunday, 3 November 2013 21:08:52 UTC+2, st...-***@public.gmane.org
wrote:
>
>
> 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 (***@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 <bio-0> 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.
Jan 1 00:00:05 beaglebone user.info kernel: [ 0.172061] pps_core:
Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti
<giometti-***@public.gmane.org>
Jan 1 00:00:05 beaglebone daemon.info avahi-daemon[140]: Loading service
file /services/sftp-ssh.service.
Jan 1 00:00:05 beaglebone user.info kernel: [ 0.172756] Advanced Linux
Sound Architecture Driver Initialized.
Jan 1 00:00:05 beaglebone daemon.info avahi-daemon[140]: Loading service
file /services/ssh.service.
Jan 1 00:00:05 beaglebone user.info kernel: [ 0.174098] Switching to
clocksource gp_timer
Jan 1 00:00:05 beaglebone daemon.info avahi-daemon[140]: Loading service
file /services/udisks.service.
Jan 1 00:00:05 beaglebone user.info kernel: [ 0.192221] NET: Registered
protocol family 2
Jan 1 00:00:05 beaglebone daemon.info avahi-daemon[140]: Network interface
enumeration completed.
Jan 1 00:00:05 beaglebone user.info kernel: [ 0.193216] TCP established
hash table entries: 4096 (order: 3, 32768 bytes)
Jan 1 00:00:05 beaglebone daemon.info avahi-daemon[140]: Registering HINFO
record with values 'ARMV7L'/'LINUX'.
Jan 1 00:00:05 beaglebone user.info kernel: [ 0.193359] TCP bind hash
table entries: 4096 (order: 4, 81920 bytes)
Jan 1 00:00:05 beaglebone daemon.info connmand[127]: Checking loopback
interface settings
Jan 1 00:00:05 beaglebone daemon.info avahi-daemon[140]: Server startup
complete. Host name is beaglebone.local. Local service cookie is 3118606904.
Jan 1 00:00:05 beaglebone user.info kernel: [ 0.193520] TCP: Hash
tables configured (established 4096 bind 4096)
Jan 1 00:00:05 beaglebone daemon.info connmand[127]: System hostname is
beaglebone
Jan 1 00:00:05 beaglebone daemon.info avahi-daemon[140]: Service
"beaglebone" (/services/udisks.service) successfully established.
Jan 1 00:00:05 beaglebone user.info kernel: [ 0.193610] TCP: reno
registered
Jan 1 00:00:05 beaglebone daemon.info avahi-daemon[140]: Service
"beaglebone" (/services/ssh.service) successfully established.
Jan 1 00:00:05 beaglebone user.info kernel: [ 0.193638] UDP hash table
entries: 256 (order: 1, 12288 bytes)
Jan 1 00:00:05 beaglebone daemon.info avahi-daemon[140]: Service
"beaglebone" (/services/sftp-ssh.service) successfully established.
Jan 1 00:00:05 beaglebone user.info kernel: [ 0.193684] UDP-Lite hash
table entries: 256 (order: 1, 12288 bytes)
Jan 1 00:00:05 beaglebone daemon.info avahi-daemon[140]: Service "GateOne
on beaglebone" (/services/gateone-avahi.service) successfully established.
Jan 1 00:00:05 beaglebone daemon.info connmand[127]: lo {newlink} index 1
operstate 0 <UNKNOWN>
Jan 1 00:00:05 beaglebone user.info kernel: [ 0.194168] NET: Registered
protocol family 1
Jan 1 00:00:05 beaglebone daemon.notice dbus[138]: [system] Activating via
systemd: service name='fi.w1.wpa_supplicant1' unit='wpa_supplicant.service'
Jan 1 00:00:05 beaglebone daemon.info avahi-daemon[140]: Service "Cloud9
IDE on beaglebone" (/services/cloud9-avahi.service) successfully
established.
Jan 1 00:00:05 beaglebone daemon.info connmand[127]: eth0 {create} index 2
type 1 <ETHER>
Jan 1 00:00:05 beaglebone user.info kernel: [ 0.194712] RPC: Registered
named UNIX socket transport module.
Jan 1 00:00:05 beaglebone daemon.info connmand[127]: eth0 {update} flags
4098 <DOWN>
Jan 1 00:00:06 beaglebone user.info kernel: [ 0.194732] RPC: Registered
udp transport module.
Jan 1 00:00:06 beaglebone daemon.info connmand[127]: eth0 {newlink} index
2 address C8:A0:30:B9:8C:EC mtu 1500
Jan 1 00:00:06 beaglebone user.info kernel: [ 0.194746] RPC: Registered
tcp transport module.
Jan 1 00:00:06 beaglebone daemon.notice dbus[138]: [system] Successfully
activated service 'fi.w1.wpa_supplicant1'
Jan 1 00:00:06 beaglebone daemon.info connmand[127]: eth0 {newlink} index
2 operstate 2 <DOWN>
Jan 1 00:00:06 beaglebone user.info kernel: [ 0.194761] RPC: Registered
tcp NFSv4.1 backchannel transport module.
Jan 1 00:00:06 beaglebone daemon.info connmand[127]: Adding interface eth0
[ ethernet ]
Jan 1 00:00:06 beaglebone user.info kernel: [ 0.195522] hw perfevents:
enabled with ARMv7 Cortex-A8 PMU driver, 5 counters available
Jan 1 00:00:06 beaglebone user.info kernel: [ 0.196062] CPU PMU:
attempt to register multiple PMU devices!
Jan 1 00:00:06 beaglebone user.warn kernel: [ 0.196103] arm-pmu: probe
of arm-pmu failed with error -28
Jan 1 00:00:06 beaglebone user.err kernel: [ 0.196491]
omap2_mbox_probe: platform not supported
Jan 1 00:00:06 beaglebone user.notice kernel: [ 0.200320] VFS: Disk
quotas dquot_6.5.2
Jan 1 00:00:06 beaglebone user.warn kernel: [ 0.200555] Dquot-cache
hash table entries: 1024 (order 0, 4096 bytes)
Jan 1 00:00:06 beaglebone user.notice kernel: [ 0.201928] NFS:
Registering the id_resolver key type
Jan 1 00:00:06 beaglebone daemon.info connmand[127]: usb0 {create} index 3
type 1 <ETHER>
Jan 1 00:00:06 beaglebone user.notice kernel: [ 0.202055] Key type
id_resolver registered
Jan 1 00:00:06 beaglebone daemon.info connmand[127]: usb0 {update} flags
4098 <DOWN>
Jan 1 00:00:06 beaglebone user.notice kernel: [ 0.202072] Key type
id_legacy registered
Jan 1 00:00:06 beaglebone daemon.info connmand[127]: usb0 {newlink} index
3 address 1A:4B:68:D0:89:A8 mtu 1500
Jan 1 00:00:06 beaglebone user.info kernel: [ 0.202138] jffs2: version
2.2. (NAND) (SUMMARY) © 2001-2006 Red Hat, Inc.
Jan 1 00:00:06 beaglebone daemon.info connmand[127]: usb0 {newlink} index
3 operstate 2 <DOWN>
Jan 1 00:00:06 beaglebone user.info kernel: [ 0.202581] msgmni has been
set to 996
Jan 1 00:00:06 beaglebone daemon.info connmand[127]: Adding interface usb0
[ gadget ]
Jan 1 00:00:06 beaglebone user.info kernel: [ 0.205390] Block layer
SCSI generic (bsg) driver version 0.4 loaded (major 249)
Jan 1 00:00:06 beaglebone daemon.info connmand[127]: eth0 {update} flags
4163 <UP,RUNNING>
Jan 1 00:00:06 beaglebone user.info kernel: [ 0.205489] io scheduler
noop registered
Jan 1 00:00:06 beaglebone daemon.info connmand[127]: eth0 {newlink} index
2 address C8:A0:30:B9:8C:EC mtu 1500
Jan 1 00:00:06 beaglebone user.info kernel: [ 0.205508] io scheduler
deadline registered
Jan 1 00:00:06 beaglebone daemon.info connmand[127]: eth0 {newlink} index
2 operstate 0 <UNKNOWN>
Jan 1 00:00:06 beaglebone user.info kernel: [ 0.205552] io scheduler
cfq registered (default)
Jan 1 00:00:06 beaglebone daemon.info connmand[127]: eth0 {update} flags
4099 <UP>
Jan 1 00:00:06 beaglebone daemon.info avahi-daemon[140]: Joining mDNS
multicast group on interface usb0.IPv4 with address 192.168.7.2.
Jan 1 00:00:06 beaglebone user.err kernel: [ 0.207177] tps65217-bl
tps65217-bl: no platform data provided
Jan 1 00:00:06 beaglebone daemon.info connmand[127]: eth0 {newlink} index
2 address C8:A0:30:B9:8C:EC mtu 1500
Jan 1 00:00:06 beaglebone daemon.info avahi-daemon[140]: New relevant
interface usb0.IPv4 for mDNS.
Jan 1 00:00:06 beaglebone daemon.info udhcpd[259]: udhcpd (v1.20.2) started
Jan 1 00:00:06 beaglebone user.warn kernel: [ 0.207219] tps65217-bl:
probe of tps65217-bl failed with error -22
Jan 1 00:00:06 beaglebone daemon.info connmand[127]: eth0 {newlink} index
2 operstate 2 <DOWN>
Jan 1 00:00:06 beaglebone daemon.info avahi-daemon[140]: Registering new
address record for 192.168.7.2 on usb0.IPv4.
Jan 1 00:00:06 beaglebone user.info kernel: [ 0.208213] Serial:
8250/16550 driver, 4 ports, IRQ sharing enabled
Jan 1 00:00:06 beaglebone daemon.info connmand[127]: usb0 {add} address
192.168.7.2/24 label usb0 family 2
Jan 1 00:00:10 beaglebone daemon.info avahi-daemon[140]: Withdrawing
address record for 192.168.7.2 on usb0.
Jan 1 00:00:10 beaglebone user.warn kernel: [ 0.210751] omap_uart
44e09000.serial: did not get pins for uart0 error: -19
Jan 1 00:00:10 beaglebone daemon.info connmand[127]: usb0 {update} flags
4099 <UP>
Jan 1 00:00:10 beaglebone daemon.info avahi-daemon[140]: Leaving mDNS
multicast group on interface usb0.IPv4 with address 192.168.7.2.
Jan 1 00:00:10 beaglebone user.info kernel: [ 0.211026]
44e09000.serial: ttyO0 at MMIO 0x44e09000 (irq = 88) is a OMAP UART0
Jan 1 00:00:10 beaglebone daemon.info connmand[127]: usb0 {newlink} index
3 address 1A:4B:68:D0:89:A8 mtu 1500
Jan 1 00:00:10 beaglebone daemon.info avahi-daemon[140]: Interface
usb0.IPv4 no longer relevant for mDNS.
Jan 1 00:00:10 beaglebone user.info kernel: [ 0.223438] console [ttyO0]
enabled
Jan 1 00:00:10 beaglebone daemon.info connmand[127]: usb0 {newlink} index
3 operstate 2 <DOWN>
Jan 1 00:00:10 beaglebone daemon.info avahi-daemon[140]: Joining mDNS
multicast group on interface usb0.IPv4 with address 192.168.7.2.
Jan 1 00:00:10 beaglebone user.info kernel: [ 0.224642] [drm]
Initialized drm 1.1.0 20060810
Jan 1 00:00:10 beaglebone daemon.info connmand[127]: usb0 {add} route
192.168.7.0 gw 0.0.0.0 scope 253 <LINK>
Jan 1 00:00:10 beaglebone daemon.info avahi-daemon[140]: New relevant
interface usb0.IPv4 for mDNS.
Jan 1 00:00:10 beaglebone daemon.info connmand[127]: usb0 {del} address
192.168.7.2/24 label usb0
Jan 1 00:00:11 beaglebone daemon.info avahi-daemon[140]: Registering new
address record for 192.168.7.2 on usb0.IPv4.
Jan 1 00:00:11 beaglebone user.info kernel: [ 0.238445] brd: module
loaded
Jan 1 00:00:11 beaglebone daemon.info connmand[127]: usb0 {del} route
192.168.7.0 gw 0.0.0.0 scope 253 <LINK>
Jan 1 00:00:11 beaglebone user.info kernel: [ 0.245470] loop: module
loaded
Jan 1 00:00:11 beaglebone daemon.info connmand[127]: usb0 {add} address
192.168.7.2/30 label usb0 family 2
Jan 1 00:00:11 beaglebone user.info kernel: [ 0.245596] at24 0-0050:
32768 byte 24c256 EEPROM, writable, 1 bytes/write
Jan 1 00:00:11 beaglebone daemon.info connmand[127]: usb0 {add} route
192.168.7.0 gw 0.0.0.0 scope 253 <LINK>
Jan 1 00:00:11 beaglebone user.info kernel: [ 0.245676] at24 1-0054:
32768 byte 24c256 EEPROM, writable, 1 bytes/write
Jan 1 00:00:11 beaglebone daemon.info connmand[127]: usb0 {add} route
192.168.7.0 gw 0.0.0.0 scope 253 <LINK>
Jan 1 00:00:11 beaglebone user.info kernel: [ 0.245745] at24 1-0055:
32768 byte 24c256 EEPROM, writable, 1 bytes/write
Jan 1 00:00:11 beaglebone daemon.info connmand[127]: eth0 {add} route
fe80:: gw :: scope 0 <UNIVERSE>
Jan 1 00:00:11 beaglebone daemon.info avahi-daemon[140]: Registering new
address record for fe80::caa0:30ff:feb9:8cec on eth0.*.
Jan 1 00:00:11 beaglebone user.info kernel: [ 0.245816] at24 1-0056:
32768 byte 24c256 EEPROM, writable, 1 bytes/write
Jan 1 00:00:11 beaglebone daemon.info connmand[127]: eth0 {update} flags
69699 <UP,RUNNING,LOWER_UP>
Jan 1 00:00:11 beaglebone user.info kernel: [ 0.245885] at24 1-0057:
32768 byte 24c256 EEPROM, writable, 1 bytes/write
Jan 1 00:00:11 beaglebone daemon.info avahi-daemon[140]: Withdrawing
address record for fe80::caa0:30ff:feb9:8cec on eth0.
Jan 1 00:00:11 beaglebone daemon.info connmand[127]: eth0 {newlink} index
2 address C8:A0:30:B9:8C:EC mtu 1500
Jan 1 00:00:11 beaglebone user.info kernel: [ 0.253063] bone-capemgr
bone_capemgr.9: Baseboard: 'A335BNLT,0A5C,3513BBBK0549'
Jan 1 00:00:11 beaglebone daemon.info connmand[127]: eth0 {newlink} index
2 operstate 6 <UP>
Jan 1 00:00:11 beaglebone user.info kernel: [ 0.253105] bone-capemgr
bone_capemgr.9: compatible-baseboard=ti,beaglebone-black
Jan 1 00:00:11 beaglebone daemon.info connmand[127]: eth0 {del} route
fe80:: gw :: scope 0 <UNIVERSE>
Jan 1 00:00:11 beaglebone user.err kernel: [ 0.283596] bone-capemgr
bone_capemgr.9: slot #0: No cape found
Jan 1 00:00:11 beaglebone user.err kernel: [ 0.320703] bone-capemgr
bone_capemgr.9: slot #1: No cape found
Jan 1 00:00:11 beaglebone user.err kernel: [ 0.357811] bone-capemgr
bone_capemgr.9: slot #2: No cape found
Jan 1 00:00:11 beaglebone user.err kernel: [ 0.394920] bone-capemgr
bone_capemgr.9: slot #3: No cape found
Jan 1 00:00:11 beaglebone user.info kernel: [ 0.401229] bone-capemgr
bone_capemgr.9: slot #4: specific override
Jan 1 00:00:11 beaglebone user.info kernel: [ 0.401272] bone-capemgr
bone_capemgr.9: bone: Using override eeprom data at slot 4
Jan 1 00:00:11 beaglebone user.info kernel: [ 0.401302] bone-capemgr
bone_capemgr.9: slot #4: 'Bone-LT-eMMC-2G,00A0,Texas
Instrument,BB-BONE-EMMC-2G'
Jan 1 00:00:11 beaglebone user.info kernel: [ 0.401459] bone-capemgr
bone_capemgr.9: slot #5: specific override
Jan 1 00:00:11 beaglebone user.info kernel: [ 0.401496] bone-capemgr
bone_capemgr.9: bone: Using override eeprom data at slot 5
Jan 1 00:00:11 beaglebone user.info kernel: [ 0.401524] bone-capemgr
bone_capemgr.9: slot #5: 'Bone-Black-HDMI,00A0,Texas
Instrument,BB-BONELT-HDMI'
Jan 1 00:00:11 beaglebone user.info kernel: [ 0.401662] bone-capemgr
bone_capemgr.9: slot #6: specific override
Jan 1 00:00:11 beaglebone user.info kernel: [ 0.401697] bone-capemgr
bone_capemgr.9: bone: Using override eeprom data at slot 6
Jan 1 00:00:11 beaglebone user.info kernel: [ 0.401726] bone-capemgr
bone_capemgr.9: slot #6: 'Bone-Black-HDMIN,00A0,Texas
Instrument,BB-BONELT-HDMIN'
Jan 1 00:00:11 beaglebone user.info kernel: [ 0.402359] bone-capemgr
bone_capemgr.9: initialized OK.
Jan 1 00:00:11 beaglebone user.info kernel: [ 0.404344] OneNAND driver
initializing
Jan 1 00:00:11 beaglebone daemon.warn connmand[127]: Skipping disconnect
of carrier, network is connecting.
Jan 1 00:00:11 beaglebone user.info kernel: [ 0.404827] bone-capemgr
bone_capemgr.9: slot #4: Requesting firmware 'cape-bone-2g-emmc1.dtbo' for
board-name 'Bone-LT-eMMC-2G', version '00A0'
Jan 1 00:00:11 beaglebone daemon.info connmand[127]: eth0 {add} route
fe80:: gw :: scope 0 <UNIVERSE>
Jan 1 00:00:11 beaglebone user.info kernel: [ 0.404861] bone-capemgr
bone_capemgr.9: slot #4: dtbo 'cape-bone-2g-emmc1.dtbo' loaded; converting
to live tree
Jan 1 00:00:11 beaglebone user.info kernel: [ 0.405171] bone-capemgr
bone_capemgr.9: slot #4: #2 overlays
Jan 1 00:00:11 beaglebone user.info kernel: [ 0.406043] bone-capemgr
bone_capemgr.9: slot #4: Applied #2 overlays.
Jan 1 00:00:11 beaglebone user.info kernel: [ 0.406223] bone-capemgr
bone_capemgr.9: slot #5: Requesting firmware
'cape-boneblack-hdmi-00A0.dtbo' for board-name 'Bone-Black-HDMI', version
'00A0'
Jan 1 00:00:11 beaglebone user.info kernel: [ 0.406270] bone-capemgr
bone_capemgr.9: slot #5: dtbo 'cape-boneblack-hdmi-00A0.dtbo' loaded;
converting to live tree
Jan 1 00:00:11 beaglebone user.info kernel: [ 0.407439] bone-capemgr
bone_capemgr.9: slot #5: #4 overlays
Jan 1 00:00:11 beaglebone user.info kernel: [ 0.409844] usbcore:
registered new interface driver asix
Jan 1 00:00:11 beaglebone user.info kernel: [ 0.409973] usbcore:
registered new interface driver cdc_ether
Jan 1 00:00:11 beaglebone user.info kernel: [ 0.410096] usbcore:
registered new interface driver smsc95xx
Jan 1 00:00:11 beaglebone user.info kernel: [ 0.410187] usbcore:
registered new interface driver net1080
Jan 1 00:00:11 beaglebone user.info kernel: [ 0.410277] usbcore:
registered new interface driver cdc_subset
Jan 1 00:00:12 beaglebone user.info kernel: [ 0.410365] usbcore:
registered new interface driver zaurus
Jan 1 00:00:12 beaglebone user.info kernel: [ 0.410638] usbcore:
registered new interface driver cdc_ncm
Jan 1 00:00:12 beaglebone user.warn kernel: [ 0.412552] platform
4830e000.fb: alias fck already exists
Jan 1 00:00:12 beaglebone daemon.notice dbus[138]: [system] Activating via
systemd: service name='org.freedesktop.ConsoleKit'
unit='console-kit-daemon.service'
Jan 1 00:00:12 beaglebone user.info kernel: [ 0.414184] bone-capemgr
bone_capemgr.9: slot #5: Applied #4 overlays.
Jan 1 00:00:12 beaglebone user.info kernel: [ 0.414282] bone-capemgr
bone_capemgr.9: slot #6: Requesting firmware
'cape-boneblack-hdmin-00A0.dtbo' for board-name 'Bone-Black-HDMIN', version
'00A0'
Jan 1 00:00:12 beaglebone user.info kernel: [ 0.414326] bone-capemgr
bone_capemgr.9: slot #6: dtbo 'cape-boneblack-hdmin-00A0.dtbo' loaded;
converting to live tree
Jan 1 00:00:12 beaglebone user.err kernel: [ 0.414761] bone-capemgr
bone_capemgr.9: slot #6: BB-BONELT-HDMIN conflict P8.45 (#5:BB-BONELT-HDMI)
Jan 1 00:00:12 beaglebone user.err kernel: [ 0.424370] bone-capemgr
bone_capemgr.9: slot #6: Failed verification
Jan 1 00:00:12 beaglebone user.info kernel: [ 0.431143] bone-capemgr
bone_capemgr.9: loader: retrying slot-6 BB-BONELT-HDMIN:00A0 (prio 2)
Jan 1 00:00:12 beaglebone user.info kernel: [ 0.431450] usbcore:
registered new interface driver cdc_acm
Jan 1 00:00:12 beaglebone user.info kernel: [ 0.431467] cdc_acm: USB
Abstract Control Model driver for USB modems and ISDN adapters
Jan 1 00:00:12 beaglebone user.info kernel: [ 0.431481] Initializing
USB Mass Storage driver...
Jan 1 00:00:12 beaglebone user.info kernel: [ 0.431607] usbcore:
registered new interface driver usb-storage
Jan 1 00:00:12 beaglebone user.info kernel: [ 0.431621] USB Mass
Storage support registered.
Jan 1 00:00:12 beaglebone user.info kernel: [ 0.431849] musb-hdrc:
version 6.0, ?dma?, otg (peripheral+host)
Jan 1 00:00:12 beaglebone user.info kernel: [ 0.432295] musb-hdrc
musb-hdrc.0.auto: pdev->id = 0
Jan 1 00:00:12 beaglebone user.info kernel: [ 0.432323] musb-hdrc
musb-hdrc.0.auto: drivers/usb/musb/musb_dsps.c:468 dsps_musb_init: OK
Jan 1 00:00:12 beaglebone user.info kernel: [ 0.432575] musb-hdrc
musb-hdrc.0.auto: *** mode=3
Jan 1 00:00:12 beaglebone user.info kernel: [ 0.432597] musb-hdrc
musb-hdrc.0.auto: *** power=250
Jan 1 00:00:12 beaglebone user.info kernel: [ 0.433460] musb-hdrc
musb-hdrc.1.auto: pdev->id = 1
Jan 1 00:00:12 beaglebone user.info kernel: [ 0.433491] musb-hdrc
musb-hdrc.1.auto: drivers/usb/musb/musb_dsps.c:468 dsps_musb_init: OK
Jan 1 00:00:12 beaglebone daemon.notice dbus[138]: [system] Activating
service name='org.freedesktop.PolicyKit1' (using servicehelper)
Jan 1 00:00:12 beaglebone user.info kernel: [ 0.433714] musb-hdrc
musb-hdrc.1.auto: *** mode=1
Jan 1 00:00:12 beaglebone user.info kernel: [ 0.433735] musb-hdrc
musb-hdrc.1.auto: *** power=250
Jan 1 00:00:12 beaglebone user.info kernel: [ 0.433756] musb-hdrc
musb-hdrc.1.auto: MUSB HDRC host driver
Jan 1 00:00:12 beaglebone user.info kernel: [ 0.434287] musb-hdrc
musb-hdrc.1.auto: new USB bus registered, assigned bus number 1
Jan 1 00:00:12 beaglebone user.info kernel: [ 0.434514] usb usb1: New
USB device found, idVendor=1d6b, idProduct=0002
Jan 1 00:00:12 beaglebone user.info kernel: [ 0.434536] usb usb1: New
USB device strings: Mfr=3, Product=2, SerialNumber=1
Jan 1 00:00:12 beaglebone user.info kernel: [ 0.434557] usb usb1:
Product: MUSB HDRC host driver
Jan 1 00:00:12 beaglebone user.info kernel: [ 0.434576] usb usb1:
Manufacturer: Linux 3.8.13 musb-hcd
Jan 1 00:00:12 beaglebone user.info kernel: [ 0.434595] usb usb1:
SerialNumber: musb-hdrc.1.auto
Jan 1 00:00:12 beaglebone user.info kernel: [ 0.435637] hub 1-0:1.0:
USB hub found
Jan 1 00:00:12 beaglebone user.info kernel: [ 0.435675] hub 1-0:1.0: 1
port detected
Jan 1 00:00:12 beaglebone user.info kernel: [ 0.437076] mousedev: PS/2
mouse device common for all mice
Jan 1 00:00:12 beaglebone user.info kernel: [ 0.439543] omap_rtc
44e3e000.rtc: rtc core: registered 44e3e000.rtc as rtc0
Jan 1 00:00:12 beaglebone user.info kernel: [ 0.440033] i2c /dev
entries driver
Jan 1 00:00:12 beaglebone user.info kernel: [ 0.441818] pps_ldisc: PPS
line discipline registered
Jan 1 00:00:12 beaglebone user.info kernel: [ 0.442021] Driver for
1-wire Dallas network protocol.
Jan 1 00:00:12 beaglebone user.info kernel: [ 0.443921] omap_wdt: OMAP
Watchdog Timer Rev 0x01: initial timeout 60 sec
Jan 1 00:00:12 beaglebone user.info kernel: [ 0.444285] cpuidle: using
governor ladder
Jan 1 00:00:12 beaglebone user.info kernel: [ 0.444304] cpuidle: using
governor menu
Jan 1 00:00:12 beaglebone user.err kernel: [ 0.444782] omap_hsmmc
mmc.5: of_parse_phandle_with_args of 'reset' failed
Jan 1 00:00:12 beaglebone user.warn kernel: [ 0.452030] omap_hsmmc
mmc.5: Failed to get rstctl; not using any
Jan 1 00:00:12 beaglebone user.err kernel: [ 0.452079] bone-capemgr
bone_capemgr.9: loader: failed to load slot-6 BB-BONELT-HDMIN:00A0 (prio 2)
Jan 1 00:00:12 beaglebone user.info kernel: [ 0.462150] edma-dma-engine
edma-dma-engine.0: allocated channel for 0:25
Jan 1 00:00:12 beaglebone user.info kernel: [ 0.462239] edma-dma-engine
edma-dma-engine.0: allocated channel for 0:24
Jan 1 00:00:12 beaglebone user.warn kernel: [ 0.462481] mmc.5 supply
vmmc_aux not found, using dummy regulator
Jan 1 00:00:12 beaglebone user.warn kernel: [ 0.462926] omap_hsmmc
mmc.5: pins are not configured from the driver
Jan 1 00:00:12 beaglebone user.info kernel: [ 0.489019] gpio-rctrl
rstctl.4: gpio_rctrl_request eMMC_RSTn
Jan 1 00:00:12 beaglebone user.info kernel: [ 0.489107] omap_hsmmc
mmc.11: Got rstctl (gpio:#0 name eMMC_RSTn) label:eMMC_RSTn
Jan 1 00:00:12 beaglebone user.info kernel: [ 0.489129] gpio-rctrl
rstctl.4: gpio_rctrl_deassert eMMC_RSTn
Jan 1 00:00:12 beaglebone user.info kernel: [ 0.489458] edma-dma-engine
edma-dma-engine.0: allocated channel for 0:3
Jan 1 00:00:12 beaglebone user.info kernel: [ 0.489541] edma-dma-engine
edma-dma-engine.0: allocated channel for 0:2
Jan 1 00:00:12 beaglebone user.warn kernel: [ 0.490069] mmc.11 supply
vmmc_aux not found, using dummy regulator
Jan 1 00:00:12 beaglebone user.warn kernel: [ 0.490207] omap_hsmmc
mmc.11: pins are not configured from the driver
Jan 1 00:00:12 beaglebone user.err kernel: [ 0.518496] pinctrl-single
44e10800.pinmux: pin 44e10854 already requested by 44e10800.pinmux; cannot
claim for gpio-leds.8
Jan 1 00:00:12 beaglebone user.err kernel: [ 0.530237] pinctrl-single
44e10800.pinmux: pin-21 (gpio-leds.8) status -22
Jan 1 00:00:13 beaglebone user.err kernel: [ 0.537564] pinctrl-single
44e10800.pinmux: could not request pin 21 on device pinctrl-single
Jan 1 00:00:13 beaglebone user.warn kernel: [ 0.546757] leds-gpio
gpio-leds.8: pins are not configured from the driver
Jan 1 00:00:13 beaglebone user.info kernel: [ 0.548168] ledtrig-cpu:
registered to indicate activity on CPUs
Jan 1 00:00:13 beaglebone user.info kernel: [ 0.548601] edma-dma-engine
edma-dma-engine.0: allocated channel for 0:36
Jan 1 00:00:13 beaglebone user.info kernel: [ 0.548688] omap-sham
53100000.sham: hw accel on OMAP rev 4.3
Jan 1 00:00:13 beaglebone user.info kernel: [ 0.550884] omap-aes
53500000.aes: OMAP AES hw accel rev: 3.2
Jan 1 00:00:13 beaglebone user.info kernel: [ 0.551013] edma-dma-engine
edma-dma-engine.0: allocated channel for 0:5
Jan 1 00:00:13 beaglebone user.info kernel: [ 0.551093] edma-dma-engine
edma-dma-engine.0: allocated channel for 0:6
Jan 1 00:00:13 beaglebone user.info kernel: [ 0.556712] usbcore:
registered new interface driver usbhid
Jan 1 00:00:13 beaglebone user.info kernel: [ 0.556733] usbhid: USB HID
core driver
Jan 1 00:00:13 beaglebone user.info kernel: [ 0.561186] davinci_evm
sound.14: nxp-hdmi-hifi <-> 48038000.mcasp mapping ok
Jan 1 00:00:13 beaglebone user.info kernel: [ 0.565522] TCP: cubic
registered
Jan 1 00:00:13 beaglebone user.info kernel: [ 0.565543] Initializing
XFRM netlink socket
Jan 1 00:00:13 beaglebone user.info kernel: [ 0.565587] NET: Registered
protocol family 17
Jan 1 00:00:13 beaglebone user.info kernel: [ 0.565661] NET: Registered
protocol family 15
Jan 1 00:00:13 beaglebone daemon.info avahi-daemon[140]: Registering new
address record for fe80::caa0:30ff:feb9:8cec on eth0.*.
Jan 1 00:00:13 beaglebone user.notice kernel: [ 0.565805] Key type
dns_resolver registered
Jan 1 00:00:13 beaglebone daemon.info polkitd[422]: started daemon version
0.104 using authority implementation `local' version `0.104'
Jan 1 00:00:13 beaglebone user.info kernel: [ 0.566106] VFP support
v0.3: implementor 41 architecture 3 part 30 variant c rev 3
Jan 1 00:00:13 beaglebone daemon.notice dbus[138]: [system] Successfully
activated service 'org.freedesktop.PolicyKit1'
Jan 1 00:00:13 beaglebone user.info kernel: [ 0.566144] ThumbEE CPU
extension supported.
Jan 1 00:00:13 beaglebone user.notice kernel: [ 0.566187] Registering
SWP/SWPB emulation handler
Jan 1 00:00:13 beaglebone user.info kernel: [ 0.567339] registered
taskstats version 1
Jan 1 00:00:13 beaglebone daemon.notice dbus[138]: [system] Successfully
activated service 'org.freedesktop.ConsoleKit'
Jan 1 00:00:13 beaglebone user.info kernel: [ 0.570485] tilcdc
4830e000.fb: No power control GPIO
Jan 1 00:00:13 beaglebone user.info kernel: [ 0.601613] mmc1: BKOPS_EN
bit is not set
Jan 1 00:00:13 beaglebone user.info kernel: [ 0.604255] mmc1: new high
speed MMC card at address 0001
Jan 1 00:00:13 beaglebone user.info kernel: [ 0.605049] mmcblk0:
mmc1:0001 MMC02G 1.78 GiB
Jan 1 00:00:13 beaglebone user.info kernel: [ 0.605410] mmcblk0boot0:
mmc1:0001 MMC02G partition 1 1.00 MiB
Jan 1 00:00:13 beaglebone user.info kernel: [ 0.605757] mmcblk0boot1:
mmc1:0001 MMC02G partition 2 1.00 MiB
Jan 1 00:00:13 beaglebone user.info kernel: [ 0.608077] mmcblk0: p1 p2
Jan 1 00:00:13 beaglebone user.info kernel: [ 0.610768] mmcblk0boot1:
unknown partition table
Jan 1 00:00:13 beaglebone user.info kernel: [ 0.612766] mmcblk0boot0:
unknown partition table
Jan 1 00:00:13 beaglebone user.info kernel: [ 0.679232] tilcdc
4830e000.fb: found TDA19988
Jan 1 00:00:13 beaglebone user.info kernel: [ 0.680114] [drm] Supports
vblank timestamp caching Rev 1 (10.10.2010).
Jan 1 00:00:13 beaglebone user.info kernel: [ 0.680130] [drm] No driver
support for vblank timestamp query.
Jan 1 00:00:13 beaglebone user.info kernel: [ 0.680602] tilcdc
4830e000.fb: No connectors reported connected with modes
Jan 1 00:00:13 beaglebone user.info kernel: [ 0.680681] [drm] Cannot
find any crtc or sizes - going 1024x768
Jan 1 00:00:13 beaglebone user.info kernel: [ 0.698089] Console:
switching to colour frame buffer device 128x48
Jan 1 00:00:13 beaglebone user.info kernel: [ 0.712764] tilcdc
4830e000.fb: fb0: frame buffer device
Jan 1 00:00:13 beaglebone user.info kernel: [ 0.712785] tilcdc
4830e000.fb: registered panic notifier
Jan 1 00:00:13 beaglebone user.info kernel: [ 0.712823] [drm]
Initialized tilcdc 1.0.0 20121205 on minor 0
Jan 1 00:00:13 beaglebone user.info kernel: [ 0.762147] davinci_mdio
4a101000.mdio: davinci mdio revision 1.6
Jan 1 00:00:13 beaglebone user.info kernel: [ 0.762176] davinci_mdio
4a101000.mdio: detected phy mask fffffffe
Jan 1 00:00:13 beaglebone user.info kernel: [ 0.763186] libphy:
4a101000.mdio: probed
Jan 1 00:00:13 beaglebone user.info kernel: [ 0.763218] davinci_mdio
4a101000.mdio: phy[0]: device 4a101000.mdio:00, driver SMSC LAN8710/LAN8720
Jan 1 00:00:13 beaglebone user.info kernel: [ 0.763457] Detected MACID
= c8:a0:30:b9:8c:ec
Jan 1 00:00:13 beaglebone user.info kernel: [ 0.763568] cpsw
4a100000.ethernet: NAPI disabled
Jan 1 00:00:13 beaglebone user.info kernel: [ 0.765167] omap_rtc
44e3e000.rtc: setting system clock to 2000-01-01 00:00:00 UTC (946684800)
Jan 1 00:00:13 beaglebone user.info kernel: [ 0.772321] ALSA device
list:
Jan 1 00:00:13 beaglebone user.info kernel: [ 0.772344] #0: TI
BeagleBone Black
Jan 1 00:00:13 beaglebone user.info kernel: [ 0.806796] EXT4-fs
(mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
Jan 1 00:00:13 beaglebone user.info kernel: [ 0.806862] VFS: Mounted
root (ext4 filesystem) readonly on device 179:2.
Jan 1 00:00:13 beaglebone user.info kernel: [ 0.811989] devtmpfs:
mounted
Jan 1 00:00:13 beaglebone user.info kernel: [ 0.812291] Freeing init
memory: 264K
Jan 1 00:00:13 beaglebone user.err kernel: 0>[ 1.312014] systemd[1]:
systemd 196 running in system mode. (+PAM -LIBWRAP -AUDIT -SELINUX +IMA
+SYSVINIT -LIBCRYPTSETUP +GCRYPT +ACL +XZ; angstrom)
Jan 1 00:00:13 beaglebone user.err kernel: 0>[ 1.350602] systemd[1]:
Inserted module 'autofs4'
Jan 1 00:00:13 beaglebone user.err kernel: 0>[ 1.352594] systemd[1]:
Set hostname to <beaglebone>.
Jan 1 00:00:13 beaglebone user.err kernel: 0>[ 1.356493] systemd[1]:
Initializing machine ID from random generator.
Jan 1 00:00:13 beaglebone user.err kernel: 0>[ 1.356789] systemd[1]:
Installed transient /etc/machine-id file.
Jan 1 00:00:13 beaglebone user.err kernel: 0>[ 1.633973] systemd[1]:
Starting Forward Password Requests to Wall Directory Watch.
Jan 1 00:00:13 beaglebone user.err kernel: 0>[ 1.634453] systemd[1]:
Started Forward Password Requests to Wall Directory Watch.
Jan 1 00:00:13 beaglebone user.err kernel: 0>[ 1.634567] systemd[1]:
Expecting device dev-ttyO0.device...
Jan 1 00:00:13 beaglebone user.err kernel: 0>[ 1.634658] systemd[1]:
Expecting device dev-ttyGS0.device...
Jan 1 00:00:13 beaglebone user.err kernel: 0>[ 1.634735] systemd[1]:
Starting Remote File Systems.
Jan 1 00:00:13 beaglebone user.err kernel: 0>[ 1.634804] systemd[1]:
Reached target Remote File Systems.
Jan 1 00:00:13 beaglebone user.err kernel: 0>[ 1.634873] systemd[1]:
Starting Syslog Socket.
Jan 1 00:00:13 beaglebone user.err kernel: 0>[ 1.635251] systemd[1]:
Listening on Syslog Socket.
Jan 1 00:00:13 beaglebone user.err kernel: 0>[ 1.635342] systemd[1]:
Starting Delayed Shutdown Socket.
Jan 1 00:00:13 beaglebone user.err kernel: 0>[ 1.635512] systemd[1]:
Listening on Delayed Shutdown Socket.
Jan 1 00:00:13 beaglebone user.err kernel: 0>[ 1.635576] systemd[1]:
Starting /dev/initctl Compatibility Named Pipe.
Jan 1 00:00:13 beaglebone user.err kernel: 0>[ 1.635726] systemd[1]:
Listening on /dev/initctl Compatibility Named Pipe.
Jan 1 00:00:13 beaglebone user.err kernel: 0>[ 1.636253] systemd[1]:
Starting udev Kernel Socket.
Jan 1 00:00:13 beaglebone user.err kernel: 0>[ 1.636468] systemd[1]:
Listening on udev Kernel Socket.
Jan 1 00:00:13 beaglebone user.err kernel: 0>[ 1.636826] systemd[1]:
Starting udev Control Socket.
Jan 1 00:00:13 beaglebone user.err kernel: 0>[ 1.637194] systemd[1]:
Listening on udev Control Socket.
Jan 1 00:00:13 beaglebone user.err kernel: 0>[ 1.637469] systemd[1]:
Starting Arbitrary Executable File Formats File System Automount Point.
Jan 1 00:00:13 beaglebone user.err kernel: 0>[ 1.638170] systemd[1]:
Set up automount Arbitrary Executable File Formats File System Automount
Point.
Jan 1 00:00:13 beaglebone user.err kernel: 0>[ 1.638284] systemd[1]:
Starting Dispatch Password Requests to Console Directory Watch.
Jan 1 00:00:13 beaglebone user.err kernel: 0>[ 1.638571] systemd[1]:
Started Dispatch Password Requests to Console Directory Watch.
Jan 1 00:00:13 beaglebone user.err kernel: 0>[ 1.638646] systemd[1]:
Starting Swap.
Jan 1 00:00:13 beaglebone user.err kernel: 0>[ 1.638722] systemd[1]:
Reached target Swap.
Jan 1 00:00:13 beaglebone user.err kernel: 0>[ 1.638819] systemd[1]:
Starting Journal Socket.
Jan 1 00:00:13 beaglebone user.err kernel: 0>[ 1.639306] systemd[1]:
Listening on Journal Socket.
Jan 1 00:00:13 beaglebone user.err kernel: 0>[ 1.639409] systemd[1]:
Starting Syslog.
Jan 1 00:00:13 beaglebone user.err kernel: 0>[ 1.639484] systemd[1]:
Reached target Syslog.
Jan 1 00:00:13 beaglebone user.err kernel: 0>[ 1.639615] systemd[1]:
Starting File System Check on Root Device...
Jan 1 00:00:13 beaglebone user.err kernel: 0>[ 1.653451] systemd[1]:
Starting Load Kernel Modules...
Jan 1 00:00:13 beaglebone user.err kernel: 0>[ 1.658484] systemd[1]:
Mounting Debug File System...
Jan 1 00:00:13 beaglebone user.err kernel: 0>[ 1.665212] systemd[1]:
Mounting POSIX Message Queue File System...
Jan 1 00:00:13 beaglebone user.err kernel: 0>[ 1.672841] systemd[1]:
Starting udev Kernel Device Manager...
Jan 1 00:00:13 beaglebone user.err kernel: 0>[ 1.678733] systemd[1]:
Starting Journal Service...
Jan 1 00:00:13 beaglebone user.err kernel: 0>[ 1.686123] systemd[1]:
Started Journal Service.
Jan 1 00:00:13 beaglebone user.err kernel: 0>[ 1.705116] systemd[1]:
Starting Apply Kernel Variables...
Jan 1 00:00:13 beaglebone user.err kernel: 0>[ 1.709038] systemd[1]:
Starting udev Coldplug all Devices...
Jan 1 00:00:13 beaglebone user.err kernel: 0>[ 1.717870] systemd[1]:
Started Machine ID first boot configure.
Jan 1 00:00:13 beaglebone user.err kernel: 0>[ 1.746680] systemd[1]:
Started Set Up Additional Binary Formats.
Jan 1 00:00:13 beaglebone user.err kernel: 0>[ 1.746916] systemd[1]:
Mounted Huge Pages File System.
Jan 1 00:00:13 beaglebone user.info kernel: [ 1.856848] Bluetooth: Core
ver 2.16
Jan 1 00:00:13 beaglebone user.info kernel: [ 1.856938] NET: Registered
protocol family 31
Jan 1 00:00:13 beaglebone user.info kernel: [ 1.856947] Bluetooth: HCI
device and connection manager initialized
Jan 1 00:00:13 beaglebone user.info kernel: [ 1.856988] Bluetooth: HCI
socket layer initialized
Jan 1 00:00:13 beaglebone user.info kernel: [ 1.857004] Bluetooth:
L2CAP socket layer initialized
Jan 1 00:00:13 beaglebone user.info kernel: [ 1.857052] Bluetooth: SCO
socket layer initialized
Jan 1 00:00:13 beaglebone user.info kernel: [ 1.869272] Bluetooth: HIDP
(Human Interface Emulation) ver 1.2
Jan 1 00:00:13 beaglebone user.info kernel: [ 1.869318] Bluetooth: HIDP
socket layer initialized
Jan 1 00:00:13 beaglebone user.err kernel: 0>[ 1.887643]
systemd-udevd[89]: starting version 196
Jan 1 00:00:13 beaglebone user.info kernel: [ 1.972847] NET: Registered
protocol family 10
Jan 1 00:00:13 beaglebone user.info kernel: [ 2.035330] NET: Registered
protocol family 23
Jan 1 00:00:13 beaglebone user.info kernel: [ 2.042631] IrCOMM protocol
(Dag Brattli)
Jan 1 00:00:13 beaglebone user.info kernel: [ 2.106256] Bluetooth:
RFCOMM TTY layer initialized
Jan 1 00:00:13 beaglebone user.info kernel: [ 2.106332] Bluetooth:
RFCOMM socket layer initialized
Jan 1 00:00:13 beaglebone user.info kernel: [ 2.106341] Bluetooth:
RFCOMM ver 1.11
Jan 1 00:00:13 beaglebone user.info kernel: [ 2.497184] EXT4-fs
(mmcblk0p2): re-mounted. Opts: (null)
Jan 1 00:00:13 beaglebone user.warn kernel: 6>[ 3.042778]
systemd-journald[90]: Received SIGUSR1
Jan 1 00:00:13 beaglebone user.info kernel: [ 5.664801] ip_tables: (C)
2000-2006 Netfilter Core Team
Jan 1 00:00:13 beaglebone user.warn kernel: [ 5.736285] gadget: using
random self ethernet address
Jan 1 00:00:13 beaglebone user.info kernel: [ 5.758055] usb0: MAC
1a:4b:68:d0:89:a8
Jan 1 00:00:13 beaglebone user.info kernel: [ 5.758072] usb0: HOST MAC
c8:a0:30:b9:8c:ee
Jan 1 00:00:13 beaglebone user.info kernel: [ 5.771984] gadget: Mass
Storage Function, version: 2009/09/11
Jan 1 00:00:13 beaglebone user.info kernel: [ 5.772007] gadget: Number
of LUNs=1
Jan 1 00:00:13 beaglebone user.info kernel: [ 5.772031] lun0: LUN:
removable file: /dev/mmcblk0p1
Jan 1 00:00:13 beaglebone user.info kernel: [ 5.772712] gadget:
Multifunction Composite Gadget
Jan 1 00:00:13 beaglebone user.info kernel: [ 5.772738] gadget:
g_multi ready
Jan 1 00:00:13 beaglebone user.info kernel: [ 5.772779] musb-hdrc
musb-hdrc.0.auto: MUSB HDRC host driver
Jan 1 00:00:13 beaglebone user.info kernel: [ 5.778552] musb-hdrc
musb-hdrc.0.auto: new USB bus registered, assigned bus number 2
Jan 1 00:00:13 beaglebone user.info kernel: [ 5.778715] usb usb2: New
USB device found, idVendor=1d6b, idProduct=0002
Jan 1 00:00:13 beaglebone user.info kernel: [ 5.778728] usb usb2: New
USB device strings: Mfr=3, Product=2, SerialNumber=1
Jan 1 00:00:13 beaglebone user.info kernel: [ 5.778740] usb usb2:
Product: MUSB HDRC host driver
Jan 1 00:00:13 beaglebone user.info kernel: [ 5.778751] usb usb2:
Manufacturer: Linux 3.8.13 musb-hcd
Jan 1 00:00:13 beaglebone user.info kernel: [ 5.778762] usb usb2:
SerialNumber: musb-hdrc.0.auto
Jan 1 00:00:13 beaglebone user.info kernel: [ 5.785304] hub 2-0:1.0:
USB hub found
Jan 1 00:00:13 beaglebone user.info kernel: [ 5.785329] hub 2-0:1.0: 1
port detected
Jan 1 00:00:13 beaglebone user.info kernel: [ 6.508777] net eth0:
initializing cpsw version 1.12 (0)
Jan 1 00:00:13 beaglebone user.info kernel: [ 6.510941] net eth0: phy
found : id is : 0x7c0f1
Jan 1 00:00:13 beaglebone user.err kernel: [ 6.510961] libphy: PHY
4a101000.mdio:01 not found
Jan 1 00:00:13 beaglebone user.err kernel: [ 6.516008] net eth0: phy
4a101000.mdio:01 not found on slave 1
Jan 1 00:00:13 beaglebone user.info kernel: [ 6.633815] IPv6:
ADDRCONF(NETDEV_UP): eth0: link is not ready
Jan 1 00:00:14 beaglebone user.info kernel: [ 6.998713] IPv6:
ADDRCONF(NETDEV_UP): usb0: link is not ready
Jan 1 00:00:14 beaglebone user.info kernel: [ 9.586964] libphy:
4a101000.mdio:00 - Link is Up - 100/Full
Jan 1 00:00:14 beaglebone user.info kernel: [ 9.587027] IPv6:
ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Jan 1 00:00:14 beaglebone user.crit kernel: 7>[ 10.605569]
systemd-udevd[89]: worker [109] terminated by signal 11 (Segmentation fault)
Jan 1 00:00:14 beaglebone user.crit kernel: 7>[ 10.617721]
systemd-udevd[89]: worker [109] failed while handling
'/devices/ocp.3/47400000.usb/musb-hdrc.0.auto/gadget/net/usb0'
Jan 1 00:00:03 beaglebone daemon.info systemd[1]: Started Restore Sound
Card State.
Jan 1 00:00:03 beaglebone daemon.info systemd[1]: Started Console System
Startup Logging.
Jan 1 00:00:04 beaglebone daemon.info systemd[1]: Started Network Time
Service (one-shot ntpdate mode).
Jan 1 00:00:04 beaglebone daemon.info systemd[1]: Started Connection
service.
Jan 1 00:00:04 beaglebone daemon.info systemd[1]: Started Avahi
mDNS/DNS-SD Stack.
Jan 1 00:00:04 beaglebone daemon.info systemd[1]: Started Login Service.
Jan 1 00:00:04 beaglebone auth.info systemd-logind[137]: New seat seat0.
Jan 1 00:00:05 beaglebone daemon.info systemd[1]: Starting WPA
supplicant...
Jan 1 00:00:06 beaglebone daemon.info systemd[1]: Started WPA supplicant.
Jan 1 00:00:06 beaglebone daemon.notice systemd[1]: mpd.service: main
process exited, code=killed, status=6/ABRT
Jan 1 00:00:06 beaglebone daemon.notice systemd[1]: Unit mpd.service
entered failed state
Jan 1 00:00:14 beaglebone daemon.info systemd-fsck[85]: Angstrom: clean,
50813/112672 files, 297411/449820 blocks
Jan 1 00:00:14 beaglebone daemon.info connmand[127]: connmand[127]:
Connection Manager version 1.4
Jan 1 00:00:14 beaglebone daemon.info connmand[127]: connmand[127]:
Checking loopback interface settings
Jan 1 00:00:14 beaglebone daemon.info connmand[127]: connmand[127]: System
hostname is beaglebone
Jan 1 00:00:14 beaglebone daemon.info connmand[127]: connmand[127]: lo
{newlink} index 1 operstate 0 <UNKNOWN>
Jan 1 00:00:14 beaglebone daemon.info connmand[127]: connmand[127]: eth0
{create} index 2 type 1 <ETHER>
Jan 1 00:00:14 beaglebone daemon.info connmand[127]: connmand[127]: eth0
{update} flags 4098 <DOWN>
Jan 1 00:00:14 beaglebone daemon.info connmand[127]: connmand[127]: eth0
{newlink} index 2 address C8:A0:30:B9:8C:EC mtu 1500
Jan 1 00:00:14 beaglebone daemon.info connmand[127]: connmand[127]: eth0
{newlink} index 2 operstate 2 <DOWN>
Jan 1 00:00:14 beaglebone daemon.info connmand[127]: connmand[127]: Adding
interface eth0 [ ethernet ]
Jan 1 00:00:14 beaglebone daemon.info connmand[127]: connmand[127]: usb0
{create} index 3 type 1 <ETHER>
Jan 1 00:00:14 beaglebone daemon.info connmand[127]: connmand[127]: usb0
{update} flags 4098 <DOWN>
Jan 1 00:00:14 beaglebone daemon.info connmand[127]: connmand[127]: usb0
{newlink} index 3 address 1A:4B:68:D0:89:A8 mtu 1500
Jan 1 00:00:14 beaglebone daemon.info connmand[127]: connmand[127]: usb0
{newlink} index 3 operstate 2 <DOWN>
Jan 1 00:00:14 beaglebone daemon.info connmand[127]: connmand[127]: Adding
interface usb0 [ gadget ]
Jan 1 00:00:14 beaglebone daemon.info connmand[127]: connmand[127]: eth0
{update} flags 4163 <UP,RUNNING>
Jan 1 00:00:14 beaglebone daemon.info connmand[127]: connmand[127]: eth0
{newlink} index 2 address C8:A0:30:B9:8C:EC mtu 1500
Jan 1 00:00:14 beaglebone daemon.info connmand[127]: connmand[127]: eth0
{newlink} index 2 operstate 0 <UNKNOWN>
Jan 1 00:00:14 beaglebone daemon.info connmand[127]: connmand[127]: eth0
{update} flags 4099 <UP>
Jan 1 00:00:14 beaglebone daemon.info connmand[127]: connmand[127]: eth0
{newlink} index 2 address C8:A0:30:B9:8C:EC mtu 1500
Jan 1 00:00:14 beaglebone daemon.info connmand[127]: connmand[127]: eth0
{newlink} index 2 operstate 2 <DOWN>
Jan 1 00:00:14 beaglebone daemon.info connmand[127]: connmand[127]: usb0
{add} address 192.168.7.2/24 label usb0 family 2
Jan 1 00:00:14 beaglebone daemon.info connmand[127]: connmand[127]: usb0
{update} flags 4099 <UP>
Jan 1 00:00:14 beaglebone daemon.info connmand[127]: connmand[127]: usb0
{newlink} index 3 address 1A:4B:68:D0:89:A8 mtu 1500
Jan 1 00:00:14 beaglebone daemon.info connmand[127]: connmand[127]: usb0
{newlink} index 3 operstate 2 <DOWN>
Jan 1 00:00:14 beaglebone daemon.info connmand[127]: connmand[127]: usb0
{add} route 192.168.7.0 gw 0.0.0.0 scope 253 <LINK>
Jan 1 00:00:14 beaglebone daemon.info connmand[127]: connmand[127]: usb0
{del} address 192.168.7.2/24 label usb0
Jan 1 00:00:14 beaglebone daemon.info connmand[127]: connmand[127]: usb0
{del} route 192.168.7.0 gw 0.0.0.0 scope 253 <LINK>
Jan 1 00:00:14 beaglebone daemon.info connmand[127]: connmand[127]: usb0
{add} address 192.168.7.2/30 label usb0 family 2
Jan 1 00:00:14 beaglebone daemon.info connmand[127]: connmand[127]: usb0
{add} route 192.168.7.0 gw 0.0.0.0 scope 253 <LINK>
Jan 1 00:00:14 beaglebone daemon.info connmand[127]: connmand[127]: usb0
{add} route 192.168.7.0 gw 0.0.0.0 scope 253 <LINK>
Jan 1 00:00:14 beaglebone daemon.info connmand[127]: connmand[127]: eth0
{add} route fe80:: gw :: scope 0 <UNIVERSE>
Jan 1 00:00:14 beaglebone daemon.info connmand[127]: connmand[127]: eth0
{update} flags 69699 <UP,RUNNING,LOWER_UP>
Jan 1 00:00:14 beaglebone daemon.info connmand[127]: connmand[127]: eth0
{newlink} index 2 address C8:A0:30:B9:8C:EC mtu 1500
Jan 1 00:00:14 beaglebone daemon.info led-config[128]: Configuring leds:
Jan 1 00:00:14 beaglebone daemon.info connmand[127]: connmand[127]: eth0
{newlink} index 2 operstate 6 <UP>
Jan 1 00:00:14 beaglebone daemon.info connmand[127]: connmand[127]: eth0
{del} route fe80:: gw :: scope 0 <UNIVERSE>
Jan 1 00:00:14 beaglebone daemon.info connmand[127]: connmand[127]:
Skipping disconnect of carrier, network is connecting.
Jan 1 00:00:14 beaglebone daemon.info connmand[127]: connmand[127]: eth0
{add} route fe80:: gw :: scope 0 <UNIVERSE>
Jan 1 00:00:14 beaglebone daemon.info g-ether-load.sh[129]: udhcpd
(v1.20.2) started
Jan 1 00:00:14 beaglebone daemon.info mpd[132]: listen: bind to
'0.0.0.0:6600' failed: Address already in use (continuing anyway, because
binding to '[::]:6600' succeeded)
Jan 1 00:00:14 beaglebone daemon.info mpd[132]: output: No "audio_output"
defined in config file
Jan 1 00:00:14 beaglebone daemon.info mpd[132]: output: Attempt to detect
audio output device
Jan 1 00:00:14 beaglebone daemon.info mpd[132]: output: Attempting to
detect a alsa audio device
Jan 1 00:00:14 beaglebone daemon.info mpd[132]: ALSA lib
confmisc.c:768:(parse_card) cannot find card '0'
Jan 1 00:00:14 beaglebone daemon.info mpd[132]: ALSA lib
conf.c:4241:(_snd_config_evaluate) function snd_func_card_driver returned
error: No such file or directory
Jan 1 00:00:14 beaglebone daemon.info mpd[132]: ALSA lib
confmisc.c:392:(snd_func_concat) error evaluating strings
Jan 1 00:00:14 beaglebone daemon.info mpd[132]: ALSA lib
conf.c:4241:(_snd_config_evaluate) function snd_func_concat returned error:
No such file or directory
Jan 1 00:00:14 beaglebone daemon.info mpd[132]: ALSA lib
confmisc.c:1251:(snd_func_refer) error evaluating name
Jan 1 00:00:14 beaglebone daemon.info mpd[132]: ALSA lib
conf.c:4241:(_snd_config_evaluate) function snd_func_refer returned error:
No such file or directory
Jan 1 00:00:14 beaglebone daemon.info mpd[132]: ALSA lib
conf.c:4720:(snd_config_expand) Evaluate error: No such file or directory
Jan 1 00:00:14 beaglebone daemon.info mpd[132]: ALSA lib
pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM default
Jan 1 00:00:14 beaglebone daemon.info mpd[132]: alsa: Error opening
default ALSA device: No such file or directory
Jan 1 00:00:14 beaglebone daemon.info mpd[132]: output: Attempting to
detect a oss audio device
Jan 1 00:00:14 beaglebone daemon.info mpd[132]: oss: Error opening OSS
device "/dev/dsp": Permission denied
Jan 1 00:00:14 beaglebone daemon.info mpd[132]: oss: Error opening OSS
device "/dev/sound/dsp": No such file or directory
Jan 1 00:00:14 beaglebone daemon.info mpd[132]: output: Attempting to
detect a pulse audio device
Jan 1 00:00:14 beaglebone daemon.info mpd[132]: Assertion 'm' failed at
pulse/thread-mainloop.c:232, function pa_threaded_mainloop_get_api().
Aborting.
Jan 1 00:00:14 beaglebone daemon.info dbus-daemon[138]: dbus[138]:
[system] Activating via systemd: service name='fi.w1.wpa_supplicant1'
unit='wpa_supplicant.service'
Jan 1 00:00:14 beaglebone daemon.info dbus-daemon[138]: dbus[138]:
[system] Successfully activated service 'fi.w1.wpa_supplicant1'
Jan 1 00:00:14 beaglebone daemon.info dbus-daemon[138]: dbus[138]:
[system] Activating via systemd: service name='org.freedesktop.ConsoleKit'
unit='console-kit-daemon.service'
Jan 1 00:00:14 beaglebone daemon.info dbus-daemon[138]: dbus[138]:
[system] Activating service name='org.freedesktop.PolicyKit1' (using
servicehelper)
Jan 1 00:00:14 beaglebone daemon.info dbus-daemon[138]: dbus[138]:
[system] Successfully activated service 'org.freedesktop.PolicyKit1'
Jan 1 00:00:14 beaglebone daemon.info dbus-daemon[138]: dbus[138]:
[system] Successfully activated service 'org.freedesktop.ConsoleKit'
Jan 1 00:00:15 beaglebone daemon.info python[134]: [W 000101 00:00:15
gateone:2691] dtach command not found. dtach support has been disabled.
Jan 1 00:00:15 beaglebone daemon.info python[134]: [I 000101 00:00:15
gateone:2714] Connections to this server will be allowed from the following
origins: '*'
Jan 1 00:00:15 beaglebone daemon.info python[134]: [I 000101 00:00:15
gateone:2124] No authentication method configured. All users will be
ANONYMOUS
Jan 1 00:00:15 beaglebone daemon.info python[134]: [I 000101 00:00:15
gateone:2205] Loaded plugins: bookmarks, example, help, logging,
logging_plugin, mobile, notice, playback, ssh
Jan 1 00:00:15 beaglebone daemon.info python[134]: [I 000101 00:00:15
gateone:2829] Listening on https://*:443/
Jan 1 00:00:15 beaglebone daemon.info python[134]: [I 000101 00:00:15
gateone:2835] Process running with pid 134
Jan 1 00:00:19 beaglebone daemon.info dbus-daemon[138]: dbus[138]:
[system] Activating service name='org.freedesktop.UPower' (using
servicehelper)
Jan 1 00:00:19 beaglebone daemon.notice dbus[138]: [system] Activating
service name='org.freedesktop.UPower' (using servicehelper)
Jan 1 00:00:19 beaglebone daemon.info dbus-daemon[138]: dbus[138]:
[system] Successfully activated service 'org.freedesktop.UPower'
Jan 1 00:00:19 beaglebone daemon.notice dbus[138]: [system] Successfully
activated service 'org.freedesktop.UPower'
Jan 1 00:00:21 beaglebone daemon.info node4[135]: ^[[36minfo -^[[39m
socket.io started
Jan 1 00:00:24 beaglebone user.info kernel: [ 25.032189] EXT4-fs
(mmcblk0p2): re-mounted. Opts: commit=0
Jan 1 00:00:24 beaglebone daemon.warn gdm-simple-greeter[441]:
Gtk-WARNING: gtkwidget.c:5709: widget not within a GtkWindow
Jan 1 00:00:25 beaglebone daemon.info node4[135]: . ..__%|iiiiiii=>,..
Jan 1 00:00:25 beaglebone daemon.info node4[135]: _<iIIviiiiiiiiiillli<_.
Jan 1 00:00:25 beaglebone daemon.info node4[135]:
.ivIvilli%||+++++|iillllvs;_
Jan 1 00:00:25 beaglebone daemon.info node4[135]: ..nvlIlv|~`..........
-<*IIIvv=
Jan 1 00:00:25 beaglebone daemon.info node4[135]: .)nvvvvv-.... . .. ...
~nvvvo=.
Jan 1 00:00:25 beaglebone daemon.info node4[135]: .__i<iiiii><vvvvn(= . .
..i>, . ... +)nnnv..
Jan 1 00:00:25 beaglebone daemon.info node4[135]: _i%vvvvllIIlIlIvIvvv(
.. . lnnsi . :)vnvnsissvisi>__.
Jan 1 00:00:25 beaglebone daemon.info node4[135]:
.<vnvvvvvvIvvvvvvvlvvII;. . |nnvv: . . -)lvvlIIIIlvvIvnnns=_.
Jan 1 00:00:25 beaglebone daemon.info node4[135]:
.:vnvvvvvvvvvvvvvIvIvIIvv>: . . . |{}l. . :<lvIvvvvvvvvvvvvvvnov.
Jan 1 00:00:25 beaglebone daemon.info node4[135]:
|)nvnvnvnvnvnvvvvvvvvvvvvis . . . =ivvvvvvvvvvvnvnvnvnvnn..
Jan 1 00:00:25 beaglebone daemon.info node4[135]:
.nnnnnnvnnvnvnvnvvvnvvvvvvvnv_ . . :vnvvvvvvvnvnnvnnnnnnnnov;
Jan 1 00:00:25 beaglebone daemon.info node4[135]:
:2oonnnnnnnnnvnvnnvnvvnvvvvvIvvi==_i.. . .vvvvvvvvnvnnvnnnnnnnnooooc
Jan 1 00:00:25 beaglebone daemon.info node4[135]:
:nnooonnnnnnnnnnvvnvvvvvvvvIvIlIvvnI- .=vvvvvvvvnvnvnnnnnnnnnnooo2(
Jan 1 00:00:25 beaglebone daemon.info node4[135]:
|{XooooonnnnnvnvnvvvvvvvIIIIIIIIv|- .<vIlIIvIvvvvvnvvnvnnnnnooo2v(
Jan 1 00:00:25 beaglebone daemon.info node4[135]:
.){2ooooonnnnvnvnvvvvvIIIIIIlll+- . =)lllIIvIvvvvvvvnvnnnvnnooo22-`
Jan 1 00:00:25 beaglebone daemon.info node4[135]:
-{2oooonnnnnvvvvvvvlIIlllllil==_ ._iIllillllllIvvvvvvnvnnnnoooo*-
Jan 1 00:00:25 beaglebone daemon.info node4[135]: .
-."11oonnvvvnvvIIlIlliliiiiillii||iliiiiiiililllIIvvvvvnnnnn2}(~.
Jan 1 00:00:25 beaglebone daemon.info node4[135]: .
-+~!lvvnvIvIIllliiiii|i|||i||i|||i||iiiiilillIIvvvvvv}|"- .
Jan 1 00:00:25 beaglebone daemon.info node4[135]: .
..--~++++++++~+~+~+~+-+-+~+~+-+~+~++~++++++~~~-:.. .
Jan 1 00:00:25 beaglebone daemon.info node4[135]: . . . . .... . . ....
.. ... .. ... . . . .
Jan 1 00:00:25 beaglebone daemon.info node4[135]: Ajax.org Cloud9 IDE
Jan 1 00:00:25 beaglebone daemon.info node4[135]: version 0.6
Jan 1 00:00:25 beaglebone daemon.info node4[135]: Project root is:
/var/lib/cloud9
Jan 1 00:00:25 beaglebone daemon.info node4[135]: Point your browser to
http://localhost:3000
Jan 1 00:00:25 beaglebone daemon.warn gdm-simple-greeter[441]: WARNING:
Unable to load CK history: no seat-id found
Jan 1 00:00:26 beaglebone authpriv.notice gdm-session-worker[444]:
pam_warn(gdm-autologin:auth): function=[pam_sm_authenticate]
service=[gdm-autologin] terminal=[:0] user=[root] ruser=[<unknown>]
rhost=[<unknown>]
Jan 1 00:00:51 beaglebone daemon.info avahi-daemon[140]: Joining mDNS
multicast group on interface eth0.IPv4 with address 169.254.37.137.
Jan 1 00:00:51 beaglebone daemon.info avahi-daemon[140]: New relevant
interface eth0.IPv4 for mDNS.
Jan 1 00:00:51 beaglebone daemon.info avahi-daemon[140]: Registering new
address record for 169.254.37.137 on eth0.IPv4.
Jan 1 00:00:51 beaglebone daemon.info connmand[127]: connmand[127]: eth0
{add} address 169.254.37.137/16 label eth0 family 2
Jan 1 00:00:51 beaglebone daemon.info connmand[127]: connmand[127]: eth0
{add} route 169.254.0.0 gw 0.0.0.0 scope 253 <LINK>
Jan 1 00:00:51 beaglebone daemon.info connmand[127]: connmand[127]: eth0
{add} route 0.0.0.0 gw 0.0.0.0 scope 253 <LINK>
Jan 1 00:00:51 beaglebone daemon.info connmand[127]: connmand[127]:
Setting default interface route failed (File exists)
Jan 1 00:00:51 beaglebone daemon.info connmand[127]: eth0 {add} address
169.254.37.137/16 label eth0 family 2
Jan 1 00:00:51 beaglebone daemon.info connmand[127]: eth0 {add} route
169.254.0.0 gw 0.0.0.0 scope 253 <LINK>
Jan 1 00:00:51 beaglebone daemon.info connmand[127]: eth0 {add} route
0.0.0.0 gw 0.0.0.0 scope 253 <LINK>
Jan 1 00:00:51 beaglebone daemon.err connmand[127]: Setting default
interface route failed (File exists)
Jan 1 00:01:43 beaglebone user.info kernel: [ 103.970303] CAUTION: musb:
Babble Interrupt Occurred
Jan 1 00:01:44 beaglebone user.info kernel: [ 104.610216] CAUTION: musb:
Babble Interrupt Occurred
Jan 1 00:01:44 beaglebone daemon.info connmand[127]: connmand[127]: usb0
{add} route fe80:: gw :: scope 0 <UNIVERSE>
Jan 1 00:01:44 beaglebone daemon.info connmand[127]: connmand[127]: usb0
{update} flags 69699 <UP,RUNNING,LOWER_UP>
Jan 1 00:01:44 beaglebone daemon.info connmand[127]: connmand[127]: usb0
{newlink} index 3 address 1A:4B:68:D0:89:A8 mtu 1500
Jan 1 00:01:44 beaglebone daemon.info connmand[127]: usb0 {add} route
fe80:: gw :: scope 0 <UNIVERSE>
Jan 1 00:01:44 beaglebone daemon.info connmand[127]: usb0 {update} flags
69699 <UP,RUNNING,LOWER_UP>
Jan 1 00:01:44 beaglebone user.info kernel: [ 104.902846] gadget:
high-speed config #1: Multifunction with RNDIS
Jan 1 00:01:44 beaglebone daemon.info connmand[127]: usb0 {newlink} index
3 address 1A:4B:68:D0:89:A8 mtu 1500
Jan 1 00:01:44 beaglebone daemon.info connmand[127]: usb0 {newlink} index
3 operstate 6 <UP>
Jan 1 00:01:44 beaglebone daemon.info connmand[127]: usb0 {del} route
fe80:: gw :: scope 0 <UNIVERSE>
Jan 1 00:01:44 beaglebone user.info kernel: [ 104.903212] IPv6:
ADDRCONF(NETDEV_CHANGE): usb0: link becomes ready
Jan 1 00:01:44 beaglebone daemon.info connmand[127]: connmand[127]: usb0
{newlink} index 3 operstate 6 <UP>
Jan 1 00:01:44 beaglebone daemon.info connmand[127]: connmand[127]: usb0
{del} route fe80:: gw :: scope 0 <UNIVERSE>
Jan 1 00:01:47 beaglebone daemon.info udhcpd[259]: Sending OFFER of
192.168.7.1
Jan 1 00:01:47 beaglebone daemon.info udhcpd[259]: Sending OFFER of
192.168.7.1
Jan 1 00:01:47 beaglebone daemon.info g-ether-load.sh[129]: Sending OFFER
of 192.168.7.1
Jan 1 00:01:47 beaglebone daemon.info g-ether-load.sh[129]: Sending OFFER
of 192.168.7.1
Jan 1 00:01:48 beaglebone daemon.info udhcpd[259]: Sending ACK to
192.168.7.1
Jan 1 00:01:48 beaglebone daemon.info g-ether-load.sh[129]: Sending ACK to
192.168.7.1
Jan 1 00:01:57 beaglebone daemon.info systemd[1]: Started SSH Key
Generation.
Jan 1 00:01:57 beaglebone daemon.info systemd[1]: Starting SSH
Per-Connection Server...
Jan 1 00:01:57 beaglebone daemon.info systemd[1]: Started SSH
Per-Connection Server.
Jan 1 00:01:57 beaglebone authpriv.warn dropbear[510]: Failed reading
'/etc/dropbear/dropbear_dss_host_key', disabling DSS
Jan 1 00:01:57 beaglebone authpriv.info dropbear[510]: Child connection
from 192.168.7.1:62265
Jan 1 00:02:05 beaglebone authpriv.notice dropbear[510]: PAM password auth
succeeded for 'root' from 192.168.7.1:62265
Jan 1 00:02:05 beaglebone authpriv.warn dropbear[511]:
lastlog_perform_login: Couldn't stat /var/log/lastlog: No such file or
directory
Jan 1 00:02:05 beaglebone authpriv.warn dropbear[511]: lastlog_openseek:
/var/log/lastlog is not a file or directory!
Jan 1 00:03:21 beaglebone daemon.info systemd[1]: Starting Bonescript
server...
Jan 1 00:03:21 beaglebone daemon.info systemd[1]: Started Bonescript
server.
Jan 1 00:03:24 beaglebone daemon.info bonescript[514]: ^[[36minfo -^[[39m
socket.io started
Jan 1 00:03:25 beaglebone daemon.info bonescript[514]: - - - [Sat, 01 Jan
2000 00:03:25 GMT] "GET /static/images/green_check.png HTTP/1.1" 304 -
"http://192.168.7.2/Support/bone101/" "Mozilla/5.0 (Macintosh; Intel Mac OS
X 10_9_0) AppleWebKit/537.36 (KHTML, like Gecko) Chr



Logged in via usb0, then did "ifup eth0".
Works fine:


Jan 1 00:08:51 beaglebone daemon.info connmand[127]: connmand[127]: eth0
{del} address 169.254.37.137/16 label eth0
Jan 1 00:08:51 beaglebone daemon.info connmand[127]: eth0 {del} address
169.254.37.137/16 label eth0
Jan 1 00:08:51 beaglebone daemon.info avahi-daemon[140]: Withdrawing
address record for 169.254.37.137 on eth0.
Jan 1 00:08:51 beaglebone daemon.info avahi-daemon[140]: Leaving mDNS
multicast group on interface eth0.IPv4 with address 169.254.37.137.
Jan 1 00:08:51 beaglebone daemon.info connmand[127]: eth0 {del} route
169.254.0.0 gw 0.0.0.0 scope 253 <LINK>
Jan 1 00:08:51 beaglebone daemon.info connmand[127]: eth0 {del} route
fe80:: gw :: scope 0 <UNIVERSE>
Jan 1 00:08:51 beaglebone daemon.info avahi-daemon[140]: Interface
eth0.IPv4 no longer relevant for mDNS.
Jan 1 00:08:51 beaglebone daemon.info avahi-daemon[140]: Withdrawing
address record for fe80::caa0:30ff:feb9:8cec on eth0.
Jan 1 00:08:51 beaglebone daemon.info connmand[127]: connmand[127]: eth0
{del} route 169.254.0.0 gw 0.0.0.0 scope 253 <LINK>
Jan 1 00:08:51 beaglebone daemon.info connmand[127]: connmand[127]: eth0
{del} route fe80:: gw :: scope 0 <UNIVERSE>
Jan 1 00:08:51 beaglebone daemon.info connmand[127]: connmand[127]: eth0
{add} address 10.64.5.226/24 label eth0 family 2
Jan 1 00:08:51 beaglebone daemon.info connmand[127]: eth0 {add} address
10.64.5.226/24 label eth0 family 2
Jan 1 00:08:51 beaglebone daemon.info avahi-daemon[140]: Joining mDNS
multicast group on interface eth0.IPv4 with address 10.64.5.226.
Jan 1 00:08:51 beaglebone daemon.info connmand[127]: eth0 {add} route
10.64.5.0 gw 0.0.0.0 scope 253 <LINK>
Jan 1 00:08:51 beaglebone daemon.info avahi-daemon[140]: New relevant
interface eth0.IPv4 for mDNS.
Jan 1 00:08:51 beaglebone daemon.info avahi-daemon[140]: Registering new
address record for 10.64.5.226 on eth0.IPv4.
Jan 1 00:08:51 beaglebone daemon.info connmand[127]: connmand[127]: eth0
{add} route 10.64.5.0 gw 0.0.0.0 scope 253 <LINK>
Jan 1 00:08:51 beaglebone daemon.info connmand[127]: connmand[127]: eth0
{add} route 0.0.0.0 gw 10.64.5.254 scope 0 <UNIVERSE>
Jan 1 00:08:51 beaglebone daemon.info connmand[127]: eth0 {add} route
0.0.0.0 gw 10.64.5.254 scope 0 <UNIVERSE>




--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[Thomas Laskowski]

My other board is still working. Running Debian Wheezy. I also sent a
board for RMA and they said there was a short on the Ethernet chip. They
fixed it and are sending it back.

-Tom

On Thursday, 25 July 2013 12:04:48 UTC-4, eskimobob wrote:
>
> Just had an email to say that the Beagle Hospital has now received my RMA
> board and are going to run it through some tests.
> I'm hoping they find a software issue that can be fixed because I have two
> more BBBs here that exhibit the same problem.
>
> On Tuesday, 16 July 2013 23:29:55 UTC+1, Gerald wrote:
>>
>> We will be watching for the Eskimbob board!
>>
>>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[Charles Steinkuehler]

X-Received: by 10.49.34.133 with SMTP id z5mr204425qei.39.1374017591811;
Tue, 16 Jul 2013 16:33:11 -0700 (PDT)
X-BeenThere: beagleboard-/***@public.gmane.org
Received: by 10.49.17.201 with SMTP id q9ls572914qed.48.gmail; Tue, 16 Jul
2013 16:33:10 -0700 (PDT)
X-Received: by 10.58.46.199 with SMTP id x7mr759629vem.30.1374017590872;
Tue, 16 Jul 2013 16:33:10 -0700 (PDT)
Received: from dukecmmtar03.coxmail.com (dukecmmtar03.coxmail.com. [68.99.120.44])
by gmr-mx.google.com with ESMTP id m7si499930qcv.2.2013.07.16.16.33.10
for <beagleboard-/***@public.gmane.org>;
Tue, 16 Jul 2013 16:33:10 -0700 (PDT)
Received-SPF: neutral (google.com: 68.99.120.44 is neither permitted nor denied by best guess record for domain of charles-***@public.gmane.org) client-ip=68.99.120.44;
Received: from dukecmimpo02.coxmail.com ([68.99.120.135])
by dukecmmtar03.coxmail.com
(InterMail vM.8.01.05.06 201-2260-151-112-20120208) with ESMTP
id <20130716233310.GBCG13174.dukecmmtar03.coxmail.com-***@public.gmane.org>
for <beagleboard-/***@public.gmane.org>;
Tue, 16 Jul 2013 19:33:10 -0400
Received: from mail.steinkuehler.net ([70.184.225.181])
by dukecmimpo02.coxmail.com with bizsmtp
id 1BZA1m0033vTAEW01BZAWN; Tue, 16 Jul 2013 19:33:10 -0400
Received: (qmail 31669 invoked from network); 16 Jul 2013 18:33:09 -0500
Received: from 222.ks.newtek.dhcp (HELO ?10.34.1.222?) (charles-***@public.gmane.org)
by mail.steinkuehler.net with SMTP; 16 Jul 2013 18:33:09 -0500
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
In-Reply-To: <51E5C4F3.40501-***@public.gmane.org>
X-Enigmail-Version: 1.5.1
X-Original-Sender: charles-***@public.gmane.org
X-Original-Authentication-Results: gmr-mx.google.com; spf=neutral
(google.com: 68.99.120.44 is neither permitted nor denied by best guess
record for domain of charles-***@public.gmane.org) smtp.mail=charles-***@public.gmane.org
Precedence: list
Mailing-list: list beagleboard-/***@public.gmane.org; contact beagleboard+owners-/***@public.gmane.org
List-ID: <beagleboard.googlegroups.com>
X-Google-Group-Id: 1035534660134
List-Post: <http://groups.google.com/group/beagleboard/post>, <mailto:beagleboard-/***@public.gmane.org>
List-Help: <http://groups.google.com/support/>, <mailto:beagleboard+help-/***@public.gmane.org>
List-Archive: <http://groups.google.com/group/beagleboard>
Sender: beagleboard-/***@public.gmane.org
List-Subscribe: <http://groups.google.com/group/beagleboard/subscribe>, <mailto:beagleboard+subscribe-/***@public.gmane.org>
List-Unsubscribe: <http://groups.google.com/group/beagleboard/subscribe>, <mailto:googlegroups-manage+1035534660134+unsubscribe-/***@public.gmane.org>
Archived-At: <http://permalink.gmane.org/gmane.comp.hardware.beagleboard.user/50123>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm seeing identical results in the official Angstrom release and my
hacked MachineKit Debian based images. Some problem specifics.

With both images, if I ping the gateway and remove then re-insert the
Ethernet cable, everything behaves as expected. Packets get dropped
while the cable is unplugged, and the phy comes back up properly when
the Ethernet cable is reconnected.

The problems come when trying to bring an interface down and back up
again. In Angstrom (I tested the 6/20 release):

* Click on the "funny icon to the left of the date"
* Select "Properties"
* Click on "Wired Networks"
* Click the "Disable" button
* Wait a moment
* Click on the "Enable" button

In Debian just:

ifdown eth0
ifup eth0

After this sequence of events (bring the interface down and back up),
with *BOTH* distributions I see exactly the same behavior. I'm
getting DHCP packets at the DHCP server, replies are going out to the
'Bone, but they are not getting received. Ditto for various other
traffic (ie: ARP requests/replies).

I have played a bit with both distributions trying to get the broken
networking up from the command line. I am no newbie at this...I've
been using various network configuration commands at a _very_ low
level since the late 1990's with the Linux Router Project. I have so
far not been able to get any farther than the automated tools, with Tx
working and Rx dead. Tx counters in /proc/net/dev are incrementing,
but the Rx counters are stuck. I suspect unloading the Ethernet
driver and reloading it might fix the issue, but it's not compiled as
a loadable module. :-/

So this pretty much exactly matches the failure described in earlier
e-mails, the behavior is exactly the same between two completely
different OS installs and two different kernels (although they share
the same BeagleBone specific patch set).

Smells like a software driver bug to me...

Gerald: Can you test disabling and enabling the driver via the GUI on
a default install? I'd _really_ like to know if you see the same
problem or if it works for you.

- --
Charles Steinkuehler
charles-***@public.gmane.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlHl2DIACgkQLywbqEHdNFyLlgCgjT1+3hSvY0joC0RoDTgvGa3u
lYkAoPr8WpIgbv97KLMAt6NRL9uCHpTo
=6wqY
-----END PGP SIGNATURE-----

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[Charles Steinkuehler]

X-Received: by 10.49.58.170 with SMTP id s10mr209441qeq.28.1374017729995;
Tue, 16 Jul 2013 16:35:29 -0700 (PDT)
X-BeenThere: beagleboard-/***@public.gmane.org
Received: by 10.49.39.201 with SMTP id r9ls618646qek.72.gmail; Tue, 16 Jul
2013 16:35:29 -0700 (PDT)
X-Received: by 10.52.23.210 with SMTP id o18mr736663vdf.1.1374017729123;
Tue, 16 Jul 2013 16:35:29 -0700 (PDT)
Received: from dukecmmtar04.coxmail.com (dukecmmtar04.coxmail.com. [68.99.120.47])
by gmr-mx.google.com with ESMTP id r1si498296qch.3.2013.07.16.16.35.29
for <beagleboard-/***@public.gmane.org>;
Tue, 16 Jul 2013 16:35:29 -0700 (PDT)
Received-SPF: neutral (google.com: 68.99.120.47 is neither permitted nor denied by best guess record for domain of charles-***@public.gmane.org) client-ip=68.99.120.47;
Received: from dukecmimpo02.coxmail.com ([68.99.120.135])
by dukecmmtar04.coxmail.com
(InterMail vM.8.01.05.06 201-2260-151-112-20120208) with ESMTP
id <20130716233528.QIME932.dukecmmtar04.coxmail.com-***@public.gmane.org>
for <beagleboard-/***@public.gmane.org>;
Tue, 16 Jul 2013 19:35:28 -0400
Received: from mail.steinkuehler.net ([70.184.225.181])
by dukecmimpo02.coxmail.com with bizsmtp
id 1BbU1m00C3vTAEW01BbUl2; Tue, 16 Jul 2013 19:35:28 -0400
Received: (qmail 31764 invoked from network); 16 Jul 2013 18:35:28 -0500
Received: from 222.ks.newtek.dhcp (HELO ?10.34.1.222?) (charles-***@public.gmane.org)
by mail.steinkuehler.net with SMTP; 16 Jul 2013 18:35:28 -0500
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
In-Reply-To: <51E5D832.4070608-***@public.gmane.org>
X-Enigmail-Version: 1.5.1
X-Original-Sender: charles-***@public.gmane.org
X-Original-Authentication-Results: gmr-mx.google.com; spf=neutral
(google.com: 68.99.120.47 is neither permitted nor denied by best guess
record for domain of charles-***@public.gmane.org) smtp.mail=charles-***@public.gmane.org
Precedence: list
Mailing-list: list beagleboard-/***@public.gmane.org; contact beagleboard+owners-/***@public.gmane.org
List-ID: <beagleboard.googlegroups.com>
X-Google-Group-Id: 1035534660134
List-Post: <http://groups.google.com/group/beagleboard/post>, <mailto:beagleboard-/***@public.gmane.org>
List-Help: <http://groups.google.com/support/>, <mailto:beagleboard+help-/***@public.gmane.org>
List-Archive: <http://groups.google.com/group/beagleboard>
Sender: beagleboard-/***@public.gmane.org
List-Subscribe: <http://groups.google.com/group/beagleboard/subscribe>, <mailto:beagleboard+subscribe-/***@public.gmane.org>
List-Unsubscribe: <http://groups.google.com/group/beagleboard/subscribe>, <mailto:googlegroups-manage+1035534660134+unsubscribe-/***@public.gmane.org>
Archived-At: <http://permalink.gmane.org/gmane.comp.hardware.beagleboard.user/50125>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 7/16/2013 6:33 PM, Charles Steinkuehler wrote:
> I'm seeing identical results in the official Angstrom release and
> my hacked MachineKit Debian based images. Some problem specifics.
>
> With both images, if I ping the gateway and remove then re-insert
> the Ethernet cable, everything behaves as expected. Packets get
> dropped while the cable is unplugged, and the phy comes back up
> properly when the Ethernet cable is reconnected.
>
> The problems come when trying to bring an interface down and back
> up again. In Angstrom (I tested the 6/20 release):
>
> * Click on the "funny icon to the left of the date" * Select
> "Properties"

Oops..."Properties" above should be "Preferences"

> * Click on "Wired Networks" * Click the "Disable" button * Wait a
> moment * Click on the "Enable" button

- --
Charles Steinkuehler
charles-***@public.gmane.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlHl2LwACgkQLywbqEHdNFxksgCeI9+YD3CpQVouvbHUL0hUL3lr
OooAn3Y6lHsV0PwRGApk7YE6vB2/BDdQ
=j2e9
-----END PGP SIGNATURE-----

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[Thomas Laskowski]

I get the same result when using ifconfig eth0 down/up on a stock image.
But unplugging then plugging back in, or plugging in a cable after a boot
works fine.

-Tom

On Tuesday, 16 July 2013 19:33:06 UTC-4, Charles Steinkuehler wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I'm seeing identical results in the official Angstrom release and my
> hacked MachineKit Debian based images. Some problem specifics.
>
> With both images, if I ping the gateway and remove then re-insert the
> Ethernet cable, everything behaves as expected. Packets get dropped
> while the cable is unplugged, and the phy comes back up properly when
> the Ethernet cable is reconnected.
>
> The problems come when trying to bring an interface down and back up
> again. In Angstrom (I tested the 6/20 release):
>
> * Click on the "funny icon to the left of the date"
> * Select "Properties"
> * Click on "Wired Networks"
> * Click the "Disable" button
> * Wait a moment
> * Click on the "Enable" button
>
> In Debian just:
>
> ifdown eth0
> ifup eth0
>
> After this sequence of events (bring the interface down and back up),
> with *BOTH* distributions I see exactly the same behavior. I'm
> getting DHCP packets at the DHCP server, replies are going out to the
> 'Bone, but they are not getting received. Ditto for various other
> traffic (ie: ARP requests/replies).
>
> I have played a bit with both distributions trying to get the broken
> networking up from the command line. I am no newbie at this...I've
> been using various network configuration commands at a _very_ low
> level since the late 1990's with the Linux Router Project. I have so
> far not been able to get any farther than the automated tools, with Tx
> working and Rx dead. Tx counters in /proc/net/dev are incrementing,
> but the Rx counters are stuck. I suspect unloading the Ethernet
> driver and reloading it might fix the issue, but it's not compiled as
> a loadable module. :-/
>
> So this pretty much exactly matches the failure described in earlier
> e-mails, the behavior is exactly the same between two completely
> different OS installs and two different kernels (although they share
> the same BeagleBone specific patch set).
>
> Smells like a software driver bug to me...
>
> Gerald: Can you test disabling and enabling the driver via the GUI on
> a default install? I'd _really_ like to know if you see the same
> problem or if it works for you.
>
> - --
> Charles Steinkuehler
> cha...-***@public.gmane.org <javascript:>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlHl2DIACgkQLywbqEHdNFyLlgCgjT1+3hSvY0joC0RoDTgvGa3u
> lYkAoPr8WpIgbv97KLMAt6NRL9uCHpTo
> =6wqY
> -----END PGP SIGNATURE-----
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[eskimobob]

My RMA authorisation came through this morning - it seems my request went
into spam and has just been found fortunately.
I'm shipping one of my three boards to Texas for investigation - not sure
how long it will take from the UK.
Fingers crossed they find something useful to all of us with the problem.

On Tuesday, 9 July 2013 15:58:23 UTC+1, Gerald wrote:
>
> Wait to hear back from the RMA folks before you ship the board.
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[Kathryn Adeney]

Gerald, a few posts back you mentioned that you were using a test Angstrom
image from 7_4. Do you know the kernel version in there?

Thanks,
Kathryn.

On Monday, June 10, 2013 11:23:32 AM UTC-4, necron...-***@public.gmane.org wrote:
>
> I'm having a strange problem with my new BeagleBone black: I can transmit
> packets from the Ethernet port but not receive them.
>
> When using DHCP, I can see (via a sniffer) the DHCP DISCOVER packet sent
> from the 'bone (via a network sniffer). I can see my DHCP server (dnsmasq
> 2.59 on stock Ubuntu 12.04 LTS 64-bit server) send a DHCP OFFER. But the
> 'bone acts like it never hears the offer; it just sends out more DISCOVERs
> at intervals. (The same DHCP server is working fine for dozens of clients
> from various vendors. There are plenty of leases left in the pool.)
>
> If I set a static address and try to ping something, I see the 'bone send
> an ARP who-has, I see the target reply with an ARP is-at, but the 'bone
> just keeps ARP-ing, and never gets an entry in its ARP table.
>
> In the ifconfig output, the eth0 interface shows 0 packets received and 0
> errors. (The number transmitted is non-0.) Nothing suspicious in the dmesg
> output that I can see.
>
> I've repeated the tests with both the latest Angstrom and with Ubuntu
> booted off an SD card. Same results. I've tried two different cables, and
> two different ports on two different Ethernet switches from different
> vendors. (All ports and cables verified to work fine with my laptop.)
>
> One interesting observation: the port seems to always end up on 10Mbps,
> even when plugged into 100Mbps- (or gigabit-) capable ports. So, it looks
> like autonegotiation isn't working either.
>
> I'm running on a 2A 5.00V regulated bench supply, and the DC looks clean
> on the o-scope.
>
> Other 'bone functions (USB host, USB target, HDMI, LEDs) all seem to work
> fine.
>
> I'm starting to suspect a hardware problem (busted PHY or magnetics;
> incomplete or bridged trace).
>
> Any suggestions for stuff I should try before I RMA the poor little guy?
> (I'm an experienced Linux user and reasonably competent electronics
> hobbyist, if that matters.)
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[Gerald Coley]

I believe all of them are based on the 3.8.13 kernel.

Gerald



On Tue, Jul 16, 2013 at 7:53 PM, Kathryn Adeney
<kathryn.adeney65-***@public.gmane.org>wrote:

> Gerald, a few posts back you mentioned that you were using a test Angstrom
> image from 7_4. Do you know the kernel version in there?
>
> Thanks,
> Kathryn.
>
>
> On Monday, June 10, 2013 11:23:32 AM UTC-4, necron...-***@public.gmane.org wrote:
>>
>> I'm having a strange problem with my new BeagleBone black: I can transmit
>> packets from the Ethernet port but not receive them.
>>
>> When using DHCP, I can see (via a sniffer) the DHCP DISCOVER packet sent
>> from the 'bone (via a network sniffer). I can see my DHCP server (dnsmasq
>> 2.59 on stock Ubuntu 12.04 LTS 64-bit server) send a DHCP OFFER. But the
>> 'bone acts like it never hears the offer; it just sends out more DISCOVERs
>> at intervals. (The same DHCP server is working fine for dozens of clients
>> from various vendors. There are plenty of leases left in the pool.)
>>
>> If I set a static address and try to ping something, I see the 'bone send
>> an ARP who-has, I see the target reply with an ARP is-at, but the 'bone
>> just keeps ARP-ing, and never gets an entry in its ARP table.
>>
>> In the ifconfig output, the eth0 interface shows 0 packets received and 0
>> errors. (The number transmitted is non-0.) Nothing suspicious in the dmesg
>> output that I can see.
>>
>> I've repeated the tests with both the latest Angstrom and with Ubuntu
>> booted off an SD card. Same results. I've tried two different cables, and
>> two different ports on two different Ethernet switches from different
>> vendors. (All ports and cables verified to work fine with my laptop.)
>>
>> One interesting observation: the port seems to always end up on 10Mbps,
>> even when plugged into 100Mbps- (or gigabit-) capable ports. So, it looks
>> like autonegotiation isn't working either.
>>
>> I'm running on a 2A 5.00V regulated bench supply, and the DC looks clean
>> on the o-scope.
>>
>> Other 'bone functions (USB host, USB target, HDMI, LEDs) all seem to work
>> fine.
>>
>> I'm starting to suspect a hardware problem (busted PHY or magnetics;
>> incomplete or bridged trace).
>>
>> Any suggestions for stuff I should try before I RMA the poor little guy?
>> (I'm an experienced Linux user and reasonably competent electronics
>> hobbyist, if that matters.)
>>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[Thomas Laskowski]

Hi,

I'm trying to flash the Angstrom image onto the internal flash when booted
from a micro SD. I am getting an error:

No space left on device

I'm using the Cloud9-IDE-GNOME xz image. It should fit!

What am I doing wrong?

Thanks,

-Tom

On Monday, 10 June 2013 11:23:32 UTC-4, necron...-***@public.gmane.org wrote:
>
> I'm having a strange problem with my new BeagleBone black: I can transmit
> packets from the Ethernet port but not receive them.
>
> When using DHCP, I can see (via a sniffer) the DHCP DISCOVER packet sent
> from the 'bone (via a network sniffer). I can see my DHCP server (dnsmasq
> 2.59 on stock Ubuntu 12.04 LTS 64-bit server) send a DHCP OFFER. But the
> 'bone acts like it never hears the offer; it just sends out more DISCOVERs
> at intervals. (The same DHCP server is working fine for dozens of clients
> from various vendors. There are plenty of leases left in the pool.)
>
> If I set a static address and try to ping something, I see the 'bone send
> an ARP who-has, I see the target reply with an ARP is-at, but the 'bone
> just keeps ARP-ing, and never gets an entry in its ARP table.
>
> In the ifconfig output, the eth0 interface shows 0 packets received and 0
> errors. (The number transmitted is non-0.) Nothing suspicious in the dmesg
> output that I can see.
>
> I've repeated the tests with both the latest Angstrom and with Ubuntu
> booted off an SD card. Same results. I've tried two different cables, and
> two different ports on two different Ethernet switches from different
> vendors. (All ports and cables verified to work fine with my laptop.)
>
> One interesting observation: the port seems to always end up on 10Mbps,
> even when plugged into 100Mbps- (or gigabit-) capable ports. So, it looks
> like autonegotiation isn't working either.
>
> I'm running on a 2A 5.00V regulated bench supply, and the DC looks clean
> on the o-scope.
>
> Other 'bone functions (USB host, USB target, HDMI, LEDs) all seem to work
> fine.
>
> I'm starting to suspect a hardware problem (busted PHY or magnetics;
> incomplete or bridged trace).
>
> Any suggestions for stuff I should try before I RMA the poor little guy?
> (I'm an experienced Linux user and reasonably competent electronics
> hobbyist, if that matters.)
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[Thomas Laskowski]

Sorry, wrong forum. I still start a new topic.

On Wednesday, 17 July 2013 08:49:04 UTC-4, Thomas Laskowski wrote:
>
> Hi,
>
> I'm trying to flash the Angstrom image onto the internal flash when booted
> from a micro SD. I am getting an error:
>
> No space left on device
>
> I'm using the Cloud9-IDE-GNOME xz image. It should fit!
>
> What am I doing wrong?
>
> Thanks,
>
> -Tom
>
> On Monday, 10 June 2013 11:23:32 UTC-4, necron...-***@public.gmane.org wrote:
>>
>> I'm having a strange problem with my new BeagleBone black: I can transmit
>> packets from the Ethernet port but not receive them.
>>
>> When using DHCP, I can see (via a sniffer) the DHCP DISCOVER packet sent
>> from the 'bone (via a network sniffer). I can see my DHCP server (dnsmasq
>> 2.59 on stock Ubuntu 12.04 LTS 64-bit server) send a DHCP OFFER. But the
>> 'bone acts like it never hears the offer; it just sends out more DISCOVERs
>> at intervals. (The same DHCP server is working fine for dozens of clients
>> from various vendors. There are plenty of leases left in the pool.)
>>
>> If I set a static address and try to ping something, I see the 'bone send
>> an ARP who-has, I see the target reply with an ARP is-at, but the 'bone
>> just keeps ARP-ing, and never gets an entry in its ARP table.
>>
>> In the ifconfig output, the eth0 interface shows 0 packets received and 0
>> errors. (The number transmitted is non-0.) Nothing suspicious in the dmesg
>> output that I can see.
>>
>> I've repeated the tests with both the latest Angstrom and with Ubuntu
>> booted off an SD card. Same results. I've tried two different cables, and
>> two different ports on two different Ethernet switches from different
>> vendors. (All ports and cables verified to work fine with my laptop.)
>>
>> One interesting observation: the port seems to always end up on 10Mbps,
>> even when plugged into 100Mbps- (or gigabit-) capable ports. So, it looks
>> like autonegotiation isn't working either.
>>
>> I'm running on a 2A 5.00V regulated bench supply, and the DC looks clean
>> on the o-scope.
>>
>> Other 'bone functions (USB host, USB target, HDMI, LEDs) all seem to work
>> fine.
>>
>> I'm starting to suspect a hardware problem (busted PHY or magnetics;
>> incomplete or bridged trace).
>>
>> Any suggestions for stuff I should try before I RMA the poor little guy?
>> (I'm an experienced Linux user and reasonably competent electronics
>> hobbyist, if that matters.)
>>
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[l***@public.gmane.org]

On Sunday, July 7, 2013 1:00:28 PM UTC-6, eskimobob wrote:
>
> I too have seen the problem both with Angstrom and Ubuntu (13.04).
> RobertCNelson suggests: "I believe it's a problem in the cpsw ethernet
> driver." (see above). Presumably both Angstrom and Ubuntu pull in the same
> low level driver.
>
> It is not clear (to me at least) whether that means it is a problem which
> the community can/should fix or whether it is something that TI need to be
> made aware of so that they can fix it.
> Can anyone clarify?
>

CPSW refers to the ethernet subsystem in the SoC, which includes a
VLAN-aware 3-port switch, two MACs, a timestamping engine for IEEE 1588,
and a DMA-based host interface along with various glue. It's all
documented in the TRM, so theoretically anyone could fix it, but it's a
little less straightforward than your typical ethernet interface. Really
nifty hardware though, if you can get it working right.

I've written and debugged a full driver suite for CPSW in the context of
another TI SoC and another OS, so I could probably track this problem down
if I can get some time to familiarize myself with the Linux drivers. It's
pretty easy to get it into a state like this where the host port DMA engine
is wedged in one direction, as there's a little ownership handshaking dance
you have to do with the DMA descriptors and the documentation on it is a
little vague in some cases, and it will kill the engine if you get things
in an inconsistent state. Luckily it stores the reason for wedging when
this happens, so it *might* be relatively easy to diagnose. There are also
various opportunities for wedging things in other places, though, so we'll
have to see what's really happening.

Anyway, I'll try to check it out in the next couple of days and I'll report
if I make any progress.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[m***@public.gmane.org]

Hi Robert,

how can i check if this patch is implemented in my image?
(Ubuntu)

thx
Attila

On Friday, January 3, 2014 5:37:19 PM UTC+1, RobertCNelson wrote:
>
> On Thu, Jan 2, 2014 at 10:08 PM, Eugene <e_b...-yrJ9Dsz9FWCaMJb+***@public.gmane.org<javascript:>>
> wrote:
> > I ran into the same problems. I hacked up a patch to 3.8.8 from this
> patch:
> > http://permalink.gmane.org/gmane.linux.network/267097
> > and the ifdown/ifup issue went away for me.
>
> Nice find! This fixes my debian netinstall, gonna push it to the
> default beagleboard.org kernel..
>
> >
> > Here is my git diff for those who want to give it a try:
> > diff --git a/drivers/net/ethernet/ti/cpsw.c
> b/drivers/net/ethernet/ti/cpsw.c
> > index 21ba53e..67c7f74 100644
> > --- a/drivers/net/ethernet/ti/cpsw.c
> > +++ b/drivers/net/ethernet/ti/cpsw.c
> > @@ -342,6 +342,7 @@ struct cpsw_priv {
> > /* snapshot of IRQ numbers */
> > u32 irqs_table[4];
> > u32 num_irqs;
> > + bool irq_enabled;
> > struct cpts cpts;
> > };
> >
> > @@ -458,7 +459,10 @@ static irqreturn_t cpsw_interrupt(int irq, void
> > *dev_id)
> >
> > if (likely(netif_running(priv->ndev))) {
> > cpsw_intr_disable(priv);
> > - cpsw_disable_irq(priv);
> > + if (priv->irq_enabled == true) {
> > + cpsw_disable_irq(priv);
> > + priv->irq_enabled = false;
> > + }
> > napi_schedule(&priv->napi);
> > }
> >
> > @@ -512,7 +516,11 @@ static int cpsw_poll(struct napi_struct *napi, int
> > budget)
> > if ((num_total_rx + num_total_tx) < budget) {
> > napi_complete(napi);
> > cpsw_intr_enable(priv);
> > - cpsw_enable_irq(priv);
> > + if (priv->irq_enabled == false) {
> > + cpsw_enable_irq(priv);
> > + priv->irq_enabled = true;
> > + }
> > +
> > }
> >
> > return num_total_rx + num_total_rx;
> > @@ -812,7 +820,10 @@ static int cpsw_ndo_stop(struct net_device *ndev)
> > struct cpsw_priv *priv = netdev_priv(ndev);
> >
> > cpsw_info(priv, ifdown, "shutting down cpsw device\n");
> > - cpsw_disable_irq(priv);
> > + if (priv->irq_enabled == true) {
> > + cpsw_disable_irq(priv);
> > + priv->irq_enabled = false;
> > + }
> > netif_stop_queue(priv->ndev);
> > if (!priv->data.disable_napi)
> > napi_disable(&priv->napi);
> > @@ -1307,6 +1318,8 @@ static int cpsw_probe(struct platform_device
> *pdev)
> > priv->msg_enable = netif_msg_init(debug_level, CPSW_DEBUG);
> > priv->rx_packet_max = max(rx_packet_max, 128);
> >
> > + priv->irq_enabled = false;
> > +
> > /*
> > * This may be required here for child devices.
> > */
> >
> > --
> > For more options, visit http://beagleboard.org/discuss
> > ---
> > You received this message because you are subscribed to the Google
> Groups
> > "BeagleBoard" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an
> > email to beagleboard...-/***@public.gmane.org <javascript:>.
> > For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
> --
> Robert Nelson
> http://www.rcn-ee.com/
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[Robert Nelson]

On Fri, Jan 31, 2014 at 3:27 AM, <moonsurveyor-***@public.gmane.org> wrote:
> Hi Robert,
>
> how can i check if this patch is implemented in my image?
> (Ubuntu)


3.8.13-bone35+ has the fix.

Regards,

--
Robert Nelson
http://www.rcn-ee.com/

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[Moon Walker]

Thank you Robert,

i am going to try to update my xenomai-patched kernel then at weekend.

Attila

On Friday, January 31, 2014 3:11:50 PM UTC+1, RobertCNelson wrote:
>
> On Fri, Jan 31, 2014 at 3:27 AM, <moonsu...-***@public.gmane.org <javascript:>>
> wrote:
> > Hi Robert,
> >
> > how can i check if this patch is implemented in my image?
> > (Ubuntu)
>
>
> 3.8.13-bone35+ has the fix.
>
> Regards,
>
> --
> Robert Nelson
> http://www.rcn-ee.com/
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[k***@public.gmane.org]

Hello Robert ,

I used pre-built boot-loader (MLO and u-boot.img) provided with
the
board, then I am facing this issue -

1) I checked in three computer , in two it is working
correctly and
shell promt is coming also.
(i checked ls, cd ,uname command)
But in one computer in last at the time beaglebone login it
hangs
and message comes like:
root:clean fsck:123file 123/3334 block
Will you please guide
Thanks:
ANKIT

On Friday, 31 January 2014 19:41:50 UTC+5:30, RobertCNelson wrote:
>
> On Fri, Jan 31, 2014 at 3:27 AM, <moonsu...-***@public.gmane.org <javascript:>>
> wrote:
> > Hi Robert,
> >
> > how can i check if this patch is implemented in my image?
> > (Ubuntu)
>
>
> 3.8.13-bone35+ has the fix.
>
> Regards,
>
> --
> Robert Nelson
> http://www.rcn-ee.com/
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[m***@public.gmane.org]

Hi Gerald,

how can i check if i have this patch?

Thx
Attila

On Friday, January 3, 2014 5:37:19 PM UTC+1, RobertCNelson wrote:
>
> On Thu, Jan 2, 2014 at 10:08 PM, Eugene <e_b...-yrJ9Dsz9FWCaMJb+***@public.gmane.org<javascript:>>
> wrote:
> > I ran into the same problems. I hacked up a patch to 3.8.8 from this
> patch:
> > http://permalink.gmane.org/gmane.linux.network/267097
> > and the ifdown/ifup issue went away for me.
>
> Nice find! This fixes my debian netinstall, gonna push it to the
> default beagleboard.org kernel..
>
> >
> > Here is my git diff for those who want to give it a try:
> > diff --git a/drivers/net/ethernet/ti/cpsw.c
> b/drivers/net/ethernet/ti/cpsw.c
> > index 21ba53e..67c7f74 100644
> > --- a/drivers/net/ethernet/ti/cpsw.c
> > +++ b/drivers/net/ethernet/ti/cpsw.c
> > @@ -342,6 +342,7 @@ struct cpsw_priv {
> > /* snapshot of IRQ numbers */
> > u32 irqs_table[4];
> > u32 num_irqs;
> > + bool irq_enabled;
> > struct cpts cpts;
> > };
> >
> > @@ -458,7 +459,10 @@ static irqreturn_t cpsw_interrupt(int irq, void
> > *dev_id)
> >
> > if (likely(netif_running(priv->ndev))) {
> > cpsw_intr_disable(priv);
> > - cpsw_disable_irq(priv);
> > + if (priv->irq_enabled == true) {
> > + cpsw_disable_irq(priv);
> > + priv->irq_enabled = false;
> > + }
> > napi_schedule(&priv->napi);
> > }
> >
> > @@ -512,7 +516,11 @@ static int cpsw_poll(struct napi_struct *napi, int
> > budget)
> > if ((num_total_rx + num_total_tx) < budget) {
> > napi_complete(napi);
> > cpsw_intr_enable(priv);
> > - cpsw_enable_irq(priv);
> > + if (priv->irq_enabled == false) {
> > + cpsw_enable_irq(priv);
> > + priv->irq_enabled = true;
> > + }
> > +
> > }
> >
> > return num_total_rx + num_total_rx;
> > @@ -812,7 +820,10 @@ static int cpsw_ndo_stop(struct net_device *ndev)
> > struct cpsw_priv *priv = netdev_priv(ndev);
> >
> > cpsw_info(priv, ifdown, "shutting down cpsw device\n");
> > - cpsw_disable_irq(priv);
> > + if (priv->irq_enabled == true) {
> > + cpsw_disable_irq(priv);
> > + priv->irq_enabled = false;
> > + }
> > netif_stop_queue(priv->ndev);
> > if (!priv->data.disable_napi)
> > napi_disable(&priv->napi);
> > @@ -1307,6 +1318,8 @@ static int cpsw_probe(struct platform_device
> *pdev)
> > priv->msg_enable = netif_msg_init(debug_level, CPSW_DEBUG);
> > priv->rx_packet_max = max(rx_packet_max, 128);
> >
> > + priv->irq_enabled = false;
> > +
> > /*
> > * This may be required here for child devices.
> > */
> >
> > --
> > For more options, visit http://beagleboard.org/discuss
> > ---
> > You received this message because you are subscribed to the Google
> Groups
> > "BeagleBoard" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an
> > email to beagleboard...-/***@public.gmane.org <javascript:>.
> > For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
> --
> Robert Nelson
> http://www.rcn-ee.com/
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[Gerald Coley]

The SW folks need to answer that question.

Gerald



On Fri, Jan 31, 2014 at 3:56 AM, <moonsurveyor-***@public.gmane.org> wrote:

> Hi Gerald,
>
> how can i check if i have this patch?
>
>
> Thx
> Attila
>
> On Friday, January 3, 2014 5:37:19 PM UTC+1, RobertCNelson wrote:
>
>> On Thu, Jan 2, 2014 at 10:08 PM, Eugene <e_b...-yrJ9Dsz9FWCaMJb+***@public.gmane.org> wrote:
>> > I ran into the same problems. I hacked up a patch to 3.8.8 from this
>> patch:
>> > http://permalink.gmane.org/gmane.linux.network/267097
>> > and the ifdown/ifup issue went away for me.
>>
>> Nice find! This fixes my debian netinstall, gonna push it to the
>> default beagleboard.org kernel..
>>
>> >
>> > Here is my git diff for those who want to give it a try:
>> > diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
>>
>> > index 21ba53e..67c7f74 100644
>> > --- a/drivers/net/ethernet/ti/cpsw.c
>> > +++ b/drivers/net/ethernet/ti/cpsw.c
>> > @@ -342,6 +342,7 @@ struct cpsw_priv {
>> > /* snapshot of IRQ numbers */
>> > u32 irqs_table[4];
>> > u32 num_irqs;
>> > + bool irq_enabled;
>> > struct cpts cpts;
>> > };
>> >
>> > @@ -458,7 +459,10 @@ static irqreturn_t cpsw_interrupt(int irq, void
>> > *dev_id)
>> >
>> > if (likely(netif_running(priv->ndev))) {
>> > cpsw_intr_disable(priv);
>> > - cpsw_disable_irq(priv);
>> > + if (priv->irq_enabled == true) {
>> > + cpsw_disable_irq(priv);
>> > + priv->irq_enabled = false;
>> > + }
>> > napi_schedule(&priv->napi);
>> > }
>> >
>> > @@ -512,7 +516,11 @@ static int cpsw_poll(struct napi_struct *napi, int
>> > budget)
>> > if ((num_total_rx + num_total_tx) < budget) {
>> > napi_complete(napi);
>> > cpsw_intr_enable(priv);
>> > - cpsw_enable_irq(priv);
>> > + if (priv->irq_enabled == false) {
>> > + cpsw_enable_irq(priv);
>> > + priv->irq_enabled = true;
>> > + }
>> > +
>> > }
>> >
>> > return num_total_rx + num_total_rx;
>> > @@ -812,7 +820,10 @@ static int cpsw_ndo_stop(struct net_device *ndev)
>> > struct cpsw_priv *priv = netdev_priv(ndev);
>> >
>> > cpsw_info(priv, ifdown, "shutting down cpsw device\n");
>> > - cpsw_disable_irq(priv);
>> > + if (priv->irq_enabled == true) {
>> > + cpsw_disable_irq(priv);
>> > + priv->irq_enabled = false;
>> > + }
>> > netif_stop_queue(priv->ndev);
>> > if (!priv->data.disable_napi)
>> > napi_disable(&priv->napi);
>> > @@ -1307,6 +1318,8 @@ static int cpsw_probe(struct platform_device
>> *pdev)
>> > priv->msg_enable = netif_msg_init(debug_level, CPSW_DEBUG);
>> > priv->rx_packet_max = max(rx_packet_max, 128);
>> >
>> > + priv->irq_enabled = false;
>> > +
>> > /*
>> > * This may be required here for child devices.
>> > */
>> >
>> > --
>> > For more options, visit http://beagleboard.org/discuss
>> > ---
>> > You received this message because you are subscribed to the Google
>> Groups
>> > "BeagleBoard" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an
>> > email to beagleboard...-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
>> > For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>> --
>> Robert Nelson
>> http://www.rcn-ee.com/
>>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
> For more options, visit https://groups.google.com/groups/opt_out.
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

[m***@public.gmane.org]

Hello All,

just figured out that one issue with this PHY is the "Energy Detect
Power-Down" feature.
This actually powers down the transceiver, and waits for a suitable signal
to power-up again (see datasheet of the PHY).

This works only on gigabit switches somewhat reliable, but on 10/100 MBit
switches, it usually doesn't come up again.

Furthermore, that may be even enforced by a schematic issue: Tx and Rx are
not connected as specified by the PHY (Tx should go to pin 1 and 2, RX to
the others). This is not a big deal as MDI-X fixes this, but this might be
the root cause that the Energy Detect algorithm doesn't work on 10/100.

However, we just disabled this feature by removing the enabling lines from
the smsc.c driver within smsc_phy_config_init().

Maybe this helps!

Am Montag, 10. Juni 2013 17:23:32 UTC+2 schrieb necron...-***@public.gmane.org:
>
> I'm having a strange problem with my new BeagleBone black: I can transmit
> packets from the Ethernet port but not receive them.
>
> When using DHCP, I can see (via a sniffer) the DHCP DISCOVER packet sent
> from the 'bone (via a network sniffer). I can see my DHCP server (dnsmasq
> 2.59 on stock Ubuntu 12.04 LTS 64-bit server) send a DHCP OFFER. But the
> 'bone acts like it never hears the offer; it just sends out more DISCOVERs
> at intervals. (The same DHCP server is working fine for dozens of clients
> from various vendors. There are plenty of leases left in the pool.)
>
> If I set a static address and try to ping something, I see the 'bone send
> an ARP who-has, I see the target reply with an ARP is-at, but the 'bone
> just keeps ARP-ing, and never gets an entry in its ARP table.
>
> In the ifconfig output, the eth0 interface shows 0 packets received and 0
> errors. (The number transmitted is non-0.) Nothing suspicious in the dmesg
> output that I can see.
>
> I've repeated the tests with both the latest Angstrom and with Ubuntu
> booted off an SD card. Same results. I've tried two different cables, and
> two different ports on two different Ethernet switches from different
> vendors. (All ports and cables verified to work fine with my laptop.)
>
> One interesting observation: the port seems to always end up on 10Mbps,
> even when plugged into 100Mbps- (or gigabit-) capable ports. So, it looks
> like autonegotiation isn't working either.
>
> I'm running on a 2A 5.00V regulated bench supply, and the DC looks clean
> on the o-scope.
>
> Other 'bone functions (USB host, USB target, HDMI, LEDs) all seem to work
> fine.
>
> I'm starting to suspect a hardware problem (busted PHY or magnetics;
> incomplete or bridged trace).
>
> Any suggestions for stuff I should try before I RMA the poor little guy?
> (I'm an experienced Linux user and reasonably competent electronics
> hobbyist, if that matters.)
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/d/optout.