Битый Южный Мост .

ок. "Включен постоянно" сделал - всё как было , так и осталось.
Так. это надо как-то подумать, написать-то я скорее всего смогу эквивалент, только вот я незнаком с системным программированием в XP. Делать что-то типа boot-loader надо ?
Или биос ковырять ?

 

просто в spec.update'е к ICH4-M упоминали о баге с переходом в/из S3/S4... который как раз мог вызвать неработоспособность USB, но это похоже не оно.

В идеале конечно бы лучше прямо в код биоса влепить, хоть это и долго и нудно. Собственно дописать надо вот этот код, если без вырубания UHCI:

Код (Text):

1. 50                           push      ax
2. 52                           push      dx
3. BAF80C                       mov       dx, 0CF8
4. 66B804EF0080                 mov       eax, 8000EF04
5. 66EF                         out       dx, eax
6. BAFC0C                       mov       dx, 0CFC
7. ED                           in        ax, dx
8. 2500F8                       and       ax, 0F800
9. 0D0004                       or        ax, 0400
10. EF                           out       dx, ax
11. BAF80C                       mov       dx, 0CF8
12. 66B8F0F80080                 mov       eax, 8000F8F0
13. 66EF                         out       dx, eax
14. BAFC0C                       mov       dx, 0CFC
15. 66ED                         in        eax, dx
16. 660FBAE81F                   bts       eax, 1F
17. 66EF                         out       dx, eax
18. 5A                           pop       dx
19. 58                           pop       ax

лично я бы селил его в ntldr. Там есть фрагмент, проверяющий размер _базовой_ памяти и выводящий сообщение об ошибке в случае нехватки -- вот на его место, благо не шибко нужен. В моем ntldr этот код аккурат на 1A00h -- 1A3Fh. Повезло, что не ICH6 оказался -- в Root Complex из реалмоде напряжно было бы писать, пришлось бы код дописывать к PM32-части ntldr (которая проверяется на целостность кстати ) или еще как-нибудь извращаться.
Вот образец: http://webfile.ru/1315608
-- от XP SP2, хз, есть ли между ними совместимость, но по идее должна быть. Перед экспериментами весьма желательно сохранять оригинал. Я его не проверял -- пока нет ICH4* под рукой.
add:

кстати возможно что кого-то всё таки с собой за компанию и взял.

 

Слил я ntldr , заменил, благо тоже SP2 с тем же размером файла...
Перегрузился.
Минуту тупо смотрел на загрузку ЦП 0% и температуру 40 С.
Открыл папку system32 - открылась мухой, раньше по 20 сек надо было ждать.
Короче - это РАБОТАЕТ !!!!!!!!!!!
_ВС_ - ты просто БОГ в программировании, не побоюсь этого слова!
Огромное спасибо !!! Надо бы это решение народу подкинуть, тем бедолагам, кого сервисные центры грузят на деньги, типа "выхода нету другого". Можно ?

зы.
Я как-то раз тоже подобным образом спас тысячи маленьких плАток с 8-битным RISC камушком от свалки из за неверного алгоритма инициализации....

 

да, конечно можно.

По снапшоту кстати UHCI выглядит вменяемо, не пробовал подключать USB-девайсы? По идее UHCI и EHCI в апп.реализации в южнике должны зависеть друг от друга, но вдруг заработает (на неполной скорости ессно), чем черт не шутит?

 

_BC_
Да уж...
Снимаю шляпу.

 

Кстати даж не пробовал, но в устройствах теперь видится только 3 концентратора USB.
После праздников отпишусь

 

не видит USB

Тут кстати вопросец . ВОт из распиновки ЮМ :
CLK48 , Type - Input
48 MHz Clock: This clock is used to run the USB controllers. It runs at 48 MHz. This clock is permitted to stop during S3 (or lower) states

А кто генерит эти 48 МГц интересно, и можно ли как-то проверить присутствие тактовой частоты на USB, может в каких регистрах инфа пишется ?

 

отсюда вывод, что сдохла общая для UHCI и EHCI часть. В принципе, раз уж UHCI на уровне регистров ведет себя мирно, то его можно и не отрубать, т.е. оставить всё как есть.

они все по идее от одного тактового генератора приходят. С большой долей вероятности эти 48МГц могут еще до кучи использоваться и для Super I/O чипа, а уж отсутствие CLK на нем было бы _очень_ заметно.

 

не тут-то было, при отключении EHCI-контроллера port routing не сбрасывается с EHCI. В результате имеем следующее: при подключении USB-устройств питание на порты подается, а вот самих девайсов UHCI-контроллер не увидит. Надо таки лезть в PM32-часть ntldr'а. ;(

 

переместил код в PM32-часть и добавил сброс port routing перед отключением (из-за чего и пришлось лезть в протмоду, ибо MMIO). Попробуй этот: http://webfile.ru/1335978 Предыдущая версия после отключения EHCI из-за port routing'а делала невозможной любую теоретическую работу UHCI с девайсами, поэтому результат был заранее предопределен. Не факт, конечно, что этот дохлый EHCI-контроллер захочет отдавать ownership, но, тем не менее, попробовать стоит.

 

не прокатило %-) но ничего страшного, благо PCMCIA->USB ст0ит 400 рублей.
Главное, что этот метод оживляет машину с XP.
_BC_ , ещё раз огромный сенкс !!! Утер ты нос многим, я тебе скажу ))

 

ну по крайней мере убедились, что UHCI не минула участь EHCI. Шанс на рабочий UHCI был ничтожным -- для этого надо было, чтобы
а) EHCI сдох независимо от UHCI
б) + при этом в EHCI уцелела часть, отвечающая за переключение port routing EHCI -> UHCI.

-- слишком тяжелые требования даже по отдельности. Даже если UHCI таки уцелел -- не имея возможности отобрать контроль у EHCI, результат будет все равно что UHCI тоже сдох.