KVM直通Tesla T4 GPU安装windows虚拟机出现PCIE报错指向GPU
问题描述
多个客户在使用kvm虚拟机搭配T4 GPU创建windows虚拟机时,物理机出现PCIE报错,且报错指向具体的GPU。
测试发现只有在安装GPU驱动时会引发物理机PCIE报错,具体由以下两种情况触发:
- kvm使用包含T4 GPU 驱动的windows镜像创建虚拟机时
- kvm使用纯净的windows镜像创建虚拟机正常,在windows虚拟机下安装GPU驱动时
详细报错示例:
#服务器事件日志出现PCIE报错 14b | 06/02/2020 | 16:57:59 | Critical Interrupt PCIE | Bus Uncorrectable error | Asserted 14c | 06/02/2020 | 16:58:14 | Critical Interrupt PCIE | Bus Uncorrectable error | Asserted #服务器黑盒日志给出了PCIE的报错busno [Jun 02 2020 16:57:59] : PCIE Error: locate:NPSENTBusNo 62 DevNo 0 FuncNo 0 Bus Uncorrectable Error assertion. [Jun 02 2020 16:57:59] : Current BIOS Code(Port80): 0x00. [Jun 02 2020 16:58:14] : PCIE Error: locate:NPSENTBusNo 181 DevNo 0 FuncNo 0 Bus Uncorrectable Error assertion. [Jun 02 2020 16:58:14] : Current BIOS Code(Port80): 0x00.
其中黑盒日志BusNo 62和BusNo 181分别指向3E:00和B5:00两个GPU。
解决办法
linux宿主机每次开机进系统后,执行命令清除root port SERR信息,可将以下命令添加进开机自启动配置中,需要注意root port的device_id 不要搞错。
setpci -s 3a:00.0 3e.w=0:2 setpci -s ae:00.0 3e.w=0:2
问题根因
直通连接的T4 GPU卡,在Windows 虚拟机下触发GPU MSI-X表的访问,这将导致来自T4不支持的请求(UR)响应,该错误由PCIe root port触发系统处理器上的不可屏蔽中断(NMI),从而导致不可恢复的系统错误。
NVIDA提交BUG给RedHat KVM团队建议修复方案:在禁用相应的MMIO访问时,使PCIe root的端口映射无效。 并将尝试对设备的MMIO访问仅向用户生成SIGBUS响应,并且将避免导致KVM虚拟机管理程序上的NMI的系统错误。
根据:https://access.redhat.com/errata/RHSA-2020:2664 June 30 之后的kernel 包含了这个bug fix : 1820632
大家可以尝试验证下。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
作用一名合格的程序员,这些kafka原理你都知道?
如果只是为了开发 Kafka 应用程序,或者只是在生产环境使用 Kafka,那么了解 Kafka 的内部工作原理不是必须的。不过,了解 Kafka 的内部工作原理有助于理解 Kafka 的行为,也利用快速诊断问题。下面我们来探讨一下这三个问题 Kafka 是如何进行复制的Kafka 是如何处理来自生产者和消费者的请求的Kafka 的存储细节是怎样的 如果感兴趣的话,就请花费你一些时间,耐心看完这篇文章。 集群成员间的关系 我们知道,Kafka 是运行在 ZooKeeper 之上的,因为 ZooKeeper 是以集群形式出现的,所以 Kafka 也可以以集群形式出现。这也就涉及到多个生产者和多个消费者如何协调的问题,这个维护集群间的关系也是由 ZooKeeper 来完成的。如果你看过我之前的文章(真的,关于 Kafka 入门看这一篇就够了),你应该会知道,Kafka 集群间会有多个 主机(broker),每个 broker 都会有一个 broker.id,每个 broker.id 都有一个唯一的标识符用来区分,这个标识符可以在配置文件里手动指定,也可以自动生成。Kafka 可以通过 br...
- 下一篇
8张图带你了解大型应用架构演进历程
前言 先点赞再观看,要有好习惯 几乎所有的大型应用都是从一个小应用开始的,好的互联网产品是慢慢运营出来的,不是一开始就开发好的,所以本篇我们来聊聊应用架构的演进历程。 如何打造一个高可用,高性能,易扩展的应用?首先我们了解一下大型应用的特点: 高可用:系统需要不间断的提供服务,不能出现单点故障 高并发:在大流量的冲击下,系统依然稳定提供服务 大数据:应用每天都会产生大量的数据,需要存储和管理好这些数据 最简单的架构 刚开始应用没有太多访问量,所以只需要一台服务器,这时候的架构如下图: 应用程序、文件、数据库往往都部署在一台服务器上。应用程序可以采用Java开发,部署在Tomcat服务器上,数据库可以使用开源的MySQL 应用与数据服务分隔 随着应用的业务越来越复杂,应用访问量越来越大,导致性能越来越差,存储空间严重不足,这时候我们考虑把服务增加到三台(能通过加机器解决的问题都不是问题);分离出应用服务器、数据库服务器、文件服务器。 应用服务器需要处理大量的访问,所以需要性能更好的CPU 数据库服务器需要存储大量的数据以及快速的检索,所以需磁盘的检索速度较快以及存储空间大 文件服务器需要...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- CentOS关闭SELinux安全模块
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- SpringBoot2初体验,简单认识spring boot2并且搭建基础工程
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- Docker安装Oracle12C,快速搭建Oracle学习环境
- SpringBoot2全家桶,快速入门学习开发网站教程
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- CentOS6,CentOS7官方镜像安装Oracle11G