На 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 решиться.