DuckDuckGo AI Chat umožňuje "pokecat si" s GPT-3.5 Turbo od OpenAI nebo Claude 1.2 Instant od Anthropic. Bez vytváření účtu. Všechny chaty jsou soukromé. DuckDuckGo je neukládá ani nepoužívá k trénování modelů umělé inteligence.
VASA-1, výzkumný projekt Microsoftu. Na vstupu stačí jediná fotka a zvukový záznam. Na výstupu je dokonalá mluvící nebo zpívající hlava. Prý si technologii nechá jenom pro sebe. Žádné demo, API nebo placená služba. Zatím.
Nová čísla časopisů od nakladatelství Raspberry Pi: MagPi 140 (pdf) a HackSpace 77 (pdf).
ESPHome, tj. open source systém umožňující nastavovat zařízení s čipy ESP (i dalšími) pomocí konfiguračních souborů a připojit je do domácí automatizace, například do Home Assistantu, byl vydán ve verzi 2024.4.0.
LF AI & Data Foundation patřící pod Linux Foundation spustila Open Platform for Enterprise AI (OPEA).
Neziskové průmyslové konsorcium Khronos Group vydalo verzi 1.1 specifikace OpenXR (Wikipedie), tj. standardu specifikujícího přístup k platformám a zařízením pro XR, tj. platformám a zařízením pro AR (rozšířenou realitu) a VR (virtuální realitu). Do základu se z rozšíření dostalo XR_EXT_local_floor. Společnost Collabora implementuje novou verzi specifikace do platformy Monado, tj. open source implementace OpenXR.
Byla vydána nová verze 0.38.0 multimediálního přehrávače mpv (Wikipedie) vycházejícího z přehrávačů MPlayer a mplayer2. Přehled novinek, změn a oprav na GitHubu. Požadován je FFmpeg 4.4 nebo novější a také libplacebo 6.338.2 nebo novější.
ClamAV (Wikipedie), tj. multiplatformní antivirový engine s otevřeným zdrojovým kódem pro detekci trojských koní, virů, malwaru a dalších škodlivých hrozeb, byl vydán ve verzích 1.3.1, 1.2.3 a 1.0.6. Ve verzi 1.3.1 je mimo jiné řešena bezpečnostní chyba CVE-2024-20380.
Digitální a informační agentura (DIA) oznámila (PDF, X a Facebook), že mobilní aplikace Portál občana je ode dneška oficiálně venku.
#HACKUJBRNO 2024, byly zveřejněny výsledky a výstupy hackathonu města Brna nad otevřenými městskými daty, který se konal 13. a 14. dubna 2024.
Prosím o radu s následujícím (kritickým) problémem. Předem se omlouvám za dlouhý zápis.
Po určité době běhu systému se na mém stroji objeví velký počet zombie pocházejících z mailového serveru Courier-MTA. Nelze je zabít. Obvyklá fráze, že stačí zabít jejich rodiče, zde selhává, neboť jejich rodičem už je init. Tento problém už pozorovalo víc lidí.
Potíž je v tom, že server po jakési události, o které prakticky nic nevím, ještě klidně i dvanáct hodin zdánlivě běží dál, než se objeví první příznaky. Prvním příznakem je (pochopitelně) nefunkčnost mailového serveru. Ale celých těch dvanáct hodin už prakticky nefunguje souborový systém ani zápis na disky. (!!!)
Přibliže deset hodin před prvním selháním se úplně přestane logovat a celých uplynulých dvanáct hodin logů, které zatím ještě lze přečíst, se nachází pouze v cache. Po (nezbytném) násilném restartu chybí samozřejmě nejen logy, ale obecně všechny změny provedené na souborovém systému.
Systém se nakonec dostane do stavu, kdy nefunguje Magic SysRq a příkaz sync zůstane navždy viset. Pokus o spuštění prakticky jakéhokoliv dalšího procesu opět časem skončí zatuhnutím procesu v podobě zombie, včetně reboot nebo vi. (Tedy není žádná možnost, jak server ohleduplně restartovat.)
V dmesg není absolutně žádná zpráva o problémech. Jen poslední dochovaná hláška kernelu je podezřelá. (Clocksource tsc unstable (delta = 4686980179 ns)) Celý tento problém jsem viděl už dvakrát. O záhadné události samotné se nedochová žádný záznam. Poslední záznam z uložených logů pochází ze včerejška cca z 02:00 a mail server vypověděl službu až dnes kolem poledne.
Jistě se mě někdo zeptá: Zapsal jsi tohle do kernelové bugzilly? Ne, nezapsal. Ten kernel je tainted. Server slouží (mimo jiné) jako WiFi AP a používá chipset Atheros. Je všeobecně známo, že MadWiFi SUCKS. A to až tak, že přibližně jednou týdně způsobí jen tak pro zábavu kernel panic. Jenže v tomto případě kernel panic nenastal... Takže se nabízí několik možností:
MadWiFi kropí paměť tak usilovně, že spousta vláken nakonec uvízne v kernel mode na nějakém zámku, ať už se to týká sítě nebo souborového systému. Problém se neodhalí včas, nenastane kernel panic a průšvih je na světě.
V kernelu je bug. S minulými verzemi se tohle nikdy nestalo. Nicméně nemám šanci to prověřit, protože bez toho odporného binárního modulu by server neposkytoval WiFi. Nemůžu WiFi prostě na měsíc odpojit a čekat, zda se ta chyba stane i bez MadWiFi...
Selhává hardware. Jeden z disků něco nemohl zapsat, nastala chyba při komunikaci s řadičem a podobně. Ale proč o tom nic nebylo v dmesg ani na konzoli? Nebyla tam ani jediná řádka, kterou by vypsal ext3, ovladač SCSI řadiče nebo podobný chytrák...
Jde o důsledek vzdáleného útoku. (O čemž pochybuji, protože mám ten stroj přece jen solidně zabezpečený a navíc nespravuje choulostivá data, která by mohla posloužit k ukradení závratné sumy peněz...)
Tak to je celé. Tohle je zlý sen každého administrátora. I když jde jen o domácí server, člověka to připraví o klidný spánek. Čím to může být? Máte někdo podobnou zkušenost?
Tohle je typický projev případu, kdy chybové e-maily se mají doručit na adresu, kterou má obsluhovat váš server, ale neumí to.
Ne, tohle nebude ten případ. Myslím, že nastavení bounces mám v pořádku. Courier-MTA i v defaultním nastavení takovéhle cyklení zvládá korektně, pokud vím. Kromě toho, v takovém případě by těch procesů bylo závratně mnoho. Nic takového se ovšem nestalo. Nedošla paměť a zatuhlých procesů kolem mail serveru bylo cca patnáct. Všechny ve stavu defunct s rodičem init.
Taky se nabízí otázka, proč se to v deseti měsících před instalací slavného chipsetu Atheros nikdy nestalo, zatímco od instalace té karty ten průser vidím podruhé.
Jak by to dopadlo, kdyby se opravdu jednalo o případ, který popisujete? Podle mě by to znamenalo velké vytížení CPU, spuštění obrovské haldy procesů a zaplnění swapu. No a mohlo by to skončit zabitím jednoho z nich kvůli nedostatku paměti, čímž by se rekurze na chvíli přerušila. (Asi jen do doby, než se nižší patro rekurze pokusí znovu o odeslání.) Jenže na mém serveru bylo vytížení CPU nulové, procesy se vůbec nemnožily a prakticky každý nově spuštěný proces (kromě těch velmi triviálních, které nic nedělají se sítí a s diskem) skončil také ve stavu nesmrtelné zombie.
Myslíte, že by se i přesto mohlo jednat o vámi popisovaný problém? Nechce se mi věřit, že by obyčejný mail server mohl takhle odvařit celý systém a způsobit, že se 12 hodin nic neloguje ani neukládá cache souborového systému...
Existuje možnost, jak bych mohl popsanou mailovou apokalypsu sám vyvolat? Stačilo by poslat nějaký vadný mail na lokální adresu? (Takové věci dělávám denně (ne já osobně, ale Cron ano) a žádná hrůza se nekoná...)
Chybové zprávy nemají mít vyplněného odesílatele, a pak se samozřejmě chybová zpráva na chybovou zprávu ani nevytvoří.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
notify_classes a spol.).
Mimochodem, existuje spousta podivných důvodů, proč init nesežere zombie, které zdědí. Například na stránce, na kterou jsem už jednou odkazoval, se lze dočíst:
We’ve recently found that having software flow on the system console after getting an XOFF can cause the system console’s buffer to fill up, giving init task constipation, and therefore all tasks that were created by init task will become zombies when they exit. Further, it appears that system console (in this case on a serial port /dev/ttyS0) has software flow is enabled by default, and is re-enabled periodically (each time character is output?).
To by vysvětlovalo, proč nefungoval shutdown ani reboot. Nicméně otázka je, zda by zablokování procesu init opravdu způsobilo takovou katastrofu, jakou jsem viděl já. Je naprosto jasné, že by pak každý démon zatuhl v režimu zombie. Každý mi ale tvrdí, že zombie je proces, který už uvolnil všechny prostředky. Je možné, že by tyto zombie, které init nestačí konzumovat, zablokovaly celý systém?
Připusťme, že by zombie (čistě hypoteticky) nadále držely nějaké prostředky, zejména pokud jde o síť. Pak by mail server samozřejmě dřív nebo později přestal přijímat spojení, protože by nikdo neuvolnil ta stará. Počet zpráv čekajících na zápis do logu taky není neomezený a když někdo poničí zamykání sítě, asi by se mohlo stát, že syslog-ng už nic nepřijímá a tím zablokuje prakticky všechny další démony, i takové, kterých se to zdánlivě vůbec netýká.
Rozdíl oproti popisované situaci je v tom, že nepoužívám žádnou sériovou konzoli. Takže co by mohlo zablokovat init? Pokud se to stane, jak na to přijdu? A jak je možné, že SSH normálně funguje? Pracuje přece taky se sítí.
Může tohle být způsobeno pokropením paměti, které nešťastnou náhodou nevyvolá panic a zanechá systém v poškozeném stavu? Hrůza pomyslet!
17.11.2008 16:51
Bluebear | skóre: 30
| blog: Bluebearův samožerblog
| Praha
Těch zombie bylo cca 15. PIDů je sice jenom 65534 (protože 0 nemá nikdo, 1 má init a 32-bitové PIDy nemám zapnuté), ale to je přece jen pořád ještě dost. Server má jenom 1,5 GB paměti a podle mě by vůbec neustál tolik zombie, aby zaplnily všechny PIDy.
17.11.2008 16:53
Bluebear | skóre: 30
| blog: Bluebearův samožerblog
| Praha
Doporučuji neprodleně vše zazálohovat (ale to už jsi určitě udělal).
No, kéž by... To jsem sice udělal minulý týden, ale od té doby je DVD vypalovačka v opravě.
Bylo to loučení aspoň nějak vidět ve SMARTu? Zrovna předevčírem mi někdo tvrdil, že SMART je k ničemu a nedokáže předpovědět nic.
17.11.2008 19:08
AraxoN | skóre: 47
| blog: slon_v_porcelane
| Košice
Tiež by som to videl na disk. Niekde na disku je kritické miesto, ktorého čítaním (či zápisom) sa celé I/O na daný fyzický disk zablokuje a od tej chvíle sa už nezapíše ani čiarka. Systém potom ešte chvíľku funguje, lebo väčšinu potrebných vecí vie naťahať z diskovej cache, ale ako sa postupne buffre plnia požiadavkami na zápis, ktoré nikto nevybavuje, tak sa cache uvoľňuje a nakoniec sa už nedá spustiť ani len "ls", lebo aj ten sa z cache vyhodil v prospech narastajúcej I/O fronty. Čím väčšia pamäť, tým väčší problém, lebo tým dlhšie trvá, kým sa to definitívne sekne a tým viac sa stratí neuložených údajov.
Prešiel by som disk dd-čkom, či sa ho podarí celý prečítať, a ak nepodarí, tak potom už len pripojiť monitor a pokochať sa nejakou obskurnou chybovou hláškou, ktorá tam asi bude svietiť.
A k tomu SMART-u - podľa wikipedie dokáže predikovať zlyhanie disku asi v 30% všetkých prípadov. Iste, bolo by fajn, ak by to bolo viac. Je to ale dôvod na úplne zavrhnutie SMART-u?
SMART long selftest nehlásí žádné chyby. (Nevím, jak přesně si mám tento výsledek vykládat, ale je to tak.)
S diskem je potíž v tom, že tam jsou dva SCSI disky a na nich LVM striping. Selhání jednoho samozřejmě pošle všechno do kytek.
Selhání disku a růst cache jsem zažil už cca třikrát, ale vždy to bylo zaprvé na IDE, zadruhé na obyčejném desktopu a zatřetí bez LVM. Pokaždé to bylo provázeno extrémně bouřlivými výpisy v logu. Byly tam zápisy od ext3, že vypršel timeout. Spousta I/O errorů. Zprávy o tom, že řadič XYZ selhal nebo mu přetekla cache a podobně.
Ale tady nevidím nic. Ani v dmesg, ani nikde jinde. Kontroluju to pravidelně. Za celý rok provozu jsem nikde takovou hlášku neviděl. Je třeba možné, že LVM2 tyhle hlášky nějak filtruje? To se mi vůbec nezdá, protože když z disku prostě něco nejde přečíst, musí tam být nějaký timeout a hláška, že se to nepodařilo.
Mám snad zkusit zapnout v LVM2 nějaké debuggovací hlášky? Dají se takové hlášky zapnout za provozu? Kdybych věděl, že disk selhává, hned bych šel na eBay koupit jiný. Takhle vím prd. Předpokládám, že pomocí dd můžu jeden z těch dvou disků celý zkopírovat (bude-li navlas stejný a půjde-li originál ještě přečíst) a LVM oddíly se tím zachrání.
Právě teď jsem přenesl pár GB dat přes 1 Mbit/s, abych měl všechno zazálohované. Ach jo, toto je opravdu k vzteku.
Opravdu může LVM i ovladač od řadiče v případě chyby jenom čekat a neříct vůbec nic?
Co tam máte za jádro? Některá 2.6.27.y revize opravovovala chybu v device-mapperu.
Řekl bych, že device mapper umí propagovat chyby (dokonce pro to existuje simulátor chybujícího blokového zařízení), navíc ta chyba by se stala na fyzickém blokovém zařízení a tak byste dostal hlášení od ATA rozhraní.
2.6.27.6 Nicméně tentýž problém jsem viděl před týdnem s 2.6.27.4. Aktualizoval jsem kernel právě proto, že jsem měl podezření na takovou chybu, nicméně kýžené zlepšení to nepřineslo, jak je vidět.
Dostal bych hlášení od SCSI, nikoliv od ATA. Právě v tom může být problém. Průšvihů s ATA rozhraním jsem viděl hodně a vždycky se přesně hlásily. Třeba vypršel timeout na DMA a podobně. Nicméně netuším, jak je to u SCSI a jestli třeba nemusím někde explicitně zapnout nějaký debugging.
Nechce se mi ani trochu věřit, že by celý systém čekal dvanáct hodin na SCSI disk a neřekl nic.
Já mám SCSI CD mechaniku a ta když čte poškrábaný disk, tak u toho jádro docela nadává. Je pravda, že chybová SCSI hlášení jsou docela kryptická, ale aspoň se dá poznat, že se něco děje.
Ještě dotaz k tomu dd: Můžu tím příkazem číst disk, na kterém jsou zrovna namountované filesystémy?
Otázka je, co se stane, když jeden ze dvou disků v rámci LVM volume group začnu takto intenzivně číst. Nerad bych, aby mi to sestřelilo filesystémy, třeba kvůli nějakému timeoutu a podobně...
Odpovím si sám. Dodal jsem si odvahy tuplákem výtečného ležáku a zkusil jsem to.
Celý příkaz se prostě provedl bez chybové hlášky. Hláška není ani v dmesg, ani jinde v logu. Zombie zatím nevidím. Rychost byla nějakých 50 MB/s, bez větších výkyvů. Každých 5 vteřin jsem posílal SIGUSR1, abych viděl statistiky.
Z toho (asi) vyplývá, že oba disky lze přečíst. O možnosti zápisu tento pokus samozřejmě neříká vůbec nic.
17.11.2008 16:55
Bluebear | skóre: 30
| blog: Bluebearův samožerblog
| Praha
Taky si říkám. Na notebooku, který mění dynamicky frekvenci, mám tuhle hlášku pořád a žádný problém to není. Jen jsem to tam napsal pro úplnost, protože to byla poslední hláška kernelu, která se objevila v dmesg před tím nekonzistentním stavem, kdy většina démonů ještě sloužila svému účelu, ale nic se nelogovalo ani nepsalo na disk.
Můj notebook teď mívá mnohem delší uptime než můj server. To je poněkud k pláči. Vzpomínám na časy, kdy jsem jenom po každých sto dnech uptime aktualizoval software a vyměnil kernel a stabilita byla samozřejmost. Ještě před pár měsíci tohle byla realita.
.
ps. Mit wifi na serveru je docela uchylarna, zvlast kdyz vis ze jsou s nim problemy, ale disky ve stripu pod LVM a bez zalohavani to je na zastreleni.
No, s kabelem nic nenadělám. Je tam backplane a dva hotswap bay. Mohl bych zkusit oba disky vytáhnout a zastrčit zpátky, ale pouhý špatný kontakt to asi nebude. To by určitě odletělo rychleji.
BIOS pro SCSI řadič se flashuje společně s „hlavním“ BIOSem, protože je to on-board řadič. Je to IBM xSeries 335. Je tam nejovější BIOS od IBM a novější už asi vydaný nebude.
Oba disky mají nejnovější firmware, ten jsem samozřejmě aktualizoval.
Jasně, že v logu nic nenajdu. Ale proč to nevidím ani v dmesg? Tento výpis určitě nečte log z disku. Čte prostě nějaký buffer, který tam kernel má a který občas flushne do kernel.log. Takže bych v dmesg čekal vřískot, kdyby nějak fatálně selhal disk. U všech disků, které jsem viděl selhat, tam vřískot byl. A jaký! Vůbec nevadilo, že to není kam zapsat...
I když, co vůbec kernel udělá, když ten buffer nemá jak zapsat do logu? Zahazuje starší zprávy, nebo se to celé zablokuje? Možná, že u těch selhání, která jsem viděl, nebyl zápis zcela zablokovaný. Těžko říct.
Jestli je DVD vypalovačka dostatečné zálohování, pak to na zastřelení snad nebude, ne? Jenže shodou okolností se vypalovačka minulý týden porouchala a musel jsem ji poslat na reklamaci. A co čert nechtěl, je to zrovna v době, kdy nepříjemně často vidím takovéhle průšvihy. Murphyho zákony fungují krásně.
U domácího serveru, který je spíš „na hraní“, se problém striping versus mirroring rozhoduje velmi snadno. A to tak, že pouhých 36 GB mi nestačí... S tím WiFi je to nepříjemné. Od Atherosu jsem čekal kdovíco, protože ho všichni vychvalují. Teď už vím, že to byla hloupost, a mám jasno v tom, že MadWiFi sucks. Kdyby existoval chipset, pro který je open-source driver a zároveň podpora pro hostapd, Atheros by okamžitě letěl z okna. Jenže takový chipset už není. Prism/Intersil už se nikde nesežene a tím nabídka končí.
I když, co vůbec kernel udělá, když ten buffer nemá jak zapsat do logu?
V jádře je kruhový buffer. Takže nevybrané zprávy se budou od konce přepisovat. Vybírání má na starost uživatelský prostor (obvykle syslog démon).
Suma sumárum jádru je (ne)vybírání systémového logu ukradené.
Tak potom vůbec nechápu, proč ten buffer ukazoval pořád totéž, od úplně první bootovací hlášky až po zprávu TSC unstable, která v době prvního selhání byla dvanáct hodin stará.
Kdykoliv jsem zažil selhání disku, v dmesg nebylo nic jiného než šílené kvantum DMA timeoutů, I/O errorů a kdovíčeho ještě. Tady nebylo nic.
Možná jsem měl zkusit něco, co zaručeně vyvolá zápis do dmesg. Třeba příkaz sysctl, který používá jakési deprecated vlastnosti. Pak bych viděl, jestli je ten buffer pro dmesg přístupný, nebo zda je úplně se vším konec.
Špatně jsem to napsal.
Ten kruhový buffer se nevyprazdňuje. Proto příkaz dmesg vždy vypíše několik posledních hlášek (prostě vypíše obsah bufferu). Ačkoliv pomocí dmesg -c lze buffer vyprázdnit.
Syslog čte nové hlášky z /proc/kmsg. Jak tam to je s bufferováním, nevím.
Možná jsem měl zkusit něco, co zaručeně vyvolá zápis do dmesg.
SysRq s nenaváznou klávesou vypisuje nápovědu. A mimo jiné se tam logují všechny SysRq požadavky včetně jejich výstupů (např. SysRq : Emergency Sync
).
To je docela dobře možné. Nicméně mezi zombie jsou prakticky výhradně procesy, které komunikují po síti. Čtení z disků fungovalo normálně. Zápis zdánlivě také, ale žádné změny se už nezachovaly.
Čekal bych, že při selhání zápisu se okamžitě napíše hláška do dmesg a že tam ta hláška samozřejmě bude i poté, kdy už se nedá nic nikam psát. Já jsem tam ovšem žádnou chybovou hlášku neviděl.
Taky je možné, že tam ten šílený MadWifi (jak příhodný název) něco pokropí a poničí zamykací struktury kolem sítě tak, že to zablokuje úplně všechno. Koneckonců, i logování je víceméně síťová záležitost. Sice je to UNIXový socket, ale přece...
22.11.2008 02:13
Bluebear | skóre: 30
| blog: Bluebearův samožerblog
| Praha
Podezřelé je, že teď už mám pět dní uptime a nic zlého to (zatím) nedělá. Takže buď ta chyba nastává v různých intervalech s velkým rozptylem, nebo to má celé jiný důvod. Kromě bodu 3, který nikdy změnu k lepšímu nepřináší, jsem pomýšlel víceméně na všechny ostatní možnosti. Kernel tam mám vlastní, ale žádné extra debuggovací hlášky zapnuté nemám. Předpokládám, že kdyby šlo o chybu disku, muselo by se to hlásit přinejmenším v dmesg. Proto možnost chyby disku v podstatě vylučuji, zejména poté, co se mi podařilo oba disky na běžícím systému přečíst pomocí dd, a to bez jakýchkoliv chybových hlášení nebo jiných následků.
Celkem vzato, zbývají jen dvě možnosti. První možost je, že driver Atheros postupně kropí paměť a je jenom otázkou času, kdy pokropí něco důležitého. V lepším případě vyvolá kernel panic, v horším připadě provede něco, co se nedá detekovat, a vyvolá podivný deadlock v celém síťovém stacku.
Otázka dne: K čemu je mi memtest, když mám moduly typu ECC REG SYNC? Nevypisuje náhodou kernel selhání ECC taktéž do dmesg? Vsadil bych se, že ano. Nicméně žádnou hlášku o selhání ECC jsem tam neviděl.
Ať už je to jakkoliv, není to žádný med. Člověk kvůli tomu nemá klidné spaní. Server je ode mě vzdušnou čarou 255 km. I několikrát denně tam nasísám, jestli se loguje, jestli se nezasekne příkaz sync, jestli tam už zase nejsou mrtvá vlákna... Prostě už to není ten starý dobrý server, který jsem zapnul a nechal 100 dní běžet. A prože DVD vypalovačka je pořád ještě v reklamaci, každý den přenáším inkrementální zálohy až sem na svůj notebook. Bééé, fňuk.
Systém se nakonec dostane do stavu, kdy nefunguje Magic SysRq
Konkrétně nefungoval který požadavek? Ani SysRq-B? Pak bych opravdu viděl chybu v rozbitých jaderných strukturách (ať už softwarově nebo hardwarově).
Pokud reboot funguje, ještě by šlo přes předpřipravený kexec rebootovat do záchranného systému, dumpnout rozbité jádro a zapitvat si.
Zkoušel jsem samozřejmě postupně celý busier pozpátku, jak se to má dělat. Bohužel u e jsem skončil definitivně a pak už nefungovalo ani b. Nemám tušení, jestli by b fungovalo, kdybych ho použil jako první.
Jedno vím jistě: Až ten problém uvidím příště, nebudu zkoušet vůbec nic, dokonce ani u, a skončím rovnou u b... Stejně už se nedá nic zachránit. Procesy stejně zůstanou jako zombie a nemůžou už nic zapisovat. Co je horší, samotný příkaz sync zůstával viset nekonečně. Bez jakékoliv chybové hlášky...
Pitvání jsem zažil jenom na Solarisu, v kurzu, který trval jen pět dní a zabýval se jen platformou AMD64 a debuggerem mdb. Nevím, jestli bych si s Linuxem poradil a něco smysluplného našel.
S minulými verzemi se tohle nikdy nestalo.
Jsou lidi, co mají na 2.6.27 problémy s hostap. A to je přitom v Linusově stromu. Takže bych se nedivil, kdyby madwifi mělo problémy taky. (Z tohoto důvodu na svém serveru mám stále 2.6.26.)
No, záleží na tom, o jaké problémy se jedná. Samozřejmě se ví, že stanice s Windows se neustále odpojují a znovu asociují bez zjevné příčiny. Ale to je v podstatě pouze detail.
Pokud jde o potíže v kernelu, za ty hostapd nemůže. Za ty může binární HAL, jeden (trunk) horší než druhý (branches/madwifi-hal-testing). Nebo se paměť nekropí přímo v tom HALu, ale někde v open-source části toho ovladače? Těžko říct. Ten ovladač se už roky nějak bastlí a nikam to nevede.
S kernelem 2.6.26 byla u mě situace extrémně špatná a vždy po několika desítkách minut provozu se úplně zastavil IPv6. Nechápu, proč IPv6 nefungoval a IPv4 ano. WiFi s tím přece nemá nic společného, je to jiná vrstva... No nicméně bylo to tak. Upgrade na 2.6.27 tyto problémy ukončil, ale přinesl jiné, jak je vidět.
A mimochodem, i dnes je v MadWiFi jeden zaručený kernel panic: Stačí dvakrát po sobě změnit frekvenci přes iwconfig v době, kdy běží hostapd. Pak už to udělá jenom hoplá...
Pak už to udělá jenom hoplá...OpenSource no :).
Mluvím o ovladači hostap pro Intersil Prism karty. Nikoliv o hostapd démonovi pro WPA2/Radius atentizaci.
Můj problém je, že kdykoliv se jádro pokusí odeslat rámec, tak v logu přibude hláška „invalid skb->cb magic“. Ale to je jiná kapitola.
Vzhledem k tomu, že všechno už vypadá normálně, rád bych tuto ošklivou kapitolu uzavřel a poděkoval všem diskutujícím za cenné postřehy.
[andrej@charon ~]$ uptime 22:42:47 up 14 days, 8:30, 1 user, load average: 0.00, 0.00, 0.00
Pokud někoho zajímá, v čem byl problém, je to vcelku jednoduché. Stačilo dát modul pro WiFi kartu na blacklist a byl rázem klid. WiFi teď zajišťuje oddělený access point a můj server funguje „pouze“ jako RADIUS. Access point je v režimu bridge. Tím pádem mám všechno, co jsem chtěl. Zaprvé, WPA2-EAP-TLS. Zadruhé, IPv6 v celé LAN. Zatřetí, stabilitu.
Až vám někdy někdo řekne „ono to má sice binární ovladač, ale funguje to dobře“, vyhoďte ho oknem ven a ten hardware mu hoďte na hlavu! Cokoliv jiného uděláte, povede to jen k potížím, které za to nestojí.
Upřímně řečeno, ještě dnes mívám špatné sny o serveru plném zombie. 
Dokud nedosáhnu těch standardních 100 dní uptime, pořád budu mít tak trochu nejistotu.
Neodpustím si na závěr jednu zajímavost. Chtěl jsem odchytit nějaký kernel panic, který způsoboval ten Atheros, abych to mohl pořádně nahlásit. Jal jsem se tedy instalovat netconsole. Těsně před instalací netconsole nastal panic dvakrát po sobě během půl hodiny. Jakmile jsem ovšem netconsole zprovoznil, nedělo se nic... Po dvanácti hodinách běhu server totálně zatuhl. Panic to nebyl, protože ten by vyvolal restart. Nedochovala se o tom ani jedna zpráva v logu. Tedy jsem natvrdo restartoval server (!) a čekal dál... Po dalším dni se stalo totéž. Zatuhnutí, žádný panic, žádná zpráva v netconsole. (!!!) No nepřipomíná vám to Heisenbergovy relace neurčitosti? Každopádně tohle byla poslední kapka. To binární svinstvo šlo ihned pryč, pro jistotu jsem důkladně zkontroloval všechny souborové systémy, přebootoval a hotovo. Od té doby server běží normálně.
Snad jen pro doplneni pro ostatni. Podobne problemy jsem pozoroval s modulem
rt61pci a kartou '05:09.0 Network controller: RaLink RT2561/RT61 rev B 802.11g" v jadrech Fedory 9 a nize.
V techto distrech je resenim pouzivat legacy modul rt61, ktery vychazi z proprietary kodu.
Z toho vypada, ze FS moduly jadra (popripade samotny navrh FS jadra) maji problem se spatne se chovajicim se wireless subsystemem.
Hmm a protoze o tom vim prd, tak to dal rozebirat nebudu.
Tiskni
Sdílej:
