docs(cluster): ipoteza mouse-ului USB, infirmata prin test la 8 minute

Commit-ul precedent (1c6ab0f) sustinea ca resetarile adaptorului USB LAN sunt
cauzate de un mouse defect care se re-enumera de ~1000 de ori pe zi pe acelasi
controller xHCI. Testul o infirma.

Portul mouse-ului dezactivat la 11:24:04; la 11:31:52 adaptorul s-a resetat
oricum, cu 0 re-enumerari de mouse si aceeasi semnatura de eroare
"xhci_hcd 0000:00:14.0: WARN Set TR Deq Ptr". Corelatia initiala era
coincidenta - mouse-ul se re-enumera la fiecare ~60 s, deci orice eveniment de
pe nod pica la cateva secunde dupa unul.

Ce ramane adevarat: mouse-ul e defect (1127 re-enumerari fata de 1 a tastaturii
pe acelasi hub) si merita inlocuit, dar e o problema separata.

Cauza resetarilor r8152 redevine necunoscuta - 6 resetari spontane in 20 h,
fara tipar. Suspecti netestati: adaptorul, portul/cablul USB3, controllerul,
alimentarea pe USB3. Mutarea pe eno1 redevine reparatia principala, fiindca
ocoleste intrebarea cu totul.

Sectiunea e pastrata cu ipoteza si infirmarea ei, ca sa nu fie reluata.

Nota buna: la resetul din 11:31:52 hotplug-ul a reatasat interfata in 4
secunde si corosync a reformat membership 1.1f4 cu 3 membri - un hopa de 10
secunde in loc de 16 ore.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VAEUqrv26jCM5KwAPtkHb8

proxmox/cluster/incidents/2026-08-27-pveelite-down.md

@@ -5,10 +5,11 @@ dar clusterul rămâne pe **2 voturi din 3**, fără marjă de quorum, și repli
 pveelite e oprită)
 **Detected:** 2026-08-27 17:31 EEST (alertă automată `pveelite-down-alert.sh` → email)
 **Resolved:** 2026-08-28 09:49 EEST (`ifreload -a` de la consola fizică)
-**Status:** **REZOLVAT** — cauză confirmată din jurnal. Pe 28.08 s-a găsit și cauza din
-spatele ei: un **mouse USB defect** care se re-enumera de ~1.000 de ori pe zi pe **același
-controller xHCI** ca adaptorul de rețea (vezi secțiunea dedicată). Portul lui e dezactivat
-din 11:24, ca experiment reversibil. Rămâne acțiunea de fond: mutarea rețelei pe `eno1`
+**Status:** **REZOLVAT** — mecanismul căderii e confirmat din jurnal (reset USB + interfață
+nereatașată în punte), iar regula de hotplug îl acoperă, demonstrat în producție. **De ce se
+resetează adaptorul rămâne necunoscut**: ipoteza unui mouse USB defect a fost formulată și
+**infirmată prin test** pe 28.08 (secțiunea dedicată). Acțiunea principală rămâne mutarea
+rețelei pe `eno1`
 **Author:** Claude Code (mmarius28@gmail.com)
 
 ---
@@ -112,11 +113,20 @@ pentru MCE, panic, temperatură peste prag, EDAC sau erori de I/O.
 
 ---
 
-### DE CE se reseta adaptorul: un mouse defect (2026-08-28, ora 11:20)
+### DE CE se resetează adaptorul: ipoteza mouse-ului, INFIRMATĂ prin test (2026-08-28)
 
-Secțiunea de mai sus explică *ce* s-a rupt — interfața recreată, nereatașată în punte. Nu
-explica însă **de ce adaptorul se reseta**, iar concluzia implicită („adaptoarele USB de
-rețea sunt nesigure prin natura lor") s-a dovedit greșită.
+> **Concluzia secțiunii, pe scurt:** un mouse USB defect **există** pe pveelite și merită
+> înlocuit, dar **nu el cauzează resetările adaptorului de rețea**. Testul controlat de la
+> 11:24 a infirmat ipoteza în 8 minute. Cauza resetărilor rămâne **necunoscută**, iar
+> mutarea pe `eno1` redevine reparația principală, nu una „de fond, pe lângă".
+>
+> Secțiunea e păstrată integral, cu ipoteza și infirmarea ei, ca să nu fie reluată.
+
+Secțiunea precedentă explică *ce* se rupe — interfața recreată, nereatașată în punte. Nu
+explica **de ce adaptorul se resetează**. Prima pistă a arătat foarte convingător, și a fost
+greșită.
+
+#### Ipoteza (11:20)
 
 **Un mouse optic defect, pe același controller xHCI, se re-enumera de o mie de ori pe zi.**
 
@@ -150,25 +160,69 @@ Toate cele 3 erori `xhci_hcd ... WARN` din boot-ul curent apar lipite de câte o
 r8152. Aceeași eroare deschide și citatul de la 16:01:45 din secțiunea precedentă — deci
 și căderea de 16 ore intră pe același tipar.
 
-**Mitigare aplicată la 11:24:04** — portul mouse-ului dezactivat din sysfs, fără acces fizic:
+#### Testul (11:24:04)
+
+Portul mouse-ului dezactivat din sysfs, fără acces fizic — experiment reversibil, deliberat
+**nepersistent** la reboot:
 
 ```bash
 echo 1 > /sys/bus/usb/devices/1-1:1.0/1-1-port1/disable   # anulare: echo 0
 ```
 
-Mouse-ul dispare din `lsusb`, tastatura rămâne. **NU e persistent la reboot** — e deliberat,
-ca să fie un experiment reversibil, nu o reparație.
+Mouse-ul dispare din `lsusb`, tastatura rămâne. Criteriul stabilit înainte de test: dacă
+resetările `r8152` încetează, ipoteza e validată.
 
-**De verificat înainte de a declara cauza confirmată:** dacă până la următoarea repornire nu
-mai apare nicio resetare `r8152`, ipoteza e validată și mitigarea merită făcută permanentă
-(regulă udev sau, mai bine, mouse-ul scos fizic — pveelite e nod headless).
+#### INFIRMARE (11:31:52 — la 8 minute după test)
 
-```bash
-ssh root@10.0.20.202 'journalctl --since "2026-08-28 11:24" | grep -cE "r8152.*reset|xhci_hcd 0000:00:14.0: WARN"'
+Adaptorul s-a resetat **cu mouse-ul complet oprit**, cu aceeași semnătură de eroare:
+
+```
+11:31:52  xhci_hcd 0000:00:14.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state.
+11:31:52  xhci_hcd 0000:00:14.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state.
+11:31:52  r8152-cfgselector 2-3: reset SuperSpeed USB device number 8 using xhci_hcd
 ```
 
-> Mutarea pe `eno1` rămâne validă și după asta — scoate rețeaua nodului de pe magistrala USB
-> cu totul. Dar ea era tratamentul; abia acum se știe boala.
+Contorii la 46 de minute după dezactivare (`journalctl --since "2026-08-28 11:24:04"`):
+
+| | |
+|---|---|
+| re-enumerări mouse | **0** — dezactivarea portului chiar a funcționat |
+| resetări `r8152` | **1** |
+| erori `xhci_hcd 0000:00:14.0: WARN` | **2** |
+
+Deci mouse-ul **nu e necesar** pentru producerea defectului. Corelația de la 10:31 (mouse
+re-enumerat, adaptor căzut 3 secunde mai târziu) a fost coincidență — mouse-ul se re-enumera
+la fiecare ~60 s, deci *orice* eveniment de pe nod pica la câteva secunde după unul.
+
+**Ce rămâne totuși adevărat:** mouse-ul e defect (1.127 re-enumerări față de 1 a tastaturii,
+pe același hub) și merită înlocuit pe cont propriu. Doar că e o defecțiune separată.
+
+#### Ce se știe acum despre resetări
+
+Șase resetări spontane în 20 de ore de uptime, fără tipar de oră și fără corelație cu
+încărcarea (nodul e idle):
+
+```
+27.08  17:26:40   <- caderea de 16 ore
+27.08  17:33:27
+28.08  05:50:29
+28.08  09:32:06
+28.08  10:31:39
+28.08  11:31:52   <- cu mouse-ul dezactivat
+```
+
+Suspecții rămași, netestați: adaptorul RTL8156B însuși, portul / cablul USB3, controllerul
+`xhci_hcd 0000:00:14.0`, alimentarea pe magistrala USB3. Un test ieftin, dacă se dorește
+înainte de switch: mutarea dongle-ului în alt port USB3 (schimbă portul și traseul, păstrează
+adaptorul) sau un alt adaptor USB LAN (schimbă adaptorul, păstrează portul).
+
+**Ce ține nodul în picioare până atunci: regula de hotplug.** La resetul din 11:31:52 a
+funcționat exact cum trebuie — reatașare în **4 secunde**, iar corosync a reformat membership
+`1.1f4` cu 3 membri la 11:32:02. Un hopa de 10 secunde în loc de 16 ore.
+
+> **Mutarea pe `eno1` redevine reparația principală**, nu una „de fond, pe lângă altele":
+> scoate rețeaua nodului de pe magistrala USB cu totul, deci nu are nevoie să știe care dintre
+> suspecții de mai sus e vinovatul.
 
 ---