1
Hardware / Re:Uspávání JMicron převodníku USB-NVMe
« Poslední příspěvek od Michal Šmucr kdy Dnes v 15:15:20 »Podle me nejde o uspavani - to nema proc padat, max to udela prodlevu.
Ta normální prodleva, kdy systém čeká na blok. zařízení, by asi byla v pohodě, jestliže se to vejde do timeoutu (tuším 30s je výchozí), ale záleží co tam konkrétně nastává za problém.
Stává se občas taky, že třeba zařízení nedá korektně suspend-resume cyklus, což by prakticky znamenalo např. to, že to nezhebne hned při suspendu, ale až při další aktivitě, kdy by se to mělo probrat.
Takže buď zabránit suspendu nebo zkusit místo resume resetovat (mě to třeba onehdá pomohlo s nějakou zvukovkou).
Proto jsem výše odkazoval na všechny quirky od modulu usbcore.
USB_QUIRK_RESET_RESUME - udělá místo resume reset
USB_QUIRK_NO_LPM - další možný workaround, pokud zařízení blbne s LPM rozšířením (umožňuje víc úrovní šetření a rychlejší přechody, když je potřeba), tak dá se to vypnout
Když se podívám do výchozích quirků, tak jsou tam pro nejrůznější typy zařízení včetně flešek, USB disků.
https://github.com/torvalds/linux/blob/7ff71e6d923969d933e1ba7e0db857782d36cd19/drivers/usb/core/quirks.c#L192
Citace
Mate RPI = problemovy USB power budget -> crash disku
To mi na začátku přišlo jako nepravděpodobné, protože bych tak na první dobrou čekal, že to zařízení bude mít nejvyšší odběr při aktivitě z hosta, ne v idle. Ale jak jsi to teď napsal, tak se mi to rozleželo a přijde mi to dobrý tip. Možná, jestli je to s výkonem na hraně, tak by to možná stálo taky za kontrolu třeba z jiného PC s Linuxem (byť by to byla i nějaká živá distribuce).
Nějak jsem si neuvědomil, že je to SSD, co právě spouští interní úlohy na pozadí (folding/GC, TRIM, bad block mgmt.), když žádná aktivita z hosta není a mohlo by to mít v tu chvíli paradoxně ještě vyšší odběr.
Tak uvidíme, jestli tazatel s něčím pochodí
![Úsměv :)](http://forum.root.cz/Smileys/default/smiley.gif)