Arch Linux önyüklemesinde rastgele "Kernel Panics" için olası çözüm

Bu gönderi, hata içeren başlangıç ​​sorunlarının neredeyse nasıl "düzeltileceğini" göstermektir. Arch Linux. Aşağıdaki resim gibi bir şey:

IMG_20140707_210559

Görüldüğü gibi, bunun, bir işletim sistemini bu problemle başlatırken rastgele ortaya çıkan birçok hata "kombinasyonundan" biri olduğunu görüyoruz. Bu hatada söylediği gibi "Donanım" da bir sorun olabileceğini gösteriyor, ancak bu işletim sisteminde hepimizin bildiği gibi işletim sistemine ait olmayanların kötü hileleri bile çözülebiliyor.

Bu yüzden, bu problemle ilgili deneyimimi anlatacağım. Yaşadıklarıma göre, sorun sadece Arch Linux veya harici olarak test ettiğim başka bir dağıtım, çünkü yüklediğim veya test ettiğim herhangi bir ubuntu ile sorunsuz başladı. Ama o parçalamaya çalıştıysa Arch Linux sabit sürücüye yüklendiğinde, işletim sisteminin normal şekilde önyüklenmesi ve kullanabilmesi için yaklaşık 50 kez yeniden başlatılması gerektiği gibi bir sorunu vardı.

Bende zaten bir sorun vardı çünkü test etmek için kurduğum ubuntu'yu sadece kullanabiliyordum ve yapabileceğim şeylerin yarısını bile yapamadım. Arch Linux. Bu yüzden bu sorunu çözmeye karar verdim ve araştırmaya başladım, aynı soruna sahip forum başlıklarını aradım, ayrıca bunun bir donanım hatası olduğundan ve tam olarak CPU olduğundan bahsettiler, bu yüzden beni endişelendirmeye başladı. Bilgisayarı açmam ve ne olduğunu doğrulamam gerekiyor, ancak yardımcı olmadı.

Ama bana pes etmemem gerektiğini gösteren bir şey şuydu: Ubuntu Yapabilirdim çünkü Arch Linux hayır (belki Ubuntu daha iyi Kemer…?). Böylece, çekirdeğe önyükleme parametreleri yazmaya başladım. Arch Linux, gibi şeyler: 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 = disable, 8042yds = 1 coptyds, i0.noacpi = XNUMX, apm = coptyds, acds = actyds pci = nocrs, rhgb, acpi = kuvvet, pnpacpi = XNUMXff ve diğerleri… Bütün bunlar okuduğum forumlarda önerildi.

Bu arada tavsiye ettiğim çekirdek parametreleri belgelerine gitmem gerekene kadar: https://www.kernel.org/doc/Documentation/kernel-parameters.txt

Ve şu an için başlatmayı başardığım oldukça ilginç bir parametre buldum Arch Linux Sorun değil:

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

Orada belirtildiği gibi, bu parametrenin yaptığı şey, simetrik işleme modunu etkinleştirmeden kullanımı bir cpu ile sınırlamaktır. İlk başta, komutu kullanana kadar oldukça iyi çalıştı pacman -Syyu; bana bir çekirdek atıldı o Segmentasyon hatası.

Bu yüzden otomatik olarak garip bir şey olduğunu fark ettim, bu yüzden diğer işlemleri çalıştırmaya başladım, ta ki aniden sistem tamamen dondu ve yeniden başlatana kadar artık çalışmadı. Ben de aynı işlemi yaptım ama bu sefer htop ve bana şunu gösterdi:

IMG-20140729-WA0001

Beklendiği gibi, yalnızca bir CPU gösterdi, diğeri devre dışı bıraktığı için, ancak programların neden fırlattığı bana çok garip geldi segfault, ve hatta grafik ortamı başlatamadı; bu yüzden en azından bana daha fazla umut veren bir şeydi, eğer çekirdek parametrelerini bir şekilde ayarlarsam, Arch Linux her zaman oldugu gibi.

Bu yüzden buna rastlayana kadar listeye yazdığım diğer parametreleri denemeye devam ettim, şu an için en iyi çözüm bu:

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

Bu parametre, simetrik işlemede CPU'nun ikinci çekirdeğini izole etmek (devre dışı bırakmak değil) kadar basit bir şey yapar, yani işlem yükü tek bir çekirdeğe verilirken diğeri yalnızca tamamlayıcıdır. Bu, çelişkili görünmesine rağmen performansı çok fazla etkilemez, çünkü bu harika işletim sistemi uygulamaları şu şekilde çalıştırabiliyordu:

Ölçek

Linux_rlz_compiz

Öyleyse bununla, önyükleme sırasında meydana gelen tek sorun, bir veya iki çekirdek paniği veya hata; ancak daha önce yeniden başlatmak zorunda kaldığım 50 zamanla karşılaştırıldığında, bunu bir "geçici çözüm" olarak görebilirim. Geri kalanı için, şimdiye kadar işletim sistemini kullanmama ve şu anda okuduğunuz bu yazıyı yazmama izin verdi :-).

Umarım sana yardım ederler ve kurtulmazlar GNU / Linux, icat ettikleri en iyi işletim sistemi. Kesinlikle söylüyorum.


Makalenin içeriği şu ilkelerimize uygundur editoryal etik. Bir hata bildirmek için tıklayın burada.

31 yorum, sizinkini bırakın

Yorumunuzu bırakın

E-posta hesabınız yayınlanmayacak. Gerekli alanlar ile işaretlenmiştir *

*

*

  1. Verilerden sorumlu: Miguel Ángel Gatón
  2. Verilerin amacı: Kontrol SPAM, yorum yönetimi.
  3. Meşruiyet: Onayınız
  4. Verilerin iletilmesi: Veriler, yasal zorunluluk dışında üçüncü kişilere iletilmeyecektir.
  5. Veri depolama: Occentus Networks (AB) tarafından barındırılan veritabanı
  6. Haklar: Bilgilerinizi istediğiniz zaman sınırlayabilir, kurtarabilir ve silebilirsiniz.

  1.   Gregorio Espadas dijo

    Çok ilginç bilgi. ArchLinux'da onu kullandığım yıllarda hiç bu çekirdek paniklerini yaşamadım, ancak sorun başıma gelirse ne yapacağımı bilmek güzel. Teşekkür ederim!

    1.    kik1n dijo

      Her neyse, Arch'ı uzun süredir kullanıyorum (Arch'sız 1 yıl gibiydim) ve kernel paniği olmadan.
      Bahşiş için teşekkürler.

    2.    c4 patlayıcı dijo

      Büyük olasılıkla, yazıda da bahsettiğim gibi, sorun donanımdan kaynaklanıyor, çünkü arch kullandığım şeyde bana bu türden herhangi bir sorun da vermemişti.

    3.    ela dijo

      Arch'da mükemmel sonuçlara sahip bir tane daha. Hiç Kernel Panik yaşamadım

    4.    hamBasic dijo

      GNU / Linux ile 2 yıldan fazla ... ArchLinux ile 2 yıl, hiçbir zaman çekirdek paniği .. 😉

    5.    Manuel de la Fuente dijo

      Çekirdek paniklerinin dağıtımın kendisinden çok donanımdan kaynaklandığını düşünüyorum. Şu anda kullandığım dizüstü bilgisayarda hiç bir panik çekirdeği görmedim, ancak içine bir Ubuntu alfa koydum (ve Arch Linux da iki yıldır buradaydı). Öte yandan, sahip olduğum başka bir dizüstü bilgisayarda, koyduğum herhangi bir dağıtım her zaman çekirdek paniği ve her zevke uygun çok çeşitli hatalar veriyor.

  2.   eliotime3000 dijo

    Debian'daki 3.14 kernel ile, çekirdek panik problemiyle karşılaştım, ayrıca bilgisayarımı her açtığımda, bir "bağlan / bağlantıyı kes zaman aşımı" mesajı alıyorum (ve ayrıca kapattığımda).

    1.    Amaury dijo

      Arch'da olduğu gibi Fedora'da da başıma geldi, ama nedenini bilmiyorum ve nasıl bir fark görmüyorum çünkü bunu araştırmak veya çözmek için zaman harcamadım (eğer bir sorunsa).

  3.   Tony dijo

    Bilgi için çok teşekkür ederim. Övünebileceğimiz birçok şeyden bazıları bu tür bir forumdur

  4.   manu dijo

    Bu neden Arch Linux'a oluyor? Sistemin yavaşlığı ya da asılmasıyla sık sık ortaya çıkan problemlerde sistemi perdeye fırlatma noktasına gelmesinde belki de yeterli değildir.

    1.    ela dijo

      Hey? Neden bahsediyorsun? o_O

    2.    Amaury dijo

      Arch, işletim sisteminin temelinden yapılandırılabilen bir KISS dağıtımıdır, birkaç kelimeyle, eğer sistem ağırsa, bu şekilde kurduğunuz içindir, sistemde hatalar varsa, bunun nedeni onları sizin oluşturmuş olmanız veya bir şeyi doğru şekilde yapılandırmamış olmanızdır. Arch wiki oldukça tamamlandı, birkaç yıl önce İspanyolca'da pek çok önemli konu yoktu ve kurulum süreci çok daha zorlu ve biraz zordu, şimdi her şey biraz daha otomatik.
      Dağıtımı kullanıcı hatalarından dolayı suçlamak çok… Windows (?).

      1.    Dayara dijo

        Dağıtımı hatalardan dolayı suçlamak tutarlıdır, çünkü gerçek budur. Manjaro ile benzer bir sorun yaşadıktan sonra, Arch, Antergos ve başka bir bilinmeyen dağıtımı denedim (şu anda adını hatırlayamıyorum, üzgünüm) birisinin bana sorun vermediğine dair güvence vermesini önerdi, ama hiçbir şey vermedi; hepsi veriyor. OpenSuse, Fedora, Mint, Mageia ve daha sonra denediklerimde bu olmuyor. Bana kalırsa, bunun dağıtımın hatası olduğunu düşünmekten başka çarem kalmadı. Ama, hey, onu şeytan gibi göstermiyorum, dahası, Arch'a dayalı hiçbir şeyi kullanamamak canımı sıkıyor çünkü onu çok seviyorum, ama bu lanet problem beni engelliyor. Bunun donanımla ilgili olduğunu da düşünmüyorum, çünkü çoğumuz aynı sikişi kullanmadan önce başımıza gelmedi. Aslında donanımla ilgili bir şey olmalı, ama aynı şeye geri dönersem, herhangi bir değişiklik yapmadıysam ve daha önce sahip olmadığım aynı ekipmanla sorunlar yaşarsam, açıkçası yapılan bir değişiklikten kaynaklanacaktır. Arch beni mahvetti.

      2.    Juanfgs dijo

        "Kullanıcı hatalarından dolayı dağıtımı suçlamak çok ... Windows (?)."

        Ürün hatalarından dolayı kullanıcıları suçlamanın çok Apple olduğunu söyleyebilirim. Bunu dürüstçe binlerce kez düşündüm, ancak bakımcıları temelde ellerini yıkayan bir şeyi ciddi bir amaç için kullanmanın avantajını görmüyorum. Ve GPL yazılımının garantisiz geldiğini düşündüğümü söylüyorum.

        İstediğiniz gibi söyleyebilirsiniz, ancak iPhone'a sinyal gelmediğine dair raporlar ve Apple'ın birkaç yıl öncesinden "yanlış anladığınızdır" yanıtı da aynıysa. Bir dağıtım yaparsanız, genellikle biraz kaliteli ve minimum düzeyde destek sağlamak istersiniz ve gerçek şu ki Arch, geliştiricilerinin yeni şeyleri paketlemekle eğlendiğini, ancak bir gerçek destek. Bu tür gönderileri her gördüğümde, kullandığım dağıtımın arkasındaki çalışmaya daha çok değer veriyorum.

        Ve evet, çalışmazsa, bir güncellemede çalışmayı durdurursa veya donanımda bir şey bozulursa bu bir yazılım sorunudur. Bir çekirdek panik dağıtımı yapmazken diğeri yapmaz… pekala, evet, açıkça işleri doğru ve diğerini yanlış yapan bir dağıtım var. Şimdi, Linux'u her yeni yazıcıyı taktığımızda çekirdeği yeniden derlemek zorunda kaldığımız 90'ların tarzında kullanmaktan zevk alıyorsanız ... işte buradasınız.

  5.   mario dijo

    Çekirdek geliştiriciler tarafından derlenmiş mi? veya kendi
    Çekirdek panikleri, derleme sırasında belirli bileşenler seçilmediğinde (VE) veya belirli donanımları desteklemek için bazı modüller etkinleştirilmediğinde oluşturulur. Donanımınız hakkında pratik ve bilgi sahibi olarak (bilgisayarı açmanız ve hangi yongalara sahip olduğunu görmeniz gerekir), özel bir çekirdek oluşturabilirsiniz (chroot yaparak). Ubuntu ve Arch kurulum CD'si bilgisayarınızda bulunuyorsa, derlemede etkinleştirilmemiş bir şey vardır.

    1.    c4 patlayıcı dijo

      Archlinux'un kendisinden, depolardan gelen stok çekirdeğiydi.

  6.   anonim dijo

    Kullandığınız çekirdek, donanımınızın beğenmediği bir şey kaldı, anakartınızda bir yonganın nadir bir sürümüne veya bir yongada bir hata olmasına (genellikle olur) sahip olmalısınız.
    Bios acpi'nizin bozuk bir tablosu olabilir, görevdeki Çinlilerin her tablonun sağlama toplamını iyi hesaplamaması normaldir, bu mesajlar genellikle önyüklemenin başında $ dmesg -human ile görünür.
    Ayrıca başka bir güç kaynağını denemelisiniz, filtreleme başarısız olduğunda dalgalanma tam da bu tür bir başarısızlık yapma eğilimindedir.
    Öncelikle, kaynağı değiştirmeyi deneyin ve ne olacağını görün, eğer aynı kalırsa, donanımınıza uygun bir çekirdek yapılandırmayı deneyin, bu süreçte bilgisayarınızı daha iyi tanıyacaksınız.

    1.    c4 patlayıcı dijo

      İpuçları için teşekkürler. Bu arada bir dizüstü bilgisayar, pili değiştirmem gerektiğini düşünüyorum. Ama bana anlattıklarının bana yardımcı olabileceğini görüyorum.

  7.   Yukiteru dijo

    Beni hala çılgına çeviren tek çekirdek paniği kısmen yeni adamların ve benim eski, modası geçmiş ve çok tozlu nVidia 6150 SE entegre kartımın hatasıdır (kısmen bunun nedeni; nVidia'da olanlar ve tüm bunlar, yalnızca tersine mühendislik kullanarak, artı sorun yalnızca NV4E yonga setli bazı kartlarda ortaya çıkıyor).

    Tek yapmanız gereken Openbox + Firefox'u ve felaket grevlerini başlatmaktır (ekranınızda tamamen rastgele siyah beyaz bir mozaik görmekten daha güzel bir şey yoktur). Ve bunu Debian, Fedora, Archlinux, Slackware'de 3.6 numaralı kernel'den beri söylüyorum ve şimdi Gentoo'da tekrar doğrulamıştım (sadece 3.12 kernel ile yüklendi), artık bir günlük almak, çekirdeğe almak veya ona bir şeyler yazmak için zaman vermekle uğraşmıyorum çok saçma bir karakter olmayın.

    1.    anonim dijo

      Size çözümü veriyorum, gentoo ile sahip olduğum bir bilgisayar ve entegre nvidia videosu nouveau sürücüsüyle aynı, bu yüzden kapalı nvidia sürücüsünü kullanmaktan başka seçeneğim yoktu, çipim 304.123 sürücüsünü kullanmalı

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

      Bir çekirdek dosyasını derlemeden önce yamalamanız gerekir, eğer yama uygulanmazsa grafik modu başlamayı reddeder.

      Adımlar:
      # nano -w /usr/src/linux-3.15.7-gentoo/drivers/acpi/osl.c
      Bu metni nano içinde ctrl + w ile arayın, acpi_os_wait_events_complete ve nano sizi bu kısma götürür:

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

      Eklemeniz gereken yama, EXPORT, ctrl + veya ctrl + x ile başlayan bu son satırdır.
      Daha sonra çekirdeği derlersiniz, modülleri kurarsınız, çekirdeği kurarsınız, ihtiyacınız varsa initramf'leri oluşturursunuz, splash kullanırsanız initramf'lara splash eklersiniz, grub için girdileri yeniden üretirsiniz ve son olarak ve çok önemlisi, çekirdek veya tescilli nvidia modülü, bunu yapmadan grafik modu çalışmayacaktır.

      # eselect çekirdek listesi
      # eselect çekirdek kümesi x
      # cd / usr / src / linux
      # Yapmak
      # make module_install
      # mount / boot
      # kurulum yap
      # dracut –hostonly »3.15.7-gentoo –force
      # 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 şimdi

      Eğer genkernel kullanıyorsanız, o dosyaya yama yaparsınız ve genkernel'in kendi kendini düzelttiğini anlıyorum.
      Ek olarak, drm desteğini ve nvidia sürücülerini ve diğer video yongalarını, nvidia modülü olarak yüklenmiş kapalı nvidia sürücüsüyle kafa kafaya çarpışmamaları için çekirdekten kaldırmanız gerekir.
      Bootsplash kullanılması durumunda, kapalı nvidia sürücüsü (doğru hatırlıyorsam) önyüklemenin tty800 «F600» terminalinde 1 × 1'den fazlasını desteklemediğinden, yüksek ekran çözünürlüklerini desteklemesi için çekirdeğe uvesa sürücüsünü dahil etmelisiniz.
      Diğer dağıtımları bilmiyorum, ancak bu adımlar atılırsa herhangi bir dağıtımda çalışmalı ve emerge değişikliğini her ne olursa olsun kurtarmalı.

      Nvidia ve uvesa için uymanız gereken yönergeler şunlardır:
      http://wiki.gentoo.org/wiki/NVidia/nvidia-drivers/es
      http://wiki.gentoo.org/wiki/Uvesafb

      1.    Yukiteru dijo

        Bilgi için teşekkürler, ancak sorunu tam olarak özel olanlara geçerek çözdüm. Önceki nVidia sürücüsünün (304.121) de 3.13'e giderken yamalanması gerektiğini hatırlıyorum çünkü modülün derlenmesinde bir sorun vardı (hata yoktu, ancak modül çalışmayı reddetti) ve her şey de ACPI olay işleyicisi nedeniyle . Debian'da sorunu aldım ve çözümü de buldum.

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

    2.    Dayara dijo

      Manjaro'yu örnek olarak kullandım, ancak daha önce aynı şeyin Arch ve diğer türevlerde de başıma geldiğinden bahsetmiştim. Bu nedenle sorunun, etkilenenlerden daha çok kendilerine ait olduğuna inanıyorum.

      Pd: İlgili mesaja doğrudan yanıt veremedim çünkü yanıtlama seçeneği görünmüyor ...

  8.   Dayara dijo

    Tam olarak Manjaro'dan Linux Mint'e gittim çünkü 0.8.9'dan sonra bir sürüme güncelledikten sonra önyükleme yaparken donuyordu (hangisini hatırlayamıyorum). Okuduğuma göre, bu genellikle dizüstü bilgisayarlarda oluyor. Söz konusu problemim bu yazıdaki ile aynı değildi, sanırım bunun enerji yönetimi ile ilgili olabileceği sonucuna vardım. Bilgisayarı fişi çekmeden çalıştırdıklarında donmayan insanlar vardı. Şu anda bunun her zaman sorunsuz bir şekilde başlamama izin verip vermediğini hatırlamıyorum, ama tabii ki daha uzun zaman harcama pahasına bunu daha çok kez yapabildim.
    Her neyse, sonunda pes ettim ve Fedora ve Linux Mint'e geçtim.

    1.    c4 patlayıcı dijo

      Tesadüfen, dün şarj cihazı olmadan askıya almaya çalıştım ve devam ettirirken takıldı ve yeniden başlatmak zorunda kaldım.

  9.   Amaury dijo

    Oldukça komik, birkaç aydır Arch ile birlikteyim ve tek bir Kernel Panic yaşamadım! Canlı ortamdan Antergos (eklenmiş depolu Arch) ile başıma geldi, ama orada daha anlaşılır buluyorum. Ana kartta veya hatalı bir RAM modülünde sorun olabilir mi? Yaklaşık 2 yıl önce bir RAM modülünün Windows'ta birkaç mavi ekrana ve ayrıca birkaç Kernel Panics'e neden olduğunu hatırlıyorum! Mandriva üzerinde. Yeniden başlatma ve yeniden başlatma arasında her bir belleği test etmem gerekiyordu.

    1.    Dayara dijo

      Bu bir Arch problemidir (tüm türevlerini sürükler), çünkü diğer dağıtımlarda bu türden problemler yoktur. Benim utanç verici bulduğum şey, şu anda çözememiş olmaları. Yıllardır sadece onlar! 2011'den beri benzer sorunları okudum. Güncelledikçe gelip giden bir şey olduğu konusunda netim, çünkü 0.8.7, 0.8.8 ve 0.8.9 sürümlerini güncellemeden kullandığınızda hiçbir şey olmuyor. O andan itibaren her şey boka batacak ve kesinlikle eski versiyonlarda da oldu. Neden sadece birkaçımıza oluyor? Bilmiyorum, ama bunun bizim sorunumuz olduğunu sanmıyorum, ama Arch'ın çünkü daha önce de belirtildiği gibi diğer dağıtımlar mükemmel çalışıyor. Bir çözüm bulmak için zamanında boynuzlarımı kırdım ama yoruldum. Bu yüzden üzgün olsam da Arch'ı kullanmayacağım.

      1.    Yukiteru dijo

        Arch 0.8.7, 0.8.8 ve 0.8.9? Arch'ın bu versiyon terminolojisini kullandığını öğrendim.

        Manjaro kullanıyor musunuz?

      2.    Yukiteru dijo

        Tamam, önceki yorumunuzu okuyarak kendime cevap veriyorum ve bir şey Manjaro ve diğeri Arch.

        Belirli bir sorun için bir dağıtımın suçlanması da tutarlı değildir (gerçekten tutarlı değildir), en azından benim durumumda nouveau ve nVidia 6150SE kartımla ilgili sorun için kaç dağıtımı denediğimi suçlayamam çünkü sorun şu ki Sürücünün ve kartın MMIO işlemesi (nVidia neyi düzelteceğini bilecek ve bu ayrıntıyı düzeltmek için çılgınca şeyler yapacak). Donanım da sorun olabilir ve hangi işletim sistemini kullanırsanız kullanın (Windows, Linux, BSD) ve bilgisayarları tamir etme deneyimime göre çok tuhaf donanım sorunları (örneğin, bellek konumunu değiştirmediğiniz sürece önyükleme yapın ve kapatırken işlemi tekrarlamanız gerekir) ve bunun için Windows ve Debian'ı suçlayamam.

  10.   raalso7 dijo

    Canlı bir ubuntu 12.04 ile çekirdek paniği yaşadım

  11.   Ulises Bernal Perez dijo

    Secure HP pavilion dm4 Dizüstü Bilgisayarım, 8 GB RAM, 500 sabit diskim, 5 yıldan fazla kullanımım var. Mikroişlemcinin hızını hatırlamıyorum, bir Intel core i5, 2 mhz'den fazla olduğunu düşünüyorum.
    Terminal ekranına hiçbir şey yazamıyorum. Bu sorunu çözmek için daha fazla bilgi aramaya devam edeceğim.