Puncte:1

regresie focală: conexiunea USB la APC SmartUPS eșuează după repornire

drapel cn

Gestionez aproximativ nouăzeci de servere Dell distribuite în întreaga lume, în prezent în curs de actualizare de la Ubuntu 16.04LTS xenial la Ubuntu 20.04LTS focal. Sursa de alimentare a fiecărui server este protejată de un SmartUPS APC conectat prin USB și monitorizat de piuliță pentru a se opri în mod curat în caz de pană de curent. Acest lucru funcționează destul de bine pe serverele care rulează încă xenial.

Pe cei care rulează focal, există o problemă frecventă cu conexiunea USB la UPS care nu apare după o repornire. Specific:

  • În timpul pornirii sistemului, nucleul nu detectează UPS-ul și se plânge în /var/log/syslog:

    kernel: [ 2.239216] usb usb1-port4: nu s-a putut aloca usb_device
    
  • upsmon se plânge periodic în syslog:

    upsmon[1105]: Sondajul UPS [ups@localhost] a eșuat - Driverul nu este conectat
    
  • SmartUPS nu apare în ieșirea lui lsusb:

    a-schmidt@undeva:~$ lsusb
    Bus 002 Dispozitiv 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
    Autobuz 001 Dispozitiv 004: ID 1604:10c0 Tascam
    Autobuz 001 Dispozitiv 003: ID 1604:10c0 Tascam
    Autobuz 001 Dispozitiv 002: ID 1604:10c0 Tascam
    Bus 001 Dispozitiv 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
    
  • Alergare sudo upsdrvctl start raportează manual că nu poate găsi dispozitivul:

    a-schmidt@somewhere:~$ sudo upsdrvctl start
    Network UPS Tools - Controler de driver UPS 2.7.4
    Network UPS Tools - Driver HID generic 0.41 (2.7.4)
    Driver de comunicare USB 0.33
    Nu s-au găsit UPS HID care se potrivesc
    Driverul nu a pornit (starea de ieșire=1)
    

Efectuând o resetare a magistralei USB prin secvența de comandă:

ecou '0000:00:14.0' | sudo tee /sys/bus/pci/drivers/xhci_hcd/unbind
ecou '0000:00:14.0' | sudo tee /sys/bus/pci/drivers/xhci_hcd/bind

ajuta de fiecare data. UPS-ul este detectat, după cum arată mesajul /var/log/syslog:

kernel: [20025.662161] usb 1-4: nou dispozitiv USB de viteză completă numărul 2 folosind xhci_hcd
kernel: [20025.838902] usb 1-4: a fost găsit un nou dispozitiv USB, idVendor=051d, idProduct=0003, bcdDevice= 0.01
kernel: [20025.838907] usb 1-4: șiruri noi de dispozitive USB: Mfr=1, Product=2, SerialNumber=3
kernel: [20025.838910] usb 1-4: Produs: Smart-UPS_1500 FW:UPS 04.1 / ID=1018
nucleu: [20025.838913] usb 1-4: Producător: American Power Conversion

Apare în lsusb, și upsdrvctl start se conectează cu succes:

a-schmidt@undeva:~$ lsusb
Bus 002 Dispozitiv 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Autobuz 001 Dispozitiv 002: ID 051d:0002 Sursă neîntreruptibilă de conversie a energiei americane
Autobuz 001 Dispozitiv 005: ID 1604:10c0 Tascam
Autobuz 001 Dispozitiv 004: ID 1604:10c0 Tascam
Autobuz 001 Dispozitiv 003: ID 1604:10c0 Tascam
Bus 001 Dispozitiv 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
a-schmidt@somewhere:~$ sudo upsdrvctl start
Network UPS Tools - Controler de driver UPS 2.7.4
Network UPS Tools - Driver HID generic 0.41 (2.7.4)
Driver de comunicare USB 0.33
Folosind subdriver: APC HID 0.96

upsmon încetează să se plângă și totul este bine din nou.

Care ar putea fi motivul acestui comportament și cum îl pot remedia?

Tilman avatar
drapel cn
Oare cei care au primit cele trei voturi de închidere s-ar gândi să împărtășească ce regulă comunității cred că încalcă întrebarea?
24601 avatar
drapel in
Din câte văd, voturile apropiate se referă la rapoarte de erori care ar trebui raportate [aici](https://bugs.launchpad.net/ubuntu/+filebug/?no-redirect)
Puncte:0
drapel cn

Acest lucru pare să fie cauzat de o eroare a nucleului deja raportată la Launchpad aici:

[regresie] Dispozitivul USB nu este detectat în timpul pornirii

și la kernel.org Bugzilla aici:

Eroare 214021 - Dispozitivele USB nu pot fi detectate în timpul pornirii

Deci soluția ar fi să așteptați până când un nucleu fix este disponibil.

Notă: am încercat să adaug un @reboot intrarea crontab pentru a rula secvența de comandă de resetare a magistralei USB după fiecare repornire ca măsură temporară, dar asta nu a funcționat deoarece @reboot se întâmplă prea târziu în procesul de pornire când nuca driverul rulează deja, așa că am renunțat la această idee.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.