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.
