总结：
- 键盘和鼠标不适用于某些内核。
- 不是要求解决方法，我已经有办法了。
- 使用
git bisect，我已经确定了 Ubuntu 内核存储库中我的输入设备停止工作的确切提交位置。 - 假设在较新的上游内核中没有出现这种故障，我下一步该做什么？
我的 USB 输入设备：
- 罗技G19有线键盘
- 罗技G502有线鼠标
- Sharkoon 键盘（非常基础，没有键盘照明，没有显示屏，没有特殊的额外按钮）
Ubuntu 版本：21.10
正常（预期）功能：
- 在 Grub 中：
- 键盘和鼠标灯在
- 当我反复按下 NumLock 键时，NumLock LED 会熄灭和亮起
- 键盘可以使用（我可以在 Grub 菜单中 使用箭头键）
- 在 Gnome 登录屏幕中：
- 键盘和鼠标灯在
- 当我反复按下 NumLock 键时，NumLock LED 会熄灭和亮起
- 屏幕上的鼠标指针移动当我移动鼠标时
- 打字正常（我可以在登录屏幕上输入我的密码）
当它不工作时：
- 在 Grub 中：
- 键盘和鼠标灯在
- 当我反复按下 NumLock 键时，NumLock LED 会熄灭和亮起
- 键盘可以使用（我可以在 Grub 菜单中 使用箭头键）
- 在 Gnome 登录屏幕中：
- 键盘和鼠标灯离开
- 当我反复按下 NumLock 键时，NumLock LED 熄灭并保持熄灭状态
- 屏幕上的鼠标指针不动当我移动鼠标时
- 打字不起作用
通过上述内容，我有一个非常可靠的场景来测试某个内核是否适合我。我用 3 种方法安装了各种内核：
- 使用
apt->Ubuntu 内核，可从 Ubuntu repo 获取 - 使用Ubuntu 主线内核安装程序-> 来自 kernel.org 的预编译内核。
- 使用我自己编译的 Ubuntu 内核git://kernel.ubuntu.com/ubuntu/ubuntu-impish.git。我曾经
git bisect检出不同的提交，然后构建其中的每一个，这样我就可以找到键盘和鼠标停止工作的确切提交。
- 已测试的工作内核：
- 5.13.0-051300-通用（UKMI）
- 5.13.0-19-通用（apt）
- 5.13.0-20-通用（apt）
- 5.13.0-21-通用（apt）
- 5.13.0-22-通用（apt）
- Ubuntu-5.13.0-22.22-0-g3ab15e228151（已编译）
- Ubuntu-5.13.0-22.22-317-g398351230dab（已编译）
- Ubuntu-5.13.0-22.22-356-g8ac4e2604dae（已编译）
- Ubuntu-5.13.0-22.22-376-gfab6fb5e61e1（已编译）
- Ubuntu-5.13.0-22.22-386-gce5ff9b36bc3（已编译）
- 5.16.11-051611-通用（UMKI）
- 经过测试的失败内核：
- Ubuntu-5.13.0-22.22-387-g0fc979747dec（已编译）
- Ubuntu-5.13.0-22.22-388-gab2802ea6621（已编译）
- Ubuntu-5.13.0-22.22-391-ge24e59fa409c（已编译）
- Ubuntu-5.13.0-22.22-396-gc3d35f3acc3a（已编译）
- Ubuntu-5.13.0-22.22-475-g79b62d0bba89（已编译）
- Ubuntu-5.13.0-23.23-0-gb188ba567fc9（已编译）
- 5.13.0-23-通用（apt）
- 5.13.0-25-通用（apt）
- 5.13.0-27-通用（apt）
- 5.13.0-28-通用（apt）
- 5.13.0-30-通用（apt）
内核 5.13.0-22 是通过提供的最新 Ubuntu 内核，apt对我有用，因此我已固定该版本以防止其自动升级。至于我具体如何做到这一点，超出了我的问题范围。
5.13.0-23 是第一个让我无法使用键盘和鼠标的 Ubuntu 内核，所以我知道导致它无法使用的提交肯定在 5.13.0-22 和 5.13.0-23 之间。我曾经git bisect识别过确切的提交，然后找到了它。这意味着运行git bisect、编译和安装内核、重新启动、测试输入设备是否工作，然后根据测试结果执行git bisect good或git bisect bad。每次编译大约需要 22 分钟，所以你可以想象我花了相当多的时间！
我的输入设备停止工作的确切提交是Ubuntu-5.13.0-22.22-387-g0fc979747dec。它包含以下更改：
xhci: Fix command ring pointer corruption while aborting a command
BugLink: https://bugs.launchpad.net/bugs/1951880
commit ff0e50d3564f33b7f4b35cadeabd951d66cfc570 upstream.
The command ring pointer is located at [6:63] bits of the command
ring control register (CRCR). All the control bits like command stop,
abort are located at [0:3] bits. While aborting a command, we read the
CRCR and set the abort bit and write to the CRCR. The read will always
give command ring pointer as all zeros. So we essentially write only
the control bits. Since we split the 64 bit write into two 32 bit writes,
there is a possibility of xHC command ring stopped before the upper
dword (all zeros) is written. If that happens, xHC updates the upper
dword of its internal command ring pointer with all zeros. Next time,
when the command ring is restarted, we see xHC memory access failures.
Fix this issue by only writing to the lower dword of CRCR where all
control bits are located.
Cc: [email protected]
Signed-off-by: Pavankumar Kondeti <[email protected]>
Signed-off-by: Mathias Nyman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
Signed-off-by: Stefan Bader <[email protected]>
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 5b54a36..5a96f3e 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -366,16 +366,22 @@ static void xhci_handle_stopped_cmd_ring(struct xhci_hcd *xhci,
/* Must be called with xhci->lock held, releases and aquires lock back */
static int xhci_abort_cmd_ring(struct xhci_hcd *xhci, unsigned long flags)
{
- u64 temp_64;
+ u32 temp_32;
int ret;
xhci_dbg(xhci, "Abort command ring\n");
reinit_completion(&xhci->cmd_ring_stop_completion);
- temp_64 = xhci_read_64(xhci, &xhci->op_regs->cmd_ring);
- xhci_write_64(xhci, temp_64 | CMD_RING_ABORT,
- &xhci->op_regs->cmd_ring);
+ /*
+ * The control bits like command stop, abort are located in lower
+ * dword of the command ring control register. Limit the write
+ * to the lower dword to avoid corrupting the command ring pointer
+ * in case if the command ring is stopped by the time upper dword
+ * is written.
+ */
+ temp_32 = readl(&xhci->op_regs->cmd_ring);
+ writel(temp_32 | CMD_RING_ABORT, &xhci->op_regs->cmd_ring);
/* Section 4.6.1.2 of xHCI 1.0 spec says software should also time the
* completion of the Command Abort operation. If CRR is not negated in 5
链接的启动板错误没有产生任何有用的结果，因为它并不是专门针对这一变化的。
链接的电子邮件主题Mathias Nyman、Pavan Kondeti 和 youling257 之间的对话就是关于这个变化的，但我没听懂。
Mathias Nyman 已更新了他的补丁。他最初的更改（带有错误）已在 Ubuntu 内核中，但他修复该错误的补丁却不在。Mathias Nyman 的补丁在主线内核中，如下所示v5.16-rc3-1-g09f736aa9547，这意味着它被包含在5.16主线内核中。根据https://kernel.ubuntu.com/，下一个 Ubuntu 版本 Jammy Jellyfish / 22.04 LTS 将基于上游内核5.15，我认为这意味着 Ubuntu 22.04 LTS 对我来说仍然会有一个损坏的键盘和鼠标，除非 Mathias Nyman 的补丁被添加到 Ubuntu 内核中。
我已经问过了#ubuntu 内核IRC 频道，但我可能在提问的时候没有太多人在线，无法看到我的问题。或者如果我查看日志文件，也许那个频道不太活跃。
我报告了 Launchpad 上的一个错误：https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1963555
还有什么我可以/应该做的吗？
答案1
我报告了一个错误：https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1963555
该错误的当前状态：确认的。
从用户的角度来看，我们无法再做任何事情，我们必须等待，直到 Ubuntu 内核开发人员在 21.10 和/或 22.04 的内核中包含所需的补丁。
如果主线补丁未添加到 Ubuntu 内核，那么最坏的情况是该问题将在 Ubuntu 22.10 中得到修复而无需采取任何措施，而 Ubuntu 22.10 可能会使用5.16或5.17内核。
在错误修复之前可能的解决方法：
- 内核固定于
5.13.0-22。 - 安装主线内核>=
5.16.0。 - 获取内核源代码（Ubuntu 或上游），修补内核并编译。
该错误存在于drivers/usb/host/xhci-ring.c，因此我预计它不仅会影响输入设备，还会影响其他设备，例如外部硬盘。