Možné řešení náhodných „jádrových panik“ při zavádění systému Arch Linux

Tento příspěvek má ukázat, jak „napravit“ téměř problém startupů s chybami Arch Linux. Něco jako následující obrázek:

IMG_20140707_210559

Jak je vidět, vidíme, že se jedná o jednu z mnoha „kombinací“ chyb, které se náhodně objeví při spuštění operačního systému s tímto problémem. Jak se uvádí v této chybě, znamená to, že v „Hardware“ může být problém, jak však všichni v tomto operačním systému víme, lze vyřešit i špatné triky toho, co do OS nepatří.

Popíšu tedy svoji zkušenost s tímto problémem. Z toho, co jsem mohl zažít, byl problém pouze s Arch Linux nebo jiné distro, které jsem testoval externě, protože u jakéhokoli ubuntu, které jsem nainstaloval nebo testoval, to začalo bez problémů. Ale kdybych se pokusil roztrhnout Arch Linux nainstalován na pevném disku, měl problém, že se musel asi 50krát restartovat, aby se OS mohl normálně spustit a mohl jej používat.

To už se mnou něco bylo v nepořádku, protože k testování jsem mohl použít pouze ubuntu, který jsem nainstaloval, a nemohl jsem dělat ani polovinu věcí, s nimiž jsem mohl dělat Arch Linux. Takže jsem se rozhodl tento problém vyřešit a začal vyšetřovat, hledal vlákna fóra, která měla stejný problém, zmínili také, že se jednalo o hardwarovou chybu a že to byl přesně CPU, takže mě to začalo znepokojovat, takže jsem se dostal k otevřete PC a ověřte, co se děje, ale nepomohlo to.

Ale něco, co mi ukázalo, že bych se neměl vzdát, bylo to, kdyby ubuntu Mohl bych proto Arch Linux ne (možná ubuntu je lepší než Oblouk…?). Takže jsem začal psát bootovací parametry do jádra Arch Linux, věci jako: lapic, nomce, intel_idle.max_cstate = 0, disable_cpu_apic, acpi_skip_timer_override, acpi = stric, clk, apm, noapic, acpi = oldboot, acpi-cpufreq, intel_pstate = deaktivovat, i8042.noacpi = 1, apm = copyds, acd apm = copyds, acdtpi = 0, apm = copyds pci = nocrs, rhgb, acpi = síla, pnpacpi = XNUMXff a další další ... To vše bylo doporučeno na fórech, která jsem četl.

Dokud jsem nemusel zadávat dokumentaci parametrů jádra, kterou mimochodem doporučuji: https://www.kernel.org/doc/Documentation/kernel-parameters.txt

A našel jsem docela zajímavý parametr, který jsem pro tuto chvíli dokázal zavést Arch Linux Žádný problém:

linux /boot/vmlinuz-linux root=UUID=fbefe36c-1712-4f3b-b3e3-3eac759d71c9 notsc nomce maxcpus = 0

Jak je zde uvedeno, tento parametr dělá omezení použití na CPU bez aktivace symetrického režimu zpracování. Zpočátku to fungovalo docela dobře, dokud jsem nepoužil příkaz pacman-Syyu; hodil mi a jádro dumpingové o Porucha Segmentace.

Automaticky jsem si tedy všiml, že se děje něco zvláštního, a tak jsem začal spouštět další procesy, až najednou systém úplně zamrzl a už nepracoval, dokud jsem ho nerestartoval. Udělal jsem tedy stejnou operaci, ale tentokrát se mi podařilo provést htop a ukázalo mi to následující:

IMG-20140729-WA0001

Jak se dalo očekávat, ukázalo se to pouze na jeden procesor, protože druhý jej deaktivoval, ale zdálo se mi velmi zvláštní, proč programy házely segfault, a nemohl ani spustit grafické prostředí; takže to bylo něco, co mi alespoň dalo větší naději, že kdybych nastavil parametry jádra jedním způsobem, spustilo by to mé Arch Linux jako obvykle.

Takže jsem zkoušel další parametry, které jsem do seznamu zapsal, dokud jsem nenarazil na tento, což je v tuto chvíli nejlepší řešení:

 linux /boot/vmlinuz-linux root=UUID=fbefe36c-1712-4f3b-b3e3-3eac759d71c9 notsc nomce isolcpus = 1

Tento parametr dělá něco tak jednoduchého, jako je izolace (ne deaktivace) druhého jádra CPU v symetrickém zpracování, to znamená, že zátěž zpracování je dána jednomu jádru, zatímco druhé je pouze doplňkové. To, i když se to zdá být rozporuplné, to moc neovlivní výkon, protože tento skvělý operační systém dokázal spouštět aplikace tímto způsobem:

test

linux_rlz_compiz

Jediným problémem, který jsem si všiml, že nastává při bootování, je tedy jedna nebo dvě paniky jádra nebo oops; ale ve srovnání s 50krát, co jsem musel restartovat dříve, to mohu považovat za „řešení“. Zbytek mi zatím umožnil používat OS a napsat tento příspěvek, který právě čtete :-).

Doufám, že vám pomohou a nedostanou se ven GNU / Linux, což je nejlepší operační systém, jaký kdy vymysleli. Říkám to jistě.


Zanechte svůj komentář

Vaše e-mailová adresa nebude zveřejněna. Povinné položky jsou označeny *

*

*

  1. Odpovědný za údaje: Miguel Ángel Gatón
  2. Účel údajů: Ovládací SPAM, správa komentářů.
  3. Legitimace: Váš souhlas
  4. Sdělování údajů: Údaje nebudou sděleny třetím osobám, s výjimkou zákonných povinností.
  5. Úložiště dat: Databáze hostovaná společností Occentus Networks (EU)
  6. Práva: Vaše údaje můžete kdykoli omezit, obnovit a odstranit.

  1.   Gregory Meče řekl

    Velmi zajímavé informace. Nikdy jsem neměl v ArchLinuxu ty jádrové paniky za ta léta, co jsem jej používal, ale je hezké vědět, co dělat, když se mi někdy problém vyskytne. Děkuji!

    1.    kik1n řekl

      Každopádně Arch používám dlouho (bez Archa jsem byl jako 1 rok) a bez paniky jádra.
      Děkuji za tip.

    2.    c4výbušný řekl

      S největší pravděpodobností, jak jsem zmínil v příspěvku, se problém stane kvůli hardwaru, protože v tom, co používám arch, mi to také nedalo žádný problém tohoto typu.

    3.    živý řekl

      Další s vynikajícími výsledky v Arch. Nikdy jsem neměl paniku jádra

    4.    rawBasic řekl

      Více než 2 roky s GNU / Linuxem ... 2 roky již s ArchLinuxem, nikdy panika jádra .. 😉

    5.    Manuál Zdroje řekl

      Myslím, že panika jádra je způsobena spíše hardwarem než samotnou distribucí. Nikdy jsem neviděl panické jádro na notebooku, který nyní používám, kromě toho, že jsem do něj vložil Ubuntu alfa (a Arch Linux zde byl také dva roky). Na druhou stranu, v jiném notebooku, který mám, jakékoli distro, které vložím, vždy způsobí paniku jádra a širokou škálu chyb pro všechny chutě.

  2.   eliotime3000 řekl

    S jádrem 3.14 na Debianu jsem narazil na problém s panikou jádra, kromě toho, kdykoli zapnu počítač, zobrazí se zpráva „časový limit pro připojení / odpojení“ (a také když jej vypnu).

    1.    Amaury řekl

      Stalo se mi to tolik ve Fedoře jako v Archu, ale nevím proč a jak nevidím rozdíl, protože jsem nestrávil čas vyšetřováním nebo řešením (pokud je to problém).

    2.    dasasd řekl
  3.   Tony řekl

    Moc děkuji za informace. Některé z mnoha věcí, kterými se můžeme pochlubit, je tento typ fóra

  4.   manu řekl

    Proč se to stalo v Arch Linuxu? Možná to nestačí na problémy, které se často objevují s pomalostí nebo zavěšením systému, které dosáhne bodu, kdy systém vrhne na pražce.

    1.    živý řekl

      Ahoj? O čem to mluvíš? o_O

    2.    Amaury řekl

      Arch je distribuce KISS konfigurovatelná ze základny samotného operačního systému, několika slovy, pokud je systém těžký, je to proto, že jste jej postavili tak, pokud má systém chyby, je to proto, že jste je generovali nebo proto, že jste správně nakonfigurovat něco Arch wiki je docela kompletní, před několika lety nebylo ve španělštině mnoho důležitých témat a proces instalace byl mnohem drsnější a poněkud obtížnější, nyní je vše trochu automatizovanější.
      Obviňování distro za chyby uživatelů je tak ... Windows (?).

      1.    Dayara řekl

        Obviňovat distro z chyb je konzistentní, jednoduše proto, že je to pravda. Poté, co jsem měl podobný problém s Manjaro, jsem zkusil Arch, Antergos a další neznámou distribuci (jméno si nyní nepamatuji, omlouvám se), které mi někdo doporučil a ujistil mě, že to nedává problémy, ale nic; všichni to dávají. V OpenSuse, Fedoře, Mintě, Mageii a všech těch, které jsem poté vyzkoušel, to neprojde. Pokud jde o mě, nezbývá mi nic jiného, ​​než si myslet, že je to chyba distro. Ale hej, nedémonizuji to ani nic, navíc mě opravdu štve, že na základě Archa nemohu nic použít, protože se mi to hodně líbí, ale ten zatracený problém mi brání. Ani si nemyslím, že jde o hardware, protože mnoho z nás, které se nám stalo, se nestalo před použitím stejného kurva. Vlastně to musí být něco, co souvisí s hardwarem, ale když se vrátím ke stejné věci, pokud jsem neprovedl žádné změny a mám problémy se stejným vybavením, se kterým jsem je dříve neměl, bude to zřejmě ke změně provedené Archem, který mě posral.

      2.    johnfgs řekl

        „Obviňování distro za chyby uživatelů je tak ... Windows (?).“

        Řekl bych vám, že obviňovat uživatele z chyb produktů je tak Apple. Upřímně jsem o tom přemýšlel tisíckrát, ale nevidím výhodu použití něčeho, co si jeho ošetřovatelé v zásadě umývají rukama, a to z nějakého vážného důvodu. A říkám, že vzhledem k tomu, že software GPL je dodáván bez záruky.

        Můžete si říkat, jak chcete, ale pokud se jedná o stejný případ hlášení nedostatku signálu do iPhonu a odezvy společnosti Apple „je, že se mýlíte“ z doby před několika lety. Pokud děláte distro, obvykle chcete poskytnout určitou kvalitu a minimální podporu a pravdou je, že Arch je v zásadě fandový systém, kde vidíte, že jeho vývojáři mají zábavu při balení nových věcí, ale mají malý zájem nabídnout skutečnou podporu . Pokaždé, když vidím tento typ příspěvku, vážím si více práce za distro, které používám.

        A ano, jedná se o softwarový problém, pokud nefunguje, přestane fungovat v aktualizaci nebo pokud dojde k poruše hardwaru. To, že panická distribuce jádra, zatímco jiná ne ... no, jasně, jasně existuje distro, které dělá věci správně a jiné špatně. Nyní, pokud je vám potěšením používat Linux ve stylu 90. let, kdy jsme museli překompilovat jádro pokaždé, když jsme připojili novou tiskárnu ... tam vy.

  5.   Mario řekl

    Je jádro kompilováno vývojáři? nebo vlastní?
    Paniky jádra se generují, když při kompilaci nebyly vybrány určité komponenty (AND), nebo nebyly aktivovány některé moduly, které podporují určitý hardware. S praxí a znalostmi vašeho hardwaru (musíte otevřít počítač a zjistit, jaké značky čipů má), můžete vytvořit vlastní jádro (chrooting). Pokud se ve vašem počítači nacházel ubuntu a instalační disk Arch, je v kompilaci něco, co není aktivováno.

    1.    c4výbušný řekl

      Bylo to základní jádro ze samotného archlinuxu, z úložišť.

  6.   anonymní řekl

    Jádro, které používáte, zbývá něco, co se vašemu hardwaru nelíbí, musíte mít na základní desce vzácnou verzi čipu nebo dokonce chybu v čipu (obvykle se to stane).
    Může to být poškozená tabulka vašeho bios acpi, je normální, že Číňané ve službě nevypočítají ani kontrolní součet každé tabulky dobře, tyto zprávy se obvykle objeví s $ dmesg -human na začátku bootování.
    Měli byste také zkusit jiný zdroj napájení, když selže filtrování, zvlnění má tendenci dělat právě tento druh selhání.
    Nejprve zkuste změnit zdroj a uvidíte, co se stane, pokud to zůstane stejné, zkuste nakonfigurovat jádro šité na míru vašemu hardwaru, mimochodem, díky čemuž budete v tomto procesu lépe znát svůj počítač.

    1.    c4výbušný řekl

      Díky za tipy. Mimochodem, jedná se o notebook, myslím, že bych měl vyměnit baterii. Ale vidím, co jsi mi řekl, mi může pomoci.

  7.   yukiteru řekl

    Jediná jádrová panika, která mě stále přivádí k šílenství, je částečně chyba chlápků v nouveau a mé staré, zastaralé a velmi zaprášené integrované karty nVidia 6150 SE (myslím částečně proto; jako ty, které nVidia má, a to vše pouze s využitím reverzního inženýrství a problém nastává pouze u některých karet s čipovou sadou NV4E).

    Stačí spustit Openbox + Firefox a udeřit katastrofu (nic krásnějšího než vidět zcela náhodnou černou a bílou mozaiku na obrazovce). A zpívám to od jádra 3.6 v Debianu, Fedoře, Archlinuxu, Slackwaru a nyní znovu ověřuji v Gentoo (právě nainstalováno s jádrem 3.12), už se neobtěžuji brát protokol, do jádra nebo mu dát čas napsat něco, co nemusí být ohromné ​​nesmysly.

    1.    anonymní řekl

      Dávám vám řešení, počítač, který mám s gentoo a integrovaným videem nvidia, se děje stejně s ovladačem nouveau, takže jsem neměl jinou možnost než použít uzavřený ovladač nvidia, můj čip musí používat ovladač 304.123

      00: 0d.0 VGA kompatibilní řadič [0300]: NVIDIA Corporation C61 [GeForce 7025 / nForce 630a] [10de: 03d6] (rev a2) (prog-if 00 [VGA řadič])

      Před kompilací musíte soubor jádra opravit, pokud nebude opraven, grafický režim se odmítne spustit.

      Kroky jsou:
      # nano -w /usr/src/linux-3.15.7-gentoo/drivers/acpi/osl.c
      Vyhledejte tento text pomocí ctrl + w v nano, acpi_os_wait_events_complete a nano vás přenese do této části:

      void acpi_os_wait_events_complete (void)
      {
      flush_workqueue (kacpid_wq);
      flush_workqueue (kacpi_notify_wq);
      }
      EXPORT_SYMBOL (acpi_os_wait_events_complete);

      Patch, který musíte přidat, je tento poslední řádek, který začíná EXPORT, ctrl + nebo ctrl + x
      Poté zkompilujete jádro, nainstalujete moduly, nainstalujete jádro, vygenerujete initramfs, pokud to potřebujete, přidáte splash do initramfs, pokud použijete splash, regenerujete položky pro grub a nakonec a velmi důležité je znovu sestavit moduly, které nejsou z jádra nebo proprietárního modulu nvidia, bez toho by grafický režim nefungoval.

      # eselect seznam jader
      # eselect sada jádra x
      # cd / usr / src / linux
      # udělat
      # make modules_install
      # mount / boot
      # make install
      # dracut –hostonly »3.15.7-gentoo – síla
      # splash_geninitramfs –verbose –res 1400 × 1050 –append /boot/initramfs-3.15.7-gentoo.img emerge-world
      # grub -mkconfig -o /boot/grub/grub.cfg
      # emerge @ module-rebuild
      # umount / boot
      # shutdown -r nyní

      Pokud používáte genkernel, pouze opravíte tento soubor a chápu, že genkernel se sám opraví.
      Kromě toho byste měli z jádra odebrat podporu drm a ovladače nvidia a další video čipy, aby se nekolidovaly čelně s uzavřeným ovladačem nvidia, který je nainstalován jako modul nvidia.
      V případě použití bootsplash musíte do jádra zahrnout ovladač uvesa, aby podporoval vysoké rozlišení obrazovky, protože uzavřený ovladač nvidia (pokud si dobře pamatuji) nepodporuje více než 800 × 600 v terminálu tty1 «F1» bota.
      Nevím o jiných distribucích, ale předpokládám, že by to mělo fungovat na jakémkoli distribuci, pokud by byly provedeny tyto kroky, přičemž by se uložila změna objevení pro cokoli.

      Toto jsou pokyny, které musíte dodržovat, pro nvidia a uvesa:
      http://wiki.gentoo.org/wiki/NVidia/nvidia-drivers/es
      http://wiki.gentoo.org/wiki/Uvesafb

      1.    yukiteru řekl

        Díky za informace, ale problém jsem vyřešil přesně změnou na proprietární. Pamatuji si, že předchozí ovladač nVidia (304.121) musel být také opraven, když šel na 3.13, protože měl problém při kompilaci modulu (nebyly žádné chyby, ale modul odmítl fungovat) a všechno také kvůli ACPI obsluha události. V Debianu jsem dostal problém a našel jsem také řešení.

        https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740097

    2.    Dayara řekl

      Jako příklad jsem použil Manjaro, ale dříve jsem zmínil, že se mi stalo to samé s Archem a dalšími deriváty. Proto se domnívám, že problém je spíše jejich než postižených.

      Pd: Nebyl jsem schopen reagovat přímo na příslušnou zprávu, protože možnost reagovat se nezobrazí ...

  8.   Dayara řekl

    Právě jsem přešel z Manjaro do Linux Mint, protože by to zamrzlo při bootování po aktualizaci na verzi po 0.8.9 (nepamatuji si kterou). Z toho, co jsem četl, se to obvykle děje na laptopech. Můj problém nebyl stejný jako ten v tomto příspěvku, myslím, že jsem dospěl k závěru, že by to mohlo souviset se správou energie. Byli lidé, kteří nezmrzli, pokud spustili notebook, když byli odpojeni. Právě teď si nepamatuji, jestli mi to umožnilo vždy začít bez problémů, ale samozřejmě jsem to dokázal vícekrát za cenu, že to budu trvat déle.
    Nakonec jsem to ale vzdal a přešel na Fedoru a Linux Mint.

    1.    c4výbušný řekl

      Shodou okolností jsem se včera pokusil pozastavit bez nabíječky a při obnovení to viselo a musel jsem restartovat.

  9.   Amaury řekl

    Je to docela vtipné, jsem v Archu několik měsíců a neměl jsem ani jednu paniku jádra! Stalo se mi to s Antergosem (Arch s přidaným úložištěm) ze živého prostředí, ale tam to považuji za srozumitelnější. Může to být problém s základní deskou nebo vadným modulem RAM? Vzpomínám si, že asi před 2 lety mi modul RAM způsobil několik modrých obrazovek ve Windows a také několik paniků jádra! na Mandrivu. Mezi restartováním a restartováním jsem musel testovat každou paměť po druhé.

    1.    Dayara řekl

      Jedná se o problém Arch (který táhne všechny jeho deriváty), protože v jiných distribucích nejsou žádné problémy tohoto typu. Považuji za trapné, že v tuto chvíli to nevyřešili. Jsou to jen oni roky! Četl jsem podobné problémy z roku 2011. Je mi jasné, že při aktualizaci se jedná o něco, co přichází a odchází, protože při použití verzí 0.8.7, 0.8.8 a 0.8.9 bez jejich aktualizace se nic neděje. Od té doby jde všechno do prdele a určitě se to stalo i ve starých verzích. Proč se to stalo jen několika z nás? Nevím, ale nemyslím si, že je to náš problém, ale Archův, protože, jak již bylo řečeno, ostatní distribuce fungují perfektně. Už jsem v jeho době zlomil rohy, abych našel řešení, ale unavil jsem se. Takže jak je mi líto, nebudu používat Archa.

      1.    yukiteru řekl

        Oblouk 0.8.7, 0.8.8 a 0.8.9? Zjistil jsem, že Arch používá nomenklaturu této verze.

        Je možné, že používáte Manjaro?

      2.    yukiteru řekl

        Dobře, odpovídám si přečtením vašeho předchozího komentáře a jedna věc je Manjaro a druhá je Arch.

        To, že obviňuji distro z určitého problému, také není konzistentní (ne opravdu konzistentní), alespoň v mém případě nemohu vinit, kolik distro se snažím za problém s nouveau a mou kartou nVidia 6150SE, protože problém je v MMIO manipulace s ovladačem a kartou (nVidia bude vědět, co opravit a bláznivé věci, které budou muset opravit tento detail). Problémem může být také hardware a můžete vidět, že v jakémkoli operačním systému, který používáte (Windows, Linux, BSD), a podle mých zkušeností s opravou počítačů jsem viděl velmi podivné problémy s hardwarem (například počítač, který odmítá bootovat, změňte umístění paměti a při vypnutí musíte postup opakovat) a nemohu za to vinit Windows a Debian.

  10.   7 řekl

    Měl jsem paniku jádra s živým ubuntu 12.04

  11.   Ulises Bernal Pérez řekl

    Mám frenetický svůj notebook Secure HP pavilion dm4, 8 GB RAM, 500 pevného disku, má více než 5 let používání. Nepamatuji si rychlost mikroprocesoru, jádra Intel i5, myslím, že více než 2 MHz.
    Na obrazovku terminálu nemohu nic napsat. Budu hledat další informace, abych tento problém vyřešil.