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 分区未通过 SDK 9.3 上的 USB 集线器安装

Guru**** 2416110 points


请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1521245/am4372-usb-partitions-not-mounting-thru-usb-hub-on-sdk-9-3

部件号:AM4372

工具/软件:

您好:

将基于 AM437x 的工程从 SDK 8.x 迁移到最新的 SDK 9.3 后、我遇到了问题。

插入带分区的 USB 驱动器时 系统 进入 am437 系统的 USB 端口时、现有udev规则会被正确触发。 此规则启动一个mount.sh脚本、该脚本可成功装载分区。

但是、在连接时 通过 USB 集线器的同一 USB 驱动器 、行为改变:

  • udev规则仍然正确触发。

  • mount.sh按预期执行。

  • 但在内部mount.shsystemd-mount由于、呼叫失败 依赖关系问题

具体来说、systemd-mount创建一个类似于run-media-sda1.automount的瞬态单元、但此单元报告的故障dev-sda1.device是由于未满足设备相关性(例如,超时或处于非活动状态)。

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'.

似乎失败了、因为 dev-sda1.device 也失败了、这是状态:

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'.

但事情是/dev/sda1 存在,实际上如果我手动运行一个挂载命令(不是 systemd-mount )分区挂载良好,它只是当运行 systemd-mount 通过集线器时,它失败。   

似乎器件节点/dev/sda1最终会出现、但systemd在创建瞬态安装时无法及时满足依赖要求。


这些是 systemd 规则 “automount.rules"的“的内容 、但我认为这基本上是 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"

由于某种原因,我无法附加/etc/udev/scripts/mount.sh 文件,但它是依赖于实际装入到 systemd-mount 二进制调用的 SDK 的默认文件

是否有人遇到此问题或可以建议如何systemd更从容地处理块设备的延迟外观(尤其是通过 USB 集线器)?

提前感谢!

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    大家好、我本周不在办公室。 请期待响应延迟。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Francisco、

    很抱歉耽误你的时间。 问题是否已解决、或者您是否仍需要帮助?

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    大家好!

    我不得不针对 udev 规则触发 mount.sh (内部使用规则触发) systemd-mount由于 /dev/sda1 设备在使用  USB 集线器时未准备就绪而失败的问题实施解决方案。

    我当前的解决方案包括:

    •  udev 启动专用服务的规则usb-sda1.service ()

    • 服务正在等待  1 秒  (以确保器件就绪)

    • 然后使用 mount (而不是)执行安装脚本 systemd-mount、从而忽略 dev-sda1.device 未就绪的情况

    这种方法可靠地工作、尽管它会带来轻微的延迟、并且感觉不如原始方法干净(由于额外的依赖性)。

    如果有人有一个更优雅的解决方案—特别是避免人为延迟的解决方案—我很乐意听到它!

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Francisco、

    感谢您的更新。

    您所描述的可能是我也会采用的解决方案。

    插入带有分区的 USB 驱动器时 系统 进入 am437 系统的 USB 端口时、现有udev规则会被正确触发。 [/报价]

    您是否知道哪个确切的 udev 事件触发了此 udev 规则、是添加了 USB 设备还是添加了/dev/sdx 设备? 如果后者,它不会有这样的/dev/sda1 Not ready 失败,是吗?

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    感谢您的答复。

     udev 规则是通过 /dev/sdx 添加触发的、因此从理论上  讲、我们不应该遇到“未就绪“问题、实际上、当将 USB 驱动器直接插入系统的端口时、此操作是正确的。

    但是、当通过 USB 集线器进行连接时、我们会观察到快速的检测/重新检测周期。 这似乎会使 第一次连接尝试挂起、因为设备短暂出现、但随后变为“未就绪“。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    但是、通过 USB 集线器连接时、我们会观察到快速检测/重新检测周期。 这似乎会使第二次连接尝试挂起、因为设备短暂出现、但随后变为“未就绪“。

    集线器似乎有问题、导致 USB 总线重置。 集线器是自供电还是总线供电? 如果总线供电、自供电集线器是否也会发生总线复位问题? 如果是自供电、您是否尝试过使用不同品牌的集线器来查看问题是否也会发生?

    将基于 AM437x 的工程从 SDK 8.x 迁移到最新的 SDK 9.3 后、我遇到了问题。

    SDK 8.x 是否也会发生总线复位问题?

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    它是一个 USB 供电的集线器,尝试了几个品牌,也报告了不同的用户对不同的设置。  基于 tisdk 8.x 使用上一个图像时、相同的设置也可以正常工作

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    请在黑暗中拍摄、但请 usbcore.autosuspend=–1" 在内“在内核命令行中添加“SDK(通过将其添加到 U-Boot bootargs env)、看看它是否解决了 sdk9.3 上的问题。