On 1/17/2013 2:59 AM, Bas Laarhoven wrote: > I think that running linuxcnc is mandatory for the lockup. After a dozen > runs, it looks like I can reproduce the lockup with 100% certainty > within one hour. > Using the JTAG interface to attach a debugger to the Bone, I've found > that once stalled the kernel is still running. It looks like it won't > schedule properly and almost all time is spent in the cpu_idle thread. > > The kernel with extra diagnostics produces these messages: > > [ 3480.386342] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" > disables this message. > [ 3480.395913] INFO: task axis:799 blocked for more than 120 seconds. > [ 3480.406643] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" > disables this message. > [ 3600.408670] INFO: task hal_manualtoolc:788 blocked for more than 120 > seconds.
Hi, Bas. Like Michael I haven't been running LinuxCNC continuously but I'm doing it now to see if I can reproduce your lockup on my BeagleBone. I'm using a Rev. A6 BeagleBone powered solely through the microUSB port (I've tried unsuccessfully to induce power problems; there's a 2a supply in the drawer if I need it) I'm running off Michael's updated root filesystem. Both the vmlinuz-3.2.21-xenomai+ kernel and the rootfs are loaded from the microSD card (e.g., TFTP and NFS were not used to bring up the system and DHCP was used only to provision the kernel ip settings, not the U-Boot settings). [1] I'm talking to the BeagleBone via ssh -X over my LAN so I don't have to futz with DISPLAY and permissions settings. [2] Since the microUSB port is connected I'm logged in over the serial port and running 'top' to see how I'm doing. So far, I've had LinuxCNC up for more than an hour with the 3-axis mill simulator running in Axis, repeatedly executing and reopening the 3d_chips.ngc file within Axis. Granted I haven't automated this; every time I notice the simulator has finished the G-Code I manually reopen and execute the file. Nevertheless, the processes Axis, milltask, hal_manualtoolc, and halui remain loaded, active, and the big cpu consumers according to 'top'. As an aside, so is sshd, which is consuming 25 percent (yikes) of CPU as long as it's updating the backplot. So, to help me understand better what you are seeing, could you please add some detail to your report? -What rev board (ok, so I think this an unlikely problem, but at some point you said you've been working with your BeagleBone for months so I wonder what's different between yours and mine)? -are you running a simulator or are you exercising some PRUSS code or what? -what do you mean by "running" LinuxCNC? Does LinuxCNC have to be actively running a program without interruption for the fault to occur or does it fault when run the way I did my own test? Finally, with respect to your next email message, how universal is your statement that TI "...decided not to support the PRUSS anymore." Does this refer to the TI documentation and software situation or does it mean TI has decided they can't make money developing SoCs with PRUSS and, hence, the current AM335x series is the end of the road? I could get depressed:-( Regards, Kent PS - I promise I'll update Michael's wiki page concerning items [1] and [2] ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
