High CPU usage after loading a cape on Jessie
103 views
Skip to first unread message
Charles Steinkuehler
Apr 10, 2016, 12:13:42 PM4/10/16
to beagl...@googlegroups.com
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.
Here's an example from top shortly after loading the cape:
> Tasks: 107 total, 10 running, 97 sleeping, 0 stopped, 0 zombie
> %Cpu(s): 15.7 us, 84.3 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
> KiB Mem: 507640 total, 405956 used, 101684 free, 23924 buffers
> KiB Swap: 0 total, 0 used, 0 free. 208136 cached Mem
>
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 1692 root 20 0 10876 1284 512 R 10.5 0.3 0:01.49 systemd-udevd
> 1693 root 20 0 10876 1312 540 R 10.5 0.3 0:01.49 systemd-udevd
> 1694 root 20 0 10876 1300 528 R 10.5 0.3 0:01.49 systemd-udevd
> 1698 root 20 0 10876 1284 512 R 10.5 0.3 0:01.48 systemd-udevd
> 1701 root 20 0 10876 1268 496 R 10.5 0.2 0:01.47 systemd-udevd
> 1719 root 20 0 10876 1088 324 R 10.5 0.2 0:01.46 systemd-udevd
> 1720 root 20 0 10876 1088 324 R 10.5 0.2 0:01.46 systemd-udevd
> 1721 root 20 0 10876 1088 324 R 10.5 0.2 0:01.46 systemd-udevd
> 661 machine+ 20 0 209288 25224 18420 S 5.9 5.0 0:11.20 lxqt-panel
> 3 root 20 0 0 0 0 R 2.6 0.0 0:00.80 ksoftirqd/0
> 436 root 20 0 59688 16448 8540 S 1.0 3.2 0:02.70 Xorg
> 1135 machine+ 20 0 3100 1252 808 R 0.7 0.2 0:00.51 top
> 1112 machine+ 20 0 9208 1596 924 S 0.3 0.3 0:00.08 sshd
--
Charles Steinkuehler
cha...@steinkuehler.net
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.
Here's an example from top shortly after loading the cape:
> Tasks: 107 total, 10 running, 97 sleeping, 0 stopped, 0 zombie
> %Cpu(s): 15.7 us, 84.3 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
> KiB Mem: 507640 total, 405956 used, 101684 free, 23924 buffers
> KiB Swap: 0 total, 0 used, 0 free. 208136 cached Mem
>
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 1692 root 20 0 10876 1284 512 R 10.5 0.3 0:01.49 systemd-udevd
> 1693 root 20 0 10876 1312 540 R 10.5 0.3 0:01.49 systemd-udevd
> 1694 root 20 0 10876 1300 528 R 10.5 0.3 0:01.49 systemd-udevd
> 1698 root 20 0 10876 1284 512 R 10.5 0.3 0:01.48 systemd-udevd
> 1701 root 20 0 10876 1268 496 R 10.5 0.2 0:01.47 systemd-udevd
> 1719 root 20 0 10876 1088 324 R 10.5 0.2 0:01.46 systemd-udevd
> 1720 root 20 0 10876 1088 324 R 10.5 0.2 0:01.46 systemd-udevd
> 1721 root 20 0 10876 1088 324 R 10.5 0.2 0:01.46 systemd-udevd
> 661 machine+ 20 0 209288 25224 18420 S 5.9 5.0 0:11.20 lxqt-panel
> 3 root 20 0 0 0 0 R 2.6 0.0 0:00.80 ksoftirqd/0
> 436 root 20 0 59688 16448 8540 S 1.0 3.2 0:02.70 Xorg
> 1135 machine+ 20 0 3100 1252 808 R 0.7 0.2 0:00.51 top
> 1112 machine+ 20 0 9208 1596 924 S 0.3 0.3 0:00.08 sshd
--
Charles Steinkuehler
cha...@steinkuehler.net
Charles Steinkuehler
Apr 10, 2016, 4:17:57 PM4/10/16
to beagl...@googlegroups.com
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 (
> 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.
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!
--
Charles Steinkuehler
cha...@steinkuehler.net
Charles Steinkuehler
Apr 10, 2016, 4:36:15 PM4/10/16
to beagl...@googlegroups.com
systemd-udevd processes go away, this appears in the syslog:
> Apr 10 20:29:00 beaglebone systemd-udevd[179]: worker [1940] /devices/ocp.3/4a300000.pruss/uio/uio3 timeout; kill it
> Apr 10 20:29:00 beaglebone rsyslogd-2007: action 'action 17' suspended, next retry is Sun Apr 10 20:29:30 2016 [try http://www.rsyslog.com/e/2007 ]
> Apr 10 20:29:00 beaglebone systemd-udevd[179]: seq 2037 '/devices/ocp.3/4a300000.pruss/uio/uio3' killed
> Apr 10 20:29:00 beaglebone systemd-udevd[179]: worker [1941] /devices/ocp.3/4a300000.pruss/uio/uio4 timeout; kill it
> Apr 10 20:29:00 beaglebone systemd-udevd[179]: seq 2038 '/devices/ocp.3/4a300000.pruss/uio/uio4' killed
> Apr 10 20:29:00 beaglebone systemd-udevd[179]: worker [1942] /devices/ocp.3/4a300000.pruss/uio/uio0 timeout; kill it
> Apr 10 20:29:00 beaglebone systemd-udevd[179]: seq 2034 '/devices/ocp.3/4a300000.pruss/uio/uio0' killed
> Apr 10 20:29:00 beaglebone systemd-udevd[179]: worker [1943] /devices/ocp.3/4a300000.pruss/uio/uio1 timeout; kill it
> Apr 10 20:29:00 beaglebone systemd-udevd[179]: seq 2035 '/devices/ocp.3/4a300000.pruss/uio/uio1' killed
> Apr 10 20:29:00 beaglebone systemd-udevd[179]: worker [1944] /devices/ocp.3/4a300000.pruss/uio/uio2 timeout; kill it
> Apr 10 20:29:00 beaglebone systemd-udevd[179]: seq 2036 '/devices/ocp.3/4a300000.pruss/uio/uio2' killed
> Apr 10 20:29:00 beaglebone systemd-udevd[179]: worker [1949] /devices/ocp.3/4a300000.pruss/uio/uio5 timeout; kill it
> Apr 10 20:29:00 beaglebone systemd-udevd[179]: seq 2039 '/devices/ocp.3/4a300000.pruss/uio/uio5' killed
> Apr 10 20:29:00 beaglebone systemd-udevd[179]: worker [1969] /devices/ocp.3/4a300000.pruss/uio/uio6 timeout; kill it
> Apr 10 20:29:00 beaglebone systemd-udevd[179]: seq 2040 '/devices/ocp.3/4a300000.pruss/uio/uio6' killed
> Apr 10 20:29:00 beaglebone systemd-udevd[179]: worker [1970] /devices/ocp.3/4a300000.pruss/uio/uio7 timeout; kill it
> Apr 10 20:29:00 beaglebone systemd-udevd[179]: seq 2041 '/devices/ocp.3/4a300000.pruss/uio/uio7' killed
> Apr 10 20:29:00 beaglebone systemd-udevd[179]: worker [1941] terminated by signal 9 (Killed)
> Apr 10 20:29:00 beaglebone systemd-udevd[179]: worker [1969] terminated by signal 9 (Killed)
> Apr 10 20:29:00 beaglebone systemd-udevd[179]: worker [1943] terminated by signal 9 (Killed)
> Apr 10 20:29:00 beaglebone systemd-udevd[179]: worker [1940] terminated by signal 9 (Killed)
> Apr 10 20:29:00 beaglebone systemd-udevd[179]: worker [1942] terminated by signal 9 (Killed)
> Apr 10 20:29:00 beaglebone systemd-udevd[179]: worker [1944] terminated by signal 9 (Killed)
> Apr 10 20:29:00 beaglebone systemd-udevd[179]: worker [1949] terminated by signal 9 (Killed)
> Apr 10 20:29:00 beaglebone systemd-udevd[179]: worker [1970] terminated by signal 9 (Killed)
If it helps, the output from udevadm monitor while this is happening:
> KERNEL[234.676750] add /devices/ocp.3/bebopr_io_enables.15 (platform)
> KERNEL[234.682423] add /devices/virtual/gpio/gpio66 (gpio)
> KERNEL[234.683781] add /devices/ocp.3/48302000.epwmss (platform)
> KERNEL[234.692111] add /devices/ocp.3/48302000.epwmss/48302200.ehrpwm (platform)
> KERNEL[234.693310] add /devices/ocp.3/48302000.epwmss/48302200.ehrpwm/pwm/pwmchip0 (pwm)
> KERNEL[234.695424] add /devices/ocp.3/48304000.epwmss (platform)
> KERNEL[234.699930] add /devices/ocp.3/48304000.epwmss/48304200.ehrpwm (platform)
> KERNEL[234.701884] add /devices/ocp.3/48304000.epwmss/48304200.ehrpwm/pwm/pwmchip2 (pwm)
> KERNEL[234.708175] add /devices/ocp.3/bebopr_pwm_J2_pinmux.16 (platform)
> UDEV [234.710359] add /devices/ocp.3/bebopr_io_enables.15 (platform)
> KERNEL[234.713400] add /devices/ocp.3/bebopr_pwm_J3_pinmux.17 (platform)
> KERNEL[234.717348] add /devices/ocp.3/bebopr_pwm_J4_pinmux.18 (platform)
> KERNEL[234.719189] add /devices/ocp.3/bebopr_pwm_J2.19 (platform)
> KERNEL[234.720210] add /devices/ocp.3/bebopr_pwm_J3.20 (platform)
> KERNEL[234.721449] add /devices/ocp.3/bebopr_pwm_J4.21 (platform)
> KERNEL[234.726645] add /devices/ocp.3/bebopr_steppers.22 (platform)
> KERNEL[234.727829] add /devices/virtual/gpio/gpio15 (gpio)
> KERNEL[234.730555] add /devices/virtual/gpio/gpio3 (gpio)
> UDEV [234.734555] add /devices/virtual/gpio/gpio66 (gpio)
> KERNEL[234.735448] add /devices/virtual/gpio/gpio2 (gpio)
> KERNEL[234.736053] add /devices/virtual/gpio/gpio14 (gpio)
> KERNEL[234.740387] add /devices/virtual/gpio/gpio49 (gpio)
> KERNEL[234.742708] add /devices/virtual/gpio/gpio48 (gpio)
> KERNEL[234.745855] add /devices/virtual/gpio/gpio5 (gpio)
> KERNEL[234.747779] add /devices/virtual/gpio/gpio47 (gpio)
> KERNEL[234.749568] add /devices/virtual/gpio/gpio46 (gpio)
> UDEV [234.754613] add /devices/ocp.3/48302000.epwmss (platform)
> KERNEL[234.755480] add /devices/virtual/gpio/gpio4 (gpio)
> KERNEL[234.757651] add /devices/virtual/gpio/gpio45 (gpio)
> KERNEL[234.758676] add /devices/virtual/gpio/gpio44 (gpio)
> UDEV [234.783503] add /devices/ocp.3/48302000.epwmss/48302200.ehrpwm (platform)
> UDEV [234.792621] add /devices/ocp.3/48302000.epwmss/48302200.ehrpwm/pwm/pwmchip0 (pwm)
> UDEV [234.797529] add /devices/ocp.3/bebopr_pwm_J2_pinmux.16 (platform)
> UDEV [234.801592] add /devices/ocp.3/bebopr_pwm_J3_pinmux.17 (platform)
> KERNEL[234.805028] add /devices/ocp.3/4a300000.pruss (platform)
> KERNEL[234.807047] add /devices/ocp.3/bebopr_sensors.23 (platform)
> KERNEL[234.815264] add /devices/virtual/gpio/gpio65 (gpio)
> KERNEL[234.818562] add /devices/virtual/gpio/gpio27 (gpio)
> KERNEL[234.822912] add /devices/virtual/gpio/gpio26 (gpio)
> KERNEL[234.823881] add /devices/virtual/gpio/gpio68 (gpio)
> KERNEL[234.828324] add /devices/virtual/gpio/gpio69 (gpio)
> KERNEL[234.830614] add /devices/virtual/gpio/gpio67 (gpio)
> KERNEL[234.838312] add /devices/ocp.3/44e0d000.tscadc (platform)
> KERNEL[234.841125] add /devices/ocp.3/44e0d000.tscadc/tiadc (platform)
> UDEV [234.843937] add /devices/ocp.3/48304000.epwmss (platform)
> KERNEL[234.848144] add /devices/ocp.3/44e0d000.tscadc/tiadc/iio:device0 (iio)
> KERNEL[234.849213] add /devices/ocp.3/bebopr_adc.24 (platform)
> KERNEL[234.851235] add /devices/ocp.3/bebopr_leds.25 (platform)
> KERNEL[234.856414] add /devices/ocp.3/bebopr_leds.25/leds/bebopr:status_led (leds)
> KERNEL[234.858903] change /devices/ocp.3/bebopr_leds.25/leds/bebopr:status_led (leds)
> KERNEL[234.887084] add /module/pwm_test (module)
> KERNEL[234.906719] add /bus/platform/drivers/pwm_test (drivers)
> UDEV [234.910018] add /devices/ocp.3/bebopr_pwm_J4_pinmux.18 (platform)
> UDEV [234.912008] add /devices/ocp.3/bebopr_pwm_J4.21 (platform)
> UDEV [234.914890] add /devices/ocp.3/bebopr_pwm_J3.20 (platform)
> UDEV [234.916336] add /devices/ocp.3/bebopr_pwm_J2.19 (platform)
> UDEV [234.925208] add /devices/virtual/gpio/gpio15 (gpio)
> UDEV [234.926982] add /devices/ocp.3/48304000.epwmss/48304200.ehrpwm (platform)
> UDEV [234.933246] add /devices/virtual/gpio/gpio3 (gpio)
> UDEV [234.937622] add /devices/virtual/gpio/gpio2 (gpio)
> UDEV [234.941306] add /devices/ocp.3/48304000.epwmss/48304200.ehrpwm/pwm/pwmchip2 (pwm)
> UDEV [234.960539] add /devices/virtual/gpio/gpio14 (gpio)
> UDEV [234.971947] add /devices/ocp.3/bebopr_steppers.22 (platform)
> UDEV [234.983079] add /devices/virtual/gpio/gpio49 (gpio)
> UDEV [235.001224] add /devices/virtual/gpio/gpio5 (gpio)
> UDEV [235.013049] add /devices/virtual/gpio/gpio48 (gpio)
> UDEV [235.021706] add /devices/virtual/gpio/gpio46 (gpio)
> UDEV [235.028745] add /devices/virtual/gpio/gpio47 (gpio)
> UDEV [235.037010] add /devices/virtual/gpio/gpio4 (gpio)
> UDEV [235.054443] add /devices/virtual/gpio/gpio45 (gpio)
> UDEV [235.063501] add /devices/virtual/gpio/gpio44 (gpio)
> UDEV [235.095346] add /devices/virtual/gpio/gpio65 (gpio)
> UDEV [235.109342] add /devices/ocp.3/bebopr_sensors.23 (platform)
> UDEV [235.135248] add /devices/virtual/gpio/gpio27 (gpio)
> KERNEL[235.138455] add /module/uio_pruss (module)
> UDEV [235.148432] add /devices/virtual/gpio/gpio68 (gpio)
> UDEV [235.156159] add /devices/virtual/gpio/gpio26 (gpio)
> KERNEL[235.170440] add /devices/ocp.3/4a300000.pruss/uio/uio0 (uio)
> UDEV [235.177086] add /devices/virtual/gpio/gpio67 (gpio)
> UDEV [235.183013] add /devices/virtual/gpio/gpio69 (gpio)
> KERNEL[235.189895] add /devices/ocp.3/4a300000.pruss/uio/uio1 (uio)
> KERNEL[235.191544] add /devices/ocp.3/4a300000.pruss/uio/uio2 (uio)
> UDEV [235.208246] add /devices/ocp.3/bebopr_adc.24 (platform)
> KERNEL[235.221280] add /devices/ocp.3/4a300000.pruss/uio/uio3 (uio)
> KERNEL[235.229149] add /devices/ocp.3/4a300000.pruss/uio/uio4 (uio)
> KERNEL[235.232855] add /devices/ocp.3/4a300000.pruss/uio/uio5 (uio)
> UDEV [235.253074] add /devices/ocp.3/bebopr_leds.25 (platform)
> KERNEL[235.265159] add /devices/ocp.3/4a300000.pruss/uio/uio6 (uio)
> KERNEL[235.269976] add /devices/ocp.3/4a300000.pruss/uio/uio7 (uio)
> UDEV [235.273659] add /module/pwm_test (module)
> KERNEL[235.278319] add /bus/platform/drivers/pruss_uio (drivers)
> UDEV [235.282275] add /devices/ocp.3/4a300000.pruss (platform)
> UDEV [235.285810] add /devices/ocp.3/44e0d000.tscadc (platform)
> UDEV [235.291244] add /devices/ocp.3/bebopr_leds.25/leds/bebopr:status_led (leds)
> UDEV [235.298998] add /devices/ocp.3/44e0d000.tscadc/tiadc (platform)
> UDEV [235.307871] add /bus/platform/drivers/pwm_test (drivers)
> UDEV [235.310061] add /module/uio_pruss (module)
> UDEV [235.336663] change /devices/ocp.3/bebopr_leds.25/leds/bebopr:status_led (leds)
> UDEV [235.346447] add /devices/ocp.3/44e0d000.tscadc/tiadc/iio:device0 (iio)
> UDEV [235.501150] add /bus/platform/drivers/pruss_uio (drivers)
--
Charles Steinkuehler
cha...@steinkuehler.net
William Hermans
Apr 10, 2016, 4:51:54 PM4/10/16
to beagl...@googlegroups.com
Any hints as to how to debug would be very welcome!
I wonder if running strace, and piping stdout to a file would provide any useful information on the subject. I'm pretty sure this would have to be run explicitly as root( not sudo ).
--
Charles Steinkuehler
cha...@steinkuehler.net
--
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...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
William Hermans
Apr 10, 2016, 5:10:20 PM4/10/16
to beagl...@googlegroups.com
I wonder if running strace, and piping stdout to a file would provide any useful information on the subject. I'm pretty sure this would have to be run explicitly as root( not sudo ).
Not really useful in the least . . .
Charles Steinkuehler
Apr 21, 2016, 8:26:07 PM4/21/16
to beagl...@googlegroups.com
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
> 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!
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?
--
Charles Steinkuehler
cha...@steinkuehler.net
Robert Nelson
Apr 21, 2016, 8:33:06 PM4/21/16
to Beagle Board
and of course, i never added who pinged me on this, when i pushed the change...
Regards,
Robert Nelson
https://rcn-ee.com/
https://rcn-ee.com/
Charles Steinkuehler
Apr 21, 2016, 8:41:48 PM4/21/16
to beagl...@googlegroups.com
created, they apparently just don't get symlinked to wherever it is
the first line in the uio.rules file is trying to put them.
Any ideas what this was all about?
Is it OK to just comment out the SYMLINK line?
--
Charles Steinkuehler
cha...@steinkuehler.net
Charles Steinkuehler
Apr 21, 2016, 10:02:23 PM4/21/16
to beagl...@googlegroups.com, Michael Haberler
trying to load a uio driver (like the PRU driver), everything works
fine. Interestingly, there are *NO* symlinks actually generated in
the /dev/uio directory, but the simple fact that it exists seems to be
enough to keep the systemd-udevd processes from chewing up tons of CPU
until they get killed.
So the solution seems to be one of:
* Create a /dev/uio directory
* Remove the SYMLINK line from /etc/udev/uio.rules
I'm not enough of a udev guru to know which is the better option, but
removing or commenting the SYMLINK line in uio.rules seems like the
better choice, since there aren't any symlinks generated anyway.
--
Charles Steinkuehler
cha...@steinkuehler.net
William Hermans
Apr 21, 2016, 10:07:34 PM4/21/16
to beagl...@googlegroups.com
After further testing, if you create a /dev/uio directory before
trying to load a uio driver (like the PRU driver), everything works
fine. Interestingly, there are *NO* symlinks actually generated in
the /dev/uio directory, but the simple fact that it exists seems to be
enough to keep the systemd-udevd processes from chewing up tons of CPU
until they get killed.
So the solution seems to be one of:
* Create a /dev/uio directory
* Remove the SYMLINK line from /etc/udev/uio.rules
I'm not enough of a udev guru to know which is the better option, but
removing or commenting the SYMLINK line in uio.rules seems like the
better choice, since there aren't any symlinks generated anyway.
I'm not an expert Charles, but I think the symlink should be removed from the udev rules file, and when various drivers that require uio are installed via *however* the "vendor" needs to include their own *.rules file. That's how it's done already in many cases.
As creating a directory structure in the /dev/ directory tree probably is not a good idea if it never gets used, or even just isn't installed. Because it could be a potential cause of confusion.
--
Charles Steinkuehler
cha...@steinkuehler.net
--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/57198616.6050505%40steinkuehler.net.
Robert Nelson
Apr 21, 2016, 10:38:19 PM4/21/16
to Beagle Board, Michael Haberler
Does the uio_pruss still work if we just nuke that whole udev rule??
Regards,
Charles Steinkuehler
Apr 21, 2016, 10:43:47 PM4/21/16
to beagl...@googlegroups.com
On 4/21/2016 9:37 PM, Robert Nelson wrote:
>
> Does the uio_pruss still work if we just nuke that whole udev rule??
Testing....
>
> Does the uio_pruss still work if we just nuke that whole udev rule??
--
Charles Steinkuehler
cha...@steinkuehler.net
William Hermans
Apr 21, 2016, 11:04:01 PM4/21/16
to beagl...@googlegroups.com
Robert, Charles,
One thing that confused me, was why does the uio_pruss driver add 8 mmap() file objects in that /dev/uio directory structure. They all point to the same address in memory it seems too. --
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/57198FD7.1040804%40steinkuehler.net.
Charles Steinkuehler
Apr 21, 2016, 11:04:39 PM4/21/16
to beagl...@googlegroups.com
On 4/21/2016 9:43 PM, Charles Steinkuehler wrote:
> On 4/21/2016 9:37 PM, Robert Nelson wrote:
>>
>> Does the uio_pruss still work if we just nuke that whole udev rule??
>
> Testing....
Commenting the first line (with SYMLINK+=):
> On 4/21/2016 9:37 PM, Robert Nelson wrote:
>>
>> Does the uio_pruss still work if we just nuke that whole udev rule??
>
> Testing....
==========
No excessive CPU usage when loading a PRU device-tree overlay.
Commenting both lines (same as not having a uio.rules file):
==========
No excessive CPU usage when loading a PRU device-tree overlay
/dev/uio* permissions change from 0660 to 0600
In both instances, I can use the PRU as expected (Machinekit loads and
moves motors).
I would recommend leaving the permissions rule (the second line) but
comment out the first line (the SYMLINK+ line). Honestly, IMHO there
should be a udev rule that creates a device node that has "pru" or
"pruss" in it somewhere, but since that's not how it was done
previously... ;-)
--
Charles Steinkuehler
cha...@steinkuehler.net
Robert Nelson
Apr 21, 2016, 11:26:41 PM4/21/16
to Beagle Board
On Thu, Apr 21, 2016 at 10:04 PM, Charles Steinkuehler <cha...@steinkuehler.net> wrote:
On 4/21/2016 9:43 PM, Charles Steinkuehler wrote:
> On 4/21/2016 9:37 PM, Robert Nelson wrote:
>>
>> Does the uio_pruss still work if we just nuke that whole udev rule??
>
> Testing....
Thanks for testing Charles!
Commenting the first line (with SYMLINK+=):
==========
No excessive CPU usage when loading a PRU device-tree overlay.
Commenting both lines (same as not having a uio.rules file):
==========
No excessive CPU usage when loading a PRU device-tree overlay
/dev/uio* permissions change from 0660 to 0600
In both instances, I can use the PRU as expected (Machinekit loads and
moves motors).
I would recommend leaving the permissions rule (the second line) but
comment out the first line (the SYMLINK+ line). Honestly, IMHO there
should be a udev rule that creates a device node that has "pru" or
"pruss" in it somewhere, but since that's not how it was done
previously... ;-)
I'll push the first line commenting change..
Regards,
William Hermans
Apr 22, 2016, 12:05:40 AM4/22/16
to beagl...@googlegroups.com
@Robert,
I think I found the answer to your question. From a text file based on something another person on these forums was discussing with me . . .# put in /etc/modprobe.d/uio.conf
#
# make driver match on compatible = "uio";
options uio_pdrv_genirq of_id=uio
# put in /etc/udev/rules.d/uio.rules
#
# create named symlink to locate the device easily
# (assumes your kernel is new enough to have of_node symlinks in sysfs)
SUBSYSTEM=="uio", SYMLINK+="uio/%s{device/of_node/uio-alias}"
#
# give some group access rights (adjust as needed)
# give some group access rights (adjust as needed)
SUBSYSTEM=="uio", GROUP="users", MODE="0660"
So this was in relation to setting up a UIO ADC driver, and was pasted by this same person as something for me to experiment with. Anyway this file I have was created 11-19-2015, which is a pretty good indication of the date when the discussion took place.
--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAOCHtYgo--FX%3DLHYob143%2BPvEHw9mid9P3zskQm1qpbAsF_4Gw%40mail.gmail.com.
William Hermans
Apr 22, 2016, 12:09:07 AM4/22/16
to beagl...@googlegroups.com
Anyway, if you have a device tree "compatible=uio" definition for any node in any device tree. It seems that udev rule will hammer the crap out of the system until the udev rule can actually do what it wants to.
William Hermans
Apr 22, 2016, 12:25:49 AM4/22/16
to beagl...@googlegroups.com
Also oddly enough, that method for loading an uio driver, at least the demonstration uio driver for ADC is broken. Exact step instructions I've created and tested personally no longer work. At least on my BBB with . . .
william@beaglebone:~$ uname -r
4.4.7-bone-rt-r9
william@beaglebone:~$ cat /etc/dogtag
BeagleBoard.org Debian Image 2015-03-01
william@beaglebone:~$ dtc -v
Version: DTC 1.4.1-g1e75ebc9
So it would seems that udev rule is no longer needed anyway . .
william@beaglebone:~$ uname -r
4.4.7-bone-rt-r9
william@beaglebone:~$ cat /etc/dogtag
BeagleBoard.org Debian Image 2015-03-01
william@beaglebone:~$ dtc -v
Version: DTC 1.4.1-g1e75ebc9
So it would seems that udev rule is no longer needed anyway . .
Reply all
Reply to author
Forward
0 new messages