Błąd Ubuntu 18.04 po przebudzeniu ze snu: Błąd odczytu na urządzeniu wymiany


11

Gdy laptop jest w trybie uśpienia przez kilka godzin, kiedy próbuję wznowić sesję, pojawia się następujący błąd:

Błąd odczytu na urządzeniu wymiany

Ładowanie ekranu logowania trwa około 30 sekund. Po zalogowaniu ekran znika raz lub dwa razy na sekundę i żaden z moich programów nie jest już otwarty. Pojawia się komunikat „Wykryto problem z systemem”. Kiedy klikam „Wyślij raport”, pojawia się kolejne powiadomienie z informacją:

Niestety program „Xorg” został nieoczekiwanie zamknięty. Twój komputer nie ma wystarczającej ilości wolnej pamięci, aby automatycznie przeanalizować problem i wysłać raport do programistów.

Do tej pory próbowałem zwiększyć dostępną przestrzeń wymiany. Początkowo było to około 2 GB, a ja utworzyłem kolejny plik wymiany o wielkości 9 GB. To nie pomogło. Zajęte miejsce wymiany (zgodnie z poleceniem swapon) po awarii zawsze wynosi około 170 MB.

Wskaźnik DMESG dla wznowienia sesji aż do błędu odczytu na urządzeniu wymiany jest następujący:

    
[64046.474054] ACPI: Wznowienie niskiego poziomu zostało ukończone
[64046.474162] ACPI: EC: EC rozpoczęty
[64046.474162] PM: Przywracanie pamięci NVS platformy
[64046.475139] Włączanie procesorów innych niż rozruchowe ...
[64046.475196] x86: Ładowanie konfiguracji SMP:
[64046.475196] smpboot: Uruchamianie węzła 0 Procesor 1 APIC 0x2
[64046.475663] pamięć podręczna: nadrzędna jednostka centralna nie powinna spać
[64046.475859] CPU1 działa
[64046.475910] smpboot: Uruchamianie węzła 0 Procesor 2 APIC 0x4
[64046.476330] pamięć podręczna: nadrzędna jednostka centralna nie powinna spać
[64046.476506] CPU2 działa
[64046.476539] smpboot: Uruchamianie węzła 0 Procesor 3 APIC 0x6
[64046.477071] cache: nadrzędna jednostka centralna nie powinna spać
[64046.477255] CPU3 działa
[64046.477274] smpboot: Uruchamianie węzła 0 Procesor 4 APIC 0x1
[64046.477721] cache: nadrzędna jednostka centralna nie powinna spać
[64046.477922] CPU4 działa
[64046.477947] smpboot: Uruchamianie węzła 0 Procesor 5 APIC 0x3
[64046.478371] cache: nadrzędna jednostka centralna nie powinna spać
[64046.478571] CPU5 działa
[64046.478591] smpboot: Uruchamianie węzła 0 Procesor 6 APIC 0x5
[64046.479018] cache: nadrzędna jednostka centralna nie powinna spać
[64046.479229] CPU6 działa
[64046.479247] smpboot: Uruchamianie węzła 0 Procesor 7 APIC 0x7
[64046.479675] cache: nadrzędna jednostka centralna nie powinna spać
[64046.479899] CPU7 działa
[64046.485913] ACPI: Budzenie ze stanu uśpienia systemu S3
[64046.639206] ACPI: EC: zdarzenie odblokowane
[64046.639711] sd 2: 0: 0: 0: [sda] Dysk startowy
[64046.873289] USB 1-11: zresetuj urządzenie USB o pełnej prędkości numer 2 za pomocą xhci_hcd
[64046.976869] ata4: łącze SATA w dół (SStatus 4 SControl 300)
[64046.976892] ata2: łącze SATA w dół (SStatus 4 SControl 300)
[64047.149289] USB 1-6: zresetuj szybkie urządzenie USB numer 40 za pomocą xhci_hcd
[64047.437370] psmouse serio1: synaptics: kwerendy maks. Współrzędne: x [..5660], y [..4570]
[64047.476302] psmouse serio1: synaptics: sprawdzone współrzędne min: x [1364 ..], y [1284 ..]
[64047.922603] OOM Killer włączony.
[64047.922605] Ponowne uruchamianie zadań ... gotowe.
[64047.928727] thermal thermal_zone1: nie można odczytać strefy termicznej (-61)
[64047.930036] Bluetooth: hci0: Wersja bootloadera 0.0 kompilacja 2 tygodnie 52 2014
[64047.935036] Bluetooth: hci0: Wersja urządzenia to 5
[64047.935037] Bluetooth: hci0: Bezpieczny rozruch jest włączony
[64047.935038] Bluetooth: hci0: blokada OTP jest włączona
[64047.935038] Bluetooth: hci0: blokada API jest włączona
[64047.935039] Bluetooth: hci0: Blokada debugowania jest wyłączona
[64047.935040] Bluetooth: hci0: Minimalna wersja oprogramowania układowego 1 tydzień 10 2014
[64047.935042] Bluetooth: hci0: Znaleziono oprogramowanie układowe urządzenia: intel / ibt-11-5.sfi
[64047.944372] PM: zawiesić wyjście
[64048.050329] Błąd odczytu na urządzeniu wymiany (8: 0: 1543400288)
[64048.460888] [drm] RC6 włączony

Daj mi znać, jeśli będą potrzebne inne informacje.


Mam bardzo podobny problem - po uaktualnieniu do wersji 18.04 zamknięcie pokrywy laptopa powoduje pojawienie się tego samego komunikatu o błędzie (błąd odczytu na urządzeniu wymiany) i ponowne uruchomienie. Jeśli uda Ci się znaleźć poprawkę w innym miejscu, byłoby wspaniale, gdybyś mógł ją tutaj udostępnić.
Adrian

1
Mając dokładnie ten sam problem. Przeprowadziłem badania i użytkownicy arch. Linuksa mieli ten sam problem kilka miesięcy temu i
doszedłem do

Odpowiedzi:


10

W jądrze Ubuntu 18.04, którego obecnie używasz, brakuje dość ważnej poprawki błędu.

Poprawka tego jest już obecna w wyższym jądrze Linuksa w wersji 4.16.8. (Błąd zawieszenia zaczął się skutecznie pojawiać w wersji jądra 4.15). Ubuntu musi tylko wybrać tę małą łatkę z góry. Błąd często powoduje awarie Xorg natychmiast po zawieszeniu, tzn. Powoduje awarię całej sesji logowania graficznego.

Uwaga: ten błąd często zdarza się bez pokazywania Read-error on swap device. Przez większość czasu w dzienniku jądra nie wystąpił błąd. (Kilka razy to pokazało EXT4-fs errori Buffer I/O errorzamiast tego). Te komunikaty o błędach mogą być spowodowane awarią sprzętu. Podczas diagnozowania tego problemu skup się na innych, bardziej wyraźnych szczegółach.

Jądro testowe jest dostępne na końcu tego błędu Ubuntu, tj. W tym komentarzu: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1776887/comments/5

Do tej pory nikt nie podał swoich wyników z zawieszaniem się za pomocą jądra testowego Ubuntu. Może się zdarzyć, że jeśli ktoś zgłosi sukces, zachęci programistę Ubuntu do włączenia poprawki. Mogę się mylić, nie jestem w 100% pewien, co to powstrzymuje.

Znane jest również obejście. Możesz uniknąć awarii, jeśli skonfigurujesz wiersz poleceń jądra tak, aby zawierał tę opcję scsi_mod.scan=sync.

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1776887


Potwierdzono, że ten błąd w górę wpływa na użytkowników Ubuntu [1]. Zgodnie z zatwierdzeniem poprawki (poniżej) najczęstszym objawem jest awaria Xorg / Xwayland, tj. Zabicie całego GUI, gdy komputer budzi się ze stanu uśpienia systemu. Częstotliwość błędu jest opisana jako raz na kilka dni [2].

[1] Np. Ten użytkownik potwierdza błąd i bardzo szczegółowe obejście: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1760450/comments/11

[2] Np. Ten dziennik awarii: https://bugzilla.redhat.com/show_bug.cgi?id=1553979#c23

To jest błąd w blk-core.c. Nie jest specyficzny dla żadnego sterownika sprzętowego. Technicznie błąd zawieszenia jest wywoływany przez rdzeń SCSI, z którego korzystają wszystkie urządzenia SATA .

Zatwierdzenie obejmuje również test, który szybko i niezawodnie dowodzi istnienia przerażającego błędu.

Myślę, że możesz uniknąć tego błędu tylko wtedy, gdy masz root na NVMe. Innym sposobem, aby nie trafić w awarię Xorg, jest nieużywanie całej pamięci RAM, więc nie ma presji, która prowadzi do zamiany zimnych stron Xorga. Ponadto nie odtworzysz awarii Xorg, jeśli natychmiast zawiesisz + wznowisz. (To w pewnym momencie sfrustrowało moje testy, uruchomiło się dopiero po pozostawieniu systemu zawieszonego podczas lunchu :).

Poprawka: „blok: nie używaj nigdzie przerywalnego”

w jądrze 4.17: https://github.com/torvalds/linux/commit/1dc3039bc87ae7d19a990c3ee71cfd8a9068f428

w jądrze 4.16.8: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?h=linux-4.16.y&id=7859056bc73dea2c3714b00c83b253d4c22bf7b6

brak poprawki w 4.15.0-24.26 (ubuntu 18.04): https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/bionic/tree/block/blk-core.c ? id = Ubuntu-4.15.0-24.26 # n856

Tzn. Ten błąd jest nadal obecny w pakiecie źródłowym Ubuntu linux-4.15.0-24.26 (i 4.15.0-23.25). Załączam szczegóły sprzętowe (lspci-vnvn.log) systemu, w którym wiadomo, że ten błąd się zdarza.

Pozdrawiam Alan

Obejście: Użyj parametru jądra: scsi_mod.scan = synchronizacja


Świetna praca! Potwierdzono na jądrze Ubuntu 18.04 w / 4.15.
ricosrealm

Właściwie to nie zadziałało po drugim teście.
ricosrealm

@ricosrealm najbardziej nieoczekiwany. Potwierdź, że twój problem (czasami) objawia się jako SIGBUS (sygnał numer 7) w Xorg lub gnome-shell. Jest to łatwe, jeśli masz systemd-coredumpzainstalowany i używany coredumpctl -r, ale nie wiem, co zrobić, gdy masz zainstalowany apport. (pakiety systemd-coredump i apport są ze sobą w konflikcie, prosimy o dokonanie oceny).
sourcejedi

@ricosrealm Ale przynajmniej mogę prosić o potwierdzenie, że 1) aktualna sesja graficzny odchodzi, ale system pozostaje inaczej użytku i można zalogować ponownie 2) dmesgczy nie pokazać się komunikat „wysypać” dla Xorg / gnome-shell . (I najczęściej nie widzę żadnych błędów jądra, ale czasami może się pojawić „Błąd odczytu na urządzeniu wymiany”).
sourcejedi

@ricosrealm Btw, wydaje się, że łatka zrobiła nieco większy postęp, odkąd opublikowałem odpowiedź. lists.ubuntu.com/archives/kernel-team/2018-June/093612.html
sourcejedi
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.