在奇怪的硬件错误和有趣的Linux内核行为的土地上，今天合并了一个修复程序，用于Linux 6.7并向后移植到现有的稳定内核系列，用于处理在使用Firewire(IEEE-1394)时可能主要在AMD Ryzen系统上发生意外系统重新启动的情况。
值得庆幸的是，FireWire多年来并不常见，将Firewire与现代AMD Ryzen系统一起使用将是一个相当小众的数字视频和/或音频硬件设置，但无论如何，这样的组合一直在给Linux用户带来问题，在插入Firewire设备或类似设备时，用户可能会意外重启。
最近有一些关于现代Linux内核版本的Firewire问题的错误报告，这对AMD Ryzen硬件来说尤其糟糕。一个解决办法是合并今天下午由SuSE的Takashi Sakamoto主持。他解释了这些麻烦：
“Via VT6306/6307/6308提供了符合1394 uchI的PCI接口。当硬件与ASMEDIA ASM1083/1085 PCIe到PCI总线桥结合时，似乎访问它的‘等时循环定时器’寄存器(在PCI内存空间上的偏移量0xf0)经常导致任何类型的AMD Ryzen机器(0x17和0x19系列)意外地重新启动系统。它不会出现在其他类型的机器(至少是AMD Pre-Ryzen机器，至少是Intel机器)或其他uchI 1394硬件(例如，德州仪器)中。
该问题明确出现在添加到v6.5内核的提交dcadfd7f7c74(“Firewire：core：Use Union for Callback of Transaction Complete”)中。它将1394uchI驱动程序改为每次访问寄存器，以调度本地异步事务。然而，该问题存在于旧版本的内核中，只要它在AMD Ryzen机器上运行，因为需要访问寄存器来维护总线时间。不难想象，当用户通过插入任何设备或通过时间感知型应用程序(例如音频采样处理)读取寄存器来产生总线重置时，用户会经历意外的系统重启。
此提交会抑制硬件组合中的意外系统重新启动。它避免了访问本身。因此，软件堆栈不能再为同一IEEE 1394总线中的单元驱动程序、用户空间应用程序和节点提供硬件时间。它带来了明显的劣势，因为时间感知的应用程序需要它，而时间感知的应用程序再次可用；例如sbp2。
所以，如果你正在运行AMD Ryzen，并且碰巧还在使用Firewire设备，那么在本周日Linux 6.7首次亮相之前，它的修复程序已经在路上了，在接下来的几天里，它将朝着维护的稳定/LTS内核版本前进。
如果你错过了去年的新闻，Linux内核有一个新的Firewire IEEE-1394子系统维护者， 打算在2029年前继续支持Linux上的Firewire.
