Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
A co Windows a Android?
Tam možná zafunguje bios a nebude se to řešit na softwarové úrovni takže ti to třeba neshoří při kernel panicu :)
Aha, on je na Linuxu nějaký problém, že něco nefunguje? O.o
V porovnání s ostatními OS ano. Navíc je to tu popsané na velmi zevrubné úrovni takže jsem se dozvěděl jedno velké kulové podložené jakýmsi nic neříkajícím plánkem, který je ovšem značně zjednodušen proti staršímu power managmentu. Otázkou je jestli v tom schématu je všechno (IMHO ne, chybí třeba CPUfreq, CPUidle, DVFS...) a rozhodující bude reálná praxe, která je většinou diametrálně jiná než na papíře
neni, ten demon tam je normalne, umi dokonce vytvorit vychozi soubor pro vsechny ventilatory, ktere maji rizeni a pak si je clovek ztisi, ja to tak doma mam.
Jinak linux bios z RAM okamzite smaze, takze stejne vse ridi on, jen precte, jak je to nastaveno, ja pouzivam fancontrol, protoze je to normalni desktop.
Jinak zde dalsi moznosti:
https://wiki.archlinux.org/index.php/Fan_Speed_Control
Směju se, jak si někteří myslí, že kernel panic má stejný výskyt jako BSOD na Windows. Většina linuxáků ho nikdy neviděla. Já za 6 let dvakrát - poprvé když jsem si špatně vypálil LiveCD a podruhé když jsem si myslel, že zvládnu vlastní konfiguraci jádra. Při normálním provozu to snad ani není možné.
Kernel panic sám o sobě není takový problém nicméně stav kdy řízení spotřeby bude řídit software (daemon) a ne bios může být u pasivního notesu vcelku kritický.
To, že linux nikdy nepadá a nikdy neměl problémy je mi úplně jasný :D Stejně tak nikdy neměl problém ani OSX, jenom ty zatracený Wokna padají, že... (píšu z nestabilního Maca takže klid)
O tom, že řízení spotřeby by neměl mít Daemon s vámi souhlasím, neříkal jsem že ne.
Že Linux s OSX nepadá a nikdy neměl problémy - napsal jsem něco takového? Ne, to jste si přidal vy. Každý OS má problémy, rozdíl je v tom, jak často se vyskytují a jak rychle se řeší. A kernel panic běžný uživatel nemá šanci vidět pokud se v systému vyloženě nerýpe nebo neexperimentuje s kernelem.
OSX jsem nikdy neměl, nemůžu posoudit.
Léta hledám seriózní statistiku, která by ukazovala poměr mezi BSODy (chcete-li KP) zaviněné chybou uživatele a chybou OS a ještě jsem nic nenašel. To, že Win hází prakticky neustále slýchávám od Linuxáků často a už mě to připadá jako hodně ohraný klišé. Zkrátka když spadne Win tak je to vina OS, když spadne Linux, je to najednou vina uživatele :) Paradoxně KP jsem viděl i na svých (poměrně robustně otestovaných) strojích - posledně sice u AMDčka, ale o to jsem si jistější, že to bylo právě kvůli power managmentu ;) A ano, opravili to nicméně Win s tím neměl problém odzačátku
Drtivá většina BSOD ve Winu je chyba softwaru tetích stran. Pády kvůli grafickým ovladačům jsou často kvůli přehřátí daného hardwaru, případně jeho fyzické vadě - obojí může způsobit chybu, za kterou je namísto něj potrestán driver. A pak jsou tu neošetřené situace v aplikacích, které se stávají, většinou je za to potrestána jen aplikace ukončením, ale občas killnutí programu nestačí, a je třeba ukončit vše - například když něco předává chybu něčemu jinému.
I když, já teda nevím, jak se KP liší od BSOD, ale BSOD není že by spadl systém. Naopak systém je plně při vědomí, a všimnul si, že je něco špatně, a tak sám pro ochranu počítače zavolal modrou smrt, která to sdělila uživateli. BSOD se od běžného běhu systému liší jen tím, že on okamžitě zapomene jakékoliv další programy a procesy, aby se chyba nepropagovala a nepoškodila hardware nebo software, a aby na něco nezapomněl, nebo nedošlo ke změně dat -> dump nezměněné paměti pro umožnění zkoumání (a následné odstranění) problému, atd...
BSOD je vzdy chyba OS, nikdy ne aplikace, jiz neni vubec videt BSOD jen a pouze proto, ze ji M$ zakazal a nastavil misto vypsani BSOD reboot ... to je cele.
Ano BSOD je spise problem dlouho bezicich serveru.
tak toto je blbost
Nj, ale ono už "windows" a "server" jsou pojmy, které by k sobě dohromady neměly nikdy přijít ;-).
Pokud mi někdo chce tvrdit, že KP je častější než BSOD tak buď vychází z několik let (5 a víc?) starých zkušeností, provozuje nějaký nedodělaný distro, má šrot PC na kterém nahradil W98 a nebo prostě lže.
Upřesním info:
Linux (Debian Testing, Ubuntu LTS, Mint LTS - vše kernel 3.2+) provozuju denně na noteboocích HP už několik let a KP je prostě naprosto nevídaná věc. Dřív server, Debian 5, také bez potíží.
Znám několik Win uživatelů, kteří právě proto, že Linux nikdy nenasadili na plno ale pořád nějaké staré šroty, parallel desktop, virtualbox apod. řešili takovéhle problémy. Na normálním moderním PC se tohle neděje.
HP notes se security íčovinama v defaultu = bsod a neviděls ho nejspíš kvůli tomu, že tam máš lino. Teď jde o to, jestli používáš lino kvůli tomu, že o tom bsodu víš nebo nevíš. Zkrátka úhel pohledu.
Konkrétně u 4530 jsem tu íčovinu vyndal (výměnou za 2 bsody) a je klid. Ale zároveň říkám, že u KP postupuju úplně stejně, akorát u Lina je těch možností víc (tím pádem ovšem i práce). OSX je v tomhle ohledu asi nejlepší. Softwarově lze ovšem zbořit všecko, akorát Win je díky dominanci na trhu a četnosti používání prostě na prvním místě - jinými slovy ikdyby byl Win stejně odolný na bsody jako je linux/OSX tak bude mít vždycky větší počet bsodů páč to taky používá větší počet uživatelů. O šrot distro vůbec nejde, on i Win se vyvíjí, že...
V linuxu zadny bios neni ;-))
linux bios okamzite smaze z RAM, jen co nabootuje ;-) dokonce mu jde rict, ze ma BIOS ignorovat, tedy ze z nej ani nema nic cist.
1) Kernel panic neznamena, ze nejaka cast kernelu nejede ;-)
2) pro tyto pripady ma kazda slusna deska hloupe cidlo, ktere po dosazeni kriticke teploty zaplne ventilator na plny vykon, tohle ale ridi termistor a ne nejaky SW
... vyhoda take je, ze kdyz je kernel panic, nic jineho nez neco z kernelu jiz nebezi, cely user-space je dole, tedy nema co vytezovat CPU a ten zustane chladny.
treba hloupa 486 byla v linuxu, kde se nic nedelo studena, zatimco v DOSu byla zahrata a chtela chladit i dkyz nic jineho nez DOS nebylo pusteno, tedy jen command.com a par .sys (treba ovladace pro RAM, mys a sluzby BIOSu)
Mas pravdu, linux proste vetsinou zamrzne, aniz by neco vyhodil:o)
Windows aspon vyhodily nejake cislo z ktereho se dalo vycist o co asi jde.
Abych nemluvil do vetru, dva ruzne PC, nainstaloval jsem windows, porad to do pulhodiny padalo. Nainstaloval jsem teda vzdy i nejaky ten linux a potvrdila se stara znama pravda, ze linux nepada. Ani tenkrat to nespadlo! Proste jen zamrzl:o)
Takze square 1 a znova windows a nejake gugleni a nakonec po deseti hodinach vyhodila chybu pamet v memtestu, takze problem vyresen.
U druheho PC to bylo to same chovani (lin vs. win), akorat byl problem v CPU.
Takze z me zkusenosti musim rict, ze uzivatele windows vidi bsod castej nez uzivatele linuxu kernel panic. A to nepocitam to, ze je tech uzivatelu o dva rady vic:) Navic naprosto drtiva vetsina BSOD je zpusobena ovladacem nvidie nebo ati .... ve zbytku je to nejaky jiny ovladac ..... nastesti je v linuxu podpora techto karet tak mizerna a jednoducha, ze se na tom nema co pokazit:o)
A jako chyba ovladace neni chyba windows a je zcela regulerni chcipnout. Pokud se ti to nelibi, muzes si ovladace nechat na vlastni riziko restartovat a BSOD uz nikdy neuvidis ..... ale je to samozrejme kravina, protoze ovladac, ktery spadne a nechce se nechat restartovat, k tomu asi ma nejaky duvod:)
Ha, přesně o tom jsem mluvil výše... Windows nepadá, on informuje o průseru.
Bohužel nevím jak u Linu, ale u Windows jsem za cca 20 let ve většině případů vyčetl, který ovladač způsobil chybu a hned bylo jasné kam mířit na odstranění závady. Jen vyjímečně to zahlásilo chybu bez ovladače a to jsem většinou rovnou zresetoval BIOS, začal testovat paměti a zkontroloval kondíky na základní desce. V jednom případu W nehlásily ovladač a celé to bylo způsobené kombinací viru a dvou rezidentních antivirů současně, tedy vina uživatele.
Moje dosavadní zkušenosti s linuxem jsou jenom z Ubuntu. Očividně je dle chování grafiky problém s ovladači, ale systém nic nehlásí a obrazovka jen čas od času blikne (asi restartovladače?).
dmesg, kernel panic hlaska, a logy ;-))
dale jde zapnout SysRq, ten prezije i kernel panic a v nem jde presne zjistit, kde kernel vymrz, zda jsou dostupne disky a dat sync, dump RAM, kde to skucelo, vypis kde ceho
Pravdepodobne vam vytuhly jen X-windows, pokud neni kernel panix, pres SysRq je mozno vypsat procesy a nevhodne zabit, SysRq kombinace nejde nahradit ani vypnout jinym programem, pokud je ovsem tato moznost zapnuta, nebot SysRq mechanizmus lze vypnout, pokud je zale zapnut, zadna aplikace si na tyhle kombinace klaves nic nenamapuje
http://www.root.cz/clanky/sysrq-klavesa-pro-reseni-problemu/
No a pokud se jedna jen z zamrzly X-server, jako ze uz jsem to sakra dlouho nezazil, tak jde v pohode vse resit pres SSH z jineho stroje ;-) ... a taky jde aktivovat klavesa CTRL+ALT+Backspace ... to se dela v X-serveru, nebot tahle natvrdo X-server shodi ... pote co zacli delat s linuxem i uzvatele, nejaky sikulka tuhle klavesovou zkratku objevil a strasne se divil, ze mu vse spadlo ... nevim jak, proste i na tuhle silenou zkratku omylem prisli ;-)))
Pokud linux zamrzne a nic nevypise, je to chyba HW, treba nestiha zdroj, mi vzdy linux zamrzl tak, ze uz PC neslo nabootovat a zacalo piskat, musel jsem vyndat RAM a dat zpet, memtest nic nenasel a udelal to jednou za X mesicu ... tak jsem vyhodil zdroj a koupil novy a od te doby nic.
Samozrejme ze se to tyka i windows, ale tam nikdy nikdo nevi ;-))) ... doby, kdy kernelovy modul nvidie shazoval kernel jsou jiz davno pryc ;-)
"Nainstaloval jsem teda vzdy i nejaky ten linux" ... "proste jen zamrzl"
No nějaký ten Linux... a distribuce? Samozřejmě existují distribuce, které jsou zprasené, to nepopírám, ty TOP jako openSUSE, Arch, Ubuntu LTS, Fedora apod. jsou stabilitou na úrovni vyšší než Windows, známý fakt.
Já mám Debian - nedokážu si ho ani představit zamrzlý. Můžu ho zatěžovat jak chci, vytahnou baterku z notebooku když je ve spánku omylem atd.. vždycky na 100% bez problémů nabootuje, nikdy nespadne.
"nastesti je v linuxu podpora techto karet tak mizerna a jednoducha, ze se na tom nema co pokazit:o)"
Ovladače od AMD jsou katastrofální. Ovladače od nVidie jsou minimálně stejně dobré jako na Windows (i když Optimus ještě není plně zavedený).
Ještě že já mám laptop, tam problém s chlazením není. :)
Pokud máte podobně řešené chlazení jako má MSI tak bych i tak doporučil jednou za rok rozebrat a vyčistit http://bit.ly/13hZCeE (a to obě strany http://bit.ly/17ZAduO)
Nene, mám kvalitní chlazení od Asusu nad 102° to nejde.
Tak možná je nejvyšší čas mrknout se mu na ledviny ;)
Cca. 14 dní zpátky kompletně rozebrán, vyčištěn a pře pastován a nebudu na něj zlí teploty klesly na 101° (samozřejmě v zátěži)
a ja mam stres kdyš se dostanu nad 55°C .. (a to a to jak na procesoru tak na GFX)
S MSI to mohu potvdit. Kdysi jsem měl řadu gx630x a topilo to opravdu výborně. Jako když si vojáci za světové války dělali v poušti na tanku vajíčka, tak u mě by ten tank byl právě v podobě MSI laptopu :D Navíc to mělo chlazení na pravou stranu a když jsem pařil, tak mi to celkom opalovalo ruku. Teploty byly asi kolem 110 stupňů, kdy se už začínalo probouzet čidlo pro podtaktování.
A to je důvod, proč jsem si jednou koupil pro poruchovost její grafické karty nechvalně známou G73Jh od ASUSu a jiný herní typ NB bych nechtěl. Teploty kolem 70°C v plné zátěži, teplo na ruce nefouká protože to jde všechno dozadu, ventilátory při běžné práci spolehlivě přehluší magnetické disky (dva), v noci si nemusím přisvěcovat na klávesnici protože je podsvícená a v neposlední řadě není notebook lesklý a klávesnice má numerický blok. Je sice podle většiny hnusnej (mě se líbí), zato účelnej.
Jen tak mimochodem autore, mohl bych poprosit o nějaký odkaz k CS (S0xX) power state pod Linuxem? Nebo ten první odstavec o pasívním provozu byl jen předmluva. Ať hledám sebevíc, ve zdrojovém odkazu totiž nic nenacházím. Pokud zaměstnám Google tak mi všude vnucuje Win8.
Mám dojem, že to co Intel představil, nijak nemění ochranu proti přehrání co je v biosu a procesoru samotném, ale tyto ochrany nedokáží analyzovat kdo a co tu zátěž vytváří a tak dokážou reagovat jen jedním způsobem, na sofistikované sledování musí prostě být démonek :)
Jinak shodit linux je snadné, můj vysílač Logitech od myšky to dělá pravidelně a to používám jen ovladače co jsou součástí distribuce.
Nebo ve starším ntb mám 9-let starou baterku, mám tam ubuntu a sem tam to hodí asi milón notifikací že se "baterie vybíjí" a celý systém jde do ... :)
To neni mozne, aby linux padal na nejakem ovladaci:) Zeptej se zde diskutujich farniku, ti ti to vyvrati:o)
jasne ze pada, proto maji vyvojari demon, ktery pri tom i ulozi RAM a jde dokonce pustit kerel v debugeru a zjistit, kde padl ... modul bezi pod RING0 a muze tedy shodit cokoliv ... vyhoda je, ze vsechny moduly pisi vyvojari kernelu a tak vse umi odladit, kvuli tomu i nvidia/ati zverejnili zdrojaky kernel modulu, nebot to hezky prasili ... mimochodem jako kazda komercni firma ;-))
Ja teda nevim co vyrobili, ale prijde mi podivne nechat takovou kritickou vec na operacnim systemu, ktery muze kazdou chvili zatuhnout .....
Chapal bych neco ve smyslu: zvysila se teplota, tak zkusim zaskrtit nejake nesmysly v systemu, treba jako enkodovani videa nebo neco podobneho .....
Ale nechavat na jadru OS veci jako throtlovani nejakych cipu je fakt divne. Nebezpecne to nebude, protoze bude mit i CPU vlastni thermal ochranu, kdyby OS vytuhnul, ale tohle mi zni spis jako prace pro nejaky BIOS ....
V linuxu je to jen zalezitost OS, tedy kernelu a ACPI, predtim APM ;-))
predtim nesel fan bud ridit vubec, nebo jej ridily termistory a ne nejak logika ;-))
termistory tam jsou porad a v pripade prehrati pusti plnou voltaz a roztoci ventilatory na plno ... to ale neni SW, to je HW zalezitost.
Je videt, ze lide nerozumi modernim OS, proc by nejaky moderni OS nechaval BIOS v RAM ? proste tento skaredy program okamzite pri nabehnuti kernelu vymaze, linux precte co je v nem a smaze jej ;-))
Jde dokonce rict, ze je bios spatny a nic cist nema a ma si to nastavit sam ... nebo parametry kernelu, ci modulu ovlivnit jen jednu hodnotu ;-))
Ja takhle opravil profi zvukovku, nejela v DOS/win9x prave kvuli tomu, ze nekdo nastavil jedno IRQ blbe a uz nesel pustit ani setup (takova ta co si vezme 5IRQ a ma i vlastni SCSI radic) ... v linuxu jela normalne a kdyz jsem ji pres moduly vynutil nastaveni na jine IRQ, tak se rozjela i v DOSu a windows .... duvodem byl fakt, ze tyhle OS buos pouzivaji, NT jiz ale bios nepouzivaji a taktez jej z RAM vymazou ... i kdyz jde zastavit cele NT-w2008 pres LPT, staci zavolat stare rozhrani LPT a vse se zastavi, dokud neuvolnim IRQ ... ale moderni protokol to nepouziva, do stareho a spatneho jde ale kazdy LPT prepnout SW ;-)) ... teda v linuxu asi nejde ;-)) ... ten ma vse virtualni ;-))
ACPI je i ve Win.
Fan lze řídit pod jakýmkoli OS pokud je na to driver (a samosebou hw, kteří prostě někteří výrobci typu Gigabyte odfláknou).
HW záležitost je vkládání null instrukcí, ostatní je i v haswellu na driveru - ve zdroji v té dokumentaci je tam na to schéma a celá posloupnost jak to postupně funguje (v některých částech se to s článkem rozchází).
Protože bios ještě dlouho bude jakýmsi pomyslným pojítkem mezi různorodým hw a různorodým sw (OS). I moderní OS totiž stále běhají na starých principech. Spoléhat na sw tím, že něčemu prostě řeknu "jsi Core 2 Duo" a ten mi pak napálí do cpu jinej power state/voltáž nebo prostě to co bude mít v konfigu je blbej nápad :)) Ve chvíli kdybys měl definován řekněme "unknown cpu" tak ti to nikdy nebude fungovat ve všech cpu stejně, prakticky to vždy dojede právě na ty powerstaty (viz. třeba AMD cpu, AMD chipset a linux kdy bylo nutné prostě čekat na jiný kernel, že)
IRQ je záležitost biosu ve kterém (kupodivu) lze IRQ nastavit manuálně (to jsou ty výhody proti "moderním" OS). Předpokládám, že to byla zvukovka od Creativu, kde ovšem IRQ nebyl jádrem pudla. LPT nepřepneš softwarově pokud nemáš oporu v hw - typicky se s tím lze setkat v dnešních pcie převodnících právě pro com/lpt a garantuju ti, že pod linem třeba skenery na tý kartě bez odpovídajícího švába nerozjedeš ani kdyby ses na hlavu postavil ;)
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.