• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 98 subscribers
  • Views 182 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.

AM4372: USB partitions not mounting thru USB HUB on SDK 9.3

Francisco Perez Carranza
Prodigy 90 points
Part Number: AM4372

Tool/software:

Hello,

I'm encountering an issue after migrating our AM437x-based project from SDK 8.x to the latest SDK 9.3.

When a USB drive with partitions is inserted directly into the USB port of our am437 system, our existing udev rule is triggered correctly. This rule launches a mount.sh script, which mounts the partitions successfully.

However, when connecting the same USB drive through a USB HUB, the behavior changes:

  • The udev rules still trigger correctly.

  • mount.sh is executed as expected.

  • But inside mount.sh, the call to systemd-mount fails due to a dependency issue.

Specifically, systemd-mount creates a transient unit like run-media-sda1.automount, but this unit reports a failure caused by a device dependency not being fulfilled (e.g., dev-sda1.device timed out or is inactive).

root@am437x-alx:~# systemctl status run-media-sda1.automount
○ run-media-sda1.automount
     Loaded: loaded (/run/systemd/transient/run-media-sda1.automount; transient)
  Transient: yes
     Active: inactive (dead)
   Triggers: ● run-media-sda1.mount
      Where: /run/media/sda1

May 19 21:18:23 am437x-alx systemd[1]: Dependency failed for run-media-sda1.automount.
May 19 21:18:23 am437x-alx systemd[1]: run-media-sda1.automount: Job run-media-sda1.automount/start failed with result 'dependency'.
May 19 21:20:03 am437x-alx systemd[1]: Dependency failed for run-media-sda1.automount.
May 19 21:20:03 am437x-alx systemd[1]: run-media-sda1.automount: Job run-media-sda1.automount/start failed with result 'dependency'.

It seems to fail because dev-sda1.device also failed, and this is the status:

root@am437x-alx:~# systemctl status dev-sda1.device 
○ dev-sda1.device - /dev/sda1
     Loaded: loaded
     Active: inactive (dead)

May 19 21:18:23 am437x-alx systemd[1]: dev-sda1.device: Job dev-sda1.device/start timed out.
May 19 21:18:23 am437x-alx systemd[1]: Timed out waiting for device /dev/sda1.
May 19 21:18:23 am437x-alx systemd[1]: dev-sda1.device: Job dev-sda1.device/start failed with result 'timeout'.
May 19 21:20:03 am437x-alx systemd[1]: dev-sda1.device: Job dev-sda1.device/start timed out.
May 19 21:20:03 am437x-alx systemd[1]: Timed out waiting for device /dev/sda1.
May 19 21:20:03 am437x-alx systemd[1]: dev-sda1.device: Job dev-sda1.device/start failed with result 'timeout'.

But the thing is that /dev/sda1 is present and actually If I manually run a mount command (not systemd-mount) the partition mounts fine, its just when running systemd-mount thru a hub when it fails.  

It seems like the device node /dev/sda1 eventually appears, but not in time for systemd to satisfy the dependency when the transient mount is created.


These are the contents of the systemd rule  "automount.rules"  but I think are pretty much the default that came with the TI sdk

# Media automounting
SUBSYSTEM=="block", ACTION=="add"    RUN+="/etc/udev/scripts/mount.sh"
SUBSYSTEM=="block", ACTION=="remove" RUN+="/etc/udev/scripts/mount.sh"
SUBSYSTEM=="block", ACTION=="change", ENV{DISK_MEDIA_CHANGE}=="1" RUN+="/etc/udev/scripts/mount.sh"

For some reason I cannot attach the /etc/udev/scripts/mount.sh file but its the default that cames with the SDK that rely the actual mount to a systemd-mount binary call

Has anyone encountered this issue or can suggest how to make systemd handle the delayed appearance of block devices more gracefully (especially via USB HUBs)?

Thanks in advance!

  • 0
    TI__Guru**** 168261 points

    Hi, I am out of office this week. Please expect delayed response.

  • 0
    TI__Guru**** 168261 points

    Hi Francisco,

    Sorry for the delay. Is the issue resolved or do you still need assistance?

  • +1 in reply to Bin Liu
    Prodigy 90 points

    Hi all,

    I had to implement a workaround for an issue where a udev rule triggering mount.sh (that internally its using systemd-mount) would fail because /dev/sda1 device wasn’t ready when using a USB hub.

    My current solution involves:

    • The udev rule launching a dedicated service (usb-sda1.service)

    • The service waits 1 second (to ensure device readiness)

    • Then executes a mounting script using mount (instead of systemd-mount) and thus ignoring if dev-sda1.device is not ready

    This works reliably, though it introduces a slight delay and feels less clean than the original approach (due to additional dependencies).

    If anyone has a more elegant solution—especially one that avoids the artificial delay—I’d love to hear it!

  • 0 in reply to Francisco Perez Carranza
    TI__Guru**** 168261 points

    Hi Francisco,

    Thanks for the update.

    What you described probably would be the solution that I would take too.

    Francisco Perez Carranza said:
    When a USB drive with partitions is inserted directly into the USB port of our am437 system, our existing udev rule is triggered correctly.

    Do you know which exact udev event triggers this udev rule, is it a usb device added, or /dev/sdx device added? If latter, it won't have such /dev/sda1 not ready failure, does it?

  • 0 in reply to Bin Liu
    Prodigy 90 points

    Thanks for your response.

    The udev rule is triggered by /dev/sdx being added, so in theory, we shouldn’t encounter the "not ready" issue—and indeed, this works correctly when plugging the USB drive directly into the system’s port.

    However, when connecting through a USB hub, we observe a rapid detection/redetection cycle. This seems to leave the first connection attempt hanging, as the device briefly appears but then becomes "not ready."

  • 0 in reply to Francisco Perez Carranza
    TI__Guru**** 168261 points
    Francisco Perez Carranza said:
    However, when connecting through a USB hub, we observe a rapid detection/redetection cycle. This seems to leave the second connection attempt hanging, as the device briefly appears but then becomes "not ready."

    It seems something wrong with the hub which causes the usb bus reset. Is the hub self-powered or bus-powered? If bus-powered, does the bus reset issue also happen with self-powered hub? If self-powered, have you tried with different brands of hubs to see if the issue also happens?

    Francisco Perez Carranza said:
    I'm encountering an issue after migrating our AM437x-based project from SDK 8.x to the latest SDK 9.3.

    Does the bus reset issue happen with SDK 8.x too?

  • 0 in reply to Bin Liu
    Prodigy 90 points

    Its a usb powered hub, tried with a couple of brands and also reported by different users on different setups.  The same setups works fine when used the previous image based on tisdk 8.x

  • 0 in reply to Francisco Perez Carranza
    TI__Guru**** 168261 points

    Shooting in the dark, but please add "usbcore.autosuspend=-1" in the kernel cmdline (by adding it to U-Boot bootargs env) to see if it resolve the issue on sdk9.3.