tl;dr:
- Tastatura și mouse-ul nu funcționează cu anumite nuclee.
- Nu cer o soluție, o am deja.
- Folosind
git bisect, am identificat commit-ul exact în depozitul de kernel Ubuntu unde dispozitivele mele de intrare nu mai funcționează.
- Ce fac în continuare, având în vedere că ruperea nu are loc în nucleele mai recente din amonte?
Dispozitivele mele de intrare USB:
- Tastatură cu fir Logitech G19
- Mouse cu fir Logitech G502
- Tastatură Sharkoon (foarte de bază, fără iluminare a tastaturii, fără afișaj, fără butoane suplimentare speciale)
Versiunea Ubuntu: 21.10
Funcționalitate normală (așteptată):
- În Grub:
- Luminile pentru tastatură și mouse sunt pe
- LED-ul NumLock se stinge și se aprinde când apăs în mod repetat tasta NumLock
- Tastatura funcționează (pot folosi tastele săgeți în meniul Grub)
- În ecranul de conectare Gnome:
- Luminile pentru tastatură și mouse sunt pe
- LED-ul NumLock se stinge și se aprinde când apăs în mod repetat tasta NumLock
- Indicatorul mouse-ului pe ecran mișcări când mișc mouse-ul
- Tastarea funcționează (îmi pot introduce parola în ecranul de conectare)
Când nu funcționează:
- În Grub:
- Luminile pentru tastatură și mouse sunt pe
- LED-ul NumLock se stinge și se aprinde când apăs în mod repetat tasta NumLock
- Tastatura funcționează (pot folosi tastele săgeți în meniul Grub)
- În ecranul de conectare Gnome:
- Luminile pentru tastatură și mouse sunt oprit
- LED-ul NumLock este stins și rămâne stins când apăs în mod repetat tasta NumLock
- Indicatorul mouse-ului pe ecran nu se mișcă când mișc mouse-ul
- Tastarea nu funcționează
Cu cele de mai sus, am un scenariu foarte solid pentru a testa dacă un anumit nucleu funcționează pentru mine sau nu. Am instalat diverse nuclee cu 3 metode:
- Folosind
apt -> Nuclee Ubuntu, disponibile din depozitul Ubuntu
- Folosind Ubuntu Mainline Kernel Installer -> nuclee pre-compilate de la kernel.org.
- Folosind nucleele Ubuntu din care m-am compilat git://kernel.ubuntu.com/ubuntu/ubuntu-impish.git. obisnuiam
git bisect pentru a verifica diferite comiteri și apoi a construi fiecare dintre acestea, astfel încât să pot găsi comiterea exactă în care tastatura și mouse-ul nu mai funcționează.
- Miezuri de lucru, testate:
- 5.13.0-051300-generic (UKMI)
- 5.13.0-19-generic (apt)
- 5.13.0-20-generic (apt)
- 5.13.0-21-generic (apt)
- 5.13.0-22-generic (apt)
- Ubuntu-5.13.0-22.22-0-g3ab15e228151 (compilat)
- Ubuntu-5.13.0-22.22-317-g398351230dab (compilat)
- Ubuntu-5.13.0-22.22-356-g8ac4e2604dae (compilat)
- Ubuntu-5.13.0-22.22-376-gfab6fb5e61e1 (compilat)
- Ubuntu-5.13.0-22.22-386-gce5ff9b36bc3 (compilat)
- 5.16.11-051611-generic (UMKI)
- Nuezele eșuate, testate:
- Ubuntu-5.13.0-22.22-387-g0fc979747dec (compilat)
- Ubuntu-5.13.0-22.22-388-gab2802ea6621 (compilat)
- Ubuntu-5.13.0-22.22-391-ge24e59fa409c (compilat)
- Ubuntu-5.13.0-22.22-396-gc3d35f3acc3a (compilat)
- Ubuntu-5.13.0-22.22-475-g79b62d0bba89 (compilat)
- Ubuntu-5.13.0-23.23-0-gb188ba567fc9 (compilat)
- 5.13.0-23-generic (apt)
- 5.13.0-25-generic (apt)
- 5.13.0-27-generic (apt)
- 5.13.0-28-generic (apt)
- 5.13.0-30-generic (apt)
Kernel 5.13.0-22 este cel mai recent kernel Ubuntu furnizat prin apt asta funcționează pentru mine, așa că am fixat acea versiune pentru a preveni upgrade-urile automate.Cum am făcut exact asta, este în afara domeniului de aplicare al întrebării mele.
5.13.0-23 este primul kernel Ubuntu care sparge tastatura și mouse-ul pentru mine, așa că știu că commit-ul care îl întrerupe trebuie să fie undeva între 5.13.0-22 și 5.13.0-23. obisnuiam git bisect pentru a identifica comiterea exactă și l-am găsit. Asta însemna să alergi git bisect, compilarea și instalarea nucleului, repornirea, testarea dacă dispozitivele de intrare funcționează și apoi face git bisect good sau git bisect rău, conform rezultatului testului. Fiecare compilație a durat aproximativ 22 de minute, așa că vă puteți imagina că mi-a luat destul de mult timp!
Comiterea exactă în care dispozitivele mele de intrare nu mai funcționează este Ubuntu-5.13.0-22.22-387-g0fc979747dec. Conține această modificare:
xhci: Remediați corupția indicatorului inelului de comandă în timp ce anulați o comandă
BugLink: https://bugs.launchpad.net/bugs/1951880
comite ff0e50d3564f33b7f4b35cadeabd951d66cfc570 în amonte.
Indicatorul inelului de comandă este situat la [6:63] biți ai comenzii
registru de control inel (CRCR). Toți biții de control, cum ar fi comanda oprire,
abort sunt situate la [0:3] biți. În timp ce anulăm o comandă, citim
CRCR și setați bitul de anulare și scrieți în CRCR. Citirea va fi mereu
dați indicatorul inelului de comandă ca toate zerourile. Deci, în esență, scriem doar
biţii de control. Deoarece am împărțit scrierea pe 64 de biți în două scrieri pe 32 de biți,
există posibilitatea ca inelul de comandă xHC să se oprească înainte de partea superioară
dword (toate zerourile) este scris. Dacă se întâmplă acest lucru, xHC actualizează partea superioară
dword a indicatorului său de inel de comandă intern cu toate zerourile. Data viitoare,
când inelul de comandă este repornit, vedem erori de acces la memoria xHC.
Remediați această problemă scriind doar în dword inferior al CRCR, unde toate
sunt localizați biții de control.
Cc: [email protected]
Semnat de: Pavankumar Kondeti <[email protected]>
Semnat de: Mathias Nyman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Semnat de: Greg Kroah-Hartman <[email protected]>
Semnat de: Kamal Mostafa <[email protected]>
Semnat de: Stefan Bader <[email protected]>
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
indice 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,
/* Trebuie apelat cu xhci->lock deținut, eliberează și dobândește blocarea înapoi */
static int xhci_abort_cmd_ring(struct xhci_hcd *xhci, steaguri lungi nesemnate)
{
- u64 temp_64;
+ u32 temp_32;
int ret;
xhci_dbg(xhci, „Anulați inelul de comandă\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);
+ /*
+ * Biții de control, cum ar fi comanda stop, abort sunt localizați în partea inferioară
+ * dword al registrului de control al inelului de comandă. Limitați scrierea
+ * la dword inferior pentru a evita coruperea indicatorului inelului de comandă
+ * în cazul în care inelul de comandă este oprit până la ora dword superioară
+ * este scris.
+ */
+ temp_32 = readl(&xhci->op_regs->cmd_ring);
+ writel(temp_32 | CMD_RING_ABORT, &xhci->op_regs->cmd_ring);
/* Secțiunea 4.6.1.2 din specificațiile xHCI 1.0 spune că software-ul ar trebui, de asemenea,
* finalizarea operațiunii Command Abort. Dacă CRR nu este negat în 5
Cel legat Eroare Launchpad nu aduce nimic util, deoarece nu este vorba doar despre această schimbare.
Cel legat fir de e-mail între Mathias Nyman, Pavan Kondeti și youling257 este vorba despre această schimbare, totuși conversația îmi trece peste cap.
Mathias Nyman a făcut o actualizare la patch-ul său. Schimbarea sa inițială (cu o eroare) este deja în nucleul Ubuntu, patch-ul în care a remediat-o, nu este. Patch-ul de la Mathias Nyman este în nucleul principal ca v5.16-rc3-1-g09f736aa9547, ceea ce înseamnă că este inclus în 5.16 nucleul principal. Conform https://kernel.ubuntu.com/, următoarea versiune Ubuntu, Jammy Jellyfish / 22.04 LTS, se va baza pe upstream 5.15 kernel, care presupun că înseamnă că Ubuntu 22.04 LTS va avea în continuare o tastatură și un mouse stricate pentru mine, cu excepția cazului în care patch-ul lui Mathias Nyman este adăugat la nucleul Ubuntu.
Am întrebat pe #ubuntu-kernel Canal IRC, dar poate că am întrebat într-un moment în care nu mulți oameni erau online să-mi vadă întrebarea. Sau poate că acel canal pur și simplu nu este foarte activ, dacă mă uit la fișierele jurnal.
Am raportat o eroare pe Launchpad: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1963555
Mai pot/ar trebui să fac altceva?
