Výzkumníci ukazují, jak mohou otevřené tunely a IPv6 Extension Headers synchronizovat pakety do krátkých provozních špiček. V kontrolovaném experimentu naměřili přes 180násobnou koncentraci paketového toku vůči průměrné rychlosti odesílání — nikoli 180násobné zvětšení objemu dat. Článek obsahuje metodiku, limity měření i mitigace pro GRE, IPIP a další tunely.
Po velkém úspěchu prvního MobileLinux Hackdaye se vracíme do Českých Budějovic s druhým ročníkem. V pátek 30. října 2026 od 10:00 se v prostorách Jihočeské univerzity uskuteční Embedded & MobileLinux Hackday #2. Těšit se můžete na témata jako Immutable Linux na telefonech (BengalOS), U-Boot a upstream vývoj, AI optimalizace pro embedded systémy nebo otevřený hardware. Nebude chybět praktické hackování, sdílení zkušeností a možnost … více »
Dne 21. října 2026 vydal projekt Node.js bezpečnostní aktualizace opravující deset zranitelností, včetně jedné umožňující potenciální vzdálené spuštění kódu (RCE). Nejzajímavější je CVE-2026-111497, chyba dekodéru Brotli, kterou objevili výzkumníci využívající OpenAI Codex Security. Chyba je v nativním dekodéru Brotli, nikoli v samotném JavaScriptu. Speciálně vytvořený komprimovaný vstup způsobí, že dekodér zamění
… více »Francouzský výrobce kabelů Nexans upozornil na napjaté dodávky elektrických kabelů. Výstavba nové výrobní linky pro některé typy kabelů může trvat přibližně tři roky. Datacentra potřebují rozsáhlé nízkonapěťové a středněnapěťové rozvody. Poptávka roste současně s modernizací elektrických sítí. Někteří odběratelé proto uzavírají výrazně delší dodavatelské smlouvy [Reuters].
Představena byla (𝕏) virtuální platforma FLYBENCH FPV, která nováčky provede zapojením a konstrukcí dronů.
Google Chrome 156 byl prohlášen za stabilní. Přehled novinek v poznámkách k vydání. Opraveno bylo 353 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Indická společnost eMudhra po bezpečnostním incidentu, tj. kompromitaci soukromých klíčů osmi mezilehlých certifikátů své certifikační autority, opouští globální byznys s SSL/TLS certifikáty.
Dle Phoronixu zveřejnila společnost Trend Micro prostřednictvím programu Zero Day Initiative (ZDI) několik hlášení bezpečnostních zranitelností přímo na veřejném mailing listu LKML, přestože některé chyby dosud nemají opravu začleněnou do hlavní větve jádra. Mezi hlášenými problémy jsou dvě zranitelnosti s hodnocením CVSS 9.0, týkající se SMB Direct a KSMBD, které mohou umožnit vzdálené spuštění kódu. Další hlášení se týkají … více »
Správce hesel KeePassXC byl vydán ve verzi 2.8.0. Přechází na Qt 6, podporuje vkládání hesel s Waylandem, rychlé odemykání pomocí Polkitu nebo možnost nastavení klávesových zkratek (seznam změn).
Databáze DuckDB (Wikipedie) byla vydána ve verzi 2.0.0 LTS. S kódovým názvem Cinnamon Teal (čírka skořicová). S vyladěným protokolem Quack.
Řešení dotazu:
Aha, takže přece jenom TQ. To je dobře - s expandérem by bylo o problém víc.
Že ta věc při startu nepiští, ačkoli je Areca připojená, pro to mám několik možných vysvětlení:
1) Areca udělala nějakou změnu ve firmwaru, aby backplany SuperMicro při startu nepištěly. To se mi ale moc nezdá, protože by se tím jenom skryl skutečný problém = rušení bzučáku na TQ backplanu do některých datových vedení / SATA lanes
2) Máte TQ backplane najumperovaný z výroby na defaultech = supermicro proprietary I2C. Takže Vám to SGPIO vlastně nefunguje. Mrkněte se do manuálu ke skříni resp. k backplanu, je to v tomto případě 1 jumper - např. tady na straně "2-6" v tisku (13 ze 17 v PDF souboru):
http://www.supermicro.com/manuals/other/BPN-SAS-836TQ.pdf
Svého času býval default I2C. Podle aktuálního manuálu je ale default SGPIO. Žeby SuperMicro udělalo změnu? Možná, že ten HW bug s bzučákem taky konečně opravili?
3) já to možná testoval jenom s Arecou 1261ML nebo 1280, to jsou SATA-only modely, možná mají jinak řešený SGPIO výstup. Možná proto se Vaše sestava při bootu chová jinak.
Fungují Vám červené "failure" LEDky, když dáte v RAIDu povel "identify drive"? V tom případě SGPIO funguje.
Pokud nefunguje, zkontroloval bych jumper na backplanu, zapojení šedých kšandiček co koukají ze "SFF-8087 chobotnic", a možná by se našla položka v konfiguraci Arecy, která volí enclosure management mezi SES2-over-SAS vs. SGPIO.
Pokud smíte ten stroj vypnout, doporučuji najít na backplanu bzučák a podívat se, kde koukají jeho nožičky na "straně disků". Býval to tuším snad šuplík číslo 8 (druhý shora v pravém sloupci). Možná vrchní řada úplně vpravo. Pokud má bzučák ze strany disků mezi nožičkami viditelnou dvojici spojů na plošáku (= SATA lane), tak doporučuju bzučák uloupnout. Nebo žeby tam bzučák už vůbec nebyl? 
Doporučuju ten bzučák zkontrolovat - problém je, že když Vám vypadne z RAIDu za provozu disk, bzučák na backplanu začne kvičet, a shodí další disk nebo dva. Což sundá celé pole. Mimochodem ten bzučák není piezo, ale dynamický. Zřejmě právě proto ruší.
Areca má svůj vlastní bzučák = na kartě RAIDového řadiče. Pokud máte v konfiguraci Arecy povolený bzučák, je to ten její onboard. Bzučák na backplanu je jiná záležitost - ten se v konfiguraci RAIDu vypnout nedá. Podle mého nemá na backplanu ani jumper, kterým by šel umlčet. Takže když se vysype RAID, neslyšíte jeden bzučák, ale dva 
Mimochodem je podle mého nesmysl, že by jeden chybějící disk způsobil, že není vidět celé pole. To mi přijde krajně divné až nesmyslné - s jedním vypadlým diskem (v RAIDu6 se dvěma) musí pole normálně nabootovat. Pokud před restartem nestihlo dokončit inicializaci, měla by tato po restartu pokračovat tam, kde před restartem skončila.
Když si to čtu znova, mám pocit, že je asi něco blbě s diskama. A našel jsem googlem tohle:
http://blog.insanegenius.com/2009/09/western-digital-re4-gp-2tb-drive.html
http://blog.insanegenius.com/2009/10/hitachi-a7k2000-and-seagate-barracude.html

Pár navazujících dotazů a poznámek:
Na tom odkazovaném webu jsou popsány problémy s konkrétními řadiči Areca, Adaptec a LSI skrz expandér proti WD RE4 GP. Společné body: disky WD, expandér, a na RAIDu procesor Intel IOP348 s on-chip SAS řadičem (těžko říct, kdo dodal Intelu "SAS IP Core", tipuju LSI nebo možná Agilent).
Ten SuperMicro server, nemá to náhodou E1/E2 SASový backplane s expandérem? SATA přes expandéry je občas docela svinstvo. (Pro srovnání, zmiňovaný TQčkový backplane má jenom pasivní propoj na jednotlivé disky.) Nicméně podle některých zmínek v diskusi na výše uvedených URL soudím, že je to na expandéru nezávislé, že ten problém je někde uvnitř firmwaru disku a týká se nějakých bugů při reakcích na SATA commandy ve chvíli, kdy ten disk zároveň provádí nějakou "změnu stavu" v interním power managementu.
Osobně jsem před časem otestoval jenom 2 ks WD10EADS (1TB) bez problému proti Arece s procesorem IOP341, kde SAS HBA je realizován samostatným LSI HBA čipem, skrz expandér s čipsetem taktéž od LSI.
Jinak se všechny moje dosavadní zkušenosti s Arecou v SuperMicru a v AXUSu týkají disků Seagate - a bez problému.
Tiskni
Sdílej: