• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 99 subscribers
  • Views 938 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.

Original question:

Linux: how driver modules auto probe

Linux/AM5718: Source of invalid modprobe invocations

David Olson61
Intellectual 350 points

Part Number: AM5718
Other Parts Discussed in Thread: TLV320AIC3104, , AM5728

Tool/software: Linux

Much like the linked question, I'm seeing a vast number of warnings about failed modprobes of built-in modules that shouldn't even be modprobed.  In my application, there are about 150 of these warnings of which the following is just a small selection:

<1c>2019-05-28 17:41:19 systemd-udevd: Process '/sbin/modprobe of:NocpT<NULL>Cti,dra7-l3-nocCsimple-bus' failed with exit code 1.
<1c>2019-05-28 17:41:19 systemd-udevd: Process '/sbin/modprobe of:Ndsp_systemT<NULL>Csyscon' failed with exit code 1.
<1c>2019-05-28 17:41:19 systemd-udevd: Process '/sbin/modprobe of:NocmcramT<NULL>Cmmio-sram' failed with exit code 1.
<1c>2019-05-28 17:41:19 systemd-udevd: Process '/sbin/modprobe of:NmmuT<NULL>Cti,dra7-dsp-iommu' failed with exit code 1.
<1c>2019-05-28 17:41:20 systemd-udevd: Process '/sbin/modprobe i2c:tlv320aic3104' failed with exit code 1.
<1c>2019-05-28 17:41:20 systemd-udevd: Process '/sbin/modprobe i2c:touchpanel' failed with exit code 1.
<1c>2019-05-28 17:41:20 systemd-udevd: Process '/sbin/modprobe i2c:dummy' failed with exit code 1.
<1c>2019-05-28 17:41:20 systemd-udevd: Process '/sbin/modprobe platform:xhci-hcd' failed with exit code 1.
<1c>2019-05-28 17:41:21 systemd-udevd: Process '/sbin/modprobe usb:v1D6Bp0002d0409dc09dsc00dp01ic09isc00ip00in00' failed with exit code 1.

I've show messages for AM5718 elements as well as hardware drivers.  In all cases, the relevant drivers are built-in (it is rarely useful to have loadable kernel modules in an embedded system).

The messages are all classified as warnings and there are no ill-effects other than the massive log pollution.  I'm mostly pursuing this in order to eliminate this "noise" that can obscure genuine issues.  I've made some progress in tracking down the source of this issue but it's slow going so thought I'd reach out for any advice y'all might have.  In particular, I'm trying to find out the source of the list of modules that systemd thinks need to be modprobed.

Unfortunately, the closest relevant TI evaluation board only supports the AM5728 and since our code vitally depends on functionality that isn't pinned out on that SoC variant, our code cannot run on any TI evaluation board.  Accordingly I don't know if this issue is reproducible on a TI board.

  • 0
    TI__Mastermind 30816 points
    David,

    I wanted to make sure you found this post:

    e2e.ti.com/.../762861

    where some very similar issues seemed to have been resolved with defconfig changes. Maybe it will be helpful to you.

    If not, could you please describe a little more how you build your system? How do you generate the filesystem?

    Thanks.
  • 0 in reply to RonB
    Intellectual 350 points

    Indeed I had seen that post and the mention of defconfig changes however there were no details describing those changes.  In any case, the vast majority of those problematic modprobes are related to TI provided drivers and configuration files that we have not touched.  For example, here's a snippet from the TI provided arch/arm/boot/dts/dra7.dtsi related to the first of the modprobe fail messages I listed:

        ocp {
            compatible = "ti,dra7-l3-noc", "simple-bus";
            #address-cells = <1>;
            #size-cells = <1>;
            ranges = <0x0 0x0 0x0 0xc0000000>;
            ti,hwmods = "l3_main_1", "l3_main_2";
            reg = <0x0 0x44000000 0x0 0x1000000>,
                  <0x0 0x45000000 0x0 0x1000>;
            interrupts-extended = <&crossbar_mpu GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>,
                          <&wakeupgen GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;

    If that configuration is in error, I certainly don't see it.

    The basic build is essentially the Yocto/bitbake setup provided by TI for the AM5728 Evaluation Module.  We've made changes necessary to incorporate our own application, add custom hardware drivers, and remove support for evaluation module hardware that doesn't exist on our board.  If there's a build issue, there are at least 3 folks that ran into the same issue (the originally linked post, the post you pointed out, and our own build).

    Note that I'm willing to chase this on my own.  What I'm looking for are "sign posts".  For example, somewhere

    compatible = "ti,dra7-l3-noc", "simple-bus";

    got turned into

    of:NocpT<NULL>Cti,dra7-l3-nocCsimple-bus'

    and added to a list that was eventually handed to modprobe.  Perhaps if I could find the code that added that 'N', 'T', '<NULL>', and 'C', I could make some progress.

  • 0 in reply to David Olson61
    TI__Mastermind 30816 points
    Take a look at drivers/of/device.c and checkout the of_device_get_modalias() function. Hopefully that will provide some insight into what you are seeing and aid your hunting.

    Hope this is helpful to you.
  • 0 in reply to RonB
    Intellectual 350 points

    Thanks for this hint.  It is definitely helping me dive deeper.

    I shall, of course, update this post with any results that I find.