Ядро не грузится на материнской плате Intel S3200SH ( http://www.intel.com/support/motherboards/server/S3200SH/ ). Загрузка доходит до "BIOS Data check successful!", после чего получается чёрный экран, а на материнской плате загораются все 4 имеющихся индикатора аварий.
На S3000AH ( http://www.intel.com/cd/products/services/emea/rus/server/boards/347628.htm ) поведение аналогичное.
C 2.6.27-alt2 тоже не работает, но по-дргому: #17992 Комментарий на всякий случай, вдруг что-то общее вылезет. C S3000AH 2.6.27 не проверял. И на critical поменяю. Хоть и хочется, чтобы на этих платах заработало, но, на них, свет клином не сошёлся...
Уберите параметр ядра vga=..., если он используется, и добавьте параметр earlyprintk=vga - с такими параметрами какой-то вывод есть? Ну и тот же вопрос - проблема на i586 или x86_64?
*** Bug 17992 has been marked as a duplicate of this bug. ***
Проблема на x86_64; я так полагаю, судя по результату, когда я с ядром ошибся в 17992, на i586 проблемы не будет. earlyprintk= в lilo в 4.1 отсутствует, но без vga= вывод на экран получился. Повторяющаяся строка DMAR:DRHD (flags: 0x0000001c)base: 0x0000feb010000000 для ovz ещё таймстамп выводится слева.
Created attachment 3089 [details] я этим ядром всё нормально
Created attachment 3090 [details] без acpi=off не грузится
Created attachment 3091 [details] без acpi=off не грузится
Почему-то думал, что имена файлов сохранятся... В общем, в аттачах dmesg-2.6.18-ovz-smp-alt24 dmesg-2.6.26-ovz-smp-alt0.3-acpi-off dmesg-2.6.27-std-def-alt2-acpi-off соответственно. Кстати, 2.6.27-std-def весьма ощутимо подтормаживает. Возможно, из-за acpi=off, как раз ?
kernel-image-std-def-2.6.25-alt8.M41.1 ведёт себя точно так же, как 2.6.26 и 2.6.27, а вот чужое, вбитое с nodeps, http://download.openvz.org/kernel/branches/2.6.22/current/kernel-2.6.22-ovz005.1.x86_64.rpm делает вид, что работает, но не может смонтировать /. Если dmesg от него интересен, могу попробовать понять, что ему не понравилось.
http://www.unsafe.ru/lakostis/RPMS/ALTLinux/kernel-2.6.24/repo/x86_64/RPMS.hasher/kernel-image-ovz-smp-2.6.24-alt2.x86_64.rpm не работает точно так же.
ftp://ftp.linux.kiev.ua/pub/Linux/ALT/people/led/Sisyphus/x86_64/RPMS.kernel/kernel-image-led-std-2.6.22-alt22.x86_64.rpm работает.
Created attachment 3092 [details] dmesg 2.6.22-led-std-alt22 с acpi, грузится
(In reply to comment #5) > Повторяющаяся строка > > DMAR:DRHD (flags: 0x0000001c)base: 0x0000feb010000000 https://bugzilla.redhat.com/show_bug.cgi?id=445553 Попробуйте загрузку с параметром intel_iommu=off (этот код появился в 2.6.24).
Видимо, оно. И, прямо, про S3200SH баг... Не умею, видимо, гуглить... Хотя индикаторы аварии так и не погасли.
Почему-то с темой про ovz на silicium@ висело...
Уважаемый новый мантейнер ядра ovz-smp в Сизифе! От всего сердца дарю тебе этот баг!
На 2.6.27-ovz-smp-alt3 баг присутствует.
(В ответ на комментарий №18) > На 2.6.27-ovz-smp-alt3 баг присутствует. Опция intel_iommu=off по-прежнему помогает?
(In reply to comment #19) Да, помогает.
(In reply to comment #20) > (In reply to comment #19) > > Да, помогает. Тогда я попробую зафиксить это в ovz-smp-2.6.26.
(In reply to comment #18) > На 2.6.27-ovz-smp-alt3 баг присутствует. alt11 не смотрел? PS: s/critical/normal/, см. http://www.altlinux.org/BugSeverityPolicy
(In reply to comment #22) > alt11 не смотрел? Не смотрел. С такими материнками сейчас только в работе техника есть, сложно время выбрать. Да и я так понял, что в alt11 это место не затрагивалось. > PS: s/critical/normal/, см. http://www.altlinux.org/BugSeverityPolicy Так это... critical: Пакет не работает (воспроизводимым образом). Ну да, на отдельно взятой серии материнок, но не работает же. :-)
Закрываю по аналогии с #17992 : BIOS S3200X38.86B.00.00.0048, 2.6.32-ovz-smp-alt4 всё работает. C S3000AH проверить пока не могу, но, надеюсь, там тоже должно обновлением BIOS решиться.
