[参考译文] Linux/AM5728：内核内部错误

向 Google 结果添加链接：
www.spinics.net/.../ 是一组线程的索引
www.spinics.net/.../msg32188.html 是似乎在谈论竞争状态的线程的顶部、可能是修补程序(？)

Michael、

我很抱歉耽误您的回答。 在没有硬件的情况下很难调试此问题、但我比较了 Linux 内核中的 TTY 驱动程序源代码- 4.4.32 (您正在使用)和 Linux 内核4.9.59 (上一个 Processor SDK 4.02中使用的内核)、并找到了可能与所述崩溃相关的更改。 因此、我建议您使用 Processor SDK 4.02.00.09来测试电路板的行为。

BR
Tsvetolin Shulev

大家好
SW Guy 说、使用新的 Linux 内核进行重建非常重要。 电路板上的所有内容与 EVM 不匹配：不同的 DDR3芯片、少一个以太网 PHY、将 USB 集线器移至 USB2端口(并更改为 USB2集线器)、使用 GPMC 而不是视频输出。 当我们构建当前版本时、我们的顾问花了大约3个月的时间将所有版本整合在一起。 大概是第二次来会快一点、但我们仍然需要提供外部帮助。

话虽如此，如果它修复了启动错误，管理层将为外部帮助付费。 您能描述一下您认为正在发挥作用的变化吗？ 这将有助于我说明管理部门如何取出钱包。

此外、我们今天遇到了类似的启动错误、最终的行为略有不同 我将把它发布到这个主题的新帖子中。

添加此帖子以描述类似但新的启动失败。 在这种情况下、发送"修复递归故障但需要重新启动！"后 它不仅停止了。 相反、它似乎尝试在 I2C 上执行某些操作并且失败。 它似乎正在尝试与 PMIC 通信：

[15.008886] OMAP_i2c 48070000.i2c：控制器超时
[16.048899] OMAP_i2c 48070000.i2c：控制器超时
[17.08888883] OMAP_i2c 48070000.i2c：控制器超时
[17.108932] Palms-GPIO 48070000.i2c：tps659038@58：tps659038_gpio：reg 0x05写入失败、-110
[18.128884] OMAP_i2c 48070000.i2c：控制器超时
[21.168897] OMAP_i2c 48070000.i2c：控制器超时
[22.208897] OMAP_i2c 48070000.i2c：控制器超时
[23.248899] OMAP_i2c 48070000.i2c：控制器超时
[26.288896] OMAP_i2c 48070000.i2c：控制器超时
[27.328897] OMAP_i2c 48070000.i2c：控制器超时
[28.368896] omap_i2c 48070000.i2c：控制器超时
[29.408883] OMAP_i2c 48070000.i2c：控制器超时
[29.428927] Palmas-GPIO 48070000.i2c：tps659038@58：tps659038_gpio：reg 0x04写入失败、-110
[30.448883] OMAP_i2c 48070000.i2c：控制器超时
[30.468923] Palms-GPIO 48070000.i2c：tps659038@58：tps659038_gpio：reg 0x04写入失败、-110
[33.1388859]信息：RCU_sched 检测到 CPU /任务上的停转：
[33.144383] 1-...：(0个周期这个 GP) IDLE=771/140000000000000/0 softirq=3942/3942 fqs=2092
[33.152855](由0检测到、t=2102个 Jiffies、g=-46、c=-47、q=1)
[33.158809] CPU 1的任务转储：
[33.162049] kworker/U4：1 D c06061c8 0 72 0 0x00000000
[33.168452]回溯：
[33.170914]由于帧指针错误、回扫中止
[33.177055]信息：RCU_PREOST_DEP占用 在 CPU/任务上检测到的停转：
[33.182750] 1-...：(后面有1个 GPS) IDLE=771/140000000000000/0 softirq=3941/3942 fqs=2091
[33.190959](由0检测到、t=2104个 jiffies、g=379、c=378、q=339)
[33.197086] CPU 1的任务转储：
[33.200324] kworker/U4：1 D c06061c8 0 72 0 0x00000000
[33.206725]回溯：
[33.209188]由于帧指针错误、回扫中止
[33.488916] OMAP_i2c 48070000.i2c：控制器超时
[34.528915] OMAP_i2c 48070000.i2c：控制器超时
[35.568894] OMAP_i2c 48070000.i2c：控制器超时
[35.588914] Palms-GPIO 48070000.i2c：tps659038@58：tps659038_gpio：reg 0x05写入失败、-110
[36.608897] OMAP_i2c 48070000.i2c：控制器超时
[39.648916] OMAP_i2c 48070000.i2c：控制器超时
[40.688894] omap_i2c 48070000.i2c：控制器超时
[40.708913] Palms-GPIO 48070000.i2c：tps659038@58：tps659038_gpio：reg 0x04写入失败、-110
[41.728893] OMAP_i2c 48070000.i2c：控制器超时
[42.768912] OMAP_i2c 48070000.i2c：控制器超时
[45.808917] OMAP_i2c 48070000.i2c：控制器超时
[46.848915] omap_i2c 48070000.i2c：控制器超时
[47.888915] OMAP-i2c 48070000.i2c：控制器超时

或者可能有多个线程尝试运行。 它肯定没有响应 Enter 键-我们在按下复位开关之前没有尝试任何其他操作。

我们要做的是查看控制台是否可以在出现"需要重新启动"消息后与处理器进行通信、因此我们(通过"我们"、我是指一个很差的实习生、他为我发现了所有这些错误)继续重启系统以再次引发启动错误。 假设我们这样做、我们应该看什么？ 检查 dev 目录？ 还有什么可能指向未加载的内容的东西？

谢谢！
马德曼

(另请参阅此主题中的我的其他回复)

您好！

Michael、您是否能够跟踪内部错误的原因？
您是否有机会尝试使用4.9内核切换到更高版本的 SDK？
发送"Recurive fault message..."是什么意思？ 您的团队是否使用带有4.4内核的原始 SDK 达到了这一点？

昨天、我在我们的自定义电路板上遇到了类似的问题(但显然涉及不同的模块)内部错误、该问题复制了572x EVM 修订版 A3原理图、请参阅下面的内容。 我想知道这个问题现在是否经历得更广泛、以及一些常见的原因是什么。

昨天1/6启动时发生了这种情况、因此我现在将其归类为间歇性的。

完全披露、我正在运行 beagleboard.org 上的 debian 8.10和 kernel 4.4.4.110-ti-r142。 当我在这里提出问题时、我切换到最新的 TI SDK、但由于这似乎是间歇性的/很难重现、

您是否会考虑查看我的内核引导/FS 安装日志以及 Michalel 的日志？

我还在 beagleboard.org 上发布了此信息、以查看是否有人遇到/看到过此情况。

谢谢！！！！

Jeff

[9.999478]无法处理虚拟地址00002248的内核寻呼请求

[0.006772] PgD = c0004000

[10.009402][00002248]* PgD=00000000

[10.013025]内部错误：Oops：17 [#1] SMP ARM

[10.017747]中链接的模块：snd_soc_simple_card etnaviv snd_soc_omap_hdmi 音频 FTDI_SIO usbseris

[10.057143] CPU：1 PID：6 Comm：kwork/U4：0未被污染4.4.4.110-ti-r142 #9
[10.064128]硬件名称：通用 DRA74X (平展器件树)
[10.070251]工作队列：Events_unbound flush_TO_ldisc
[10.075238] task：ee16a080 ti：ee188000 task.ti：ee188000

[10.080657] PC 位于 n_tty_receive_buf_common+0x84/0xa68

[10.085991] LR 位于 DOWN_READ+0x1c/0x4c
[10.089926] PC：[ ] LR：[ ] PSR：200f0013
[10.089926] sp：ee189e18 IP：ee189e00 FP：ee189e84
[10.101449] R10：ed4b7c00 R9：ee03d000 R8：ee03d014
[10.106651] r7：ed4b7c00 r6：ed4b7d84 r5：ed4b7c80 r4：c0af0c30
[10.113241] r3：00002000 r2：00000000 r1：ee69e0a0 r0：00000000
[10.119793]标志：模式 SVC_32 ISA ARM 段无时 FIQ 上的 nzCv IRQ
[10.126954]控制：10c5387d 表：ad53c06a DAC：00000051
[10.132720]进程 kworker/U4：0 (pid：6、栈限制= 0xee188218)
[10.139009]堆栈：(0xee189e18至0xee18a000)
[10.143380] 9e00： ed4b7c80 ee189e28
[10.151589] 9e20：c00867a4 00020001 ed4b7d84 55555556 ee16a44c c1011a48 c0af0c30 c100d300
[10.159798] 9e40：00002000 00000000 00000000 ee69e0a0 00000003 00000000 ee189e8c ee69e000
[10.168008] 9e60：00000001 e03d004 ed4b7c00 e03d014 e03d000 c0676d4c ee189e189c ee189e88
[10.184425] 9ea0：c0aac9a0 ee5b09c0 ee189ed4 ee03d004 ee0b5f80 ee03fc00 00000000 ee022b00
[10.192635] 9ec0：c10e5fd8 ee022b05 ee189f14 ee189ed8 c005fee4 c067a968 ee188000 c0061030
[10.200846] 9ee0：ee189efc 00000000 c0061030 ee0b5f80 ee0b5f98 ee03fc00 00000088 ee03fc14
[10.209055] 9f00：ee188000 ee03fc00 ee189f54 ee189f18 c0060284 c005fd9c c1033e04 c0d48010
[10.217264] 9f20：ee188000 c10e5bb9 00000000 00000000 e0b7400 ee188000 e0b5f80 c0060224
[10.225473] 9f40：00000000 0000e189f20e189f58 c00664a8 c0060230 00000000 2dd1a000
[10.233683] 9f60：ee0b5f80 00000000 ee189f6c ee189f6c 00000000 ee189f7c
[10.241892] 9f80：ee189f7c dc8ba66e c00747b4 ee0b7400 c0066390 00000000 00000000 00000000
[10.250101] 9fa0：00000000 ee189fb0 c0010ef8 c006639c 00000000 00000000 00000000 00000000
[10.258310] 9fc0：00000000 00000000 00000000 00000000 00000000 00000000 00000000
[10.266518] 9fe0：00000000 00000000 00000000 00000000 00000013 00000000 00000000 08000000
[10.274732][ ](n_tty_receive_buf_common)、来自[ ](n_tty_receive_buf2+0x24/0x2C)
[10.283903][ ](n_tty_receive_buf2)、来自[ ](flush_TO_ldo+0xf0/0x13c)
[10.292290][ ](flush_TO_ldisc)从[ ](Process_One_Work+0x154/0x494)
[10.300588][ ](Process_One_Work)、来自[ ](worker_thread+0x60/0x548)
[10.308712][ ](worker_thread)、来自[ ](kthread+0x118/0x130)
[10.316140][ ](kthread)、来自[ ](RET_FANK_F叉+0x14/0x3c)
[10.32332]代码：e50b2030 e50b3034 eb10e2f3 e51b3044 (e5930248)
[10.329557]--[结束线迹406ed7c803d6bcc7 ]--

[10.33587] Unable to handle kernel paging request at virtual address ffffffffec.(无法处理虚拟地址 ffffffec 的内核分页请求。

您好 Jeff
我们还没有找到解决办法。 我们发现启动失败的方式不止一种。 我们正在尝试查看是否涉及任何硬件问题、因此我们已开始检测复位信号和内核电压轨、以查看我们是否可以捕获与启动故障相关的定序错误。 这是一项单调的重复性工作、这就是我感谢我的雇主为实习生提供帮助的原因！ 但是，到目前为止还不幸运。

我们的软件人员进行了一些更改、使我们的启动故障率降至1%左右。 不够好，但现在还可以忍受。
其中一个与 DSP 有关-软件在我们第一次尝试启动其中一个 DSP 时挂起。 注释掉一行代码即可修复该问题。 我不记得细节、但我可以在需要时四处寻找。
PRU 未启动时出现类似问题。 为此、SW 添加了一个检查、以确保 PRU 加载到 dev 文件夹中。 它在我们的应用程序启动之前运行。 如果 PRU 不在 dev 文件夹中、则此检查器会发出 reboot 命令。

我们正在尝试获取软件资源、以使用最新版本重新构建 Linux 内核、但这需要数周的时间才能实现。

如果学到任何东西、我将发布更多内容。 祝您好运！

我忽略了我们定制板的一点、就是通过 Pinmux 工具在 mux_data.h 中调整/定制 SPL 中的 IO 时序延迟。 我们与之交谈的 TI 支持工程师表示可能会发生奇怪的行为、并认为我们最终需要采取这一步骤。

想知道这种间歇性内核崩溃、内部错误是否可能与 DDR3或其他组件接口中的错误时序/不兼容延迟有关？？？

您是否偶然调整了定制硬件的 IO 延迟、或者只是采用了引脚多路复用工具或参考设计(例如572xEVM、IDK、BB-X15)的默认值？ 我大部分时间都集中在焊盘配置上、而不是 IO 延迟上。 也许是时候关注后者了吗？

谢谢！！

Jeff

我在 Hyperlynx 上花了几天时间、在布局中调整了 DDR3和其他 I/O。 然后、固件工程师花了几天时间在内核中正确设置 DDR3。 我对此很开心。 尽管如此、我们仍在寻找间歇性不良信号、尤其是电源定序和复位。

您好！

Doyle，您是否找到原因和解决方案？

BR、

Vefone

您好、Michael、

每次出现内核内部错误时、您是否会看到基本上相同的控制台日志：

例如？

无法在同一虚拟地址处理内核分页请求？

PgD =同一地址？

*PgD =相同的解引用数据？

链接的模块： 相同的模块列表？

我最近没有听到 TI 提示音、因此我正在联系那里的人员、看看他们是否能够引导我们朝着正确的方向前进、IO 延迟问题、接线问题或其他问题？

谢谢！

此外、我认为 BeagleBoard 的家伙、当他看到我们的内部错误控制台日志时、他也在想 DDR3。 我在那里交叉发布。

如果这是 DDR3问题、为什么在内核启动后、但内核正在安装 FS 时、这会增加呢？ 为什么 u-boot 或内核启动中没有问题？

此外、如果 TI/BeagleBoard/BeagleBone Pundits 认为这是一个 DDR3问题、是否有测试工具可以运行扩展 DDR3测试以测试对 DDR3以及 IO Pad 配置的读取和写入？

一位来自 Denx 的 u-boot 家伙说、TI 拥有5728的测试工具。 例如、我们简要介绍了5718 IDK、它附带了 SD 卡上的测试工具、该工具基于 DOS 或 TI-RTOS。

否、仍在调查中。
Mike

我的同事重新浏览了日志(实习生是很棒的资源！)。 这是他发现的东西。 我们似乎有两种故障模式。

我浏览了显示“Unable to handle kernel paging request”(无法处理内核分页请求)错误消息的5个故障的日志文件。

系统首先显示消息 PC 处于 n_tty_receive_buf_common+0x7c/0xa60、然后有时在几行后的同一启动时也显示 PC 处于 kthread_data+0x10/0x18、有时它只显示消息 PC 处于 n_tty_receive_buf_common+0x7c/0xa60

下面是我在日志文件中看到的内容、有时系统会在00002248和 ffffffec 处显示无法处理内核寻呼请求、只要地址是00002248–PC 在 n_TTY 上、当地址是 ffffec–PC 在 kthread 上。

如果出现这两个错误消息、PgD 始终为 PgD = c0003000。
*PgD 在这两种情况下都不同，但在所有故障下都是相同的。
*PgD=80000080004003
*PgD=80000080007003

您好！

Mike、如果您解决了问题、请反馈。 我的定制板上有相同的问题、但我不知道如何测试。

BR、

Vefone

谢谢 Michael、

将更新您在周五晚些时候提供的新信息上的 BeagleBoard 线程。 他们似乎在想外部 RAM/DDR3正在发生什么事情。

我们需要在板上测试其他外设和功能、以便我们的应用团队可以运行其最新代码的测试、因此我们需要在后台运行此类代码。 但我仍在尝试跟踪它。

此外、我还在寻找 TI 和其他地方的测试程序、希望能做一些扩展 DDR3测试。

谢谢！！

Vefone、

由于您遇到与 Micheal 相同的问题、我对您遇到的问题非常好奇？

*您使用的是什么 SOC，5728？  

*您使用的是什么 DDR3？  我们使用的是 Micron、

MT41K256M16TW

*如果控制台日志与我们看到的不同，或者故障模式是否相同，您是否也可以发布这些控制台日志？

*发生的频率是多少？

*您是否都花了时间专门针对您的定制硬件调优/计算 IO 延迟、或者您是否使用 TI Pinmux 工具的库存 IO 延迟值或引导加载程序的现有值？

 

谢谢！！

Jeff

…

此外、

这里有一个关于 DDR3合规性测试的主题。 我没有参加过这些活动，所以我现在不知道这些活动是否与这个特定问题有关。 但它看起来有些材料可能是相关的。

该主题引用了 sprac36.pdf、我在这里找到了 zip 存档文件、

www.ti.com/.../getliterature.tsp

e2e.ti.com/.../2249691。

第一个链接是 EMIF 电子表格/工作簿。

这是 TI 的相关应用手册文档：

www.ti.com/.../sprac36a.pdf

非常好。 我们使用了电子表格并遵循了该应用手册。 我们使用的是1 GB 版本的 Micron DDR3、因此我们几乎必须定制所有产品。

BTW、适用于 TI 应用的无耻插头：他们对原理图进行了非常透彻的审阅。 关注此主题的任何人：如果您尚未将您的设计发送给晶圆厂(或甚至可能已经发送)、一定要与您的 TI 代表合作、将您的原理图提交给应用工程师进行审核。 他们发现了很多问题、如果我处理这些问题、可能需要我数周时间才能跟踪。 我想网站的某个位置有一个链接。

您好！

Jeff、我使用的是 AM5728。 我使用 的是 Micron MT41K256M16HA-125。

以下是日志：

e2e.ti.com/.../am5728-log.txt

发生概率约为1000倍的三倍。 顺便说一下、并非所有电路板都有问题。

*您是否都花了时间专门针对您的定制硬件调优/计算 IO 延迟、或者您是否使用 TI Pinmux 工具的库存 IO 延迟值或引导加载程序的现有值？

不、我不对它进行测试。

原因可能是？

BR、

Vefone

您好！
Jeff、现在我正在使用 uboot 中的现有值。请勿更改它。

感谢 Vefone 发布日志和此信息！

那么、您是否使用 uboot 中的现有值获得相同的错误率？

如果我有疑问，您的设计是否是现有 TI 设计之一(例如 am572x EVM)的密件？

我认为 TI 的 BSP 团队在开发各种开发板(例如572XEVM、5718IDK、5728IDK)时会遇到此错误。  

如果是、TI 可以提供一些有关这些错误含义的线索、这将是很棒的！！！

您好 Jeff
您使用的是哪个版本的 Linux 内核？ 我的板位于4.4.3.32上、vefone 使用4.4.19。
Mike

您好、Michael、

我们使用的是为 BeagleBoard-X15增补的内核版本4.4.110、我们从 BeagleBoard.org 上基于 Debian 的映像开始。