Read error on swap device

The Ubuntu 18.04 kernel you are currently using is missing a rather important bug fix.

The fix for this is already present in the upstream Linux kernel version 4.16.8. (The suspend bug effectively started happening in kernel version 4.15). Ubuntu only needs to cherry-pick this small patch from upstream. The bug frequently causes Xorg crashes immediately after suspend, i.e. it crashes the whole graphical login session.

Note this bug often happens without showing Read-error on swap device. Most of the time, there was no error in the kernel log. (A few times, it showed EXT4-fs error and Buffer I/O error instead). Also, these error messages could be caused by a hardware failure instead. When diagnosing this problem, please focus on other, more distinct details.

A test kernel is available at the end of this Ubuntu bug, i.e. in this comment: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1776887/comments/5

So far no-one has reported their results from suspending with the Ubuntu test kernel. It might be that if someone can report success, it will encourage the Ubuntu developer to finally include the bug fix. I could be wrong though, I’m not 100% sure what’s holding this up.

There is also a known workaround. You can avoid the crash if you configure the kernel command line to include the option scsi_mod.scan=sync.

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

---

This upstream bug has been confirmed to affect Ubuntu users[1]. As per
the fix commit (below), the most frequent symptom is a crash of
Xorg/Xwayland, i.e. killing the entire GUI, when a laptop is woken
from system sleep. Frequency of the bug is described as once every few
days[2].

[1] E.g. this user confirms the bug & very specific workaround:
https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1760450/comments/11

[2] E.g. this log of crashes:
https://bugzilla.redhat.com/show_bug.cgi?id=1553979#c23

This is a bug in blk-core.c. It is not specific to any one hardware
driver. Technically the suspend bug is triggered by the SCSI core —
which is used by all SATA devices.

The commit also includes a test which quickly and reliably proves the
existence of a horrifying bug.

I guess you might avoid this bug only if you have root on NVMe. The
other way to not hit the Xorg crash is if you don’t use all your RAM,
so there’s no pressure that leads to cold pages of Xorg being swapped.
Also, you won’t reproduce the Xorg crash if you suspend+resume
immediately. (This frustrated my tests at one point, it only triggered
after left the system suspended over lunch :).

Fix: «block: do not use interruptible wait anywhere»

in kernel 4.17:
https://github.com/torvalds/linux/commit/1dc3039bc87ae7d19a990c3ee71cfd8a9068f428

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

lack of fix in 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

I.e., this bug is still present in Ubuntu source package
linux-4.15.0-24.26 (and 4.15.0-23.25). I attach hardware details
(lspci-vnvn.log) of a system where this bug is known to happen.

Regards Alan

WORKAROUND: Use kernel parameter: scsi_mod.scan=sync

Предисловие

Страшная сказочка:

EDAC MC0: 1 CE read ECC error on CPU#0Channel#1_DIMM#0 (channel:1 slot:0)
EXT4-fs error: ext4_wait_block_bitmap:445: Cannot read block bitmap
Out of memory: Kill process 95 (sshd) score 31 or sacrifice child
CMCI storm detected: switching to poll mode
page allocation failure: order:1, mode:0x4020
invalid opcode: 0000 [#1] SMP

Неприятно выглядит, правда? Список

может быть очень длинным

очень длинный. В этой статье я расскажу как с этим жить и что мы с ним сделали.

Часть из этих сообщений в примерах выше заставит вас погрузиться в бездны современной архитектуры процессоров («CMCI storm», удачи в поиске дороги назад, из дебрей интернетов)… Cтранные вещи в ядре могут нарушать ожидания о том, как работают компьютеры, делая последующую отладку очень затруднённой. Отсутствие знания о том, что случилось может даже оставить с грустным ответом «какая-то неведомая фигня, ребутнули, вроде, прошло».

Странные вещи можно разделить на четыре группы:

• Отказ центрального оборудования (в том числе процессора. Как вам сообщение «Generic CACHE Level-2 Generic Error»?)
• Отказ периферийного оборудования (CMCI storm от сетевой карты? Отвалившийся SAS HBA?)
• Ошибки в ядре
• Нехватка ресурсов

Иногда ошибки происходят в sad path (триада понятий: happy path, sad path, bad path) — грустно, но предсказуемо. Есть осмысленная ветка кода, которая на эту проблему реагирует. Ядро поделило на ноль, жёсткий диск начал сыпать Buffer I/O error on device… и т.д. Чаще всего подобные ошибки либо означают перезагрузку сервера (в идеале — автоматическую), либо обрабатываются в районе ПО (одинокий сломавшийся жёсткий диск — даже не проблема, а так, рейд пересобрать после замены), либо в железе (recoverable ECC error у памяти). Иногда ошибки даже проходят незамеченными (например, IO error для CD-привода, одинокий segmentation fault для программы, которая «перезапустилась и продолжает работать»).

Печальный пример

Но иногда ошибки не обрабатываются «ожидаемым» образом, а приводят систему в состояние, когда «никогда такого не было, и вот опять» (bad path).

Живой пример из недавней практики: RAID-контроллер на сервере ушёл в оффлайн и тут же вернулся обратно (PCI bus reset силами watchdog’а в драйвере). Все массивы были обнаружены как «новые» диски и получили новые же буквы, uuid’ы остались те же. Всё, что было в databag’ах chef’а было подмонтировано при первой же возможности по тем же самым путям.

Получилась конструкция, мягко говоря, не предусмотренная КоАП:
/dev/sda -> /mountpoint (битый)
/dev/sdd ->/mountpoint (рабочий)
При этом файлы, которые были открыты на ‘битой’ версии /mountpoint давали IO error на любые операции, а новые файлы создавались на рабочей /mountpoint. Оттуда же брались и новооткрытые на чтение файлы. При этом своп был на «битой» /dev/sda и можно было наблюдать фантастические сообщения:

Read-error on swap-device (8:0:330471000)
Write-error on swap-device (8:0:362589920).

(до этого момента я не знал, что Linux может сделать read error на swap и остаться жить).

Сам sda был хардварным рейдом, но кому поможет избыточность дисков, если отваливается контроллер целиком? Получившаяся конструкция полностью проходила все проверки. Диск есть? Есть и примонтирован. Состояние рейда? ОК! Свободное место? Есть. Размер очереди на IO? Всё ок. Счётчик ошибок для подмонтированного блочного устройства? По нулям (устройство-то новое). Новые запросы на запись отрабатывают? Отрабатывают. Чего ещё желать?

А ведь при этом куча ПО словила ошибку записи и перешла в неожиданное состояние. Кто-то завершился, кто-то продолжал писать в файл не смотря на ошибки (то же ядро со swap-файлом). Даже специальная проверка на то, все диски, которые ожидает увидеть chef, примонтированы, тоже говорила «ок».

После разбора полётов мы изменили проверку на «примонтированность» с проверки на «диск примонтирован» на «диск примонтирован не более одного раза». Ну и анализ логов. Собственно, о них и статья.

Отказы центрального оборудования

Тяжело собирать выбитые зубы сломанными руками. То же самое касается реакции системы на отказ центральных компонент. Если у сервера проблемы с питанием процессора, с самим процессором (да, они тоже ломаются), оперативной памятью, контроллером PCI или другими критическими для работы компонентами, то он либо виснет (и тут приходит watchdog и перезагружает), либо паникует. Однако, есть целый класс некритических ошибок (например, ошибка работы с памятью, хотя и очень плохая, но часто не приводит к перезагрузке). Иногда ошибается процессор, сбоит программа в виртуальной машине ACPI, чудачат контроллеры памяти или PCI-шины. Иногда эти ошибки «всего лишь» меняют несколько байт (бит?) в некоторых местах. Последствия этого предсказать невозможно. То есть не «трудно», а «невозможно».

Ошибки в ядре

Тоже бывают. BUG on bla-bla-bla. Неприятное, но не смертельное «ну не получилось». В некоторых случаях ошибка фатальна и ведёт к panic, в некоторых, с точки зрения ядра, нет. Однако, последствия ошибки ядра опять же, очень трудно описать с позиции userspace. Раньше всё было хорошо, ничего не поменялось, и вот уже всё плохо.

История

В ядре что-то пошло не так. То ли мьютекс, то ли попортилась память, но на выходе мы получили странный трейс, и неубиваемый процесс, жрущий 100% CPU. Обнаружил я его, когда увидел, что nova-compute (написана на python) не отвечает на heartbeat’ы. Пошёл на хост. Вижу, в top’е, 100% CPU. Не перезапускается. Не убивается (kill -9). Strace показывает ничего (нет запроса).

Погодь, опытный админ. Этот процесс не был в ‘D’, он не «ушёл в IO и не вернулся». Он вообще не выполнял никакого syscall’а. Он просто ел 100% CPU (в ядерном контексте?). Он был ‘R’ и он игнорировал сигнал 9 (и он был не init). В том случае историю до конца не раскопали, но предположение было, что либо в результате ошибки, либо незамеченного повреждения памяти, при переключении контекста ядро не могло обработать какую-то блокировку, так что CPU time засчитывалось процессу, но процессор при этом работал в контексте ядра. То есть «висит груша, жрёт 100%, прибить нельзя». Удивительным образом, процесс самозавершился (или дообработал kill -9) через минут 10, после чего shutdown/migration прошёл штатным образом (типа, happy end).

Нехватка ресурсов

Когда вашему уютненькому приложению говорят «фиг тебе, а не файловый сокет», это sad path. Всё под контролем и хорошо. Но когда сетевой драйвер не может получить себе цельный кусок памяти на 8кБ (для jumbo frame) — «page allocation failure: order:2», и молча дропает пакет — это плохо. То есть снаружи видно, что плохо, а внутри всё хорошо, кроме строчек в dmesg. Основная причина этой ошибки — фрагментация памяти (куски памяти должны быть непрерывными), плюс особенность используемого (на тот момент) ядра. Кстати, в качестве временной меры (до вывода сервера из эксплуатации) мы чуть-чуть понизили размер jumbo frame до состояния, когда модулю было достаточно 2 страниц подряд, а не 4. Чуть-чуть полегчало.

А бывает так, что приходит волшебный OOM killer и отбирает новогодние подарки у какого-нибудь процесса. Особенно печально это выглядит, когда умирает вспомогательный процесс (например, epam для beam.smp в контексте erlang’а) и про это никто не в курсе. Ещё интереснее, когда нехватка памяти случается на очень занятой системе — мало того, что OOM killer убивает кого попало, процесс поиска «жертвы» может затянуться на десятки секунд, и в течение этого времени сервер не делает ничего. Вообще ничего — ни сеть, ни диск не работают. Только ядро шуршрит по структурам в памяти. А потом (за вычетом «не проснувшегося лузера») продолжает работать так, как будто ничего не произошло. И гадай после этого, почему сработал failover с таймаутом в 20с.

Подводя к теме рассказа

Во всём этом грустном есть одно общее — ядро пишет о причинах грусти в dmesg. Даже если ядро решает запаниковать, оно сначала в dmesg пишет, а потом паникует. Разбор причин post mortem — едва ли не самая важная работа системного администратора, она напоминает работу специалиста по вещественным уликам. Мельчайшие следы того, что остались, позволяют складывать вместе кусочки мозаики. Особо мозаика интересна, когда эксцесс происходит в масштабе нескольких серверов.

Вторая важная вещь: о всех этих гадостях лучше узнавать когда они происходят. Потому что между «печальным трейсом» в dmesg и деградацией сервиса, которая будет заметна со стороны, могут проходить значительные интервалы времени (до нескольких десятков часов). И есть время «поправить так, как будто ничего и не было».

Таким образом, хочется и «собирать логи», и «реагировать на них».

Те, кто про себя уже вздохнул «ну, ещё один рассказ про netconsole» — нет. Про netconsole я скажу несколько слов, а потом расскажу как с этим жить потом, когда данные уже получены по UDP.

netconsole

Подробное howto уже писалось: habrahabr.ru/post/131220, а тут я дам краткую выжимку: netconsole — модуль ядра для отправки журнала ядра в UDP-пакетах. Заметим, это настолько низкий уровень, что на нём не работает даже ARP, то есть вы должны указать мак-адрес получателя.

Зато netconsole работает, даже если выполомаете весь сетевой стек. Например, сделаете rmmod ip, или, или удалите IP-адрес с интерфейса, или при включенном бриджинге, rmmod openvswitch. Очень смешно видеть, как ядро по сети пишет о том, что вся сеть сломана.

При загрузке модуля ему указывается локальный интерфейс, IP-адрес с которого отправлять, IP и MAC-адреса получателя. Если трафик отправляется за пределы сегмента сети, то в качестве MAC’а указывается MAC-адрес шлюза (.1).

Приём

Всё интересное начинается тут. Собирать netconsole можно с помощью syslog (и его вариаций — syslog-ng, rsyslog). В нашем случае используется logstash. Про эту конструкцию мы уже писали: писали.

Логи во-первых принимаются, во-вторых маркируются по input’у как ‘netconsole’ (условно выбранная нами метка), а главное, производится запись имени сервера вместо адреса. Это очень важный процесс и про него чуть ниже.

Пример конфига:

input {
  udp {
      type => "netconsole"
      port => "6666"
      buffer_size => "1048576"
  }
}

filter {
  if [type] == "netconsole" {
    dns {
      action => "replace"
      reverse => ["host"]
    }

    mutate {
      add_field => ["syslog_host", "%{host}"]
    }
  }
}

Единственное нетривиальное тут — это выставление поля host. И оно очень важно, потому что иначе потом dmesg не найти будет. Настолько важно, что у нас сейчас идёт дискуссия о том, надо ли нам на хостах мониторинга выписывать все адреса в /etc/hosts и использовать его, для того, чтобы авария на dns в момент записи трейса, не попортила бы лог с ошибками.

Далее, нам надо эти логи смотреть. В контексте kibana, для собственно удобства, было добавлена колоночка ‘TERMS’ с выбором: syslog или netconsole. Получившийся фильтр выглядит так:
host must 'hostname' and source must 'netconsole'.

Получившееся уже можно читать, но очень неудобно. Для удобства я использую ещё ручной скрипт,
который выдирает dmesg просто плейнтекстом из elasticsearch’а:

#!/usr/bin/python
from pyelasticsearch import *
import json
import sys

es = ElasticSearch('http://elastic.local:9200/')
q=json.load(sys.stdin)
res=es.search(q)['hits']['hits']
for i in res:
        print(i['_source']['message']),

На stdin ему кормится заинтересовавший запрос из kibana в виде JSON (кнопка ‘i’ в интересующем виджете), на stdout оно выдаёт аккуратную стопочку строк без лишнего мусора. Впрочем, про жизнь и борьбу с Kibana я напишу отдельно.

Мониторинг

Выше был показано как смотреть данные post mortem. Есть ещё задача реагировать на «плохие» строки и оповещать о них shinken (nagios). А уж как действовать на нервы админам, nagios и сам отлично знает.

Делается это с помощью фильтров.

filter {
 if [type] == "netconsole" {
    if (
            [message] =~ /ioc0: attempting task abort!/ or
            [message] =~ /mptbase: ioc0:.+Code={Abort}/ or
            [message] =~ /Device offlined/ or
            ...
            [message] =~ /Read-error on swap-device/ or
            "1" == "2"          
  ) {
      noop {
        add_tag => ["notify"]
      }
}

Мы выставляем флаг notify, если нам не нравится строчка. Обратите внимание на «1» == «2» — эта строчка добавлена для того, чтобы смело писать or на каждой «осмысленной» строке и не бояться поломать синтаксис.

Обработка флага происходит очень просто:

output {
  if "notify" in [tags] {
    exec {
      command => "/usr/lib/nagios/plugins/log_event_sender.sh %{syslog_host} log_event '%{message}'"
    }
  }
}

Тестирование

Я бы сказал, что на этом «всё», если бы не одно «но». Некоторые виды страшных строк появляются крайне редко — и очень сложно узнать, сработает ли мониторинг на них или нет. До какого-то момента мы полагались на «мы его не сломаем», но опасения нелепой опечатки в фильтрах, полностью отключающей срабатывания на ошибки, было слишком большим.

И родился микрофреймворк для тестирования.

Идея простая: каждый регэксп в фильтрах должен ловить только одну строку. И для каждого регэкспа должен быть оригинал (желательно, скопированный прям на живую, из реального события), который мы хотим поймать.

Пример файла фильров я показал выше. Пример файла с примерами вы можете посмотреть во вступлении. Одна гадость на одну строчку.

Дальше идёт простейший тест: мы запускаем logstash в stdin/stdout режиме, и проверяем, что число входных строк равно числу выходных (с меткой notify). Если оно расходится — значит, кто-то что-то сломал. Если сходится, значит, на каждую плохую строчку что-то её да поймает.

Ниже run_test.sh, в котором ничего интересного не происходит — пишем микроконфиг с помощью echo, вставляем в середину его фильтр, который тестируем, проверяем, что всё совпало. Если нет — админ сам разбирается что не так.

#!/bin/bash
TMPC=logstash-test-$RANDOM.conf
TMPO=logstash-test-output-$RANDOM.txt
LOGSTASH=logstash/logstash-1.4.2/bin/logstash
TIMEOUT=60
FILTERS=....../filters.conf.erb

if test ! -d logstash;
then
    echo "No local logstash found at $LOGSTASH (Please download/unpack)"
    exit -1
fi
echo 'input { stdin { type => "netconsole" } }' > $TMPC
cat $FILTERS >>$TMPC
echo 'output { if "notify" in [tags] { stdout { } } }' >>$TMPC
#echo $LOGSTASH --quiet -f $TMPC
cat netconsole_examples.txt | timeout -s SIGKILL $TIMEOUT $LOGSTASH --quiet -f $TMPC  > $TMPO
if test `wc -l netconsole_examples.txt | awk '{print $1}'` -ne `wc -l $TMPO | awk '{print $1}'`; then
    echo Netconsole test FAILED
    echo Input: `wc -l netconsole_examples.txt`
    echo Output: `wc -l $TMPO`
    echo not removing files $TMPC and $TMPO
    exit 1
else
    echo netsonsole test PASSED
    rm $TMPC $TMPO
    exit 0
fi

После каждого редактирования надо/можно запустить run_test.sh и проверить, что оно работает. netconsole_examples.txt, заодно, служит отличным методом для хранения всех самых самых ужасных вещей, какие только можно встретить в этой жизни. (Сами эти строчки комментируются по вкусу, с добавлением ссылок на статьи в Вики, где хранятся post mortem разборы и т.д.).

На выходе мониторинга имеем вот такие сообщения:

** PROBLEM alert - database1984.utah42.nsa.gov/log_event is CRITICAL **
Shinken Notification

Notification Type: PROBLEM

Service: log_event
Host: database1984.utah42.nsa.gov
Address: 238.211.14.5
State: CRITICAL

Date/Time: 23-01-2015 Additional Info : Jan 23 03:59:21 database1984 kernel: [15941700.780017] mce: [Hardware Error]: Machine check events logged

Arch Linux

You are not logged in.

#1 2018-03-16 02:18:40

«Read-error on swap-device» when exiting out of suspend

This has happened twice now, with almost identical symptoms and error logs.
I suspend my computer for a few hours. When I come back, X11 has crashed. I run startx again, check dmesg and get this error in the log:

I’ve checked the swap partition and it seems to be running fine:

I’ve looked around a bit but can’t find a direct answer for why this is happening.

#2 2018-03-19 11:36:19

Re: «Read-error on swap-device» when exiting out of suspend

The same problem has just happened to me for the fourth time in about 3-4 weeks. I have a theory on what might play a role in causing it, but currently no time to test it:
* this might happen more often, but still not always, when there is something in the swap when going to standby (I have not checked precisely how much, but my taskbar always shows about 1% swap usage these days, so that might be enough to increase the likelihood of a crash)
* my swap is encrypted, but that should not be problem since the encrypted disk stays mounted throughout the crash
* once or twice I’ve also seen a graphics card related XID error (it might have been 79, but don’t take my word on it, it was more than a week ago and the error only showed up for a few seconds)
* inconvenient side note: the crash makes systemd restart the whole user session, which explicitly kills all tmux and screen sessions opened from there, even ones for the root user

Some details on my system (in case these are also relevant):
* processor: first generation i7
* ram: 16GB, encrypted swap: 15GB (similar to you, ‘mkswap -c’ did not find any errors)
* graphics card: Nvidia gtx-750ti
* kernel: 4.15.8-1
* dm/wm: lightdm, herbstluftwm

#3 2018-04-10 15:17:08

Re: «Read-error on swap-device» when exiting out of suspend

Finally found someone with this same problem.
After resuming, the session is ended, returning to display manager.
I have to use hybrid sleep so when the fail occurs, there are a copy of it on swap partition.

Here is what dmesg returns:

[36124.946085] PM: suspend exit
[36125.036078] Read-error on swap-device (8:0:67154840)
[36125.041210] Read-error on swap-device (8:0:67154392)
[36126.239944] Corrupted low memory at 00000000a9ddb825 (9ce0 phys) = a000000000000000
[36126.239950] Corrupted low memory at 0000000057dde89c (9ce8 phys) = 0b030038
[36126.547606] r8169 0000:07:01.0 enp7s1: link up
[36129.763797] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[36130.618903] ata3.00: configured for UDMA/133

I have too this problem of «Corrupted low memory». It appeared some months ago but I dont remember if together with this suspend problem.

#4 2018-04-10 17:58:26

Re: «Read-error on swap-device» when exiting out of suspend

You should check the (old) xorg log and will likely find sth. like

#5 2018-04-11 10:53:28

Re: «Read-error on swap-device» when exiting out of suspend

You should check the (old) xorg log and will likely find sth. like

next time I will check my Xorg.0.log and Xorg.0.log.old
(at this moment, no EE flag at all)

#6 2018-04-11 14:18:55

Re: «Read-error on swap-device» when exiting out of suspend

Again, resuming from suspend killed the session but this time, the error «Read-error on swap-device» does not appeared. We can see «Corrupted low memory» again.
About BTRFS error: prior to setting btrfs in my disk, I already had the problem — not the guilt one.

[17427.386136] OOM killer enabled.
[17427.386137] Restarting tasks . done.
[17427.389247] PM: suspend exit
[17427.392353] BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 60, flush 0, corrupt 0, gen 0
[17427.392389] BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 61, flush 0, corrupt 0, gen 0
[17427.392401] BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 62, flush 0, corrupt 0, gen 0
[17427.393369] BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 63, flush 0, corrupt 0, gen 0
[17427.397085] BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 64, flush 0, corrupt 0, gen 0
[17427.397129] BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 65, flush 0, corrupt 0, gen 0
[17427.397141] BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 66, flush 0, corrupt 0, gen 0
[17427.397153] BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 67, flush 0, corrupt 0, gen 0
[17427.397163] BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 68, flush 0, corrupt 0, gen 0
[17427.397172] BTRFS error (device sda2): bdev /dev/sda2 errs: wr 0, rd 69, flush 0, corrupt 0, gen 0
[17428.982578] r8169 0000:07:01.0 enp7s1: link up
[17432.206986] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[17433.087114] ata3.00: configured for UDMA/133
[17449.106589] Corrupted low memory at 000000008ee7978c (9ce0 phys) = a000000000000000
[17449.106595] Corrupted low memory at 00000000d43ed837 (9ce8 phys) = 0b030038
[17520.439791]

#7 2018-04-24 12:57:09

Re: «Read-error on swap-device» when exiting out of suspend

increased my swap partition from 6GiB to 8GiB (my ram is 6GiB) as recommended and seems the problem is gone. Two days and suspended/hibernated around 13 times. No more «Read-error on swap-device» showed up. Hope the system continues flawless as always arch worked for me.

#8 2018-07-20 14:06:29

Re: «Read-error on swap-device» when exiting out of suspend

There is a bug which causes this introduced in upstream kernel v4.14, which was fixed in v4.17 and v4.16.8. If the Xorg.log shows that the crash is a «bus error» and not a «segmentation fault», it is almost certainly the same problem.

The previous arch forum thread on it is here:

«Read-error on swap-device» during resume is a *possible* signature for this error (but this error message could be caused by other things, and most of the time this crash was quite silent, at least for me). For examples where this message happened, see:

The «BTRFS error» is consistent with the «EXT4-fs error» which is also noted in the last link.

Last edited by sourcejedi (2018-07-20 14:10:12)

#9 2018-07-20 14:40:36

Re: «Read-error on swap-device» when exiting out of suspend

If you still do not have a new enough kernel, and you don’t want to install an older kernel (switch to the linux-lts package mentioned in the Arch thread?), there is a workaround.

Add the option «scsi_mod.scan=sync» to the end of your kernel command line e.g. in GRUB.

Last edited by sourcejedi (2018-07-20 14:52:53)

Источник

Arch Linux

You are not logged in.

#1 2014-10-01 12:45:38

kernel: Read-error on swap-device (8:0:2778448)

Last night I started par2 to repairing part of a large collection of file to make sure that the set of recovery data was good. This morning I was checking on it and saw «bus error (core dump)». I checked the systemd journal and saw the following.

A quick Google search lead to the assumption that this is due to a bad block, however I just tested it for bad block a few months ago. I’ll check it again this after noon after work, but for now I wanted to get some other opinions. See if there is some other explanaition beyound a bad block.

[edit] The result of «smartctl -a /dev/sda». It looks like I might have an issue with my cable or something from the UDMA count.

[edit2] Just to make sure, I checked and found that none of the other drives have UDMA CRC errors, even the one that shares the same controller.
[edit3] Badblocks came back negative, and the previous time I tried this, just the night before, I didn’t have any issues. I forgot to mention that last bit.

Last edited by nstgc (2014-10-01 20:02:58)

#2 2014-10-01 12:55:30

Re: kernel: Read-error on swap-device (8:0:2778448)

Try smartctl to see if it is showing anything.

I may have to CONSOLE you about your usage of ridiculously easy graphical interfaces.
Look ma, no mouse.

#3 2014-10-01 13:21:00

Re: kernel: Read-error on swap-device (8:0:2778448)

Try smartctl to see if it is showing anything.

I will when I get home.

I just remembered that I have another thread on these forums about my Steam library disappearing. My steam library is on a raid0 btrfs volume that does not include the drive that the swap partition is on. The point being that if this is a drive issue, it is unrelated to the previous problem. if its a different hardware issue or a software issue, it could still be related.

[edit] The SMART information is in the opening thread now. It looks like it may be a cable issue.

[edit2] Just to make sure, I checked and found that none of the other drives have UDMA CRC errors, even the one that shares the same controller.
[edit3] Badblocks came back negative, and the previous time I tried this, just the night before, I didn’t have any issues. I forgot to mention that last bit.

Last edited by nstgc (2014-10-01 20:03:09)

Источник

Read error on swap device

I’m getting this message over the serial cable after leaving my raspberry pi running for some time, and it makes the machine grind to a halt, which is a pain as it’s headless and I usually access it using VNC and SSH.

The spec is Rpi 2b powered by the Rpi 3 official PSU. Kingston class 10 32gb sd card, running Raspbian Jessie installed using NOOBS.

Here’s the complete log from the serial cable:

After this error the machine is unresponsive, cannot access over SSH or even login over the serial cable.

I fixed it by pulling the power cable, putting the SD card into a laptop running Ubuntu, FSCK’ing all the partitions, putting the card back in the Pi and it boots and runs fine now.

This isn’t a one off, I’ve had to do this more than once, is there any way I can stop this from happening again?

I’d really like to fix this as I usually access this machine remotely, and having to physically access this machine can be a pain.

I can post my bootup log over the serial cable also if it would help debug if needed.

Thanks

Re: Read-error on swap-device

Down the rabbit hole we go. After a little research it seems that mounting the SD card in read-only and disabling the swap file is the way to go if you want something more robust and reliable.

I have some log files in the program I’m running, but I think I can write these to a NAS instead of the SD card. These aren’t huge logs, around 10mb every hour; I just need to change a few paths in my shellscript.

90% of the programs I use in my script do not need write access, I can use /dev/shm for temporary working files, it’s essentially a RAMdisk. /dev/shm will be around 10Mb at the most.

The only thing I’m having trouble with a read-only system is getting Chromium to run. It creates a hidden user profile directory in the users home folder, and refuses to even start up if the home folder is read-only.

I don’t quite know what to do now, I could use a USB thumb drive and try and make a read-write partition and make that the home folder, but I have a feeling I’m going to get the same crashing issues if the USB drive goes bad.

Another option would be to try and make the home folder on the NAS, but this could be rather slow as Chromium also uses the home folder for it’s cache along with cookies, bookmarks, etc. I don’t mind if it’s a little slower, the goal here is reliability over speed.

Does anyone have experience of running Chromium using a read-only system drive? If so what method did you go with and how well did it work.

Also are there any other options I’ve missed, or any issues I’ve missed?

Источник

Thread: Hibernate Error : read error on swap device

Thread Tools

Display

Hibernate Error : read error on swap device

I have ubuntu 9.04. I cant hibernate my system. I just hangs with some lines on screen
«[some number]read-error on swap device[some number]»
I installed ubuntu through «install inside windows».
pls help.

Re: Hibernate Error : read error on swap device

can’t hibernate/suspend-to-disk (S4) on a Wubi installation, which is what you have

you can still suspend (-to-ram) S3

Last edited by logos34; June 8th, 2009 at 06:52 AM .

Re: Hibernate Error : read error on swap device

can’t hibernate/suspend-to-disk (S4) on a Wubi installation, which is what you have

you can still suspend (-to-ram) S3

means there is no way to hibernate .

Re: Hibernate Error : read error on swap device

no, I don’t believe so. it’s a known limitation of wubi. basically you’re running linux INSIDE windows on a loopback-mounted virtual filesystem. hibernation require a dedicated swap file or partition

Re: Hibernate Error : read error on swap device

Hello!
I’m facing the same problem, but I installed Ubuntu 12.10 through CD and «alongside Windows». I didn’t use Wubi (at least I think so). And now I am not able to hibernate. Whenever I start the laptop from hibernation ,a whole screen of «read-error on swap-device» appears. Also I distinctly remember that the only partition that is mentioned is /dev/sda5 (ext4) of 366.11 GiB. I do have a /dev/sda6 linux-swap partition of 2 GiB (equal to size of RAM).

I’m quite worried. I recently replaced my hard drive and installed Windows 7 and then Ubuntu 12.10. Is it a problem with the hard drive or the installation.
What should I do?
Is there a way to fix this?

Thank you very much for your time,effort and consideration in advance.

Re: Hibernate Error : read error on swap device

If it’s any help, my most recent hibernate error (accidentally closed the laptop lid) showed this screen when I reopened the lid:

[23859.796020] done.
[23859.004491] video LNXVIDEO:01: Restoring backlight state
[23859.005495] Read-error on swap-device (0:0:31000)
[23859.005444] Read-error on swap-device (0:0:31000)
[23859.005440] Read-error on swap-device (0:0:31016)
[23859.005451] Read-error on swap-device (0:0:31024)
[23859.005455] Read-error on swap-device (0:0:31032)
[23859.005450] Read-error on swap-device (0:0:31040)
[23859.060519] Read-error on swap-device (0:0:0904)
[23859.060525] Read-error on swap-device (0:0:0920)
[. many numbers below in the same fashion. I’m also not really sure about the accuracy of the numbers]
[23859.063399] EXT4-fs (sda5): previous I/0 error to superblock detected
[23849.063408] EXT4-fs error (device sda5): ext4_find_entry:1209: inode #12109704L comm kworker/u:53: reading directory lblock 0
[23859.065360] Core dump to |/usr/share/apport/apport 2349 7 0 pipe failed
[23859.069327] Core dump to |/usr/share/apport/apport 3874 7 0 pipe failed
[23859.069430] Core dump to |/usr/share/apport/apport 2160 7 0 pipe failed
[23859.069667] Read-error on swap-device (8:0:23816)
[23859.069676] Read-error on swap-device (8:0:23824)
[numbers] Core dump to |/usr/share/apport/apport 2543 7 0 pipe failed
Core dump to |/usr/apport/apport 2941 7 9 pipe failed
Core dump to |/usr/apport/apport 2568 7 0 pipe failed
Core dump to |/ust/apport/apport 1 7 0 pipe failed
[23859.888708] Kernel panic — not syncing: Attempted to kill init! exitcode=0x00000007
[23850.888708]
[23859.888711] Pid: 1, comm: init Tainted: G W I 3.5.0.26.generic #42-Ubuntu
[23859.888713] Call Trace:
[23859.888715] [ ] panic+0x81/0x17b
[23859.888723] [ ] do_exit+0x745/0x7a0
[23859.888729] [ ] ? __sigqueue_free+0x32/0x40
[23859.888732] [ ] do_group_exit+0xa0
[23859.888734] [ ] get_signal_to_deliver+0x175/0x5a0
[23859.888738] [ ] ? force_sig_info_fault+0x5a/0x60
[23859.888740] [ ] do_signal+0x2d/0x890
[23859.888745] [ ] ? kmap_atomic_prot+0xd7/0xf0
[23859.888749] [ ] ? is_prefetch.isra.17+0x26/0x130
[23859.888751] [ ] ? mm_fault_error+0x196/0x1d0
[23859.888754] [ ] ? do_page_fault+0x441/0x480
[23859.888759] [ ] ? vfs_write+0xe8/0x160
[23859.888764] [ ] ? wait_on_retry_sync_kiocb+0x50/0x50
[23859.888766] [ ] ? vmailoc_fault+0x176/0x176
[23859.888768] [ ] do_notify_resume+0x85/0xb0
[23859.888770] [ ] work_notifysig+0x30/0x37
_

P.S. I apologise for any typos and inaccuracies but the picture from which I gathered the information didn’t have a perfect resolution.

Re: Hibernate Error : read error on swap device

Old thread closed. Anyone having further questions, please start a new thread.

Источник

stderr wrote:

HypnoToad wrote:The only thing I’m having trouble with a read-only system is getting Chromium to run. It creates a hidden user profile directory in the users home folder, and refuses to even start up if the home folder is read-only. I don’t quite know what to do now, I could use a USB thumb drive

You said it was headless and you are using a browser, so that’s ssh -X? I would network in the /home directory and test that out, but how big is the directory that ch wants to write into, especially if you disable local cache? Perhaps it would fit in a ram disk, and compressed ram disk even more so.

Hi, thanks for the reply. I’m using both SSH and VNC to access this machine. VNC is handy as run a VNC viewer from a mobile devices that don’t support flash content, and VNC into the Pi so I can use flash content when needed.

I’ve only just found that Chromium has a plethora command line switches: http://peter.sh/experiments/chromium-co … -switches/

—disk-cache-dir ⊗ Use a specific disk cache location, rather than one derived from the UserDatadir. ↪
—disk-cache-size ⊗ Forces the maximum disk space to be used by the disk cache, in bytes. ↪

I’ll see if setting the cache size to 0 bytes is ok, and I can move the whole user data folder also to the remote folder, and see if it works and how much this affects the performance, I’ll experiment with a ram disk also but I am quite tight on memory, in fact I have a cron job which runs once a minute, it checks how much RAM chromium is using and if it goes above 750Mb then it sends a warning, I did this as I wanted avoid using the swapfile. Even with only a single tab and 1 extension Chromium is usually using between 600-700Mb.

Right now with Chromium running, the ~/.config/chromium folder is ~35Mb, so I’ll try a ram drive also, as then I won’t run into problems if I ever need to reboot or update my NAS.

Before I go fully read-only it does seem that there may be an issue with the memory card I’m using:

https://github.com/raspberrypi/firmware … -219287224

The Kingston SDC10G2/16GB cards seem to have a controller fault that makes the ERASE operation both slow and hazardous. The ext4 filesystem will attempt to use ERASE on nodes as they are deleted, and this can lead to corruption. The rpi-4.4.y tree contains a patch that disables erase on such cards (name=»SD16G», manfid=0x41, oemid=0x3432″) to improve performance and stop the corruption; a kernel including this patch is now available via rpi-update.

When I run

grep . /sys/class/mmc_host/mmc0/mmc0:*/* 2>/dev/null

I get

/sys/class/mmc_host/mmc0/mmc0:0007/manfid:0x000027
/sys/class/mmc_host/mmc0/mmc0:0007/name:SD32G
/sys/class/mmc_host/mmc0/mmc0:0007/oemid:0x5048

so it looks like there is a known issue with my card.

I’m going to run rpi-update and reboot before going read-only, and see if this fixes things.

EDIT: Found a spare Sandisk Ultra SD card, I’ll try these out and see if they have the same issue.

Страницы: [1]   Вниз

0 Пользователей и 1 Гость просматривают эту тему.

---

---

---

Страницы: [1]   Вверх