Можливе рішення випадкових "ядерних панікерів" при завантаженні Arch Linux

Цей пост повинен показати, як "виправити" майже проблему стартапів за допомогою помилок Arch Linux. Щось на зразок такого зображення:

IMG_20140707_210559

Як бачимо, ми бачимо, що це одна з багатьох "комбінацій" помилок, які випадково з'являються при запуску операційної системи з цією проблемою. Як сказано в цій помилці, це вказує на те, що в "Обладнанні" може бути проблема, однак, як ми всі знаємо в цій операційній системі, можна вирішити навіть погані трюки того, що не належить ОС.

Отже, я опишу свій досвід цієї проблеми. З того, що я зміг пережити, проблема полягала лише в Arch Linux або інший дистрибутив, який я тестував зовні, оскільки з будь-яким встановленим або протестованим ubuntu він запускався без проблем. Але якби я спробував розірвати Arch Linux встановлений на жорсткому диску, у мене виникла проблема, через яку мені довелося перезавантажуватись приблизно 50 разів, щоб ОС нормально завантажилася та використовувала її.

Це вже зі мною щось не так, тому що я міг використовувати лише встановлене мені ubuntu, щоб перевірити його, і я не міг зробити навіть половини речей, з якими міг би зробити Arch Linux. Тому я вирішив вирішити цю проблему і почав досліджувати, шукаючи теми форуму, у яких була та сама проблема, вони також згадали, що це була апаратна помилка і що це був саме ЦП, тому це мене почало турбувати, тому я потрапив до відкрийте ПК і перевірте, що відбувається, проте це не допомогло.

Але щось, що показало мені, від чого я не повинен здаватися, було те, що якщо Ubuntu Я міг, бо Arch Linux ні (можливо Ubuntu краще ніж арка…?). Тому я почав писати параметри завантаження в ядро Arch Linux, такі речі як: 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, i8042.noacpi = 1, apm = copypi, acdt = copyd apm = копії, acdtpi = 0, apm = копії pci = nocrs, rhgb, acpi = сила, pnpacpi = XNUMXff та інші ... Усе це було рекомендовано на форумах, які я читав.

Поки мені не довелося переходити до документації параметрів ядра, що я рекомендую до речі: https://www.kernel.org/doc/Documentation/kernel-parameters.txt

І я знайшов досить цікавий параметр, який на даний момент мені вдалося завантажити Arch Linux Без проблем:

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

Як там зазначено, цим параметром обмежується використання процесора без активації симетричного режиму обробки. Спочатку це працювало досить добре, доки я не використовував команду пакман -Сйю; кинув мені а ядро скинуто o помилка сегментації.

Тому я автоматично помітив, що відбувається щось дивне, тому я почав запускати інші процеси, поки раптом система повністю не замерзла і більше не працювала, поки я не перезавантажив її. Тож я зробив ту саму операцію, але цього разу мені вдалося виконати htop і це показало мені наступне:

IMG-20140729-WA0001

Як і слід було очікувати, він показав лише один процесор, оскільки інший його відключив, однак мені здалося дуже дивним, чому програми кидали сегментарно, і навіть не міг запустити графічне середовище; отже, це було щось, що принаймні дало мені більше надії, що якщо я встановлю параметри ядра в один бік, він завантажить Arch Linux як завжди.

Тому я продовжував пробувати інші параметри, які я писав у списку, поки не натрапив на цей, що є найкращим рішенням на даний момент:

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

Цей параметр робить щось настільки просте, як виділення (не деактивація) другого ядра процесора в симетричній обробці, тобто навантаження на обробку передається одному ядру, тоді як інше є лише доповненням. Це, хоч і здається суперечливим, не так сильно впливає на продуктивність, оскільки ця чудова ОС могла запускати програми таким чином:

тест

linux_rlz_compiz

Отже, з цим, єдина проблема, яку я спостерігав і виникає під час завантаження, - це одна або дві паніки ядра або ой-ой; але порівняно з 50-ма рази, які мені доводилося перезавантажувати раніше, я можу вважати це "обхідним шляхом". В іншому, поки що це дозволило мені користуватися ОС і написати цю публікацію, яку ви зараз читаєте :-).

Сподіваюся, вони допоможуть вам і не вибраться GNU / Linux, яка є найкращою операційною системою, яку вони коли-небудь винайшли. Я це кажу точно.