黑群晖vm在proxmox内IRQ反复报内核错误的临时解决办法

由于把pve宿主机上的主板从服务器级的X11SAE-M换成了消费级的asrock z270超级航母,bios上虽然有vt-d的选项,但是也经过了iommu重新分组之类的配置才正常开启直通,BIOS的不同随之带来了更多的问题.

所以这里也不确定为啥同样版本的代码的内核在x11sae-m上不报错,但是消费级主板上就出现bug.极有可能是BIOS编写上并没有为vt-d做好完整的pci-e通道规划

群晖的vm配置了直通的阵列卡从vfio_iommu的pve设备而来,但是恐怕scsi卡太老旧了 又都是服务器拆机卡,不管是IT模式还是RAID模式,跟IOMMU里的PCIE新的功能规范相容性太低,时不时地会在内核打印

do_IRQ: 2.38 No irq handler for vector

而客户机群晖采用了btrfs的文件系统下总线上通讯非常频繁没办法如BIOS预期的那样完美切换主动总线电源管理的状态 相信跟宿主机内核的通信也是有关系的,这个时候客户机也照样打印了同样位置的中断找不到handler来调用这个向量.

00226: unsigned int __irq_en
00227: {
00228:         struct pt_regs *old_regs = set_irq_regs(regs);
00229:
00230:         /* high bit used in ret_from_ code*/
00231:         unsigned vector = ~regs->orig_ax;
00232:         unsigned irq;
00233:
00234:         exit_idle();
00235:         irq_enter();
00236:
00237:         irq = __get_cpu_var(vector_irq)[vector];
00238:
00239:         if (!handle_irq(irq, regs)){
00240:                 ack_APIC_irq();
00241:
00242:                 if (printk_ratelimit())
00243:                         pr_emerg(“%s:%d.%d No irq handler for vector (irq %d)\n“,
00244:                     func__, smp_processor_id(), vector, irq);
00245:         }
00246:
00247:         irq_exit();
00248:
00249:         set_irq_regs(old_regs);
00250:         return 1;
00251: }?   enddo_IRQ

看了https://ilinuxkernel.com/?p=1192 的代码解析判断由于sas卡与主板BIOS处理直通设备的电源管理的代码上不够完善,目前来说宿主机内核版本是5.4.44,客户机群晖的内核版本是4.4.59+都有同样的内核日志打印出来 但是这样直通出来的IRQ信号和位置貌似对客户机来讲会更加降低客户机的健壮度.导致群晖的磁盘管理器直接找不到SAS卡 (irq的映射位置都错乱了)从而cmd_timeout掉盘报错.

更精彩的代码解析在http://www.jeepshoe.net/art/123095.html

有时间的时候可以去读一下了解一下Linux如何处理硬件中断与内核软中断 在未来的场景可以通过mpstat监控softirq的压力来避免这个问题.

浪潮的工程师手册里提到了临时的解决方案是在启动grub.cfg里添加内核参数规定 pci='nomsi,noaer' 注意,这仍然也是一个临时方案 内核代码务必在未来某个时间点要解决这个问题

我在宿主机上添加了这两个内核参数,经过几个星期的使用下来是没有用的 该报的错继续爆,该掉的盘继续掉,不过经过上个月底的持续崩溃后实在是受不了了,加载群晖的synoboot1分区把这两个内核参数添加到

set extra_args_918= 'iommu=no-intremap pcie_aspm=off pcie_hp=nomsi pcie_pme=nomsi skip_isa_align realloc noaer'

宿主机bootargs添加 irqpoll来解决老旧主板对默认对IRQ的分配不更新导致的IRQ平衡破裂.让kernel用poll机制重新分配无法被主板BIOS分配的部分.

经过了一个半星期的运行使用,客户机没有再报同样的错误.功能上也没有被影响,直通的SAS卡没有再出现cmd_timeout,按照之前出错时间频度上统计,2,3天就会出错或者2,3个小时也可能马上出错,目前有一周半的时间的稳定运行来看,这个问题被暂时压住了.这是一个经验 需要记录一下.