Linux general protection fault

Arch Linux

You are not logged in.

#1 2020-02-15 19:51:36

General Protection Fault

First off, thank you for taking the time to look at my question.

I’ve been running Arch on a mid-2015 Macbook Pro for about 2 years. It has run surprisingly well for me and I’ve had very few issues until recently.

Here is my environment:
* Arch Linux (5.5.3-arch1-1) on mid-2015 Macbook Pro
* i3-gaps
* xorg

This is what I’ve been seeing:
* I go about my daily work, running programs like firefox, chromium, vim, tmux, polybar, ssh
* After a variable amount of time (it’s happened after anywhere from 30 minutes to 2 days) X freezes up and I get no response from keyboard or mouse
* I’ve tried switching to another TTY (ctrl+alt+F ) with no response
* I have metrics showing in polybar, and CPU, memory, and temperature all look okay
* I was once on a video call using zoom when this happened and I still got audio (via a headset that was plugged in using a USB hub)
* I have tried shelling into the box over SSH twice and once it worked and the other time it did not
* While shelled in, I’ve tried killing off suspected processes one by one with no success (firefox, chromium, zoom, etc.), and also double-checked CPU, memory, temp, inodes, etc. with nothing suspicious jumping out

Eventually, these processes become unresponsive, as in the audio stopped for the call I was in and my ssh shell session no longer responded (and a new session could not be opened)
After a reboot, I looked at the journald error logs and in each case I have seen a «general protection fault» right before the issues start. I’ve added a log snippet below. Any idea what could be causing this? One final thing- I’ve recently started using alacritty as my go-to terminal (with many instances open at a time, usually), but I’d be surprised if this turned out to be the issue. If there is anything else that I can provide for better context please let me know.

«`
Feb 15 08:12:32 thethecounter kernel: general protection fault: 0000 [#2] PREEMPT SMP PTI
Feb 15 08:12:32 thethecounter kernel: CPU: 0 PID: 542405 Comm: chromium Tainted: G D 5.5.2-arch1-1 #1
Feb 15 08:12:32 thethecounter kernel: Hardware name: Apple Inc. MacBookPro11,4/Mac-06F11FD93F0323C5, BIOS MBP114.88Z.0184.B00.1806051659 06/05/2018
Feb 15 08:12:32 thethecounter kernel: RIP: 0010:kmem_cache_alloc+0x7d/0x210
Feb 15 08:12:32 thethecounter kernel: Code: 6f 48 8b 70 08 48 39 f2 75 e7 4c 8b 28 4d 85 ed 0f 84 75 01 00 00 41 8b 5e 20 49 8b 3e 48 8d 8a 00 02 00 00 4c 89 e8 4c 01 eb 33 1b 49 33 9e 70 01 00 00 65 48 0f c7 0f 0f 94 c0 84 c0 74 ae
Feb 15 08:12:32 thethecounter kernel: RSP: 0018:ffff95a0073abd40 EFLAGS: 00010286
Feb 15 08:12:32 thethecounter kernel: RAX: cd712bb18f074514 RBX: cd712bb18f074514 RCX: 0000000094fa3000
Feb 15 08:12:32 thethecounter kernel: RDX: 0000000094fa2e00 RSI: 0000000094fa2e00 RDI: 0000000000033490
Feb 15 08:12:32 thethecounter kernel: RBP: 0000000000000cc0 R08: 00007f7cfbc83700 R09: ffff95a0073cbf58
Feb 15 08:12:32 thethecounter kernel: R10: 00007f7cfbc82a30 R11: 00000000003d0f00 R12: ffffffff906b48af
Feb 15 08:12:32 thethecounter kernel: R13: cd712bb18f074514 R14: ffff8c486d423800 R15: ffff8c486d423800
Feb 15 08:12:32 thethecounter kernel: FS: 00007f7cfce43cc0(0000) GS:ffff8c486f200000(0000) knlGS:0000000000000000
Feb 15 08:12:32 thethecounter kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Feb 15 08:12:32 thethecounter kernel: CR2: 00007f7cfbc82a38 CR3: 000000026fa92001 CR4: 00000000001606f0
Feb 15 08:12:32 thethecounter kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Feb 15 08:12:32 thethecounter kernel: DR3: 0000000000000080 DR6: 00000000ffff0ff0 DR7: 0000000020000400
Feb 15 08:12:32 thethecounter kernel: Call Trace:
Feb 15 08:12:32 thethecounter kernel: alloc_pid+0x4f/0x3c0
Feb 15 08:12:32 thethecounter kernel: ? preempt_count_add+0x49/0xa0
Feb 15 08:12:32 thethecounter kernel: copy_process+0xf27/0x1b80
Feb 15 08:12:32 thethecounter kernel: _do_fork+0x94/0x3f0
Feb 15 08:12:32 thethecounter kernel: __x64_sys_clone+0x81/0xa0
Feb 15 08:12:32 thethecounter kernel: do_syscall_64+0x4e/0x150
Feb 15 08:12:32 thethecounter kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9
Feb 15 08:12:32 thethecounter kernel: RIP: 0033:0x7f7d02e3e3c5
Feb 15 08:12:32 thethecounter kernel: Code: 48 85 ff 74 3d 48 85 f6 74 38 48 83 ee 10 48 89 4e 08 48 89 3e 48 89 d7 4c 89 c2 4d 89 c8 4c 8b 54 24 08 b8 38 00 00 00 0f 05 85 c0 7c 13 74 01 c3 31 ed 58 5f ff d0 48 89 c7 b8 3c 00 00 00
Feb 15 08:12:32 thethecounter kernel: RSP: 002b:00007ffdd7adb938 EFLAGS: 00000206 ORIG_RAX: 0000000000000038
Feb 15 08:12:32 thethecounter kernel: RAX: ffffffffffffffda RBX: 00007f7cfbc83700 RCX: 00007f7d02e3e3c5
Feb 15 08:12:32 thethecounter kernel: RDX: 00007f7cfbc839d0 RSI: 00007f7cfbc82a30 RDI: 00000000003d0f00
Feb 15 08:12:32 thethecounter kernel: RBP: 00007ffdd7adbc28 R08: 00007f7cfbc83700 R09: 00007f7cfbc83700
Feb 15 08:12:32 thethecounter kernel: R10: 00007f7cfbc839d0 R11: 0000000000000206 R12: 00007ffdd7adb9ee
Feb 15 08:12:32 thethecounter kernel: R13: 00007ffdd7adb9ef R14: 00007f7cfbc82a40 R15: 00007f7cfbc83700
Feb 15 08:12:32 thethecounter kernel: Modules linked in: snd_hda_codec_hdmi ofpart cmdlinepart intel_rapl_msr intel_rapl_common intel_spi_platform intel_spi spi_nor i915 brcmfmac mei_hdcp mtd iTCO_wdt iTCO_vendor_support btusb snd_hda_codec_cirrus nls_iso8859_1 snd_hda_codec_generic btrtl nls_cp437 brcmutil vfat snd_usb_audio fat ledtrig_audio x86_pkg_temp_thermal btbcm btintel intel_powerclamp snd_hda_intel uvcvideo coretemp snd_usbmidi_lib snd_intel_dspcfg kvm_intel bluetooth snd_hda_codec i2c_algo_bit snd_rawmidi videobuf2_vmalloc cfg80211 drm_kms_helper applesmc snd_hda_core videobuf2_memops kvm drm snd_seq_device snd_hwdep videobuf2_v4l2 mmc_core snd_pcm ecdh_generic irqbypass intel_cstate videobuf2_common mei_me tg3 intel_uncore mei intel_gtt videodev pcspkr rfkill lpc_ich i2c_i801 intel_rapl_perf bdc_pci intel_pch_thermal snd_timer ecc agpgart input_leds syscopyarea joydev mousedev bcm5974 mc snd acpi_als sysfillrect thunderbolt libphy sbs sysimgblt kfifo_buf soundcore fb_sys_fops sbshc industrialio
Feb 15 08:12:32 thethecounter kernel: apple_gmux evdev apple_bl ac mac_hid sg crypto_user ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 hid_apple uas usb_storage hid_generic usbhid hid dm_crypt dm_mod sd_mod crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel ahci libahci aesni_intel libata xhci_pci crypto_simd cryptd xhci_hcd glue_helper scsi_mod
Feb 15 08:12:32 thethecounter kernel: —[ end trace e639b560608972c3 ]—
Feb 15 08:12:32 thethecounter kernel: RIP: 0010:kmem_cache_alloc+0x7d/0x210
Feb 15 08:12:32 thethecounter kernel: Code: 6f 48 8b 70 08 48 39 f2 75 e7 4c 8b 28 4d 85 ed 0f 84 75 01 00 00 41 8b 5e 20 49 8b 3e 48 8d 8a 00 02 00 00 4c 89 e8 4c 01 eb 33 1b 49 33 9e 70 01 00 00 65 48 0f c7 0f 0f 94 c0 84 c0 74 ae
Feb 15 08:12:32 thethecounter kernel: RSP: 0018:ffff95a00308ba30 EFLAGS: 00010286
Feb 15 08:12:32 thethecounter kernel: RAX: cd712bb18f074514 RBX: cd712bb18f074514 RCX: 0000000094fa3000
Feb 15 08:12:32 thethecounter kernel: RDX: 0000000094fa2e00 RSI: 0000000094fa2e00 RDI: 0000000000033490
Feb 15 08:12:32 thethecounter kernel: RBP: 0000000000000cc0 R08: 0000000000000000 R09: ffff8c484a7fd700
Feb 15 08:12:32 thethecounter kernel: R10: 0000000000000000 R11: 0000000000000002 R12: ffffffffc0e208e5
Feb 15 08:12:32 thethecounter kernel: R13: cd712bb18f074514 R14: ffff8c486d423800 R15: ffff8c486d423800
Feb 15 08:12:32 thethecounter kernel: FS: 00007f7cfce43cc0(0000) GS:ffff8c486f200000(0000) knlGS:0000000000000000
Feb 15 08:12:32 thethecounter kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Feb 15 08:12:32 thethecounter kernel: CR2: 00007f7cfbc82a38 CR3: 000000026fa92001 CR4: 00000000001606f0
Feb 15 08:12:32 thethecounter kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Feb 15 08:12:32 thethecounter kernel: DR3: 0000000000000080 DR6: 00000000ffff0ff0 DR7: 0000000020000400
«`

Last edited by trevordf (2020-02-15 23:35:23)

Источник

GENERAL PROTECTION FAULT

при загрузке получаю исключение — GENERAL PROTECTION FAULT

вопрос: в чем может быть причина, где рыть? может какие-то проблемы с GDT ?

Re: GENERAL PROTECTION FAULT

Не, ну кто ось пишет?
Это скорее всего 13-е исключение, если ты о x86, а оно может возникать по многим причинам. Читай доки по процессору.

Напиши обработчики всех исключений, а в них выводи всю инфу, какую только можно, регистры, стек, етк.

Больше подсказать не могу.

P.S. Мне самому интересно, как отлаживают оси на самом начальном этапе разработки.

Re: Re: GENERAL PROTECTION FAULT

ага. именно 13ое

но к счастью с этим уже разобрался (оказалось не совсем коректно настроил сегмент кода)

теперь другая проблема — 6ое exception —

invalid operation code

Re: GENERAL PROTECTION FAULT

Значит у тебя программа прыгает куда-то не туда, ну или ты действительно использовал какую-то неподдерживаемую инструкцию.

Re: GENERAL PROTECTION FAULT

Хоть мне и не нравится, когда изобретают велосипед, колеса у которого могут быть квадратнее :)) чем у существующего, хочу сказать, молодец чувак. Очч-ч-чень интересная задача. Для самообразования. А может и не только. Ведь надо ж когда-то кому-то начинать :))

Re: GENERAL PROTECTION FAULT

Вспомнил свой курсовой, когда надо было переключиться в защищенный режим, и запустить несколько задач, которые можно было бы принудительно переключать между собой.

Из док были доки по 386 и 486м процам, ух и навозился, зато получилась конфетка вся из себя 32-х разрядная, все таблицы, код, данные задвигались выше мегабайта, у каждой задачи была своя LDT, ринги поддерживались все, какие хочешь, крэш подзадачи не вешал всю систему, етк. Аж самому понравилось, правда с отладкой гимора было выше крыши 🙂

Re: GENERAL PROTECTION FAULT

ОС написать легко (сам написал парочку когда-то 😉 — трудно заставить кого-то ей пользоваться, не перетащив в нее весь шит к которому так все привыкли. А перетащив — получишь тот же самый «линсди» или «винаос», в лучшем случае «кнюкс». Ну и зачем оно надо?!

Если пишешь на С/C++, то ВООБЩЕ не трать зря время. До тебя огромное количество людей занималось этим 30 лет, все что можно сделать давно попробовано и сделано. И что нельзя сделать тоже, см. osnews. Ничего хорошего не получилось и не получится, это можно считать доказанным практикой окончательно и бесповоротно.

Ищи/создавай другой инструмент.

всем сенькс — баг пофиксен

всем сенькс — баг пофиксен

аж на душе легче.

итого на добавление возможности реагировать на события от харда мне понадобилась РОВНО неделя.

теперь осталось самое интересное — процессы, swap etc

Источник

General protection fault on Linux #10631

Comments

markvincze commented Jul 4, 2018

I’m running a pretty standard ASP.NET Core application in Kubernetes on the Google Cloud.
I’m using self-contained deployment with the linux-x64 runtime identifier, the target framework is 2.1 , and I’m using the microsoft/dotnet:2.1-runtime-deps base image.
The host distro is the Container-Optimized OS by Google.

I have 100 instances running on 100 separate host nodes. The cluster is heavily loaded with traffic due to executing some load tests, so the application is using 100% of the host CPU most of the time.

What I see is that out of my 100 instances, a handful of them were restarted a couple of times, which means that their Docker container on the host node crashed. With docker ls -a I can see that the exit code was 137 .

But if I check the logs of the container, I don’t see any errors or exceptions printed by the framework, the last output message is a normal log message of my application.

The only error message I could find was by running dmesg , the last event reported is a general protection fault in libcoreclr.so .

If I check the resource usage of the currently running container, it reports 99% CPU-usage.

Which is expected under our current stress test, but this should not cause the process to crash, right?

How could I investigate what is causing this issue?

The text was updated successfully, but these errors were encountered:

Источник

Зависает linux (general protection fault)

Кусок лога: https://pastebin.com/WrkGPc7j i7-8700K, nvidia 1030, 32GiB DDR4/1TB SSD/2*2TB HDD

у тебя там nouveau, попробуй без него

а так похоже например на переразогнанную память

Можно как-то отключить nouveau, не удаляя его? Планки самсунговские, c-die, разве 3200 16-18-18-38-2N при 1.33V много для них?

А мамка какая? xhci, насколько я понимаю, это USB. И да, попробуй ядро посвежее.

Asrock z370 extreme 4. Ядро как раз поставил, после того ребута 5.8 стало (но зависание с установкой не связано, и до этого такое бывало). И заодно попробовал напряжение чуть поднять, как раз на 0.03 на памяти и до 1.005 на контроллере памяти (или что там это было).

Как решали люди такую же проблему. Но у них не линукс, а виндоуз. Похоже, это железячные проблемы, да:

Кстати, у меня были такие же проблемы. Правда, мать под AMD проц. Думал, это с AMD связано только. Ан нет.

Убери разгон всего, верни и частоты и напряжение на сток и проверяй.

Как ни странно, помогло. Кроме того, смена nouveau на проприетарные драйвера от nvidia тоже помогла.

Источник

General protection fault при вызове emerge

После обновления GCC до версии 10.1 и пересборки им питона (тоже обновление прилетело) я стал периодически ловить GPF при вызове emerge.

Да, процессор с памятью я разгонял, но не думаю что дело конкретно в этом — memtest86 после шестичасового прогона никаких ошибок не выдал, а стабильность разгона ЦП я давно проверил во всяких линпаках. К тому же, раньше-то такого не возникало.

Подскажите, в какую сторону копать, чтобы обнаружить причину этого бага.

memtest86 после шестичасового прогона никаких ошибок

это ни о чём не говорит, мемтест — говно

это ни о чём не говорит, мемтест — говно

С древним memtest86+ не путаешь? Есть еще проприентарный (freeware) в виде EFI приложения.

очевидно не путаю, ведь у тебя софт падает

Оно, кстати, не всегда падает. Просто трейс выкидывает в консоль. И до пересборки свежим GCC такого не было.

Может быть gcc неподдерживаемые инструкции генерит — aes, avx. Какой проц, «-march» какой?

а ты думал всё будет просто

И до пересборки свежим GCC такого не было

тогда бы была другая ошибка. кроме того у него хрюзен

Обращение к невыровненным данным в avx.

Ryzen 7 2700, -march=znver1.

Несколько месяцев подряд такое совпадение было?

Повод сделать полную переборку! emerge -e world

И снова нечаянно скастовали world 🙂

… приведёт к падению на любом имеющемся проце. что ты хотел этим сказать?

Сбросил настройки в UEFI, ничего не изменилось.

значит теперь пробуй бинарный дистрибутив

Что gpf можно вызвать неправильной иструкцией.

Хотя тут, скорее, проблема в смене (версии) тулчейна.

это уже не «неподдеживаемая инструкция», а баг компилятора

Или проца, или обоих, или еще микрокода, зашитого в биос или загружаемого.

gcc-10.1 в тестовой «

а в арче он уже месяц. если бы был такой баг, давно бы вонь подняли

максимум локальная поломка в генте

Сделай полное обновление тулчейна, строго в такой же последовательности

Потом можешь еще сделать констрольный выстрел emerge @system

В арче пакеты собраны с -march=znver1 ?

юзеры сами компиляют код, у многих из них zen

юзеры сами компиляют код, у многих из них zen

Прям все пакеты компиляют: и системные, и несистемные? Или только то, что только один раз в жизни запускают?

а зачем все, если у ТС валятся уже gcc/педон/binutis /glibc

И что из этого арчебальды компиляют с -march=znver1?

всё, ведь это одни из самых распространённых пакетов. кроме того свежий gcc есть не только в арче

Показывай свои самодельные пакеты для сборки этих пакетов с -march=znver1.

какие ещё самодельные пакеты, если они есть в репах, а CFLAGS настраиваются в /etc/makepkg.conf?

И арчибальды компиляют то, что есть в виде готовых бинарей?

иногда нужно наложить патчи, например сейчас в binutils поломана сборка wine

Ты уж определись: «все, всё и всегда» или «иногда, когда нужно один раз в жизни»

ты предполагаешь, что исключительно gcc/python/binutils/glibc сломаны, когда весь остальной софт работает? маловероятно

Ах да. Покажи /etc/makepkg.conf . Посмотрим все вместе какого размера у тебя march

значит теперь пробуй бинарный дистрибутив

Загрузил убунту с флешки, позапускал разные питоновские скрипты. Все ок.

а ты полную нагрузку на проц дай

Так уже. Вчера скачал интеловский линпак, погонял минут десять — все ок. Видимо, с оптимизацией под Zen в новом GCC что-то накосячили.

Пересобрал с -march=native, теперь все ок.

Сравниваю ключи для -march=native и вычисленного -march следющим скриптом

Источник