Xorg在自定义图像中崩溃
我生成了一个图像 研华 PCM-9375 板使用 yocto 系统(分支邓菲尔)。
结果使用 Xorg 作为视频管理器,但是,由于安装了 geode 驱动程序,应用程序崩溃了。
我调试了一下,发现当使用以下参数调用驱动程序函数 LXReadMSR 时会发生崩溃:addr=0x80002000h、lo=0xbffff994 和 hi=0xbffff998。最后两个是指针,其内容分别是:5136和0。 下面的代码片段是 gdb 的回溯:
(gdb) bt
#0 0xb7693ba7 in LXReadMSR (hi=0xbffff998, lo=0xbffff994, addr=2147491840) at ../../xf86-video-geode-2.11.20/src/lx_driver.c:131
#1 LXReadMSR (addr=2147491840, lo=0xbffff994, hi=0xbffff998) at ../../xf86-video-geode-2.11.20/src/lx_driver.c:126
#2 0xb7681eef in msr_create_geodelink_table (gliu_nodes=0xb76b2880 <gliu_nodes>) at ../../xf86-video-geode-2.11.20/src/cim/cim_msr.c:199
#3 0xb7682400 in msr_init_table () at ../../xf86-video-geode-2.11.20/src/cim/cim_msr.c:82
#4 0xb7693282 in LXPreInit (pScrni=0x6a79e0, flags=0) at ../../xf86-video-geode-2.11.20/src/lx_driver.c:349
#5 0x00480986 in InitOutput (pScreenInfo=0x688280 <screenInfo>, argc=12, argv=0xbffffc44) at ../../../../xorg-server-1.20.14/hw/xfree86/common/xf86Init.c:522
#6 0x00444525 in dix_main (argc=12, argv=0xbffffc44, envp=0xbffffc78) at ../../xorg-server-1.20.14/dix/main.c:193
#7 0x0042d89b in main (argc=12, argv=0xbffffc44, envp=0xbffffc78) at ../../xorg-server-1.20.14/dix/stubmain.c:34
查看处理器文档,我发现addr指向GLD_MSR_CAP寄存器(第“6.6.1.1 GLD功能MSR(GLD_MSR_CAP)”章节)在文档中),但是我不知道发生了什么。
尝试的解决方案:
- 插入 CLI 内核指令“iomem=relaxed”,如驱动程序自述文件的第 6 项所指出的 github 存储库;
- 将内核配置“CONFIG_BLK_DEV_CS5535=y”替换为“CONFIG_BLK_DEV_CS5536=y”。
他们都没有工作。
Xorg版本:1.20.14
Geode驱动版本:2.11.20
有人遇到过类似的问题吗?有谁知道发生了什么事?
我接下来的尝试将是修改内核配置参数,但是有很多,我不知道其中哪些与问题有关。
I generated an image to an advantech PCM-9375 board using the yocto system (branch dunfell).
The outcome uses Xorg as the video manager, however, the application is crashing due to the geode driver installed with it.
I debugged it and discovered that the crashes happen when the driver function LXReadMSR is called with the parameters: addr=0x80002000h, lo=0xbffff994 and hi=0xbffff998. The last two are pointers, and their contents are: 5136 and 0, respectively.
The snippet below is the gdb's backtrace:
(gdb) bt
#0 0xb7693ba7 in LXReadMSR (hi=0xbffff998, lo=0xbffff994, addr=2147491840) at ../../xf86-video-geode-2.11.20/src/lx_driver.c:131
#1 LXReadMSR (addr=2147491840, lo=0xbffff994, hi=0xbffff998) at ../../xf86-video-geode-2.11.20/src/lx_driver.c:126
#2 0xb7681eef in msr_create_geodelink_table (gliu_nodes=0xb76b2880 <gliu_nodes>) at ../../xf86-video-geode-2.11.20/src/cim/cim_msr.c:199
#3 0xb7682400 in msr_init_table () at ../../xf86-video-geode-2.11.20/src/cim/cim_msr.c:82
#4 0xb7693282 in LXPreInit (pScrni=0x6a79e0, flags=0) at ../../xf86-video-geode-2.11.20/src/lx_driver.c:349
#5 0x00480986 in InitOutput (pScreenInfo=0x688280 <screenInfo>, argc=12, argv=0xbffffc44) at ../../../../xorg-server-1.20.14/hw/xfree86/common/xf86Init.c:522
#6 0x00444525 in dix_main (argc=12, argv=0xbffffc44, envp=0xbffffc78) at ../../xorg-server-1.20.14/dix/main.c:193
#7 0x0042d89b in main (argc=12, argv=0xbffffc44, envp=0xbffffc78) at ../../xorg-server-1.20.14/dix/stubmain.c:34
Looking in the documentation of the processor, I found out that addr points to GLD_MSR_CAP register (chapter "6.6.1.1 GLD Capabilities MSR (GLD_MSR_CAP)" in the documentation), however I didn't figure out what's happening.
Solutions tried:
- Insertion of the CLI kernel instruction "iomem=relaxed", as pointed by item 6 of the driver's readme file in its github repository;
- Replacing of the kernel configuration "CONFIG_BLK_DEV_CS5535=y" by "CONFIG_BLK_DEV_CS5536=y".
None of them worked.
Xorg version: 1.20.14
Geode driver version: 2.11.20
Did anyone have a similar problem? Does anyone know what's happenning?
My next tries will be the modification of kernel config parameters, but there are a lot and I'don't know which of them are related to the problem.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
启用内核选项“ config_x86_iopl_ioperm”时解决的问题。
阅读这篇文章。
Problem solved when the kernel option "CONFIG_X86_IOPL_IOPERM" was enabled.
I've come to this solution after reading this post.