Bug 17992 - kernel-image-std-def-2.6.27-alt2 не грузится на Intel S3200SH
Summary: kernel-image-std-def-2.6.27-alt2 не грузится на Intel S3200SH
Status: CLOSED FIXED
Alias: None
Product: Sisyphus
Classification: Development
Component: kernel-image-std-def (show other bugs)
Version: unstable
Hardware: all Linux
: P2 major
Assignee: Vitaly Chikunov
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on: 17971
Blocks:
  Show dependency tree
 
Reported: 2008-11-25 16:26 MSK by Sergey Y. Afonin
Modified: 2010-09-01 14:49 MSD (History)
5 users (show)

See Also:


Attachments
фото экрана загрузки (673.39 KB, image/png)
2008-11-25 16:26 MSK, Sergey Y. Afonin
no flags Details
std-def-2.6.30-alt10 (376.41 KB, image/gif)
2009-08-22 14:43 MSD, Sergey Y. Afonin
no flags Details
нормально загружающееся 2.6.18-ovz-rhel-alt2.M40.4 (22.38 KB, text/plain)
2009-08-22 14:50 MSD, Sergey Y. Afonin
no flags Details
dmesg 2.6.30 c intel_iommu=off (51.33 KB, text/plain)
2009-08-23 17:49 MSD, Sergey Y. Afonin
no flags Details
dmesg 2.6.30 c mem=2048M (49.90 KB, text/plain)
2009-08-23 17:50 MSD, Sergey Y. Afonin
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sergey Y. Afonin 2008-11-25 16:26:57 MSK
Created attachment 3088 [details]
фото экрана загрузки

Загрузка доходит строки "Clocksource tsc untable ...", после чего больше ничего не происходит. Хотя, есть реакция, если вытащить/вставить клавиатуру (в виде вывода сообщения input: AT Translated ... и т.д.). Возможно, этот баг, в каком-то месте, связан с  #17971, но, кроме наличия вывода на экран, с 2.6.27-alt2 не загораются и индикаторы аварии. Фотография в аттаче.
Comment 1 Sergey Vlasov 2008-11-25 17:32:46 MSK
Странная ошибка; покажите вывод команды

  rpmquery -f /lib/mkinitrd/*

И это i586 или x86_64?
Comment 2 Sergey Y. Afonin 2008-11-25 17:39:16 MSK
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.
Comment 3 Sergey Vlasov 2008-11-25 17:45:20 MSK
А откуда на x86_64 в ядре isapnp?  Похоже, загрузилось ядро i586, в результате ни один исполняемый файл не запускается.
Comment 4 Sergey Y. Afonin 2008-11-25 17:48:27 MSK
Блин, точно. 2.6.27 я же из своего кэша взял, а у меня i586...
Comment 5 Sergey Y. Afonin 2008-11-25 18:20:43 MSK
Нет, всё-таки, баг есть. Вот теперь, с ядром x86_64, поведение один в один, как в #17971 c ovz-smp-2.6.26. С "nolapic noapic acpi=off" грузятся оба.
Comment 6 Sergey Vlasov 2008-11-25 18:31:52 MSK
Тогда приложите вывод dmesg от нового ядра с этими параметрами, а также dmesg от самого свежего из имеющихся ядер, которое грузилось без таких параметров.
Comment 7 Sergey Y. Afonin 2008-11-25 18:47:57 MSK
По выводу без vga= в lilo совпадает. Подробности в #17971 сейчас напишу.

*** This bug has been marked as a duplicate of bug 17971 ***
Comment 8 Sergey Y. Afonin 2009-01-15 12:11:21 MSK
Наверное, я зря баг закрыл, как duplicate. Пакет-то другой и патч отдельно прикладывать надо...
Comment 9 Mikhail Gusarov 2009-01-15 13:33:07 MSK
*ping*, на всякий случай.
Comment 10 Michail Yakushin 2009-06-01 10:51:26 MSD
На текущих ядрах как оно себя ведёт?
Comment 11 Sergey Y. Afonin 2009-06-04 11:43:40 MSD
Пока не могу проверить: все компьютеры в работе, надо момент поймать. Выходные заняты на 3 недели вперёд. :-(
Comment 12 Michael Shigorin 2009-08-21 21:30:35 MSD
ping
Comment 13 Sergey Y. Afonin 2009-08-22 14:42:14 MSD
Проверил. На ovz-smp-2.6.27-alt8 без изменений, на std-def-2.6.30-alt10 стало немного по-другому: доходит до попытки монтирования root fs и реагирует на Ctrl+Alt+Del. dmesg с новым ядром сделать забыл. :-(
Comment 14 Sergey Y. Afonin 2009-08-22 14:43:25 MSD
Created attachment 3765 [details]
std-def-2.6.30-alt10
Comment 15 Sergey Y. Afonin 2009-08-22 14:50:26 MSD
Created attachment 3766 [details]
нормально загружающееся 2.6.18-ovz-rhel-alt2.M40.4
Comment 16 Sergey Vlasov 2009-08-22 18:07:54 MSD
(В ответ на комментарий №14)
> Created an attachment (id=3765) [details]
> std-def-2.6.30-alt10

Какие параметры ядра были указаны при загрузке?  Упоминание nommu_map_sg в выводе наводит на мысль, что используется параметр iommu=off (вместо, возможно, необходимого на этой машине intel_iommu=off).
Comment 17 Sergey Y. Afonin 2009-08-23 14:02:01 MSD
(In reply to comment #16)

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

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

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

С "intel_iommu=off" работает, я про это писал в #17971. Для 2.6.30 это тоже справедливо. То есть, это параметр - нормальный путь ? Тут проблема ещё есть неявная. Материнская плата имеет 4 индикатора аварии, если используется "intel_iommu=off", они все горят.
Comment 18 Sergey Vlasov 2009-08-23 15:01:17 MSD
(В ответ на комментарий №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 (когда загрузка прерывается из-за недоступности корня) они не светятся?
Comment 19 Sergey Y. Afonin 2009-08-23 15:56:06 MSD
> Хорошо бы снять сообщения ядра

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

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

Светятся, я не очень удачно написал. Не светятся они при загрузке 2.6.18. В процессе загрузки они то включаются, то выключаются, но где-то в середине загрузки ядра все гаснут.
Comment 20 Sergey Y. Afonin 2009-08-23 17:49:32 MSD
Created attachment 3770 [details]
dmesg 2.6.30 c intel_iommu=off
Comment 21 Sergey Y. Afonin 2009-08-23 17:50:42 MSD
Created attachment 3771 [details]
dmesg 2.6.30 c mem=2048M
Comment 22 Sergey Y. Afonin 2009-08-23 18:00:55 MSD
Не выдержал, сходил на работу. :-)
BIOS не совсем свежий: S3200X38.86B.00.00.0030. Есть уже R0048. Список изменений там только для 4x, в этом списке про iommu (если они его так же называют) не пишут. Нуль-модемного кабеля не было, так что, если вывод debug console ещё нужен, сделаю позже. С обновлением BIOS рисковать не хочется на рабочем компьютере, попробую заказать ещё таких материнок (оно и так надо - у R0030 список поддерживаемых процессоров мал, а тут апгрейд просится, так что BIOS апдейтить, видимо, надо).
Comment 23 Sergey Vlasov 2009-08-23 20:34:13 MSD
Как выяснилось, попытка разбора таблицы 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 в ядре.
Comment 24 Alexei V. Mezin 2010-02-18 22:12:55 MSK
(В ответ на комментарий №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++ для разных комбинаций опций и ядер. Если надо, приложу сюда.
Comment 25 Sergey Y. Afonin 2010-02-19 09:30:22 MSK
> На ядре ovz-smp-2.6.27 без опции intel_iommu=off все работает (VT/iommu в БИОСе
> включены), но часы отстают на 10 секунд за минуту!
> 
> При добавлении опции вроде бы все работает.

То есть, с intel_iommu=off  таймер начинает работать нормально ?
Comment 26 Alexei V. Mezin 2010-02-19 22:30:25 MSK
(В ответ на комментарий №25)

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

Да.

На праздниках постараюсь проверить, как себя ведет 2.6.30 или даже .32.
Comment 27 Michail Yakushin 2010-06-22 15:56:36 MSD
Проблема ещё актуальна?
Comment 28 Alexei V. Mezin 2010-06-22 22:30:11 MSD
(В ответ на комментарий №27)
> Проблема ещё актуальна?

Сервер в работе, под 2.6.27-ovz-smp-alt12. Вроде проблем нет. С новыми ядрами пока проверять не могу, ибо сервер 24*7, но в ближайшее время он станет посвободнее, и если надо, то смогу проверить что-нить.
Comment 29 Sergey Y. Afonin 2010-08-26 10:54:07 MSD
Появился сервер для опытов на некоторое время.

BIOS S3200X38.86B.00.00.0048, 2.6.32-std-def-alt20, в cmdline ничего особенного.
Индикаторы аварии не горят, часы идут точно (по крайней мере пока, за 10 минут работы). Если ничего нового за пару-тройку дней не вылезет, закрою баг.
Comment 30 Michael Shigorin 2010-09-01 13:54:17 MSD
И-ии? :)
Comment 31 Sergey Y. Afonin 2010-09-01 14:46:36 MSD
А, да. Всё работает.