ИИтог

Владелец Lenovo X1 Carbon обошёл битую распаянную память через memmap

разноеРедакция ИИтогHacker News🔥38Рейтинг ИИтог38Влияние30Новизна25Релевантность70Неожиданность40Участники10Достоверность65
Владелец Lenovo X1 Carbon обошёл битую распаянную память через memmap

Автор блога blog.hardill.me.uk рассказывает о своём рабочем ноутбуке Lenovo X1 Carbon, который он получил в 2021 году и использует под Fedora. Долгое время машина работала отлично, но недавно в браузере стали чаще падать вкладки, а корневая файловая система время от времени сама переходила в режим «только чтение». В журнале ядра появились предупреждения BTRFS о несовпадении контрольных сумм (csum failed) и ошибка с огромным счётчиком corrupt. Это навело автора на мысль о неисправной оперативной памяти.

Он добавил образ Memtest86+ на USB-флешку с Ventoy и загрузился с неё. Эта утилита запускает минимальную систему, пишет в каждый доступный физический адрес набор шаблонов и читает их обратно; несовпадение означает проблему. Ошибки появились почти сразу. Раньше, пишет автор, по выводу можно было определить сбойную планку DIMM или вынуть одну из планок и повторить тест, а затем купить замену. Сейчас оперативная память у большинства ноутбуков распаяна прямо на материнской плате (исключение, по словам автора, например, Framework), и без навыков работы с BGA-микросхемами (ball grid array) заменить её практически нереально. Автор объясняет распайку погоней за ещё более тонкими ноутбуками (разъём DIMM добавляет примерно 6 мм толщины) и, как он выражается, возможно, циничным расчётом: любая поломка заставит покупать ноутбук целиком.

Амортизация за 5 лет и прогресс означают, что менять ноутбук, вероятно, пора, но автор хочет продлить жизнь Lenovo X1 Carbon: тот всё ещё очень способен и мог бы заменить ещё более старый Dell XPS 13, который автор использует как личный ноутбук. О новом ноутбуке автор обещает написать позже.

Пока новая машина едет, он решил сделать старую стабильнее. Нашлись два параметра ядра Linux, позволяющие не использовать сбойные области памяти: badram и memmap. badram, патч вне основной ветки ядра, который обычно поставляется только в дистрибутивах на базе Debian и Ubuntu, поэтому для Fedora не подошёл. memmap, штатная функция ядра, ей нужен список адресов и длин в формате длина$смещение в командной строке ядра. Memtest86+ умеет выводить нужный формат (и для badram, и для memmap) и сохранять его в файл, но с образом на флешке Ventoy это не заработало, так что автору пришлось сфотографировать экран и вручную переписать значения, по его слову, «весело».

Согласно документации, параметры нужно добавить в GRUB_CMDLINE_LINUX в /etc/default/grub и выполнить grub2-mkconfig -o /boot/grub2/grub.cfg. После этого ноутбук перестал загружаться. Через меню GRUB автор посмотрел командную строку и увидел, что $0 в записи memmap был заменён самим grub2-mkconfig, как при классической подстановке переменных окружения ($0 обычно означает имя запускаемого скрипта). В найденном баге RedHat описано решение: сохранить значение в переменную окружения GRUB командой grub2-editenv (переменная memmap_val, значения с экранированным $) и в /etc/default/grub оставить только ссылку memmap=$memmap_val. После повторного grub2-mkconfig машина загрузилась, а в /proc/cmdline появились правильные значения (на ядре 7.2.11-200.fc44.x86_64).

Значения memmap автор сохранил в текстовый файл на USB-флешке, чтобы применить их заново при полной переустановке. По его оценке, это должно продержать ноутбук до прихода нового, а хочется надеяться, и дольше. Следующий шаг: убедиться, что всё нужное сохранено в резервной копии, и запустить btrfs check --fix, чтобы попробовать исправить метаданные файловой системы.

Ключевые факты

  • Lenovo X1 Carbon 2021 года под Fedora стал ронять вкладки браузера и переводить корневую файловую систему в режим «только чтение»; Memtest86+ нашёл ошибки памяти почти сразу.
  • Память распаяна на плате, заменить планку DIMM нельзя. Автор объясняет это погоней за тонкостью (DIMM-разъём добавляет около 6 мм) и, возможно, расчётом на покупку нового ноутбука.
  • Из двух вариантов обхода (badram и memmap) подошёл только memmap: badram, внешний патч для Debian/Ubuntu, а memmap, штатная функция ядра.
  • grub2-mkconfig подменил $0 в значениях memmap, и система не загрузилась; помогло решение из бага RedHat, вынести значения в переменную memmap_val через grub2-editenv.
  • Обход должен продержать ноутбук до прихода нового; дальше автор планирует резервную копию и btrfs check --fix.

Почему это важно

Заметка показывает, чем обернулась массовая распайка оперативной памяти. Раньше сбойную планку находили и меняли. Теперь дефект памяти в ноутбуке без разъёма DIMM по сути означает приговор для всей машины, если только не обойти плохие адреса программно. Автор называет эту тенденцию по-настоящему злой, особенно на фоне высоких цен из-за дефицита, и подозревает, что производители в том числе рассчитывают на покупку нового ноутбука после любой поломки (это его догадка).

Кому это важно

Владельцам ноутбуков с распаянной памятью, особенно под Linux: у них есть шанс продлить жизнь машине, а не выкидывать её. Также тем, кто выбирает новый ноутбук и сравнивает конструкции: автор отдельно называет Framework исключением среди ноутбуков. Пригодится администраторам Fedora и RedHat-подобных систем, где grub2-mkconfig может испортить значения со знаком $ в командной строке ядра.

Как это применить

Последовательность автора такая. Сначала запустить Memtest86+ (например, с флешки Ventoy) и получить список сбойных областей. Затем передать их ядру параметром memmap в формате длина$смещение: на Fedora работает именно он, а badram обычно есть только в дистрибутивах на основе Debian и Ubuntu. Значения в GRUB_CMDLINE_LINUX с $ ломаются при grub2-mkconfig, поэтому нужно сохранить строку значений в переменной grubenv memmap_val командой grub2-editenv, а в /etc/default/grub оставить memmap со ссылкой на эту переменную, затем снова выполнить grub2-mkconfig. Корректность видна в /proc/cmdline. Значения стоит сохранить отдельным файлом на случай переустановки. Автор переписывал адреса вручную с фотографии экрана, потому что сохранение из Memtest86+ на его образе Ventoy не сработало.

Можно ли доверять

Это личный блог, а не исследование: автор описывает собственный опыт и приводит фрагменты журналов и конфигурации, которые можно сверить. Объяснения причин (почему производители распаивают память), его мнение и догадки. Причина самого сбоя памяти в тексте не названа, как и то, насколько долго обход держится и прекратились ли падения после него. Итоговое «должно продержать до нового ноутбука» сам автор формулирует осторожно.

Риски и подводные камни

Обход через memmap не лечит железо: память остаётся неисправной, а исключённые области, лишь те, что нашёл тест. Автор отмечает, что некоторые ошибки проявляются только периодически, поэтому Memtest86+ запускают на несколько проходов. Ошибка в командной строке ядра может сделать систему незагружаемой: у автора так и вышло, пока он не посмотрел строку в меню GRUB. Уже случившиеся ошибки контрольных сумм BTRFS означают, что с метаданными файловой системы, возможно, нужно разбираться отдельно: автор перед btrfs check --fix собирается сделать резервную копию. Результат этой проверки в заметке не описан.

«Тенденция распаивать оперативную память в современных ноутбуках, настоящее зло, особенно в нынешние непростые времена высоких цен из-за дефицита.»

— автор блога blog.hardill.me.uk