Vlákno názorů k článku Z praxe: šest překážek Linuxu na cestě do malých firem (2/2) od pb. - Já bych poukázal ještě na jednu věc: absence...

Blbe googlis ... hledej raid45 module (ten jaksi neni, a s raid456 kterej jaksi je ... se to samo nebavi, pro par vyssich kernelu se jeste da splasit patch, ale pro ty soucasny bys ho uz musel celej prekopat)

Karta byla wifina na preskocich. Vic takhle zhlavy nedam, musel bych ji vyhrabat.

SW chybou se dá zničit spusta věcí. Kód driveru údajně pocházel od Samsungu, ale vztahoval se k úplně jiné verzi HW, používal nedokumentovnaý interface, a pracoval s pamětí BIOSu, nikoliv s UEFI. Jinými slovy driver byl určený pro jiný HW, jiný firmware, a nebyl vůbec testovaný na cílovém HW. Samozřejmě jinak je v tom Tux naprosto nevinně :D

SW chybou se nic normalniho znicit neda. To je vzdy a pouze chyba vyrobce.

Aha. Takže když SW zničí HW, tak je to chyba HW, a SW je vlastně naprosto v pohodě :D

Samozrejme, protoze normalni HW se pomoci SW znicit neda, a to v zadnem pripade.

To je samozřejmě nesmysl. Pokud může SW provést například flash firmwaru, může logicky způsobit, že bude HW nepoužitelný. Podobně se dá ze SW přestavit časování pamětí, zakázat bootování z HDD apod. Většinou se HW nezničí, ale pro laického uživatele zůstane nepoužitelný.

1. Aha. A proto při každém flashi zařízení vidím varování, že flash nemám přerušovat, protože jinak může dojít k poškození zařízení. Na desktopu mám náhodou desku se záložním BIOSem, ale to je velká výjimka.

2. Zkuste si otevřít pokročilá nastavení BIOSu, a tam například změnit napájecí napětí pamětí na příliš nízké nebo vysoké. Klidně to můžete udělat. V prvním případě vám stroj asi nenajede, v druhém případě bych čekal, že ty paměti navíc můžete po nějaké době usmažit.

Tomu "zničení HW" se říká "to brick (something)". Bohužel neznám žádný dobrý český překlad. Jinak oba výše popsané příklady nejsou o tom, že HW může poškodit výrobce, ale o tom, že ho obecně může poškodit špatně napsaný SW.

Flash firware muze zpusobit, ze bude HW nefunkcni, ale nemuze zpusobit zniceni HW. Neni pak nic snazsiho nez pripojit programator a flash opakovat.

Zmena casovani pameti nemuze pamet znicit, maximalne bude pamet nestabilni a bude vykazovat provozni chyby.

Pokud je moznost neco flashovat soucasti uzivatelskeho rozhrani (=vsechny PC MB trebas), tak je i nepovedeny flash a nestartujici deska ciste vina vyrobce, kterej to zmrvil.

LOL. Jak budete připojovat programátor například k základní desce, síťové kartě nebo kabelovému modemu? V některých případech můžete vyloupnout čip a vrazit ho do externího programátoru (a pak shánět naprogramovaný chip z jiného kusu stejného HW). Ve většině případů ten chip ale najdete připájený na desce, samozřejmě technologií SMT, takže ho nedostanete ven bez poškození spousty věcí kolem.

Fakta jsou taková, že HW lze těžce ublížit pomocí SW. Může se vám to nelíbit, ale to je tak všechno, co s tím můžete dělat. Podstata diskuse ale byla v něčem jiném. Pokud SW neúmyslně ten HW zničí, protože s ním provádí něco co nemá provádět, tak je zjevně *SW* vadný.

Ještě zjednodušené přirovnání. Pokud lze flashnout firmware telefonu náhodnou binárkou a tím ho odstavit, můžete klidně tvrdit, že je to chyba telefonu. Pokud vám ale takhle díky nějakému bugu odpraví telefon instalace Tetrisu nebo launcheru na telefonu s Androidem, těžko budete tvrdit, že je ten Tetris nebo launcher v pořádku.

V dnešní době se používá technologie ISP (In System Programming) - vetšina čipů ho podporuje.

Je to řešeno tak, že na desce jsou vyvedeny headery (piny, kontaktní plošky), ke kterým se připojí programátor (JTAG nebo novější SWD, používá se i UART aj.).

Programovaní čipů přímo v zařízení je levnější pro výrobce, nemusí čipy nejdřív programovat a pak osazovat, ale rovnou se na lince vyrobí celé zařízení, které se pak jednoduše naprogramuje a otestuje. Eliminací zbytečných kroků se výroba zlevní a chybovost při výrobě se sníží. Navíc výrobce dál může vyvíjet a upravovat firmware pro zařízení i při/po jeho výrobě bez nutnosti mít prototyp. Čili další eliminace zbytečné redundance.
Proto programovací kontakty najdeme dnes skoro ve všem.

Doba kdy bylo potřeba čip vyndat a strčit ho do programátoru skončila někdy koncem minulého století.

Jinak samozřejmě souhlasím s tím, že hardware který se nechá odpálit uživatelským softwarem si nic jiného nezaslouží.

OK, názory se mohou lišit :). A jak se postavíte k výroku "software který omylem odpálí HW je v pořádku"?

OK, na tom se shodneme. Ještě to vysvětlit zdejším uživatelům Linuxu, kteří si zjevně myslí, že když Linux poškodí nějaký HW, tak je to jen a pouze problém toho HW, a SW je v pohodě.

Původně byla řeč o noteboocích Samsung, které bylo možné odstavit zabootováním Linuxu. Na vině byl kernelový modul, který nebyl testovaný s cílovým HW, používá nedokumentovaný interface BIOSu (který kdysi fungoval někomu na nějakém předpotopním Samsungu), a díky bordelu v kernelu byl aktivovaný i při UEFI bootu. Ten kód nenapsal Samsung.

Podobně v případě odstavení CD-ROM mechanik nepsal kód ATA driveru výrobce LG. Autoři kernelu si usmysleli, že budou rozeznávat CD-ROM a CD-R mechaniky tak, že pošlou požadavek na zápis, a pokud to nevyhodí chybu, tak je to CD-R mechanika. Je to prasárna, protože detekce měla být prováděna standardně přes capability bits.

Podobně ničení síťových karet Intel e1000e nebylo způsobené kódem výrobce. Příčinou byl ftrace, který nebezpečně implementoval modifikaci živého kódu, a špatně koukal, kam zapisuje.

Jde o tři případy poškození HW různými bugy Linuxu. Otázkou je, kolik podobných špinavých hacků, nesprávných předpokladů, netestování driverů s cílovým HW a nesprávných zápisů do paměti zařízení v kódu Linuxu vyhnívá, a jenom šťastnou náhodou nezpůsobily zrovna k poškození HW.

ATA nedefinuje chování CD-ROM mechaniky v odpovědi na příkaz k zápisu. Driver CD-ROM mechanice takový příkaz vůbec nemá poslat, natož aby ho používal jako způsob detekce typu zařízení. Jenže jde o Linux, takže autoři driveru použili špinavý hack - a dopadlo to špatně.

Volba příkazu pro flash firmware byla možná nešťastná. ATA samozřejmě nepopisuje příkaz pro flash firmwaru, a výrobce ho nějak implementovat musí. Otázkou je, jestli daný příkaz vybrali před standardizací příkazů pro práci s CD-R, nebo až po ní. Každopádně to ake nic nemění na tom, že ten driver byl zprasený, a díky tomu došlo k odstavení HW.

Nic to nemeni leda na tom, ze takovy HW si chcipnout zaslouzi. Ostatne uplne stejne jako svyho casu(ne zas tak davno) sitovky intel ... ktere sejmul jejich vlastni SW, coz potesi, specielne na serverech.

A opět tu máme názor experta :). Pokud hovoříme o té samé věci, tak poškození karet s driverem e1000e způsobovala zmršená implementace ftrace. Byla použitá nebezpečná technika modifikace živého kódu, a navíc díky budu docházelo k modifikaci paměti na nesprávném místě. Otázkou je, kolik podobných problémů v kernelu Linuxu vyhnívá, a jen shodou okolností nepoškodily žádný HW.
http://lwn.net/Articles/304105/

Jinak děkuji za technologický update. Problém je v tom, že když uživateli SW například omylem přepíše firmware, tak je pro něj zařízení nepoužitelné, a musí do servisu. Jestli servis vymění board, vyjme čip a přeprogramuje ho, nebo zařízení rozebere a připojí externí programátor, to je už v podstatě detail.

Navíc HW lze zničit i řadou dalších postupů. Například řadu CTR monitorů bylo možné odpálit nastavením nesprávných obnovovacích frekvencí. U HDD zcela jistě snížíte životnost non-stop seekováním, a s "vhodným" firmwarem jistě nebude problém opakovaně zaparkovat hlavy na médiu a tím ho poškodit. Robot na pásky nebo optická média jistě vhodným SW opotřebujete, v řadě případů i rychle mechanicky poškodíte - například umlátíte rameno o zarážku. Podobně u skenerů. Dále můžete různé komponenty uvařit manipulací s chlazením, případně v kombinaci s vytížením nějaké části čipu, zvýšením napětí apod.