Проверить CPU 1
Mikhail Ramendik
Хотя время тестирования пока не было достаточным, но есть подозрение,
что при использовании cpuset-hack ("все процессы, какие можно, зажать
на CPU0 перед запуском init) зависания отсутствуют.
Мне хотелось бы проверить - есть ли аппаратные проблемы с CPU 1. Если
их нет, то (при условии что действительно "помогло") речь похоже о
ядерной проблеме на чипсете SiS, и это повод искать желающих её
ловить. Возможно написанием на LKML.
Но сначала таки надо проверить. А как?
Известный мне метод - винда, prime95, сутки. Но у меня не получается
оcвободить этот компьютер на сутки.
Если бы можно было на Линуксе взять такой же stress testing и
привязать с CPU 1, оставив юзерские задачи на CPU 0, то вопрос бы
решился. (Конечно, производительность потеряется за счёт доступа к
памяти, но это приемлемо).
Соответственно, вопрос: есть ли на Линуксе надёжный и общепринятый
метод CPU stress testing, на результаты коего можно ссылаться на том
же LKML в смысле "процессор проверен и работает"? Проверять надо и кэш
тоже, разумеется.
--
Yours, Mikhail Ramendik
Unless explicitly stated, all opinions in my mail are my own and do
not reflect the views of any organization
Alexander Danilov
> Всем привет!
>
>
> Соответственно, вопрос: есть ли на Линуксе надёжный и общепринятый
> метод CPU stress testing, на результаты коего можно ссылаться на том
> же LKML в смысле "процессор проверен и работает"? Проверять надо и кэш
> тоже, разумеется.
>
apt-get install cpuburn
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/4E6D053E...@gmail.com
Mikhail Ramendik
>> Соответственно, вопрос: есть ли на Линуксе надёжный и общепринятый
>> метод CPU stress testing, на результаты коего можно ссылаться на том
>> же LKML в смысле "процессор проверен и работает"? Проверять надо и кэш
>> тоже, разумеется.
>>
>
> apt-get install cpuburn
А два мегабайта L2 кэша тоже будут тестироваться?
Mikhail Ramendik
> Мне хотелось бы проверить - есть ли аппаратные проблемы с CPU 1. Если
> их нет, то (при условии что действительно "помогло") речь похоже о
> ядерной проблеме на чипсете SiS, и это повод искать желающих её
> ловить. Возможно написанием на LKML.
Погонял в результате mersenne mprime в режиме stress test, загнав в
cpuset где только CPU 1.
Во время работы теста взаимодействие с системой было явно замедленной
(задержки при отрисовке окон и т.д.), несмотря на то что все остальные
задачи - на CPU 0. Вероятно, это из-за падающих на CPU 1 всез
прерываний?
Примерно через полчаса после запуска теста система зависла. При том
что до этого более суток не висла (с тех пор как были найдены эти
настройки). Тест работал от юзера. Оопсов перед зависанием не было.
Похоже, нагрузка CPU 1 каким-то образом вешает систему. Даже если там
только юзерские задачи. Похоже то ли на хитрую аппаратную
неисравность, то ли на хитрую чипсетную штуку. И пока я не потестирую
"сутки prime95 под виндой", понять, что из этого - не получится.
Но посмотрим ещё несколько суток - останется ли система, не
использующая CPU 1 без необходимости, стабильной. И не начнутся ли
зависы про просмотре HD видео (раньше не было, но я включил
провацирующую зависы опцию no_hz=off).