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.
工具与软件:
您好!
我们将使用 SDK 10.00.08内核 ti-linux-6.6.6.y、并且对于此版本、在启动期间、如果连接到 NVMe PCIe 设备、我们会出现内核严重错误。
使用旧版 SDK 09.02.00.010内核 ti-linux-6.1.y 可以正常运行。
如果我们插入不同的电路板(PCIe 转 USB 3.0适配器)、则同一个 PCIe 插槽可以正常工作。
我检查了内核配置和设备树、它们看起来是正确的。
内核紧急情况由 NVME_PCI_ENABLE 函数在以下指令中触发:
if (readl(dev->bar + NVME_REG_CSTS) == -1) {
下面是内核恐慌的节选:
[ 5.998134] j721e-pcie 2900000.pcie: PCI host bridge to bus 0000:00 [ 6.004436] pci_bus 0000:00: root bus resource [bus 00-ff] [ 6.009942] pci_bus 0000:00: root bus resource [io 0x0000-0xffff] (bus address [0x10001000-0x10010fff]) [ 6.019437] pci_bus 0000:00: root bus resource [mem 0x10011000-0x17ffffff] [ 6.026359] pci 0000:00:00.0: [104c:b012] type 01 class 0x060400 [ 6.032370] pci_bus 0000:00: 2-byte config write to 0000:00:00.0 offset 0x4 may corrupt adjacent RW1C bits [ 6.042151] pci 0000:00:00.0: supports D1 [ 6.046156] pci 0000:00:00.0: PME# supported from D0 D1 D3hot [ 6.051930] pci 0000:00:00.0: reg 0x224: [mem 0x00000000-0x003fffff 64bit] [ 6.058802] pci 0000:00:00.0: VF(n) BAR0 space: [mem 0x00000000-0x00ffffff 64bit] (contains BAR0 for 4 VFs) [ 6.070865] pci 0000:00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring [ 6.079034] pci 0000:01:00.0: [144d:a808] type 00 class 0x010802 [ 6.085091] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x00003fff 64bit] [ 6.092385] pci 0000:01:00.0: 15.752 Gb/s available PCIe bandwidth, limited by 8.0 GT/s PCIe x2 link at 0000:00:00.0 (capable of 31.504 Gb/s with 8.0 GT/s PCIe x4 link) [ 6.123674] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01 [ 6.130306] pci 0000:00:00.0: BAR 7: assigned [mem 0x10400000-0x113fffff 64bit] [ 6.137635] pci 0000:00:00.0: BAR 14: assigned [mem 0x10100000-0x101fffff] [ 6.144514] pci 0000:01:00.0: BAR 0: assigned [mem 0x10100000-0x10103fff 64bit] [ 6.151851] pci 0000:00:00.0: PCI bridge to [bus 01] [ 6.162334] pci 0000:00:00.0: bridge window [mem 0x10100000-0x101fffff] [ 6.169411] pcieport 0000:00:00.0: of_irq_parse_pci: failed with rc=-22 [ 6.176042] pcieport 0000:00:00.0: enabling device (0000 -> 0002) [ 6.182469] pcieport 0000:00:00.0: PME: Signaling with IRQ 617 [ 6.188592] pcieport 0000:00:00.0: AER: enabled with IRQ 617 [ 6.194688] pcieport 0000:00:00.0: of_irq_parse_pci: failed with rc=-22 [ 6.201879] nvme nvme0: pci function 0000:01:00.0 [ 6.206701] nvme 0000:01:00.0: enabling device (0000 -> 0002) [ OK ] Created slice Slice /system/systemd[ 6.215812] SError Interrupt on CPU7, code 0x00000000bf000000 -- SError [ 6.215818] CPU: 7 PID: 64 Comm: kworker/u16:3 Not tainted 6.6.32-01373-gda8dd76693a4-dirty #35 [ 6.215823] Hardware name: Toradex Aquila AM69 on Aquila Development Board (DT) [ 6.215826] Workqueue: events_unbound deferred_probe_work_func [ 6.215841] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 6.215845] pc : nvme_pci_enable+0x5c/0x524 [ 6.215856] lr : nvme_pci_enable+0x50/0x524 [ 6.215859] sp : ffffffc0824737e0 [ 6.215861] x29: ffffffc0824737e0 x28: 0000000000000000 x27: ffffffc081106000 [ 6.215866] x26: ffffff8800283100 x25: ffffff8800c5b800 x24: 000000000000ffff [ 6.215870] x23: ffffff88020f71f0 x22: ffffff880102a000 x21: ffffff880102a000 [ 6.215875] x20: ffffff880102a0c0 x19: ffffff88020f7000 x18: ffffffffffffffff [ 6.215879] x17: 0000000000000000 x16: 0000000000000000 x15: 0720072007200720 [ 6.215883] x14: 0720072007200720 x13: ffffffc08111ad70 x12: 0000000000000621 [ 6.215887] x11: 000000000000020b x10: ffffffc081172d70 x9 : ffffffc08111ad70 [ 6.215891] x8 : 00000000ffffefff x7 : ffffffc081172d70 x6 : 0000000000000000 [ 6.215895] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 6.215899] x2 : 0000000000000000 x1 : ffffff8800ff8000 x0 : 0000000000000000 [ 6.215905] Kernel panic - not syncing: Asynchronous SError Interrupt [ 6.215908] CPU: 7 PID: 64 Comm: kworker/u16:3 Not tainted 6.6.32-01373-gda8dd76693a4-dirty #35 [ 6.215911] Hardware name: Toradex Aquila AM69 on Aquila Development Board (DT) [ 6.215912] Workqueue: events_unbound deferred_probe_work_func [ 6.215916] Call trace: [ 6.215919] dump_backtrace+0x94/0x114 [ 6.215928] show_stack+0x18/0x24 [ 6.215932] dump_stack_lvl+0x48/0x60 [ 6.215937] dump_stack+0x18/0x24 [ 6.215939] panic+0x314/0x364 [ 6.215945] nmi_panic+0x8c/0x90 [ 6.215949] arm64_serror_panic+0x6c/0x78 [ 6.215951] do_serror+0x3c/0x78 [ 6.215953] el1h_64_error_handler+0x30/0x48 [ 6.215957] el1h_64_error+0x64/0x68 [ 6.215960] nvme_pci_enable+0x5c/0x524 [ 6.215963] nvme_probe+0x280/0x6f8 [ 6.215966] pci_device_probe+0xa8/0x16c [ 6.215971] really_probe+0x184/0x3c8 [ 6.215975] __driver_probe_device+0x7c/0x16c [ 6.215978] driver_probe_device+0x3c/0x10c [ 6.215981] __device_attach_driver+0xbc/0x158 [ 6.215984] bus_for_each_drv+0x80/0xdc [ 6.215990] __device_attach+0xa8/0x1d4 [ 6.215993] device_attach+0x14/0x20 [ 6.215996] pci_bus_add_device+0x64/0xd4 [ 6.216002] pci_bus_add_devices+0x3c/0x88 [ 6.216006] pci_bus_add_devices+0x68/0x88 [ 6.216010] pci_host_probe+0x44/0xbc [ 6.216015] cdns_pcie_host_setup+0x10c/0x1c8 [ 6.216020] j721e_pcie_probe+0x3cc/0x444 [ 6.216024] platform_probe+0x68/0xdc [ 6.216027] really_probe+0x184/0x3c8 [ 6.216030] __driver_probe_device+0x7c/0x16c [ 6.216032] driver_probe_device+0x3c/0x10c [ 6.216035] __device_attach_driver+0xbc/0x158 [ 6.216037] bus_for_each_drv+0x80/0xdc [ 6.216042] __device_attach+0xa8/0x1d4 [ 6.216044] device_initial_probe+0x14/0x20 [ 6.216047] bus_probe_device+0xac/0xb0 [ 6.216052] deferred_probe_work_func+0x9c/0xec [ 6.216054] process_one_work+0x138/0x260 [ 6.216061] worker_thread+0x32c/0x438 [ 6.216065] kthread+0x118/0x11c [ 6.216070] ret_from_fork+0x10/0x20 [ 6.216074] SMP: stopping secondary CPUs [ 6.216084] Kernel Offset: disabled [ 6.216086] CPU features: 0x0,80000000,28020000,1000420b [ 6.216089] Memory Limit: none [ 6.539032] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]---
我尝试使用此补丁而不做任何更改: lore.kernel.org/.../
"你说什么? 您是否遇到同样的行为?
Emanuele
尊敬的 Emanuele:
我刚才试用了针对 SK-AM69板的 SDK 10.0、无法重现该问题。 我在这里使用了预编译的 edgeai 映像10.0: https://www.ti.com/tool/download/PROCESSOR-SDK-LINUX - AM69A。
至于差异、我使用的是不同的 SSD 卡、即"Kingston TC2200"和"SanDisk Corp WD Black SN770"。 我需要搜索 Samsung SSD 卡来复制确切的设置。
在下面附加我看到的日志:
root@am69-sk:/opt/edgeai-gst-apps# uname -a Linux am69-sk 6.6.32-ti-gdb8871293143-dirty #1 SMP PREEMPT Thu Aug 1 19:10:56 UTC 2024 aarch64 GNU/Linux root@am69-sk:/opt/edgeai-gst-apps# lspci 0000:00:00.0 PCI bridge: Texas Instruments Device b012 0000:01:00.0 Non-Volatile memory controller: Kingston Technology Company, Inc. NV2 NVMe SSD TC2200 (DRAM-less) 0001:00:00.0 PCI bridge: Texas Instruments Device b012 0001:01:00.0 Non-Volatile memory controller: Sandisk Corp WD Black SN770 / PC SN740 256GB / PC SN560 (DRAM-less) NVMe SSD (rev 01) 0002:00:00.0 PCI bridge: Texas Instruments Device b012 root@am69-sk:/opt/edgeai-gst-apps#
在您的终端、您是否可以尝试另一个 SSD 卡以查看是否出现相同问题? 最好是,如果您可以尝试从不同的供应商的 SSD 卡,以验证所有 SSD 卡在您的系统上出现故障,如果您可以另外尝试三星970 SSD 卡的不同实例,以验证它是否是您测试过的单个 SSD 的问题。
此致、
Takuma
尊敬的 Emanuele:
我目前不在办公室,但我可以在星期三用 dmesg 输出与你联系。
此致、
Takuma
尊敬的 Emanuele:
下面随附了我的 引导日志。 由于我对 MCAN 进行了不同的调试、Linux 的提交 ID 可能已经发生变化、但关于 PCIe 接口应该没有变化。
e2e.ti.com/.../10_5F00_0_5F00_am69_5F00_dmesg.txt
请随意使用它与您的 dmesg 日志进行比较。
此致、
Takuma
尊敬的 Emanuele:
我能够获得三星 NVMe PCIe 卡。 我能得到的最接近的是三星970 PRO 卡,到目前为止我不能重现问题:
e2e.ti.com/.../10_5F00_0_5F00_0_5F00_8_5F00_samsung970PRO_5F00_dmesg.txt
您拥有的 Samsung 970 EVO 和 PCIe 卡的特定实例可能存在一些问题。 作为一种解决方法、您可以在不同的 NVMe PCIe 卡上继续开发吗?
此致、
Takuma
尊敬的 藤原琢磨:
感谢您的支持。
请允许我在此提供有关该问题的背景。 我们有来自 AM69 SERDES1的三个接口 PCIE0 (2通道)、PCIe2 (1通道)和 QSGMII_LANe2。 由于默认 SW 配置不允许来自单个 SERDES1的三个接口、因此我们在下游分支中提供了以下补丁、以确保按照 TI 的建议、在不使用 SSC 的情况下 PCIe 多链路工作。
此补丁以及我们的 DT 似乎在 ti-linux-6.1.y 上与 Samsung 970 EVO + PCIe (连接在 AM69 PCIE0、2个通道上)一起正常运行、并在我们更新到 ti-linux-6.6.6.6.y 时引起内核严重错误(如此处报告的)。
您能否从终端处检查是否需要修改给定的补丁和/或任何其他配置以便在 ti-linux-6.6.6.y 上支持 PCIe 多链接?
感谢您的支持。
此致、
Parth P
尊敬的 PARTH:
感谢您的讲解。 如果出现这种情况、我认为我们应该查看设备树以及修补的驱动程序。
您是否可以共享 四个文件:
此致、
Takuma
请根据您的请求找到以下文件以供您参考。
如果您需要更多信息、请告诉我。 感谢您的支持。
此致、
Parth P
尊敬的 PARTH:
需要说明的是、插入 SSD 卡时、具有2个 PCIe 和1个 USB 的 SERDES0没有问题? 只有连接到2个 PCIe 和1个 SGMII 的 SERDES1出现问题、并且只有三星 NVMe SSD 卡出现问题、而没有任何其他 PCIe 卡出现问题?
到目前为止、我在设备树中没有看到任何不正确的内容。 修补的种子驱动程序我需要一些时间来审查。
但是、我确实看到有一件事与我的工作设置与您的引导日志不同。 PCIe 控制器启动后、看起来很快就会探测到 NVMe 设备。
您能否在此处尝试一下该补丁、该补丁会增加将 PCIe 复位置为无效的延迟: https://lore.kernel.org/lkml/20230707095119.447952-1-a-verma1@ti.com/
此致、
Takuma
尊敬的 藤原琢磨:
感谢您在此问题上提供帮助。 目前、通过内核配置中的以下更改、我们已解决上述 PCIe NVMe SSD 崩溃问题。
-CONFIG_PHY_CADENCE_TORRENT=m +CONFIG_PHY_CADENCE_TORRENT=y -CONFIG_PHY_J721E_WIZ=m +CONFIG_PHY_J721E_WIZ=y
您能否告诉我、您是否知道为什么将这些节奏 Torrent PHY 和 J721e wiz 驱动程序设置为模块不能按给定用例的预期工作? 这是某些限制还是已知问题?
此致、
Parth P
尊敬的 PARTH:
指定的工程师当天不在办公室。 请预计响应会有延迟。
谢谢!
Fabiana
尊敬的 PARTH:
问题很可能出在初始化 SERDES 驱动程序的时间安排(Torrent 是 SERDES IP 的名称、而 wiz 是此 SERDES IP 的包装程序)。 通过将"m"设置为"y"、它会将 SERDES 驱动程序构建到内核中、而不是构建可加载的内核模块、从而使这些驱动程序能够快速进行探测。 我认为这是解决这个时序问题的有效方法。
如我之前的回复中所述、与来自默认 TI EVM 板上默认 TI SDK 的启动日志相比、我在您的共享启动日志中很早就发现了 NVMe 驱动程序。 就相关性而言、相关性就像 NVMe 依赖于-> PCIe 依赖于-> SERDES 一样。 因此、默认的 TI SDK 很可能具有一些额外的驱动程序和模块、这会延迟 NVMe 驱动程序的实际探测、从而使问题未出现。
此致、
Takuma
尊敬的 藤原琢磨:
感谢您对此问题的支持。 我想报告的是、我们没有完全解决提到的 PCIe NVMe 崩溃问题。 我在之前的回复中提到的解决方案与内核配置相关、即具有静态驱动程序而不是模块驱动程序、这有助于一点上的改善、并且未能以永久方式完全解决问题。
我们仍然可以看到、当显示器连接到设备时、PCIe NVMe 与 AM69上最新的 TI 10.x SDK 组件以系统方式崩溃。 我知道、DisplayPort 在这里对 PCIe 没有任何作用、除了它可能影响探测序列并导致某种竞 态条件、从而导致内核恐慌这一事实。
完整日志: /cfs-file/__key/communityserver-discussions-components-files/791/dmesg_2D00_nvme_2B00_dp_2D00_panic.txt
我亦尝试了以下建议、但该建议对改善情况并无帮助。
您能否在此处试用此补丁来增加将 PCIe 复位置为无效的延迟: https://lore.kernel.org/lkml/20230707095119.447952-1-a-verma1@ti.com/
您能否看看这个问题并告诉我可以做些什么来永久修复提到的 PCIe NVMe 内核恐慌?
谢谢你。
此致、
Parth P
尊敬的 PARTH:
我一直无法在 我们的 最后重现这一问题 到目前为止、使用 TI EVM 和 TI 默认10.0 SDK 映像时、评估板成功启动且 PCIe 在没有任何崩溃的情况下进行枚举的时间为100%、有无显示、这对于我可以获取的所有 NVMe SSD 卡都是如此。
我只能说、该问题可能与硬件相关、如果连接显示器导致问题、则与信号完整性或电源有关、或者您的特定 PCIe NVMe 卡示例有问题、或者如您所说、与如何探测驱动程序的计时有关。 但是、我确实看到、在最新日志中、PCIe 端口初始化后、NVMe 会在较晚的时间出现。
如果您有 TI EVM、请在 TI EVM 上尝试使用它、以重新确认我在我们的电路板上看到的内容。 我的理解是正确的、如果没有显示器、不会发生内核严重情况、PCIe 会正确进行枚举吗?
此致、
Takuma
藤原琢磨
对我来说,这似乎只是一个但触发了一些时间情况(例如一个竞争条件)。 仅仅尝试查看一个事实、即您无法使用 EVM 再现它是不够的 IMO。 不同的电路板可能会以不同的顺序探测不同的驱动器、并具有不同的执行时间。
将驱动器从`m`Ω 移动到`Ω y`Ω(从模块移动到内置)产生了很大的影响、以至于我们认为问题已得到解决、对我来说、这仅仅是一个计时问题的提示。
我还想再次重申、使用基于 TI 内核6.1的先前 SDK、这个问题不可重现、并且这与您关于这个问题是硬件问题的假设不一致。
如果您查看日志、在尝试访问 PCIe 配置空间时会发生崩溃、对于我而言、如果此空间尚未堆叠到 CPU、则可能会发生这种情况。
您能看一下我的注意事项吗?
Hi-FD、
如果您有 TI EVM 板、请尝试重现该板上的问题并与我们分享重现该问题的方法。 到目前为止、我们 最后还不能重现此问题、我相信您理解这会使 我们很难 进行调试。
如果我们两个人都无法在 TI EVM 板上重现该 问题、则必须进行此调试、因为该问题是特定于您的系统的(又名、我们无法收集日志、也无法在未显示该问题的系统上测试修复)。 我们所能做的最好的事情就是为实验和推测提供建议、以便分析您在系统上运行的实验的结果。
因此、我想问以下两件事之一:
此致、
Takuma
尊敬的 藤原琢磨:
请按照建议找到以下实验的日志。 我在尝试热插拔 PCIe NVMe SSD 卡时在 PCI 重新扫描时看到相同的崩溃。
如果您无法在 TI EVM 板上重现问题、那么您可以进行 以下实验:
[报价]
- 在 PCIe 未连接到 SSD 的情况下引导系统。 保持显示器连接、因为在最新的响应中、显示似乎是导致问题的原因。
- 引导系统后、通过 PCIe 连接 SSD 卡
- 运行"echo 1 >/sys/bus/pci/rescan 以手动重新扫描 PCIe 总线
- 共享生成的日志。 如果时序是问题、这应该正确枚举 PCIe。
谢谢。
此致、Parth P
尊敬的 PARTH:
取得了有趣的结果。 这似乎不是时序问题(至少、不是 PCIe 控制器和探测 NVMe 时的时序问题)。
我假设这在定制电路板上、但这是使用内部参考时钟、还是外部时钟发生器为 SoC 和器件提供100MHz 参考时钟?
我提问、因为如果使用内部时钟、有一个勘误表会影响极少的一组器件。
此致、
Takuma
尊敬的 藤原琢磨
感谢您的答复。 如前所述、我们的定制硬件使用外部时钟发生器。
。 由于默认软件配置不允许单个 SERDES1的三个接口、因此我们在下游分支中提供了以下补丁、以使 PCIe 多链路可以按照 TI 的建议在没有 SSC 的情况下工作。
另一个有趣的发现是、TI AM69 SK 板上还存在用于热插拔和 PCIe 重新扫描建议实验的 PCIe NVMe 崩溃(带有 SDK 10.x 预编译二进制文件)。
日志: /cfs-file/__key/communityserver-discussions-components-files/791/AM69A_5F00_SK_5F00_SDK_5F00_10.x_5F00_PCIE_5F00_Rescan_5F00_Crash.txt
考虑到上述发现并假设此用例可以正常工作、您是否同意也可以从 TI/PCIe 驱动程序端检查一些事项?
此致、
Parth P
尊敬的 PARTH:
谢谢您的建议。 我还能够在 SK-AM69上重现此问题。 到目前为止、这似乎仅在热插拔和使用 Samsung SSD 手动重新扫描 PCIe 插槽时才会触发(问题不会显示是否正常启动、仅在手动重新扫描时才显示、问题仅显示特定 SSD)。 我在金士顿 SSD 上尝试了相同的实验,但无法看到问题。 因此、它看起来是临界情况。
我正在研究这个问题、但到目前为止、这似乎不是一个时间问题。 我已将问题范围缩小到 NVMe 驱动程序中的第2490行: https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/drivers/nvme/host/pci.c?h=ti-linux-6.6.y#n2490。我尝试的一个实验是、在该 NVME_PCI_ENABLE 功能内的每一行之前、添加3秒的睡眠时间、但错误仍然存在、这意味着这不是时序问题。
对比9.2 SDK 中使用的6.1内核和10.0 SDK 中使用的6.6内核之间的 NVMe 驱动程序、已经有几个重大更改、例如 NVMe 分配的最大大小更改。 这些更改都来自上游 Linux、而不是来自 TI、因此我想提醒您、由于是特殊情况和上游 Linux 中的变化、调试将需要相当长的时间。 但是、我们需要对此进行检查。
此致、
Takuma
尊敬的 PARTH:
您是否能找到一个具有 PME 状态 D0和 D3COLD/HOT 的 PCIe 卡、并在6.6内核上测试引导以及重新扫描? 运行 lspci -vv 时应显示 PCIe 卡的功能。
到目前为止、我发现启用了电源管理(+)的卡不会出错、而禁用了电源管理(-)的卡将导致旧的6.1内核和6.6内核上出现内核恐慌、同时进行重新扫描。 由于我在两个内核上都看到内核恐慌,我不确定我是否在追逐您的板上表现出的问题。
此致、
Takuma
尊敬的 PARTH:
此致、
Takuma