Не первый и не десятый уже по счету раз сталкиваюсь с одной и тоже проблемой: компьютеры и ноутбуки на базе АМД без каких-либо внешних причин тормозят при работе. Заметил случайно - на ноутбуке по привычке, под Live-средой для проверки производительности был запущен простенький тест WinRAR'а ("Тест быстродействия"), предоставивший, помимо статистики нагрева, цифирки производительности подсистемы процессор-память-чипсет. Не важно, сколько он выдал - я мимоходом запомнил значение и занялся текучкой - чисткой, переустановкой, настройкой. И по концовке, через пару часов вошканья, я зачем-то повторил тест уже под свежеустановленной ОС. И о..л (оторопел, а не то, что вы подумали ;)) - цифра была раза в два ниже. При том, что версия WinRAR'а была та же - подобная разница в попугаях возможна либо при радикальной разнице конфигураций, либо при существенных проблемах в текущей. Но ведь цифра-то была, ноутбук мог под Live'кой - так откуда такая разница? Неужто почистил криво... но датчики-то перегрева не фиксируют же? Для проверки снова загрузился в ту же среду, запустил тот же тест - получил исходную цифру, без изменений. Снова перегрузился в Windows - снова тот же падёж производительности... причем, присмотревшись, заметил, что действительно как-то система реагирует замедленно - как говорят, "лагает". Заглянул в диспетчер задач - нашел источник проблемы: процесс "Системные прерывания" в простое грузит процессор до 30%, под любой нагрузкой вроде обычного запуска приложения - до 50%. Но с чего?

Сделав неверный вывод о том, что причина кроется в свежеустановленных обновлениях Windows, коих пришло несколько десятков, я потратил пол-часика на изучения того, были ли какие-то из них критические и относящиеся к производительности, удалил пару подозрительных - бесполезно. Что ж, времени куча, разбираться в глюке не охота - быстрее будет перебить систему, что и делаю. Перебил, сразу проверил WinRAR - "о, оно, результат даже чуть выше, чем в Live'ке, но в пределах погрешности - значит, дело было действительно в обновлениях",- подумал я и решил обновления не ставить. Установил все остальное, настроил ПО и после одной из финальных перезагрузок зачем-то зашел в диспетчер задач... в котором снова встретил все тот же процесс "Системные прерывания", занимающийся тем же безобразием - 28% процессора. Да что за ять, я же обновления не ставил? И изначально в системе все было нормально - что же я изменил\установил, что эта гадость снова проявилась?

Поскольку я уже был зол, я пошел за пивом и перебил систему в третий раз. Снова на чистую проверил результат теста - все ок, значение адекватное. Стал думать: это не ПО - его набор одинаков как на начале свежеустановленной системы, так и в ее конце. Что меняется, если не обновления? Драйвера, точно. А кто ж из них-то?

Стал ставить по очереди, начиная с самых подозрительных: всякие ATK, программы поддержки функций клавиатуры (FN+) и пр., каждый раз перегружая машину и запуская тест. Не оно. Значит, драйвера. Тогда наоборот - по минимальной вероятности: драйвер мыши, звука, видеокарты - мимо. Хм. А что остается? Картридер? Чипсетные? Так их тут всего ничего - SM BUS, еще парочка, AMD SATA да и все. Блин, я же поставил уже все, что было в предыдущие разы - и никаких тормозов, злобный процесс ничего не грузит - но так же не бывает? С горя выбираю к установке все оставшиеся из упомянутых, ставлю, перегружаю систему - и "Здравствуйте, я ваша тётя" - заактивничал процесс-то, снова грызет CPU... но ёшкин же кот, кто из этих трех-то?

Не буду затягивать интгригу - виновником оказался драйвер AMD SATA. Причем, проверял как на Windows 7 32бита, так и на Windows 8.0 x64, с родными драйверами и свежайшими с сайта АМД - суть одна: после установки драйвера и последующей перезагрузки - система работает так, как будто ей гири к ногам привязали.

Для придирчивых - конкретика из последнего:

• ноутбук HP 635 (LH487EA#ACB)
• устройство PCI\VEN_1002&DEV_4391&SUBSYS_3577103C&REV_00
• наименование AMD SATA Controller, режим AHCI
• версия сбойного драйвера AMD 22.01.2014 1.3.1.211
• версия несбойного (проверено) AMD 04.10.2011 1.2.1.317

В данном случае новый (сбойный) драйвер был установлен пакетом SAM Drivers 14.11, рабочий - средствами программы SkyIAR из среды Live. В принципе, исходя из вышеозвученного, родной драйвер Windows также к сбою не приводит - то бишь, достаточно следить за тем, чтоб драйвер на САТА не установился либо контролировать отсутствие указанных симптомов (падёж производительности при загрузке процессора процессом "Системные прерывания").

Вроде все, чем хотел поделиться по данному вопросу)