Možné riešenie pre náhodný „Kernel Panics“ pri zavedení systému Arch Linux

Tento príspevok má ukázať, ako „opraviť“ takmer problém startupov s chybami Arch Linux. Niečo ako nasledujúci obrázok:

IMG_20140707_210559

Ako je vidno, vidíme, že ide o jednu z mnohých „kombinácií“ chýb, ktoré sa náhodne objavia pri spustení operačného systému s týmto problémom. Ako sa hovorí v tejto chybe, znamená to, že v „hardvéri“ môže byť problém, avšak ako všetci vieme v tomto operačnom systéme, dajú sa vyriešiť aj zlé triky toho, čo do OS nepatrí.

Takže popíšem svoju skúsenosť s týmto problémom. Podľa toho, čo som mohol zažiť, bol problém iba s Arch Linux alebo iné distro, ktoré som testoval externe, pretože s ubuntu, ktoré som si nainštaloval alebo otestoval, sa spustilo bez problémov. Ale keby sa pokúsil roztrhnúť Arch Linux nainštalovaný na pevnom disku, mal problém, že sa musel asi 50krát reštartovať, aby sa OS mohol normálne bootovať a mohol ho používať.

Toto už so mnou malo niečo zlé, pretože som na jeho otestovanie mohol použiť iba ubuntu, ktorý som si nainštaloval, a nemohol som robiť ani polovicu vecí, s ktorými som mohol robiť Arch Linux. Preto som sa rozhodol tento problém vyriešiť a začal som vyšetrovať, hľadať vlákna fóra, ktoré mali rovnaký problém, spomenuli tiež, že išlo o hardvérovú chybu a že to bol práve procesor, takže ma to začalo znepokojovať, takže Musím otvoriť počítač a overiť, čo sa deje, ale nepomohlo to.

Ale niečo, čo mi ukázalo, že by som sa nemal vzdať, bolo to, ak ubuntu Mohol som preto Arch Linux nie (možno ubuntu je lepší ako Oblúk…?). Takže som začal zapisovať bootovacie parametre do jadra Arch Linux, veci ako: 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 = deaktivovať, i8042.noacpi = 1, apm = copyds, acd apm = copyds, acdtpi = 0, apm = copyds pci = nocrs, rhgb, acpi = sila, pnpacpi = XNUMXff a ďalšie ďalšie ... Toto všetko odporúčali fóra, ktoré som čítal.

Kým som nemusel zadávať dokumentáciu parametrov jadra, ktorú mimochodom odporúčam: https://www.kernel.org/doc/Documentation/kernel-parameters.txt

A našiel som celkom zaujímavý parameter, ktorý som pre túto chvíľu dokázal naštartovať Arch Linux Žiaden problém:

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

Ako je tam naznačené, týmto parametrom je obmedzené použitie na procesor bez aktivácie symetrického režimu spracovania. Spočiatku to fungovalo celkom dobre, až kým som nepoužil príkaz pacman-Syyu; hodil mi a jadro vyhodené o porucha segmentácie.

Automaticky som si teda všimol, že sa deje niečo zvláštne, a tak som začal spúšťať ďalšie procesy, až kým systém zrazu úplne nezamrzol a už nefungoval, kým som ho reštartoval. Urobil som teda rovnakú operáciu, ale tentokrát sa mi ju podarilo vykonať htop a ukázalo mi to nasledovné:

IMG-20140729-WA0001

Podľa očakávaní ukazoval iba jeden procesor, pretože ho druhý deaktivoval, ale zdalo sa mi veľmi čudné, prečo programy vrhali segfault, a nemohlo sa ani spustiť grafické prostredie; takže to bolo niečo, čo mi dalo aspoň väčšiu nádej, že ak nastavím parametre jadra jedným spôsobom, naštartuje sa to moje Arch Linux ako zvyčajne.

Skúšal som teda ďalšie parametre, ktoré som do zoznamu zapísal, až kým som nenarazil na tento, čo je momentálne najlepšie riešenie:

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

Tento parameter robí niečo také jednoduché ako izolácia (nie deaktivácia) druhého jadra CPU v symetrickom spracovaní, to znamená, že zaťaženie spracovania je dané jednému jadru, zatiaľ čo druhé je iba komplementárne. Aj keď sa to zdá byť protichodné, nemá to nijaký vplyv na výkon, pretože tento skvelý operačný systém dokázal spúšťať aplikácie týmto spôsobom:

test

linux_rlz_compiz

Takže s týmto jediným problémom, ktorý som si všimol a ktorý nastáva pri bootovaní, je jedna alebo dve paniky alebo ups jadra; ale v porovnaní s 50-krát, čo som musel predtým reštartovať, to môžem považovať za „riešenie“. Pokiaľ ide o zvyšok, zatiaľ mi to umožnilo používať OS a napísať tento príspevok, ktorý práve čítate :-).

Dúfam, že vám pomôžu a nedostanú sa z toho GNU / Linux, čo je najlepší operačný systém, aký kedy vymysleli. Hovorím to naisto.


Zanechajte svoj komentár

Vaša e-mailová adresa nebude zverejnená. Povinné položky sú označené *

*

*

  1. Zodpovedný za údaje: Miguel Ángel Gatón
  2. Účel údajov: Kontrolný SPAM, správa komentárov.
  3. Legitimácia: Váš súhlas
  4. Oznamovanie údajov: Údaje nebudú poskytnuté tretím stranám, iba ak to vyplýva zo zákona.
  5. Ukladanie dát: Databáza hostená spoločnosťou Occentus Networks (EU)
  6. Práva: Svoje údaje môžete kedykoľvek obmedziť, obnoviť a vymazať.

  1.   Gregory meče dijo

    Velmi zaujimave info. Nikdy som nemal také panické záchvaty jadra v ArchLinuxe za tie roky, čo ho používam, ale je pekné vedieť, čo robiť, ak sa mi problém niekedy vyskytne. Ďakujem!

    1.    kik1n dijo

      Každopádne Arch používam už dlho (bol som asi 1 rok bez Archu) a bez paniky jadra.
      Ďakujem za tip.

    2.    c4výbušný dijo

      S najväčšou pravdepodobnosťou, ako som už spomínal v príspevku, sa problém deje kvôli hardvéru, pretože v tom, čo používam arch, mi to tiež neprinieslo žiadny problém tohto typu.

    3.    živý dijo

      Ďalšia s vynikajúcimi výsledkami v archíve. Nikdy som nemal jadrovú paniku

    4.    rawBasic dijo

      Viac ako 2 roky s GNU / Linux ... 2 roky už s ArchLinuxom, nikdy neprepadla panike jadra .. 😉

    5.    Manuál zdroja dijo

      Myslím si, že panika jadra je spôsobená skôr hardvérom ako samotnou distribúciou. Nikdy som nevidel panické jadro na notebooku, ktorý používam, až na to, že som doň vložil Ubuntu alfa (a Arch Linux tu bol tiež dva roky). Na druhej strane, v inom notebooku, ktorý mám, každé distro, ktoré vložím, spôsobí vždy paniku jadra a širokú škálu chýb pre všetky chute.

  2.   eliotime3000 dijo

    S jadrom 3.14 na Debiane som narazil na problém s jadrovou panikou, okrem toho vždy, keď zapnem počítač, zobrazí sa správa „časový limit pripojenia / odpojenia“ (a tiež keď ho vypnem).

    1.    Amaury dijo

      Stalo sa mi to toľko vo Fedore ako v Arche, ale neviem prečo a ako nevidím rozdiel, pretože som nestrávil čas vyšetrovaním alebo riešením (ak je to problém).

    2.    dasasd dijo
  3.   Tony dijo

    Dakujem pekne za info. Niektoré z mnohých vecí, ktorými sa môžeme pochváliť, je tento typ fóra

  4.   manu dijo

    Prečo sa to stalo v Arch Linuxe? Možno to nestačí na problémy, ktoré sa často objavujú pri pomalosti alebo zavesení systému, pri ktorom dôjde k uvrhnutiu systému na pražce.

    1.    živý dijo

      Hej? O čom to rozprávaš? o_O

    2.    Amaury dijo

      Arch je distribúcia KISS konfigurovateľná zo základne samotného operačného systému, niekoľkými slovami, ak je systém ťažký, je to preto, že ste ho postavili tak, ak má systém chyby, je to preto, že ste ich vygenerovali alebo preto, že ste niečo nenakonfigurovali správne. Arch wiki je dosť kompletný, pred pár rokmi nebolo v španielčine veľa dôležitých tém a to a proces inštalácie bol oveľa drsnejší a trochu zložitejší, teraz je všetko trochu automatizovanejšie.
      Obviňovanie distro za chyby používateľov je tak ... Windows (?).

      1.    Dayara dijo

        Obviňovanie distro z chýb je konzistentné, jednoducho preto, že je to pravda. Po podobnom probléme s Manjaro som vyskúšal Arch, Antergos a inú neznámu distribúciu (meno si teraz nepamätám, pardon), ktoré mi niekto odporučil a uistil ma, že to nerobí problémy, ale nič; všetci to dajú. V OpenSuse, Fedore, Minte, Mageii a všetkých ďalších, ktoré som potom vyskúšal, sa to nestáva. Pokiaľ teda ide o mňa, nezostáva mi nič iné, ako si myslieť, že je to chyba distro. Ale hej, nedémonizujem to ani nič, navyše ma štve, že nemôžem nič použiť na základe Archa, pretože sa mi to veľmi páči, ale ten prekliatý problém mi prekáža. Rovnako si nemyslím, že ide o hardvér, pretože veľa z nás, čo sa nám stalo, sa nestalo predtým, ako sme použili to isté sakra. Vlastne to musí byť niečo, čo súvisí s hardvérom, ale keď sa vrátim k tomu istému, pokiaľ som neurobil žiadne zmeny a mám problémy s rovnakým vybavením, s akým som ich predtým nemal, bude to zjavne spôsobené vykonanou zmenou od Archa, ktorý ma posral.

      2.    johnfgs dijo

        „Obviňovanie distro z chýb používateľa je také ... Windows (?).“

        Povedal by som vám, že obviňovanie používateľov z chýb produktu je tak Apple. Úprimne som o tom premýšľal už tisíckrát, ale nevidím výhodu v tom, že by som z nejakého vážneho dôvodu použil niečo, čoho si správcovia v podstate umývajú ruky. A hovorím, že vzhľadom na to, že softvér GPL je dodávaný bez záruky.

        Môžete si povedať, ako chcete, ale ak ide o rovnaký prípad správ o nedostatku signálu pre iPhone a odpoveď spoločnosti Apple „je, že to chápete zle“ spred niekoľkých rokov. Ak robíte distribúciu, obvykle chcete poskytnúť určitú kvalitu a minimálnu podporu. Pravdou je, že Arch je v zásade systém pre fanúšikov, kde vidíte, že jeho vývojári sa zabávajú balením nových vecí, ale majú malý záujem ponúknuť skutočná podpora. Zakaždým, keď vidím tieto typy príspevkov, viac si vážim prácu, ktorú používam za distribúciu.

        A áno, ide o softvérový problém, ak nefunguje, prestane fungovať v aktualizácii alebo sa pokazí niečo z hardvéru. To, že panická porucha v jadre, zatiaľ čo iná nie, ... no, áno, zjavne existuje distro, ktoré robí veci dobre a iné zle. Teraz, ak je vám potešením používať Linux v štýle 90. rokov, kedy sme museli prekompilovať jadro zakaždým, keď sme pripojili novú tlačiareň ... tam ste.

  5.   mario dijo

    Je jadro zostavené vývojármi? alebo svoj vlastný?
    Panikové jadrá sa generujú tým, že ste pri kompilácii nevybrali (A) určité komponenty, alebo neaktivujete niektoré moduly na podporu určitého hardvéru. S praxou a znalosťami vášho hardvéru (musíte otvoriť počítač a zistiť, aké značky čipov má), môžete vytvoriť vlastné jadro (chrootovaním). Ak sa vo vašom počítači nachádzal ubuntu a inštalačné CD Arch, v kompilácii je niečo, čo nie je aktivované.

    1.    c4výbušný dijo

      Bolo to základné jadro zo samotného archlinuxu, z archívov.

  6.   anonymný dijo

    Jadro, ktoré používate, zostalo niečo, čo sa vášmu hardvéru nepáči, musíte mať na základnej doske vzácnu verziu čipu alebo dokonca chybu v čipe (zvyčajne sa to stane).
    Môže to byť poškodená tabuľka z vášho bios acpi, je normálne, že službukonajúci Číňania nevypočítajú ani kontrolný súčet každej tabuľky dobre, tieto správy sa zvyčajne objavia s $ dmesg -human na začiatku bootovania.
    Mali by ste tiež vyskúšať iný zdroj napájania, keď zlyhá filtrovanie, zvlnenie má tendenciu robiť práve tento druh poruchy.
    Najskôr skúste zmeniť písmo a uvidíte, čo sa stane, ak zostane rovnaké, skúste nakonfigurovať jadro prispôsobené vášmu hardvéru, vďaka čomu v tomto procese lepšie spoznáte svoj počítač.

    1.    c4výbušný dijo

      Ďakujem za tipy. Mimochodom, je to notebook, myslím si, že by som mal vymeniť batériu. Ale vidím, čo si mi povedal, mi môže pomôcť.

  7.   yukiteru dijo

    Jedna z jadrových paník, ktorá ma stále privádza do šialenstva, je čiastočne chybou nových ľudí a mojej starej, zastaranej a veľmi zaprášenej integrovanej karty nVidia 6150 SE (myslím tým čiastočne preto, že odviedli vynikajúcu prácu podporujúcu vesmír grafických čipov ako tie, ktoré nVidia má, a to všetko iba s využitím reverzného inžinierstva a problém nastáva iba pri niektorých kartách s čipsetom NV4E).

    Stačí spustiť Openbox + Firefox a môžete zasiahnuť katastrofu (nič krajšie ako vidieť úplne náhodnú čiernobielu mozaiku na obrazovke). A spievam to už od jadra 3.6 v Debiane, Fedore, Archlinuxe, Slackware a teraz znova overené v Gentoo (práve nainštalované s jadrom 3.12), už sa neobťažujem brať log, do jadra alebo mu dať čas napíš niečo, čo nebudú ohromné ​​nezmysly.

    1.    anonymný dijo

      Dávam vám riešenie, počítač, ktorý mám s programom gentoo a integrovaným videom nvidia, je rovnaký aj s ovládačom nouveau, takže mi nezostávalo nič iné, ako použiť uzavretý ovládač nvidia, môj čip musí používať ovládač 304.123

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

      Pred kompiláciou musíte opraviť súbor jadra, pokiaľ nebude opravený, grafický režim sa odmietne spustiť.

      Kroky sú tieto:
      # nano -w /usr/src/linux-3.15.7-gentoo/drivers/acpi/osl.c
      Vyhľadajte pomocou ctrl + w v nano tento text, acpi_os_wait_events_complete a nano vás zavedie do tejto časti:

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

      Patch, ktorý musíš pridať, je tento posledný riadok, ktorý začína EXPORT, ctrl + alebo ctrl + x
      Potom skompilujete jadro, nainštalujete moduly, nainštalujete jadro, vygenerujete initramfs, ak to potrebujete, pridajte splash do initramfs, ak používate splash, regenerujete položky pre grub a nakoniec a čo je dôležité, musíte znova zostaviť moduly, ktoré nie sú z jadra ani z patentovaného modulu nvidia, bez toho grafický režim nebude fungovať.

      # eselect zoznam jadier
      # eselect sada jadra x
      # cd / usr / src / linux
      # urobiť
      # make modules_install
      # mount / boot
      # make install
      # dracut –hostonly »3.15.7-gentoo – sila
      # 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 teraz

      Ak používate genkernel, iba opravíte tento súbor a chápem, že genkernel sa sám opraví.
      Mali by ste tiež odstrániť podporu drm a ovládače nvidia a ďalšie video čipy z jadra, aby sa nezrazili čelne s uzavretým ovládačom nvidia, ktorý je nainštalovaný ako modul nvidia.
      V prípade použitia bootsplash musíte do jadra zahrnúť ovládač uvesa, aby podporoval vysoké rozlíšenie obrazovky, pretože uzavretý ovládač nvidia (pokiaľ si dobre pamätám) nepodporuje viac ako 800 × 600 v termináli tty1 «F1» bootovacieho zariadenia.
      O iných distribúciách neviem, ale predpokladám, že ak by sa tieto kroky vykonali, malo by to fungovať na akomkoľvek distro, čím by sa uložila zmena, ktorá by sa objavila, na čokoľvek.

      Toto sú pokyny, ktoré musíte dodržiavať pre zariadenia nvidia a uvesa:
      http://wiki.gentoo.org/wiki/NVidia/nvidia-drivers/es
      http://wiki.gentoo.org/wiki/Uvesafb

      1.    yukiteru dijo

        Ďakujem za informácie, ale problém som vyriešil presne zmenou na proprietárne. Pamätám si, že predchádzajúci ovládač nVidia (304.121) musel byť tiež opravený, keď šiel na 3.13, pretože mal problém pri kompilácii modulu (neboli tam žiadne chyby, ale modul odmietol pracovať) a všetko tiež kvôli obslužnému programu udalostí ACPI . V Debiane som dostal problém a našiel som riešenie tiež.

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

    2.    Dayara dijo

      Ako príklad som použil Manjaro, ale už som spomínal, že to isté sa mi stalo s Archom a inými derivátmi. Preto sa domnievam, že problém je viac ako ich postihnutých.

      Pd: Nedokázal som odpovedať priamo na príslušnú správu, pretože sa mi nezobrazuje možnosť odpovedať ...

  8.   Dayara dijo

    Práve som prešiel z Manjaro do Linux Mint, pretože by to zamrzlo pri bootovaní po aktualizácii na verziu po 0.8.9 (nepamätám si ktorú). Podľa toho, čo som čítal, sa to väčšinou deje na notebookoch. Môj predmetný problém nebol rovnaký ako problém v tomto príspevku, myslím si, že som dospel k záveru, že by to mohlo súvisieť s energetickým manažmentom. Boli ľudia, ktorí nezmrzli, ak spustili notebook odpojený od siete. Momentálne si nepamätám, či mi to umožnilo vždy začať bez problémov, ale samozrejme som to dokázal viackrát za cenu, že mi to bude trvať dlhšie.
    Nakoniec som to ale vzdal a prešiel na Fedoru a Linux Mint.

    1.    c4výbušný dijo

      Zhodou okolností som sa včera pokúsil pozastaviť ho bez nabíjačky a pri jeho obnovení to zavesilo a musel som reštartovať.

  9.   Amaury dijo

    Je to celkom sranda, som v Arche pár mesiacov a nemal som ani jednu Kernel Panic! Stalo sa mi to s Antergosom (Arch s pridaným úložiskom) zo živého prostredia, ale tam to považujem za zrozumiteľnejšie. Môže to byť problém s matičnou doskou alebo chybným modulom RAM? Pamätám si asi pred 2 rokmi, keď mi modul RAM spôsobil niekoľko modrých obrazoviek vo Windows a tiež niekoľko paník jadra! na Mandrive. Medzi reštartom a reštartom som musel testovať každú pamäť naraz.

    1.    Dayara dijo

      Je to problém Archu (ktorý nesie všetky svoje deriváty), pretože v iných distrách také problémy nie sú. Príde mi trápne, že v tejto chvíli to nevyriešili. Sú to už len roky! Čítal som podobné problémy z roku 2011. Je mi jasné, že je to niečo, čo pri aktualizácii prichádza a odchádza, pretože pri použití verzií 0.8.7, 0.8.8 a 0.8.9 bez ich aktualizácie sa nič nedeje. Odvtedy ide všetko do sračiek a určite sa to stalo aj v starých verziách. Prečo sa to stáva len pár z nás? Neviem, ale nemyslím si, že je to náš problém, ale Arch, pretože, ako už bolo povedané, iné distribúcie idú perfektne. Už v jeho dňoch som si zlomil rohy, aby som našiel riešenie, ale unavil som sa. Takže ako je mi ľúto, nebudem používať Archa.

      1.    yukiteru dijo

        Arch 0.8.7, 0.8.8 a 0.8.9? Zistil som, že Arch používa túto nomenklatúru verzie.

        Je možné, že používate Manjaro?

      2.    yukiteru dijo

        Dobre, odpovedám si prečítaním vášho predchádzajúceho komentára a jedna vec je Manjaro a druhá je Arch.

        To, že obviňujem distribúciu z určitého problému, tiež nie je konzistentné (nie skutočne konzistentné), aspoň v mojom prípade nemôžem za to, koľko distro sa snažím za problém s nouveau a mojou kartou nVidia 6150SE, pretože problémom je MMIO narábanie s vodičom a kartou (nVidia bude vedieť, čo opraviť, a šialené veci, ktoré budú musieť opraviť tento detail). Problémom môže byť aj hardvér. Vidíte, že v každom operačnom systéme, ktorý používate (Windows, Linux, BSD), a podľa mojich skúseností s opravou počítačov som zaznamenal veľmi zvláštne hardvérové ​​problémy (napríklad počítač, ktorý sa odmietne spustiť, pokiaľ zmeňte umiestnenie pamäte a pri vypínaní musíte postup zopakovať) a nemôžem za to viniť Windows a Debian.

  10.   raalso7 dijo

    Mal som paniku z jadra so živým ubuntu 12.04

  11.   Ulysses Bernal Perez dijo

    Mám frenetiku na svojom notebooku Secure HP pavilion dm4, 8 GB RAM, 500 pevnom disku, má viac ako 5 rokov používania. Nepamätám si rýchlosť mikroprocesora, Intel Core i5, myslím, že viac ako 2 MHz.
    Na terminálovú obrazovku nemôžem nič napísať. Na vyriešenie tohto problému budem naďalej hľadať ďalšie informácie.