From 8b9c3c86dbf3a0579cc43a3f15a0f2b61d9e9009 Mon Sep 17 00:00:00 2001 From: Marius Date: Fri, 28 Aug 2026 12:13:12 +0300 Subject: [PATCH] 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) Claude-Session: https://claude.ai/code/session_01VAEUqrv26jCM5KwAPtkHb8 --- .../incidents/2026-08-27-pveelite-down.md | 90 +++++++++++++++---- 1 file changed, 72 insertions(+), 18 deletions(-) diff --git a/proxmox/cluster/incidents/2026-08-27-pveelite-down.md b/proxmox/cluster/incidents/2026-08-27-pveelite-down.md index 22099c6..3b86e8f 100644 --- a/proxmox/cluster/incidents/2026-08-27-pveelite-down.md +++ b/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. ---