Próbáltad már kihúzni?

Testvérem asztali gépében egy ASUS A88X-PRO alaplap ketyeg. A gépen dual boot van, egy Ubuntu és egy Win 8.1 telepítéssel. A gép közel egy éve szépen muzsikál, jól tűrve az OS-ek közötti váltásokat. Aztán, tegnap délután, egy win->linux váltás után, fogta magát és megállt rajta a vezetékes hálózati interface. Se kép, se hang, se link, se ACK led. Totál halott az egész. Testvérem próbálkozott vele Win alatt, Linux alatt. Semmi változás. Tucatnyi ki-be kapcsolás és egy elbaszott délután után felhív, hogy segítsek neki talpra állítani a gépet. Jó másfél óra alatt végigmentünk az összes hálózati hibakeresési lépésen, kezdve a "jó kábelt használsz"-tól, a BIOS-on keresztül, egészen a driverekig. Végigtúrtuk az összes hw szintű beállítást. Az ethernet interface minkét OS alatt élt és virult. Csak épp a delej nem érkezett be a drótok felől.
Abban maradtunk, hogy alszunk rá egyet. Éjfél felé, még küldtem neki egy mailt, hogy mit nézzen még meg az ethtool-al.
Reggel, negyed kilenckor kaptam egy levelet, hogy a gép újból tökéletesen működik. Történ, hogy a tesónak eszébe jutott, hogy egyszer történt valami hasonló, és akkor a gép leáramtalanítása után eltűnt a hiba. Kilőtte a hosszabbítót a gép alól, és minő meglepetés, a rendszer magához tért.
Tehát, 2017-ben ott tartunk, hogy egy ME-vel, Trust zone-al, zseboperációrendszerekkel, pótpótpótpótprocesszorokkal fertőzött asztali számítógép resetnél, újraindulásnál, leállításnál, nem indul valóban újjá csak valami annak látszó tevékenységet folytat. A perifériák nem resetelődnek, a memóriáikban korábbi beállítások maradnak a tápfeszültség teljes elvételéig. Félelmetes, hogy egy klasszikus 286-os vagy 386-os dedikált reset gombja sokkal hatékonyabb eszköz.
Sanda gyanúm, hogy a ludas valami teljesítmény management flag lehet, ami szimplán lekapcsolta a PHY-t. És ez ironikus, mert valószínűleg, a processzorba integrált "backdoorok" és "management eszközök" működését is ugyanúgy blokkolja. Szintén ironikus, hogy egyik operációs rendszer sem biztosít lehetőséget, a lassan 20 évvel ezelőtti asztali számítógépekkel vetekedő teljesítménnyel rendelkező perifériák resetelésére és újraindítására.
Szóval, eljutottunk oda, hogy egy desktop PC ugyanúgy viselkedik mint egy dugasztápos olcsó kínai router.

Hozzászólások

Volt ilyen lan port tetszhalál már régebben is. MSI g31 lapoknál többször is láttam.
De találkoztam már olyan optiplexekkel is amik sima reboot után nem voltak hajlandóak usb bootra, kellett nekik egy teljes power cycle előtte.
Vannak ilyen anomáliák. A háztáji hardver gány. :)

Nem hiszem, hogy a háztáji HW lenne a ludas. Ha jól rémlik akkor a móka valami olyasmi, hogy minden S1/S2/S3 váltáskor az OS-nek le kell szólnia az adott HW-t működtető microcode/firmware-nek, hogy most akkor mi fog történni, hogy mindenki szépen úgy muzsikáljon ahogy azt a karmester szeretné. A gáz csak akkor van ha az egyik ilyen váltásnál valami beakad, vagy a kernel csak feltételezi, hogy a HW biztos megcsinálja amit kérsz tőle. Ilyenkor előfordulnak ilyen jellegű anomáliák (nekem USB portok szoktak általában meghülyülni ha suspend után húzom le a rájuk kötött eszközt és nem előtte).
A mechanizmus kb ugyan ez szervereknél is, csak ott ritkábban rángat az ember eszközöket, ritkábban indít újra, meg feltételezhetően (bár ebben nem lennék azért teljesen biztos) a szerver jellegű HW-k firmware-jét / microcodját némileg komolyabban megírják.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Otletem sincs hogy lehetne ugy megvalositani wake on lan-t, hogy kozben a halokartya tapot sem kap (etherneten keresztul sem). Valoszinuleg sehogy.
Igy viszont adodik a logikus kovetkeztetes, hogy ez akkor is tap alatt van (es akkor sem indul ujra), amikor egyebkent a gep tobbi resze nem. (sokszor az USB csatikon ilyenkor is van tap, meg persze az oran akkor is, ha kihuzod)

--
Worrying about killer AI and the superintelligent robots is like worrying about overcrowding on Mars. - Garry Kasparov

Gondolom Realtek cuccról van szó, ott ezt a problémát már szerintem egy évtizede tapasztalom, sőt olyat is lehet tapasztalni, hogy Linux+Win dualboot esetén, Linuxból Winbe bootolva az eth totál halott, csak az áramtalamítás segít..

Hasonló problémám nagy ritkán nekem is van az asztali gépemmel. Én arra jutottam, hogy a sima power off azért nem segít, mert standby tápról jár az interface, hiszen az egész gépet be tudom kapcsolni távolról. Az alábbi scriptem szokott segíteni:

#!/bin/bash

INTERFACE='p6p1'
DRIVER='r8169'
# ROOTSCRIPT="ethtool -s $INTERFACE advertise 0x008"
ROOTSCRIPT="modprobe -r $DRIVER; sleep 5; modprobe $DRIVER"

if [ $EUID -eq 0 ]; then
    $ROOTSCRIPT
else
    beesu - -P "$ROOTSCRIPT"
fi

A kommentelt résszel működött korábban, valamiért az már nem segít. Helyesebben szólva valami olyan hibaüzenetet ad, mintha a kernel vagy az ethtool nem támogatná az adott feature-t. Ezért lett most a driver kinyírása, majd újra betöltése.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az alaplapi ethernet vezérlők a WOL miatt, meg kb. ATX feltalálása óta (~20 év?) áram alatt maradnak. (szerk.: persze nem mindegyik, de a tiéd és a többség igen).
Ezt meg lehet figyelni úgy, hogy a link meg az activity led villódzik a gép kikapcsolása után is.
Szóval fogtatok egy szép hardveres hibát, amit úgy lehet kiküszöbölni, hogy az ethernet vezérlő áramtalanítódik, az meg csak úgy megy, ha az egész gépből kitéped a tápot.

--
arch,debian,retropie,osmc,android,windows

Az ATX szabványt 1995ben hozta ki az Intel, melynek az volt a célja, hogy az alaplap és házgyártók közötti kvázi szaványokat egységessé tegye és emellett az egész asztali PCt olcsóbbá tegye. A 3v3 alaplapról való kiutálása csökkentette az alaplap alkatrésszámát és a nagyobb kimeneti áram nagyobb rugalmasságot tett lehetővé az egy alaplap által támogatott processzorok terén. A csatlakozók és a panelméret, panelen található furatok szabványosításával a házgyártókat és kész konfgurációkat gyártókat segítette. A hagyományos, kapcsolós tápegységek helyetti stadby részint olcsósította a tápegységeket, másrészt lehetőséget biztosított távoli, vagy időzített management funkciókhoz. Az alaplapok is olcsóbbak lehettek, mert az addig használt NiCd és NiMh akksikat lecserélhettét a jóval olcsóbb LiIon akkukkal.
A probléma ott van elásva, hogy a gyártók, miközben komplett minix rendszereket ágyaznak be a processzorokba, elfelejtenek olyan apró funkciókat, mint mondjuk, lehetőséget biztosítani az "always-on" perifériák le és felkapcsolására, újrainicializálására és ennek user általi kontrollálásának a biztosítására. Bárki aki dolgozott huzamosabb ideig működő rendszerrel, annak ismert a különféle memóriafolyások, adatdegradációk. Egy folyamatosan bekapcsolt rendszernél ezeknek a kezelésére, mind hardveres, mind szoftveres oldalról fel kell készülni.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "