- Hiena blogja
- A hozzászóláshoz be kell jelentkezni
- 1179 megtekintés
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. :)
- A hozzászóláshoz be kell jelentkezni
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!"..
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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..
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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. "
- A hozzászóláshoz be kell jelentkezni