Poslední příspěvky

11

Hardware / Re:Uspávání JMicron převodníku USB-NVMe

« Poslední příspěvek od Michal Šmucr kdy Dnes v 00:18:20 »

Díky, projdu si to a vyzkouším.

Napájením si to troufnu říct nebude. S testováním je to malinko problém - ten převodník je JEDINÝ disk, takže když se odpojí, systém se zasekne. Na lokálním terminálu vypíše "EXT4-fs (sda2): shut down requested (2)" a tím končí. Pomůže je PWR OFF/ON.

Zatím na tom jede jen čistý RaspberryOS bez GUI, nulová zátěž. Prakticky to nic nedělá, časem to má fungovat jen na sbírání logů a posílání alertů. Právě kvůli velkému počtu zápisů jsem tam hodil externí disk, protože karta by to nedala.

NZ. Mohly by tam být i nějaké další hlášky okolo, co by případně mohly něco dalšího napovědět.
Nevím, jak rychle a často to nastane, ale zkusil bych se tam připojit z jiného počítače přes ssh klienta.
Kdyby mezi tím byl stavový firewall, nebo něco, co by mě odpojovalo, tak bych ještě nastavil na klientu ssh keepalive
https://www.a2hosting.com/kb/getting-started-guide/accessing-your-account/keeping-ssh-connections-alive/
V té SSH session na RPi bych pak pustil:
sudo journalctl --dmesg -f
To by mělo interaktivně vypisovat všechny kernelové hlášky do momentu, než to úplně zhebne. A logoval bych to pak na tom klientu (buď klasicky přesměrovat do souboru, nebo třeba interní logování v PuTTY na Windows).

Jinak držím palce s těmi quirky a workaroundy.

12

Hardware / Re:Uspávání JMicron převodníku USB-NVMe

« Poslední příspěvek od Michal Šmucr kdy Dnes v 00:09:22 »

Jo no.. ty prevodniky jsou nekdy dost divne - napr. ja mam takovy USB box na sata, ve ktere mam live distribuci na testovani ruzneho hw co me prijde pod ruku - a onen prevodnik uplne nedava urcity suspend rezim, ktery vnuti deska (nevim zda to souvisi s charging portem). Nebo mozna jde o stav kdy se pozaduje nejake cteni, ale pak resnu komp a zustane to tam v bufferu - nicmene vysledek je: activity indicator na prevodniku blika jako kdyby se neco melo dit, ale uz disk nereaguje na enumeraci v biosu a nebootnu z nej. Musi to projit skutecnym power cycle (tj bud odpojit, nebo vypnout zdroj a pockat az se vybije 5VSB vetev).

Ano, taky se ke mě dostalo relativně dost USB zařízení, co měly nějaké divnosti, zdaleka nejen převodníky. Dost často to bylo i jen třeba špatně udělanými deskriptory, viz třeba ty zmíněné nutné quirky na vypínání LPM (kdyby to rovnou neinzerovali v deskriptoru, nebylo by to třeba). Mimo přechodů mezi suspend a resume stavy pak podobně třeba i různé problémy s low power a hi power (> 100mA) stavy, deklarace self/bus powered zařízení atp.
Nejvtipnější je pak to, jak se to prakticky chová. Že třeba máš zařízení, co jede evidentně mimo specifikaci, takže bys čekal, že to bude všude problém, ale potíže se vyjeví jen někde.
Před mnoha lety jsem spolupracoval na nějakém projektu, kde byla i USB zvukovka, základ nějaký XMOS, FW dělal jeden kluk z Holandska. Vyvíjel to na eval desce připojené k Macu, vestavěný class-compliant ovladač, paráda. Pak to zkusili na různých Windows počítačích s OEM ovladačem to bylo tak 50/50 chodí/nechodí, na Linuxu ani prd.
Pak se ke mě dostal prototyp a přesně tam byla primární příčina v těch špatných deskriptorech, po zjištění oprava na chvíli (pak ještě nějaké další věci, co chtělo doimplementovat a ošetřit v těch "šablonách" od XMOSu). Nicméně na tom Macu tohle paradoxně prošlo měsíce vcelku bez povšimnutí (WTF moment ).

S tím, co popisuješ u tvého převodníku, těžko říct, možná je to nějaký interní problém jeho FW, což se bude trochu blbě řešit. Děje se to (že to po rebootu neprojde enumerací) jen v kombinaci s tím počítačem, kde je ten charging port, nebo i s jinými?
Charging port by moc s nějakým autosuspendem režimem neměl úplně souviset. To spíš při rebootu může nastat to, že ten nabíjecí port neodpojí napájení (což se typicky u normálních portů děje), takže se zařízení neresetuje do nějakého výchozího režimu na připojení.
Na některých PC/deskách se ty Always-On režim dá i vypnout. Někdy se to jmenuje tak nějak krypticky, třeba Erp Ready (což je nějaká Euro regulace pro šetrná zařízení, která když se povolí, tak to zároveň vypne permanentní napájení USB portů).
I když pokud je to vyloženě (červený) charging port, tak tam můžou být ještě další věci okolo s kterými ten převodník může dál interagovat, PD čip, ošetření detekce dobíjení přes BC (což se děje přes D+ a D- linky).

13

Hardware / Re:Uspávání JMicron převodníku USB-NVMe

« Poslední příspěvek od aigor.net kdy 15. 02. 2025, 21:19:26 »

Neznám konkrétní zařízení, ani jsem moc nezkoumal podobné USB-NVMe řadiče, spíš USB-SATA.

Nicméně přesto zkusím nadhodit pár tipů. Bude to asi trochu o laborování.
...

Díky, projdu si to a vyzkouším.

Napájením si to troufnu říct nebude. S testováním je to malinko problém - ten převodník je JEDINÝ disk, takže když se odpojí, systém se zasekne. Na lokálním terminálu vypíše "EXT4-fs (sda2): shut down requested (2)" a tím končí. Pomůže je PWR OFF/ON.

Zatím na tom jede jen čistý RaspberryOS bez GUI, nulová zátěž. Prakticky to nic nedělá, časem to má fungovat jen na sbírání logů a posílání alertů. Právě kvůli velkému počtu zápisů jsem tam hodil externí disk, protože karta by to nedala.

14

Hardware / Hledám RAID kartu pro 4× SATA RAID1(10)

« Poslední příspěvek od LA MA kdy 15. 02. 2025, 19:57:00 »

Ahoj,

potrebujem poradit, nejaku lacnu a spolahlivu RAID kartu pre 4x SSD SATA zapojene do RAID1 (mozno 10), idealne chranenu pred vypadkom napajania (SSD sice nemaju ochranu - Samsung 850Pro....).

Bude pouzita v PC s chipsetom H610 (asus doska), Windows 11 Pro.

Dovod, podla manualu doska podporovala Intel RS, ale realita je taka, ze sa neda zapnut.

Takze hladam alternativu.

Pojde o lacnu alternativu k "profi" serveriku s DB pre 4 uzivatelov.

Dakujem.
 

15

Hardware / Re:Uspávání JMicron převodníku USB-NVMe

« Poslední příspěvek od RDa kdy 15. 02. 2025, 17:58:13 »

Jo no.. ty prevodniky jsou nekdy dost divne - napr. ja mam takovy USB box na sata, ve ktere mam live distribuci na testovani ruzneho hw co me prijde pod ruku - a onen prevodnik uplne nedava urcity suspend rezim, ktery vnuti deska (nevim zda to souvisi s charging portem). Nebo mozna jde o stav kdy se pozaduje nejake cteni, ale pak resnu komp a zustane to tam v bufferu - nicmene vysledek je: activity indicator na prevodniku blika jako kdyby se neco melo dit, ale uz disk nereaguje na enumeraci v biosu a nebootnu z nej. Musi to projit skutecnym power cycle (tj bud odpojit, nebo vypnout zdroj a pockat az se vybije 5VSB vetev).

16

Hardware / Re:Uspávání JMicron převodníku USB-NVMe

« Poslední příspěvek od Michal Šmucr kdy 15. 02. 2025, 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

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í

17

Bazar / Prodám sadu Hardwario (BigClown)

« Poslední příspěvek od trodden passive kdy 15. 02. 2025, 14:14:26 »

Prodám hardwario sadu (dříve BigClown) viz foto - USB rádio, detektor pohybu, detektor úniku vody, termostat, relé, clima, 2x skládaná sada s větším battery modulem - teploměr+vlhkoměr+VOC detektor(jen 1x) Vše plně funkční, kromě clima modulu.Spadl mě na zem a občas funguje a občas ne. Cena za komplet 3000,- + zásilkovna

18

Hardware / Re:Uspávání JMicron převodníku USB-NVMe

« Poslední příspěvek od RDa kdy 15. 02. 2025, 13:28:35 »

Podle me nejde o uspavani - to nema proc padat, max to udela prodlevu.

Mate RPI = problemovy USB power budget -> crash disku

Nektere prevodniky maj problem s UAS -> zkuste prepnout na usb-mass-storage driver, jak radi Michal

19

Odkladiště / Re:Obchodním sdělením ÚOOÚ

« Poslední příspěvek od LolPhirae kdy 15. 02. 2025, 11:13:58 »

Tak že, stěžovat si na ÚOOÚ u ÚOOÚ? .

No, už jsem to tady naznačoval , že to nebude příliš produktivní... 

20

Hardware / Re:Uspávání JMicron převodníku USB-NVMe

« Poslední příspěvek od Michal Šmucr kdy 15. 02. 2025, 11:04:39 »

Neznám konkrétní zařízení, ani jsem moc nezkoumal podobné USB-NVMe řadiče, spíš USB-SATA.

Nicméně přesto zkusím nadhodit pár tipů. Bude to asi trochu o laborování.

Pokud je problém s autosuspendem na úrovni USB zařízení, tak máte několik možností.
Zkusit kompletně vypnout autosuspend pro všechna USB zařízení (Parametr udává výchozí čas v sekundách, kdy je zařízení bez aktivity, než se uspí. Když se nastaví -1, autosuspend se vypne).
echo -1 > /sys/module/usbcore/parameters/autosuspend

Což by mohlo být zajímavé na základní ozkoušení. Pokud by to zabralo, můžete to pak např. nastavit jako parametr kernelu po bootu. Tzn. na rpi, přidat na konec řádku do /boot/cmdline.txt další parametr usbcore.autosuspend=-1

Můžete to také selektivně zakázat pouze na konkrétním zařízení.
Nejdřív si dohledejte, kde je to zapojené (sběrnice, zařízení), pomocí lsusb, případně lsusb -t. Pak najdete odpovídající cestu v sysfs a /sys/bus/devices
Tzn. například u mě je mass-storage zařízení 1-1.3 (můžete dál ověřit v iVendor, iProduct)
/sys/bus/usb/devices/1-1.3/
Tam se pak dá také zapsat timeout úplně stejným způsobem jako v předchozím případě:
echo -1 > /sys/bus/usb/devices/1-1.3/power/autosuspend

Pokud byste to pak chtěl aplikovat po startu, napíšete si jen nějaký skript, co to provede, případně systemd službu, udev pravidlo.

Další možnost je, že to suspend úplně nevyřeší, protože některá USB storage zařízení nechodí úplně hezky v UAS (USB Attached SCSI) režimu, třeba kvůli bugu ve firmware.
Naštěstí je pro tyhle případy možné konkrétní zařízení přepnout do standardního USB mass storage režimu pomocí tzn. usb-storage quirků. Je to v určitých situacích pomalejší, ale alespoň použitelné.
Viz.
https://forums.raspberrypi.com/viewtopic.php?f=28&t=245931

Tzn. když si potvrdíte, že to zařízení jede v UAS režimu, tak si zjistíte USB VID:PID a přidáte další parametr kernelu (zas /boot/cmdline.txt)

usb-storage.quirks=VID:PID:u (:u je pak speciální switch)

usb-storage.quirks má ještě víc parametrů, kdyžtak můžete experimentovat i dál
https://github.com/torvalds/linux/blob/7ff71e6d923969d933e1ba7e0db857782d36cd19/Documentation/admin-guide/kernel-parameters.txt#L7610

Finálně ještě odkážu na referenci quirků pro celý USB subsystém ze stejného dokumentu, kdyby bylo třeba ještě další laborování:

usbcore.quirks
https://github.com/torvalds/linux/blob/7ff71e6d923969d933e1ba7e0db857782d36cd19/Documentation/admin-guide/kernel-parameters.txt#L7531

Nakonec varianta - brod, než to vyřešíte jinak. Nastavit si cron úlohu, systemd timer, co pak periodicky sáhne na dané zařízení, aby se neuspalo. Ekvivalent toho vašeho občasného zápisu, čtení.
Většinou není třeba sahat na filesystém, postačí použít třeba hdparm nebo smartctl, co jednou za čas "sáhne" na zařízení.. Např. hdparm /dev/sda