Včera som sa dal do práce na vedľajšom projekte s nízkою prioritou s kódovým názvom bee weighter. Nejde o váženie samotných včiel, ale celého ich domova – úľa – aby bolo možné zistiť, či je plný medu na extrakciu.

Bohužiaľ som bol poriadne spomalený nepríjemným problémom, ktorý sa prejavuje touto chybou v celom rozsahu:

avrdude: ser_open(): can't open device "/dev/ttyACM0": Input/output error

Existuje samozrejme vlákno na Unix Stack Exchange venované tomuto problému, no najlepšie, čo som z neho vyťažil, bolo akési obídenie problému:

sudo modprobe -r cdc_acm && sudo modprobe cc_acm

Musel som to spúšťať zakaždým pred každým príkazom, ktorý pracoval s portom /dev/ttyACM0 – či už pri nahrávaní skice do Arduino Pro Micro 3.3V/8MHz od SparkFun, alebo pri pristupovaní k sériovému portu na kontrolu váhových dát alebo dátumu a času z čipu reálneho času (RTC). Jedinou výnimkou, keď modprobe nebol potrebný, bolo rýchle po sebe idúce spustenie príkazov na prístup k sériovému portu. Bolo to veľmi frustrujúce.

Najprv som si myslel, že problémom môže byť jadro linux-zen, ktoré používam na spúšťanie F-Droid aplikácií na Linuxe. Niektoré výsledky vyhľadávania naznačovali, že vlastné jadro môže byť problémom, ale zavedenie bežného jadra dodaného s Arch problém nevyriešilo. Pre istotu som sa nabootoval do Windows 10 a tam všetko fungovalo.

Potom som narazil na tento komentár vo vlákne na Reddite venovanom tomu istému problému, a ten mi pomohol.

Stručne povedané, vlákno diskutovalo o tom, že problém je pravdepodobne spojený s jadrom, pričom poukazovalo na konkrétne verzie jadra vykazujúce tento problém. Riešením pre mňa bolo vypnutie funkcie automatického pozastavenia USB. Je to možné urobiť aspoň tromi spôsobmi:

  1. Cez parameter jadra bootloadera (pozri odkaz na Stack Exchange vyššie)
  2. Cez pravidlá udev (pozri odkazy nižšie)
  3. Cez konfiguráciu tlp (riešenie z vyššie spomínaného vlákna na Reddite)

tlp som mal už nainštalovaný. Používa sa na správu napájania v Linuxe. Riešenie spočíva v editovaní /etc/tlp.conf, odkomentovaní a nastavení USB_AUTOSUSPEND=0. Po reštarte problém zmizol.

Treba poznamenať, že to pravdepodobne znamená, že notebook môže vydržať trochu menej na batériu a špecifické pravidlo udev pre toto by mohlo byť optimálnejšie. Nepodarilo sa mi to takto rozbehnúť, ale rád by som videl také riešenie.

Toto je 60. príspevok #100daystooffload.

Odkazy pre udev #