посмотри как у тебя винт определяется биосом
что имеется в виду - Large, LBA ...
если винт небольшой, то он должен определяться как LBA
я думаю что в этом проблема

Хм, IMHO - любой винт должен определяться (или ты должен сказать, чтоб определялся) как LBA - ибо остальное - от лукавого и надо иметь очень обоснованные доводы, чтобы поставить винт в Large.

у этих (*#%^*%^ матерей есть пара очень приятных опций в БИОСе, с которыми NTевые оси просто тупо несовместимы. Что-то насчет ACPI (или APIC?) и "PnP OS Installed". Вот поиграйтесь ими и скажите что получилось.

А я поддерживаю версию о размере винта, вернее умении матери работать с неким данным ей размером. Такая грабля была когда мать (soltek sl-75kv+) некорректно работала с винтом в 120Gb. Она не висла при детекте, показывала разделы, но и ничего хорошего не получалось. 98 винда ставилась, XP - нет. Вылечено было прошивкой свежайшего биоса.

Спасибо всем, кто откликнулся. Дополнительная инфа: пробовал винт на 2 Г и на 40 Г ( оба определялись как LBA), пробовал АТА-raid controller от TEKRAM - синдром тот же. Еще вот чего: когда перепрошивал BIOS, (я это делал на этой мамке два раза) то первый раз Awdflash 776, скачанный от PC Partner перешил SST 49LV002F без замечаний, второй раз я перешивал Uniflash'ем ( с bootблоком) и тот, при верификации, дал ошибку. Сменил флешку, прошил программатором - те же грабли. Поэтому вопрос (я надеюсь, Вы понимаете ход моей мысли): как при загрузке образ BIOS переносится в ОЗУ? Кто это делает? Ведь не процессор же? А кто - мультик? Это второй самостоятельный процессор на маме.

Мать - PC Partner 815 EBAS3, BIOS скачан с сайта производителя и перепрошит... виснет или после сообщения: Werifying DMI pool просто висит. Memtest проходит без ошибок.

Да у Вас, батенька, проблема с BIOS в том, что область ESCD, где раположен DMI Pool, просто запорчена при предыдущем старте. И кстати, а Memtest каким боком в этой ситуации??? Вы бы еще и Sandra запустили. Так, на всякий случай :)

... когда перепрошивал BIOS, (я это делал на этой мамке два раза) то первый раз Awdflash 776, скачанный от PC Partner перешил SST 49LV002F без замечаний, второй раз я перешивал Uniflash'ем ( с bootблоком) и тот, при верификации, дал ошибку. Сменил флешку, прошил программатором - те же грабли.

Именно "грабли", как Вы метко заметили, и возникли после экспериментов с прошивкой. Эти самые "грабли" и вызывают останов на верификации DMI Pool...

Поэтому вопрос (я надеюсь, Вы понимаете ход моей мысли): как при загрузке образ BIOS переносится в ОЗУ? Кто это делает? Ведь не процессор же? А кто - мультик? Это второй самостоятельный процессор на маме.

Ход Вашей мысли непонятен. Особенно в связи с дерзким предположением, что BIOS в ОЗУ переносит не процессор. Смею Вас разочаровать. Именно процессор, а не "мультик" исполняет ассемблерный код, задача которого а) настроить регистры чипсета, б) распаковать BIOS в ОЗУ в) перенасторить регистры чипсета на нужные адреса. В детали вдаваться не стоит, но все же нужно отметить, что ESCD - неупакованная область, и она находится только во Flash ROM и в ОЗУ не переносится.

Кроме того, и это самое главное, Ваш вопрос уместно бы смотрелся не в разделе "Ремонт плат", а в разделе "Перешивка BIOS" или что-то в это роде, связанное с наладкой системы.

Скорее всего, прав Root.

И тогда, ежели уж никак не получается воткнуть систему с различными настройками этой вонючей ACPI и P&P OS (Plug and Pray, как ее правильно назвали сами американцы), или просто не хочется тратить силы и время на 4 варианта комбинации - можно тупо поставить нужную NT-подобную ось на другую мать, и просто перенести винт на эту. Правда, для этого надо выполнить ряд условий:

1) Ставить систему лучше на как можно более "старую" плату, с минимумом "наворотов" на борту. Бессмысленно - на что-то из последних четвертых пней. Перенос легко идет снизу вверх и очень тяжело - сверху вниз.

2) Систему надо сделать "толерантной" к смене материнки. Как такое достигается - описано много где, Вам же будет достаточно тупо скачать парочку файлов:

_http://www.sarov.ru/files/idedrivers.zip
_http://www.sarov.ru/files/mergeide.reg

Reg-файл выполнить, а содержимое архива после распаковки поместить в WinNT\System32\Drivers, оставляя там более свежие имеющиеся драйвера.

3) После "приживления" системы на "припадочной" матери, в Девайс Манагере убить... например, шину PCI, предварительно на всякий случай скопировав файлы реестра в какое-нить хорошее место. Такое действие полезно для правильного переопределения P&P Биоса, тех самых функций ACPI и прочей дряни.

По крайней мере, нам практически всегда удавалось победить упомянутые глюки подобным способом.

Все вышесказанное, однако, справедливо лишь в случае, ежели машинка нормально загружается хотя бы под ДОС, и выдерживает под ним сколь угодно перезагрузок. Ежели уже перестала, после многократных упражнений с перепрошивкой - тогда прав Icbook.

После "приживления" системы на "припадочной" матери...

... она снова повиснет при следующей перезагрузке, т.к. либо DMI Pool "кривой", либо плата по разным причинам не может перезаписать Flash ROM, что бы внести изменения в этот самый DMI Pool. Предположительно, конечно.

Я, однако, предполагаю, что у товарища просто криво определяется "железо" чересчур умной Хрюшей. Сразу после сообщения ...DMI POOL... должна начинаться загрузка системы, но... по какой-то идиотской причине даже NTLDR нормально отработать неспособна.

На такие грабли наступать приходилось, как правило, на второпневых матерях, особенно с дуальным питанием, особенно при блоке питания АТ, особенно ежели Биос у нее гордо объявляет себя P&P (см. выше :mrgreen: ).

По нашим (возможно, и неверным) предположениям, это происходит потому, что "умная" Хрюша не может отказаться от УПРАВЛЕНИЯ всеми функциями материнки даже на стадии после предустановки, когда еще не все драйвера устройств установлены. Тут-то, на стадии "раздачи слонов", и возникает затык (видимо, из-за безнадежной кривизны той самой функции P&P Биоса, на который Хрюша легкомысленно понадеялась). А вот если установить на это место хоть какие-нибудь драйвера, даже чужие... все прокатывает нормально.

Сразу после сообщения ...DMI POOL... должна начинаться загрузка системы, но... по какой-то идиотской причине даже NTLDR нормально отработать неспособна.
...
По нашим (возможно, и неверным) предположениям, это происходит потому, что "умная" Хрюша не может отказаться от УПРАВЛЕНИЯ всеми функциями материнки даже на стадии после предустановки, когда еще не все драйвера устройств установлены. Тут-то и возникает затык. А вот если установить на это место хоть какие-нибудь драйвера, даже чужие... все прокатывает нормально.

Вполне возможны оба варианта, но, как хорошо заметил наш коллега совсем по другому поводу "некая религиозная догма в моем подсознании заставляет меня" предполагать BIOS problem, особенно после экспериментов вопрошающего с Uniflash.
:)

To geodimetr.
Кстати, наш спор может решить простой эксперимент. Если в процессе инсталляции, например, WinXP потребуется перезагрузка, в процессе которой пользователь войдет в CMOS Setup и укажет, что грузиться с FDD, а платформа повиснет на DMI Pool, то прав я. Если загрузка с FDD "прокатит", то прав geodimetr.