Bug 17992

Странная ошибка; покажите вывод команды

  rpmquery -f /lib/mkinitrd/*

И это i586 или x86_64?

mkinitrd-busybox-1.3.2-alt1
mkinitrd-initramfs-3.0.5-alt1
klibc-utils-initramfs-1.5-alt1
module-init-tools-initramfs-3.3-alt0.5.pre6
udev-initramfs-118-alt1

Вообще, это я на 4.1 с ядрами на S3200SH экспериментирую. Возможно, я, тут, не совсем прав. Система x86_64.

А откуда на x86_64 в ядре isapnp?  Похоже, загрузилось ядро i586, в результате ни один исполняемый файл не запускается.

Блин, точно. 2.6.27 я же из своего кэша взял, а у меня i586...

Нет, всё-таки, баг есть. Вот теперь, с ядром x86_64, поведение один в один, как в #17971 c ovz-smp-2.6.26. С "nolapic noapic acpi=off" грузятся оба.

Тогда приложите вывод dmesg от нового ядра с этими параметрами, а также dmesg от самого свежего из имеющихся ядер, которое грузилось без таких параметров.

По выводу без vga= в lilo совпадает. Подробности в #17971 сейчас напишу.

*** This bug has been marked as a duplicate of bug 17971 ***

Наверное, я зря баг закрыл, как duplicate. Пакет-то другой и патч отдельно прикладывать надо...

*ping*, на всякий случай.

На текущих ядрах как оно себя ведёт?

Пока не могу проверить: все компьютеры в работе, надо момент поймать. Выходные заняты на 3 недели вперёд. :-(

ping

Проверил. На ovz-smp-2.6.27-alt8 без изменений, на std-def-2.6.30-alt10 стало немного по-другому: доходит до попытки монтирования root fs и реагирует на Ctrl+Alt+Del. dmesg с новым ядром сделать забыл. :-(

Created attachment 3765 [details]
std-def-2.6.30-alt10

Created attachment 3766 [details]
нормально загружающееся 2.6.18-ovz-rhel-alt2.M40.4

(В ответ на комментарий №14)
> Created an attachment (id=3765) [details]
> std-def-2.6.30-alt10

Какие параметры ядра были указаны при загрузке?  Упоминание nommu_map_sg в выводе наводит на мысль, что используется параметр iommu=off (вместо, возможно, необходимого на этой машине intel_iommu=off).

(In reply to comment #16)

> Какие параметры ядра были указаны при загрузке?

Всё по-умолчанию.

> Упоминание nommu_map_sg в выводе наводит на мысль, что используется
> параметр iommu=off (вместо, возможно, необходимого на этой машине
> intel_iommu=off).

С "intel_iommu=off" работает, я про это писал в #17971. Для 2.6.30 это тоже справедливо. То есть, это параметр - нормальный путь ? Тут проблема ещё есть неявная. Материнская плата имеет 4 индикатора аварии, если используется "intel_iommu=off", они все горят.

(В ответ на комментарий №17)
> Всё по-умолчанию.
Хорошо бы снять сообщения ядра через serial console (при загрузке с опциями debug console=ttyS0,115200). Либо можно попробовать загрузиться с опцией mem=2048M - это должно позволить продолжить работу даже при неработоспособном IOMMU.

Похоже, в коде инициализации IOMMU есть ошибка - в случае, если detect_intel_iommu() обнаруживает наличие аппаратного IOMMU, но затем intel_iommu_init() по каким-то причинам не проходит, переключение на использование swiotlb не выполняется, даже если его использование в текущей конфигурации необходимо.

> С "intel_iommu=off" работает, я про это писал в #17971. Для 2.6.30 это тоже
> справедливо. То есть, это параметр - нормальный путь ?
Для обхода ошибок - нормальный; кстати, обновлений BIOS с тех пор не было? Покажите ещё dmesg от 2.6.30 с intel_iommu=off.

> Тут проблема ещё есть неявная. Материнская плата имеет 4 индикатора аварии,
> если используется "intel_iommu=off", они все горят.
С этим сложно что-то сделать - надо знать, чем на самом деле управляются эти индикаторы. А что, при загрузке без intel_iommu=off (когда загрузка прерывается из-за недоступности корня) они не светятся?

> Хорошо бы снять сообщения ядра

Сделаю, только, опять, не быстро получится.

> А что, при загрузке без intel_iommu=off (когда загрузка прерывается из-за недоступности корня) они не светятся?

Светятся, я не очень удачно написал. Не светятся они при загрузке 2.6.18. В процессе загрузки они то включаются, то выключаются, но где-то в середине загрузки ядра все гаснут.

Created attachment 3770 [details]
dmesg 2.6.30 c intel_iommu=off

Created attachment 3771 [details]
dmesg 2.6.30 c mem=2048M

Не выдержал, сходил на работу. :-)
BIOS не совсем свежий: S3200X38.86B.00.00.0030. Есть уже R0048. Список изменений там только для 4x, в этом списке про iommu (если они его так же называют) не пишут. Нуль-модемного кабеля не было, так что, если вывод debug console ещё нужен, сделаю позже. С обновлением BIOS рисковать не хочется на рабочем компьютере, попробую заказать ещё таких материнок (оно и так надо - у R0030 список поддерживаемых процессоров мал, а тут апгрейд просится, так что BIOS апдейтить, видимо, надо).

Как выяснилось, попытка разбора таблицы DMAR выполняется даже при использовании intel_iommu=off - следующий кусок присутствует в dmesg в любом случае:

DMAR:Host address width 40
DMAR:DRHD (flags: 0x00000001)base: 0x00000000feb00000
DMAR:Invalid 0-length structure
DMAR:parse DMAR table failure.

Т.е., BIOS предоставляет ошибочную таблицу DMAR; в ядрах до 2.6.29 такая ошибка приводила к зависанию при загрузке, теперь это исправлено, однако автоматически обработать эту ситуацию всё равно не получается. Проблема в том, что разбор содержимого таблицы DMAR (когда обнаруживается ошибка) выполняется слишком поздно, чтобы после обнаружения ошибки инициализировать SWIOTLB, в результате ядро оказывается без какого-либо IOMMU вообще, что при наличии RAM за пределами первых 4 ГБ адресного пространства приводит к невозможности нормальной работы с устройствами, поддерживающими только 32-разрядную адресацию. Можно разве что попытаться перенести анализ содержимого таблицы DMAR на более раннюю стадию (из intel_iommu_init() в detect_intel_iommu(), когда ещё есть возможность инициализации SWIOTLB), но для этого придётся дописать дополнительный кусок кода, дублирующий уже существующий (полную инициализацию DMAR в этот момент выполнить нельзя, поскольку ещё не выполнена инициализация PCI - из-за чего, кстати, всё равно не удастся отловить все возможные ошибки в таблице, поэтому останется возможность получить неработоспособную конфигурацию).

Кстати, возможно, в BIOS есть настройки, влияющие на доступность таблицы DMAR (например, включение Intel VT-d) - можно попробовать их отключить там вместо отключения опцией intel_iommu=off в ядре.

(В ответ на комментарий №22)
> BIOS не совсем свежий: S3200X38.86B.00.00.0030. Есть уже R0048. 

Напишу сюда, чтоб не потерялось.

Плата S3210SHLC.

БИОС версии
S3200X38.86B.00.00.0048
05/22/2009 

Система p5, 64бит, 4Гб памяти.

На ядре ovz-smp-2.6.27 без опции intel_iommu=off все работает (VT/iommu в БИОСе включены), но часы отстают на 10 секунд за минуту!

При добавлении опции вроде бы все работает. Есть dmesg для 27 и 30 ядра с разными опциями и состоянием БИОСа, есть результаты работ bonnie++ для разных комбинаций опций и ядер. Если надо, приложу сюда.

> На ядре ovz-smp-2.6.27 без опции intel_iommu=off все работает (VT/iommu в БИОСе
> включены), но часы отстают на 10 секунд за минуту!
> 
> При добавлении опции вроде бы все работает.

То есть, с intel_iommu=off  таймер начинает работать нормально ?

(В ответ на комментарий №25)

> То есть, с intel_iommu=off  таймер начинает работать нормально ?

Да.

На праздниках постараюсь проверить, как себя ведет 2.6.30 или даже .32.

Проблема ещё актуальна?

(В ответ на комментарий №27)
> Проблема ещё актуальна?

Сервер в работе, под 2.6.27-ovz-smp-alt12. Вроде проблем нет. С новыми ядрами пока проверять не могу, ибо сервер 24*7, но в ближайшее время он станет посвободнее, и если надо, то смогу проверить что-нить.

Появился сервер для опытов на некоторое время.

BIOS S3200X38.86B.00.00.0048, 2.6.32-std-def-alt20, в cmdline ничего особенного.
Индикаторы аварии не горят, часы идут точно (по крайней мере пока, за 10 минут работы). Если ничего нового за пару-тройку дней не вылезет, закрою баг.

И-ии? :)

А, да. Всё работает.