Beagleboard Xm Unreliable ethernet

DaveL · March 16, 2011, 11:06am

Hi

We have a beagle board Xm running linux, and have some issues with the
beagle board's ethernet interface.

Basically after a rest or power up we issue

ifconfig usb0 <ipaddress>

The interface does not always come up (no lights on the interface),
without removing the ethernet cable, waiting a few seconds and then
inserting the cable. Sometimes two attempts are needed here.

The lights are on after powerup, however it is after issuing the
command that occasionally the interface seems to fall over.

This occurs wit the out of the box kernel and filesystem 2.3.32.

Does anyone else have similar experiences and a solution. We are
thinking this might be a feature of the usb device in powersave mode.

We have tried the obvious of a new cable etc.

Dave

Gokul.C · March 16, 2011, 1:21pm

The problem may also be due to insufficient power supply to power the onboard hub.
Try it with atleast 3A powersupply.

Edgar1 · March 23, 2012, 12:16pm

Hello,

I have the same issue on the Beagle Board xM rev C with Linux omap 3.2.2-x4. The Ethernet interface doesn’t always come up on boot.

If the Ethernet happens to come up on boot, then I see these messages:
ccrma@satellite:~$ dmesg | grep smsc
[ 21.716583] smsc95xx v1.0.4
[ 21.834564] smsc95xx 1-2.1:1.0: eth0: register ‘smsc95xx’ at usb-ehci-omap.0-2.1, smsc95xx USB 2.0 Ethernet, 9a:93:55:13:7a:fc
[ 21.852294] usbcore: registered new interface driver smsc95xx
[ 25.380645] smsc95xx 1-2.1:1.0: eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1

However, if Ethernet doesn’t come up on boot, then I have to plug and unplug the ethernet cable at the Beagle Board xM until I get the following kernel message (which should’ve appeared during startup):
[ 88.431365] smsc95xx 1-2.1:1.0: eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1

I have the issue both with the 5V regulated 2.5A Jameco supply 689864 and another 2.5A regulated USB hub power supply. I don’t have any 3A power supplies to test with at the moment, but this seems a bit excessive given that the board typically draws much less current, and 3A isn’t even that much more than 2.5A. Does the board need some stronger power supply filtering/regulation, maybe a bigger cap somewhere?

Cheers,
John

RobertCNelson · March 23, 2012, 12:29pm

I have a board that does this too, it just seemed like it started
happening post 2.6.36... Haven't been able to bisect it down to any
commit, as it's pretty random..

To work around it, i just:

sudo rmmod smsc95xx ; sleep 5 ; sudo modprobe smsc95xx ; sudo
/etc/init.d/networking restart

and if that fails, force a reboot.. (as the board isn't easily accessible..)

Regards,

Edgar1 · April 20, 2012, 2:28pm

Hi Robert,

Thanks for your response. At least I have an excuse to tell the students why occasionally the Ethernet doesn’t work

We don’t have students log in over serial, because then each student would need to purchase a USB-to-serial adaptor to connect to their laptop. (Also as far as I know, there is no straight-forward way to forward X-windows over that kind of connection in a way that is easily compatible with Mac OS, Windows, and Linux laptops.)

Originally, we used the USB over Ethernet feature for the Beagle Board original, but I found that every time I plugged it into my OS X laptop, it came up as a new device name, which was really inconvenient because I had to input the settings each time, and then I wound up will all of these old interfaces that I had to manually delete one after another. (I realize there could possible be an easy way to fix this on OS X, but I started thinking that maybe not very many people used this kind of connection, so maybe it would be a hassle to get it working under Windows and Linux as well. Students bring in all sorts of different kinds of laptops – the worst are these netbooks with crippled versions of Windows, for which the feature for sharing a wireless Internet connection with the Ethernet port is disabled.)

So that is why we are using the Ethernet connection. It has become quite standard by now, so at least it seems to be relatively easy to setup. (The worst thing is that Windows users have to install Cygwin, which takes quite a while depending on which packages they install. Because of that we ask Windows users to install Cygwin before coming to the first class.)

Anyway of course your solution works for getting the Ethernet up and going again (I usually instead resort to just unplugging and replugging the Ethernet cable until the lights on the Ethernet port come on), but this is confusing for beginning students, and since they are only connected by Ethernet, they can’t run that command if they’re not plugged in. (A while ago I tried running “sudo ifdown eth0; sleep 5; sudo ifup eth0” on boot, but of course the Ethernet can always fail to come up upon the manually-setup ifup, even if it already came up the first time after all.

Finally, I just purchased a 3A 5V power supply (DVE DSA-0151F-05) to see if this helps, but I can only verify that this does not make the Ethernet connection come up reliably. There is no easily measurable improvement for me.

uname -a
Linux omap 3.2.2-x4 #1 SMP PREEMPT Wed Feb 15 07:09:50 PST 2012 armv7l GNU/Linux

Cheers,
Edgar

RobertCNelson · April 20, 2012, 2:55pm

Hi Robert,

Thanks for your response. At least I have an excuse to tell the students why
occasionally the Ethernet doesn't work

We don't have students log in over serial, because then each student would
need to purchase a USB-to-serial adaptor to connect to their laptop. (Also
as far as I know, there is no straight-forward way to forward X-windows over
that kind of connection in a way that is easily compatible with Mac OS,
Windows, and Linux laptops.)

Still, a pretty big missing debuging option for the students.. It's
too bad, they avg $15/20...

Originally, we used the USB over Ethernet feature for the Beagle Board
original, but I found that every time I plugged it into my OS X laptop, it
came up as a new device name, which was really inconvenient because I had to
input the settings each time, and then I wound up will all of these old
interfaces that I had to manually delete one after another. (I realize there
could possible be an easy way to fix this on OS X, but I started thinking
that maybe not very many people used this kind of connection, so maybe it
would be a hassle to get it working under Windows and Linux as well.
Students bring in all sorts of different kinds of laptops -- the worst are
these netbooks with crippled versions of Windows, for which the feature for
sharing a wireless Internet connection with the Ethernet port is disabled.)

Look in "/etc/network/interfaces" there's usually a commented out hint
to fix this..

# Example to keep MAC address between reboots
#hwaddress ether DE:AD:BE:EF:CA:FE

So that is why we are using the Ethernet connection. It has become quite
standard by now, so at least it seems to be relatively easy to setup. (The
worst thing is that Windows users have to install Cygwin, which takes quite
a while depending on which packages they install. Because of that we ask
Windows users to install Cygwin before coming to the first class.)

Anyway of course your solution works for getting the Ethernet up and going
again (I usually instead resort to just unplugging and replugging the
Ethernet cable until the lights on the Ethernet port come on), but this is
confusing for beginning students, and since they are only connected by
Ethernet, they can't run that command if they're not plugged in. (A while
ago I tried running "sudo ifdown eth0; sleep 5; sudo ifup eth0" on boot, but
of course the Ethernet can always fail to come up upon the manually-setup
ifup, even if it already came up the first time after all.

Finally, I just purchased a 3A 5V power supply (DVE DSA-0151F-05) to see if
this helps, but I can only verify that this does not make the Ethernet
connection come up reliably. There is no easily measurable improvement for
me.

uname -a
Linux omap 3.2.2-x4 #1 SMP PREEMPT Wed Feb 15 07:09:50 PST 2012 armv7l
GNU/Linux

BTW, Upgrade them to: v3.2.15-x8

Which includes a pretty important fix on the xM's, usb..
https://github.com/RobertCNelson/stable-kernel/blob/master/patches/omap_fixes/0002-Fix-sprz319-erratum-2.1.patch

However I then had to disable the patch in my v3.2.15-x9, as it breaks
all Beagle C4 boards.. (hardlock on kernel load). I'm hoping to debug
that patch more tonight/saturday before leave for the ti conference
next week..

Regards,

Edgar1 · September 25, 2012, 7:27pm

Dear Robert,

Today I had a chance to merge in the “fix-sprz319-erratum-2.1.patch” patch into the 3.2.30-x14 kernel–I believe that is currently what is in the stable branch in the git repository. After just a minute of plugging and unplugging the ethernet cable into the xM rev C board, it seemed to fix the problem. But I will have to wait a few weeks of students working with it to report back for sure. Also, maybe I will find out if this fixes the occassional USB disconnect problem.

Actually today I just wanted to check if I am using the current “best”/really most version of the kernel for the xM. Because I compile some other patches in with the kernel (and it’s not automatic unfortunately, I have to do several steps manually), it takes a long time to try out a new kernel and see how it is working.

Am I using the right version of the kernel now for Ubuntu? I’m using the image to teach students how to make art projects using it. While I’m at it, should I compile the last 2.6.xx kernel just in case it turns out to be more stable down the line? (One other interesting thing I noticed was I had to pull in the old load_uImage.sh script that I used some time back in order to get this kernel onto the image file.)

Are there any other patches that I should either exclude or include into the kernel because I’m using the xM? Note: For example, students like to setup projects in museums, so it is much more convenient if their Beagle Board xMs run for weeks without any problems.

Cheers!

RobertCNelson · September 25, 2012, 7:59pm

Dear Robert,

Today I had a chance to merge in the "fix-sprz319-erratum-2.1.patch" patch
into the 3.2.30-x14 kernel--I believe that is currently what is in the
stable branch in the git repository. After just a minute of plugging and
unplugging the ethernet cable into the xM rev C board, it seemed to fix the
problem. But I will have to wait a few weeks of students working with it to
report back for sure. Also, maybe I will find out if this fixes the
occassional USB disconnect problem.

Actually today I just wanted to check if I am using the current
"best"/really most version of the kernel for the xM. Because I compile some
other patches in with the kernel (and it's not automatic unfortunately, I
have to do several steps manually), it takes a long time to try out a new
kernel and see how it is working.

I've had pretty good luck with v3.5.x on the xM..

(the original panda is still the only thing holding me back from
making it default..)

Note: we had to disable the 800Mhz option.. (unless you disable
cpufreq, then you can bring it back..)

github.com

RobertCNelson/stable-kernel/blob/v3.5.x/patch.sh#L87


      
          	${git} "${DIR}/patches/beagle/expansion/0009-Beagle-Camera-add-MT9P031-Aptina-image-sensor-driver.patch"
          
          	#v3.5: looks to be removed: (might want to revert it back in...)
          	#http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commit;h=b6e695abe710ee1ae248463d325169efac487e17
          	#git am "${DIR}/patches/beagle/0001-beagleboard-reinstate-usage-of-hi-speed-PLL-divider.patch"
          
          	#Status: for meego guys..
          	${git} "${DIR}/patches/beagle/0001-meego-modedb-add-Toshiba-LTA070B220F-800x480-support.patch"
          
          	${git} "${DIR}/patches/beagle/0002-backlight-Add-TLC59108-backlight-control-driver.patch"
          	${git} "${DIR}/patches/beagle/0003-tlc59108-adjust-for-beagleboard-uLCD7.patch"
          
          	#Status: not for upstream
          	${git} "${DIR}/patches/beagle/0004-zeroMAP-Open-your-eyes.patch"
          
          	${git} "${DIR}/patches/beagle/0005-OMAP3-USB-EHCI-fix.patch"
          
          	#cpufreq: only 800Mhz seems to cause hard lock... disable for now..
          	${git} "${DIR}/patches/beagle/0006-TEMP-Beagle-xM-cpufreq-disable-800Mhz-opp.patch"
          }

see Tony's reply here: Re: Beagleboard xM crashes when being set to 800MHz with smartreflex on linux-omap-3.6-rc6 — Linux OMAP ARM

Basically once the os is running, if you call reboot, it will randomly
crash on the next bootup when attempting to set 800Mhz..

And for your xM's.. (make sure to enable the sprz319_erratum wordaround..)

github.com

RobertCNelson/stable-kernel/blob/v3.5.x/patch.sh#L179


      
          }
          
          cpuidle_omap () {
          	echo "cpuidle_omap"
          	${git} "${DIR}/patches/cpuidle_omap/0001-ARM-OMAP-timer-allow-gp-timer-clock-event-to-be-used.patch"
          	${git} "${DIR}/patches/cpuidle_omap/0002-ARM-OMAP4-CPUidle-Use-coupled-cpuidle-states-to-impl.patch"
          	${git} "${DIR}/patches/cpuidle_omap/0003-ARM-OMAP4-CPUidle-add-synchronization-for-coupled-id.patch"
          	${git} "${DIR}/patches/cpuidle_omap/0004-ARM-OMAP4-CPUidle-Open-broadcast-clock-event-device.patch"
          	${git} "${DIR}/patches/cpuidle_omap/0005-ARM-OMAP4-sleep-Save-the-complete-used-register-stac.patch"
          	${git} "${DIR}/patches/cpuidle_omap/0006-cpufreq-OMAP-Handle-missing-frequency-table-on-SMP-s.patch"
          	${git} "${DIR}/patches/cpuidle_omap/0007-ARM-OMAP4-Register-the-OPP-table-only-for-4430-devic.patch"
          }
          
          omap3isp () {
          	#omap3isp: Revert to v3.4.x, till we figure out, how to actually set the 'pixel rate control'
          	#"no pixel rate control in subdev %s\n","
          	${git} "${DIR}/patches/omap3isp/0001-Revert-media-omap3isp-Move-CCDC-link-validation-to-c.patch"
          	${git} "${DIR}/patches/omap3isp/0002-Revert-media-omap3isp-Default-link-validation-for-cc.patch"
          	${git} "${DIR}/patches/omap3isp/0003-Revert-media-omap3isp-Use-external-rate-instead-of-v.patch"
          	${git} "${DIR}/patches/omap3isp/0004-Revert-media-omap3isp-Introduce-isp_video_check_exte.patch"
          }

Am I using the right version of the kernel now for Ubuntu? I'm using the
image to teach students how to make art projects using it. While I'm at it,
should I compile the last 2.6.xx kernel just in case it turns out to be more
stable down the line? (One other interesting thing I noticed was I had to
pull in the old load_uImage.sh script that I used some time back in order to
get this kernel onto the image file.)

With the new script, it doesn't assume that you need a uImage, so if
your using an older bootloader (it doesn't use zimages) then make sure
your zreladdress is set in system.sh..

Are there any other patches that I should either exclude or include into the
kernel because I'm using the xM? Note: For example, students like to setup
projects in museums, so it is much more convenient if their Beagle Board xMs
run for weeks without any problems.

Regards,

Edgar1 · September 25, 2012, 11:41pm

Dear Robert,

Thanks for your reply and your tips! I will keep the patch fix-sprz319-erratum-2.1.patch then.

Regarding my 3.2.30 release, I have cpufreq disabled, and I also turned off cpu idle. It’s better for audio that the CPU always runs full speed so that it never drops vectors of audio (students always love to make projects that use up 80% of the CPU with audio…) I realize that it is rather heavy handed, but this way, they also can’t mess around with cpufreq, misconfigure their project, and then need help with it. (It is true that the boards run noticeably hotter.) Is there any reason you know of why I would want to run at a slower clockspeed than 800MHz for the 3.2.30 release?

I will of course keep the group updated if I have any more useful info.

Cheers!

RobertCNelson · September 25, 2012, 11:47pm

Well other than battery/solar powered applications.

For your situation, you might as well drop the cpuidle/cpufreq and
just force 800Mhz with mpurate=800 on bootup..

Have your students looked at importing the real-time patchset? That
might be something interesting for them to test and report their
findings.

Regards,