Per a previous post, I have an issue with the Beagleboard XM freezing when running a USB intensive program. This was under opensuse 12. The particular software uses Cmake and compiled fine under openuse for arm. On the outside chance that my problem is related to the OS used, I decided to try some other distrubutions. [The beagleboard RMA group isn’t interested unless the crash is under Angstron, and Liquidware is completely useless.]
So much for background. Here is the error message, in this case from Ubuntu:
The RMA group, as you call them, would be most happy to supply you with a second board if you wanted to run your test on an additional piece of hardware. All you have to do is ask me!
Gerald
I already contacted them. They said the new board would be the same as the old board. RMA seemed kind of pointless unless you are saying the Beagleboard XM has a manufacturing problem or the QA isn’t very rigorous.
I’m willing to go with their theory of blaming the OS, but to prove it incorrect or at least dubious would require running the software on a few different distributions with lockup on each.
Which brings me back to this Cmake issue. Anyone?
The reason we rely on Angstrom is because that is the distribution we chose so that we would not be flooded with RMAs based on dozens of distributions and dozens of revisions of kernels, and dozens of revisions of distributions to determine if the HW was the issue, which is covered by the RMA process. You would not believe the number of RMAs we get that work fine that have reported hard failures, like will not power on, will not boot. or Ethernet does not work. Separating SW from the HW, especially SW that someone else compiled or modified, is a challenge.
If you are convinced that the board is bad but works under Angstrom, we would be happy to assist by running your image on a card in out facility. We are willing to help you. We are not insinuating anything other than a desire to assist where we can.
Gerald
Sounds like the smsc95xx out of memory problem… Please enable serial logging and post the error messages dumped before lockup…
Regards,
I completely understand your situation. You are not responsible for software other than what you include. However, you troll the interwebs, and the natives are grumbling about problems with usb on the beagleboard. Capacitor mods, etc. Nobody has suggested getting out the torches and pitchforks yet. I’m actually holding out hope that one of the other distributions won’t have the problem. I also got a class 6 micro sd, thinking maybe it is a speed issue with the class 4.
In the mean time, I loaded up opensuse, which is where I was able to get cmake running. Obviously some variable is set correctly on that distro that isn’t correct on fedora and ubuntu. I will give ubuntu credit that at least the board can be rebooted via software, which apparently has eluded opensuse. 
Actually you tried to help me in the other thread I posted on this issue. As far as I can tell, there is nothing to set up for serial logging. I basically posed that question to the opensuse arm forum, which is where my post sits waiting for a reply. I do have the serial port going to my PC. [Tera Term VT, since MS decided to dump hyperterminal on win7]
Regarding being out of memory, I never saw the system monitor get close to being out of memory. I also ran the software at runlevel 3 to free up memory and reduce overhead. There was no difference. I tried both the 300MHz and 800MHz fixed clocks rather than let the OS move the clock rate on the fly. Again, no difference.
I’ve found a number of post regarding smsc95xx for the Pi. The opensuse posts regarding smsc95xx seem to be related to other problems.
I found this for gentoo:
Solution if the former fails: Add smsc95xx.turbo_mode=N to kernel parameters, or vm.min_free_kbytes = 4096 to /etc/sysctl.conf
I do have a /etc/sysctl.con file and will investigate.
Per a previous post, I have an issue with the Beagleboard XM freezing when running a USB intensive program. This was under opensuse 12. The particular software uses Cmake and compiled fine under openuse for arm. On the outside chance that my problem is related to the OS used, I decided to try some other distrubutions. [The beagleboard RMA group isn’t interested unless the crash is under Angstron, and Liquidware is completely useless.]
So much for background. Here is the error message, in this case from Ubuntu:
root@localhost:/usr/local/src/rtl_sdr/rtl-sdr/build# cmake …/
CMake Error: CMake was unable to find a build program corresponding to “Unix Makefiles”. CMAKE_MAKE_PROGRAM is not set. You probably need to select a different build tool.
CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly.
Missing variable is:
CMAKE_C_COMPILER_ENV_VAR
CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly.
Missing variable is:
CMAKE_C_COMPILER
CMake Error: Could not find cmake module file:/usr/local/src/rtl_sdr/rtl-sdr/build/CMakeFiles/CMakeCCompiler.cmake
CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
– Configuring incomplete, errors occurred!
I tried to solve this from internet searching, but sadly cmake, being multiplatform, generates way too many false hits. Restrict it to arm and the results are few and cryptic.
Incidentally, having now used opensuse, fedora, and ubuntu under arm, Opensuse is at the head of the pack in my opinion for completeness. However my inquiry about diagnostics regarding the Beagleboard XM freezing has sat unanswered on their forum for nearly a week.
Sounds like the smsc95xx out of memory problem… Please enable serial logging and post the error messages dumped before lockup…
Regards,
Actually you tried to help me in the other thread I posted on this issue. As far as I can tell, there is nothing to set up for serial logging. I basically posed that question to the opensuse arm forum, which is where my post sits waiting for a reply. I do have the serial port going to my PC. [Tera Term VT, since MS decided to dump hyperterminal on win7]
Regarding being out of memory, I never saw the system monitor get close to being out of memory. I also ran the software at runlevel 3 to free up memory and reduce overhead. There was no difference. I tried both the 300MHz and 800MHz fixed clocks rather than let the OS move the clock rate on the fly. Again, no difference.
I’ve found a number of post regarding smsc95xx for the Pi. The opensuse posts regarding smsc95xx seem to be related to other problems.
I found this for gentoo:
Solution if the former fails: Add smsc95xx.turbo_mode=N to kernel parameters, or vm.min_free_kbytes = 4096 to /etc/sysctl.conf
I do have a /etc/sysctl.con file and will investigate.
Adding the vm.min_free parameter lead to the decoder software crashing rather than the system locking up. It issued this error message:
cb transfer status 1 cancelling
I will take this up the author of the program. I am now leaning towards this being a software issue more than a hardware issue. At the moment, I am running the same software on Ubuntu with no lock up after an hour. However, I have run the software under opensuse for 12 hours until the board froze, so it is too early to tell if the problem is gone.
It turns out that if you run
apt-get install build-essential
the environment variable (or whatever) needed for cmake to function is correct.
Thanks this one help using Ubuntu 13.4 on BeagleBone Black.