• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 465 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

PROCESSOR-SDK-AM335X: modprobe failures during boot on built-in drivers

Glen Geisen
Prodigy 130 points
Part Number: PROCESSOR-SDK-AM335X

I am trying to understand/fix several (~30) modprobe failure messages during boot of a custom AM335x board. Currently using SDK 05.00 with Linux kernel 4.10. The syslog messages are all similar to the following. 

# journalctl |grep modprobe
Oct 23 14:26:14 15301634 systemd-udevd[117]: Process '/sbin/modprobe platform:Fixed MDIO bus' failed with exit code 1.
Oct 23 14:26:14 15301634 systemd-udevd[115]: Process '/sbin/modprobe platform:cpufreq-dt' failed with exit code 1.
Oct 23 14:26:14 15301634 systemd-udevd[116]: Process '/sbin/modprobe of:NocpT<NULL>Csimple-bus' failed with exit code 1.
Oct 23 14:26:14 15301634 systemd-udevd[119]: Process '/sbin/modprobe platform:alarmtimer' failed with exit code 1.
Oct 23 14:26:14 15301634 systemd-udevd[116]: Process '/sbin/modprobe of:NgpioT<NULL>Cti,omap4-gpio' failed with exit code 1.
Oct 23 14:26:14 15301634 systemd-udevd[115]: Process '/sbin/modprobe of:NocmcramT<NULL>Cmmio-sram' failed with exit code 1.
Oct 23 14:26:14 15301634 systemd-udevd[119]: Process '/sbin/modprobe of:Ni2cT<NULL>Cti,omap4-i2c' failed with exit code 1.
[...]

Taking the second error message for example. If I check the dependencies of "cpufreq-dt" using `modprobe -D`, it returns "builtin cpufreq-dt". This is correct because the .config file specifies "CONFIG_CPUFREQ_DT=y". So why is the kernel calling modprobe to load the module?

  • 0
    TI__Guru**** 168201 points

    Hi Glen,

    Is your Linux filesystem '/lib/modules/`uname -r`/ in sync with the kernel image?

    does the following command print anything on your board?

    # find /lib/modules/`uname -r`/ -name 'cpufreq-dt.ko'

  • 0 in reply to Bin Liu
    Prodigy 130 points

    Yes they are in sync.`uname -r` yields '4.14.227-g4796173fc5' which matches the directory name in /lib/modules. 

    The above command does not find 'cpufreq-dt.ko' and I wouldn't expect it to because it is built-in. Correct?

  • 0 in reply to Glen Geisen
    TI__Guru**** 168201 points

    Hi Glen,

    I just realized these messages are printed by systemd udevd, not kernel.

    I guess it is due to your Linux system has those udev rules expecting those drivers to be built as module then complains about the modules are not found.

  • 0 in reply to Bin Liu
    Prodigy 130 points

    there are no rules in /usr/lib/udev/rules.d, but a few in /etc/udev/rules.d/. I don't see any rules that enumerate modules, but there is one rule using modprobe  

    # Try and modprobe for drivers for new hardware
ACTION=="add", DEVPATH=="/devices/*", ENV{MODALIAS}=="?*", RUN+="/sbin/modprobe $env{MODALIAS}"
    I commented this out and no longer see the modprobe error messages. I assume it was running modprobe against all the devices in /sys/devices/. I see many of the devices that were modprobe errors in that directory hierarchy, including the example above ''cpufreq-dt'. Are these devices created by the kernel because they are built-in? If yes, why would udev want to modprobe them?

    # ls /sys/devices
armv7_cortex_a8  breakpoint       platform         soc0             software         system           virtual

ls /sys/devices/platform
Fixed MDIO bus.0  cpufreq-dt        opp-table         pmu               reg-dummy         snd-soc-dummy     ti-cpufreq
alarmtimer        ocp               pm33xx            power             serial8250        soc               uevent

    If the hardware configuration does not change, are there any repercussions in commenting this out? 

  • +1 in reply to Glen Geisen
    TI__Guru**** 168201 points

    Hi Glen,

    I never had such issue before, and don't have enough understanding of udev to comment on why this issue happens with this udev rule. Udev is a purly open-source package, it is out of our support scope.

    If you comment this out, and lsmod command still shows all the relevant modules are loaded, then you won't have any issue with commenting out this rule.

    By the way, I just checked the filesystem in SDK8.6, this udev rule is different now:

    # Try and modprobe for drivers for new hardware
ACTION=="add", DEVPATH=="/devices/*", ENV{MODALIAS}=="?*", RUN{builtin}+="kmod load $env{MODALIAS}"