On Thu, Apr 21, 2016 at 7:25 PM, Charles Steinkuehler < char...@steinkuehler.net> wrote:
> On 4/10/2016 3:36 PM, Charles Steinkuehler wrote: > > On 4/10/2016 3:17 PM, Charles Steinkuehler wrote: > >> On 4/10/2016 11:13 AM, Charles Steinkuehler wrote: > >>> I am experimenting with getting Machinekit running on Debian Jessie, > >>> and have run into an issue with loading capes. > >>> > >>> After I manually load a cape: > >>> > >>> $ SLOTS=/sys/devices/bone_capemgr.*/slots > >>> $ sudo -A su -c "echo cape-bebopr-brdg:R2 > $SLOTS" > >>> > >>> ...CPU usage maxes out and I have eight systemd-udevd tasks running > >>> that are each taking a good chunk of the CPU. These typically go away > >>> after apx. 17 seconds of CPU time (each), or about 2-1/2 minutes, but > >>> I'm wondering what in the world is going on. > >>> > >>> Is this a known issue? Any ideas how to tell what the systemd-udevd > >>> processes are doing? > >>> > >>> The kernel is 3.8.13-xenomai-r78, which works fine under Wheezy. > >> > >> I get the same results with a "stock" Debian Jessie image ( > >> > >> debian@beaglebone:~$ cat /etc/dogtag > >> BeagleBoard.org Debian Image 2016-03-27 > >> > >> ...using the 3.8.13-bone79 kernel. The 4.1.18-ti-r55 kernel provide > >> with the Jessie image has a cape manager (although the slots file is > >> in a different location), but trying to load the cape-bebopr-brdg:R2 > >> cape fails. > >> > >> Any hints as to how to debug would be very welcome! > > OK, this doesn't appear to be a PRU issue, it's a fundamental problem > with udev. The systemd-udevd process that are chewing up CPU cycles > are endlessly trying to create a symlink due to the contents of > /etc/udev/rules.d/uio.rules, which contains: > > SUBSYSTEM=="uio", SYMLINK+="uio/%s{device/of_node/uio-alias}" > SUBSYSTEM=="uio", GROUP="users", MODE="0660" > > When you strace one of the 'stuck' systemd-udevd processes, you get an > endless (until the process is killed) repeating stream of: > > > mkdir("/dev", 0755) = -1 EEXIST (File exists) > > symlink("../uio1", "/dev/uio/") = -1 ENOENT (No such file or > directory) > > stat64("/dev/uio", 0xbeffb430) = -1 ENOENT (No such file or > directory) > > mkdir("/dev", 0755) = -1 EEXIST (File exists) > > symlink("../uio1", "/dev/uio/") = -1 ENOENT (No such file or > directory) > > stat64("/dev/uio", 0xbeffb430) = -1 ENOENT (No such file or > directory) > > ... > > The symlink fails because there is no /dev/uio directory, which the > systemd-udevd process seems to think is supposed to exist. > > Any uio and/or udev gurus know what's going on? > and of course, i never added who pinged me on this, when i pushed the change... https://github.com/RobertCNelson/omap-image-builder/commit/47f982cf2896664dacd21126cf4381b078b94d15 Regards, -- Robert Nelson https://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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAOCHtYhaA%2B9OSiyRu9XE%2Bt%3DaO2_4e8Pguf%3Dsx5-LeULY4a8P7Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.