Created attachment 3088 [details] фото экрана загрузки Загрузка доходит строки "Clocksource tsc untable ...", после чего больше ничего не происходит. Хотя, есть реакция, если вытащить/вставить клавиатуру (в виде вывода сообщения input: AT Translated ... и т.д.). Возможно, этот баг, в каком-то месте, связан с #17971, но, кроме наличия вывода на экран, с 2.6.27-alt2 не загораются и индикаторы аварии. Фотография в аттаче.
Странная ошибка; покажите вывод команды 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 минут работы). Если ничего нового за пару-тройку дней не вылезет, закрою баг.
И-ии? :)
А, да. Всё работает.
