From: Валерий Абросимов <abrosimovATyandexDOTru>
Newsgroups: linuxshop.ru
Date: Mon, 14 Oct 2003 14:31:37 +0000 (UTC)
Subject: Стабильность оборудования в Linux
Daniel Robbins <drobbins@gentoo.org>, 1.03.01.
Перевод - Валерий Абросимов <abrosimovATyandexDOTru>
Содержание:
- Загрузка процессора
- Возможные проблемы с процессором
- Восстановление вашего процессора
- Критический тест процессора
- Проверка памяти
- Симптомы плохой памяти
- Разрешение проблем с памятью
- Источники
Многие из нас в мире Linux встречались с разными проблемами
оборудования. Как часто мы, установив любимый дистрибутив,
скомпилировав и установив дополнительные приложения, узнавали, что
наше оборудование имеет фатальный баг? Симптомами этого является либо
редкие segmentation faults, повреждения данных, зависания, либо
непонятные потери данных - все это приводит к тому, что настроенная
система Linux с трудом удерживается на плаву.
В этой статье мы заглянем в глубину того, как определить сбои в работе
процессора и оперативной памяти - что позволит вам вовремя заменить
дефективные части пока они не довели дело до серьезной аварии. Если вы
испытываете проблемы с нестабильностью работы и думаете, что они
связаны с оборудованием, я рекомендую вам проверить и процессор и
память чтобы убедиться, что они работают нормально. Однако, даже если
вы не имеете таких проблем, все равно стоит периодически проверять
работу этих узлов. Делая это, вы можете определить многие проблемы
оборудования, которые могли привести к потере данных в самое
неожиданное время и многочасовым поискам источника проблемы.
Соответствующие приложения помогут вам избежать головной боли, а если
ваша система пройдет тесты, то вы будете спокойны и уверены, что с ней
все в порядке.
Загрузка процессора
-------------------
Если у вас ужасно некачественный процессор, ваша машина не сможет
загрузить Linux или проработает всего несколько минут перед тем, как
зависнуть. Процессор в таком состоянии легко определить потому, что
симптомы явны. Но есть множество скрытых дефектов, которые определить
не так легко; обычно менее явные ошибки приводят либо к зависанию
машины каждый раз по непонятной причине, либо к неожиданным процессам
в самой машине. Большинство нестабильностей в процессоре можно
определить, давая ему задание, которое приводит к нагреву камня и
проявляет все слабые места.
Давайте взглянем не некоторые стресс-тесты процессора. Вы можете быть
удивлены услышать, что один из лучших тестов стабильности процессора
встроен в Linux -- это компилирование ядра. Компилятор gcc - это
отличная утилита для проверки общей стабильности процессора, а
компилирование ядра сильно использует gcc.
Создав и запустив следующий скрипт из /usr/src/linux, вы дадите вашей
машине очень мощный стресс-тест:
The cpubuild script
#!/bin/bash
make dep
while [ "foo" = "foo" ]
do make clean
make -j2 bzImage
if [ $? -ne 0 ] then echo OUCH OUCH OUCH OUCH
exit 1
fi
done
Вы заметили, что этот скрипт повторно компилирует ядро. Причина этого
проста - некоторые процессоры имеют внутренние ошибки, позволяющие им
95% времени отлично компилировать ядро, но после пяти или более
компилирований процессор нагревается до уровня, при котором он может
стать нестабильным.
В приведенном скрипте обязательно установите опцию -j с числом на один
большим, чем количество процессоров на вашей системе; другими словами,
используйте "2" для одно-процессорных, "3" для двух-процессорных и
т.д. машин. Опция -j указывает на необходимость компилирования ядра
параллельно, чтобы всегда как минимум один процесс gcc был в работе
после компилирования каждого исходного файла - так вы создадите
максимальную нагрузку на процессор. Если вы не собираетесь работать на
своем компьютере вечером, то запустите этот скрипт и позвольте машине
перекомпилировать ядро на протяжении нескольких часов.
Возможные проблемы с процессором
--------------------------------
Если этот скрипт отлично выполняется в течение нескольких часов,
поздравляю! Ваш процессор прошел первый тест. Однако, возможно, что
этот скрипт закончится неожиданно. Как узнать, у вас проблемы с
процессором или что-то еще? Если gcc выдаст ошибку наподобие этой, то
скорее всего у вас проблемы с процессором:
gcc: Internal compiler error: program cc1 got fatal signal 11
На данный момент у вас три возможности, чтобы определить состояние
вашего процессора:
* Если вы введете "make bzImage", чтобы восстановить компилирование
и процесс прервется на том же файле, продолжайте вводить "make
bzImage" раз за разом. Если после десяти попыток процесс все равно
прекращается на этом файле, то проблема скорее всего в ошибке
компилятора, которая проявляется таким образом. Однако, в наши дни
компиляторы достаточно стабильны, так что наврядли это произойдет.
* Если вы введете "make bzImage" чтобы восстановить компилирование и
получите еще один signal 11 немного позже, то наиболее вероятно
ваш процессор не в порядке.
* Если вы введете "make bzImage" чтобы восстановить компилирование и
ядро скомпилируется успешно, это не значит, что с вашим
процессором все в порядке. Обычно, это означает, что ошибки есть,
но они проявляются только, когда камень нагревается до
определенной температуры (процессор становится горячее, когда он
используется в течение долгого периода времени, выполнение
нескольких компиляций ядра может привести его к такому
критическому состоянию).
Восстановление вашего процессора
--------------------------------
Если ваш процессор испытывает периодические сбои при тяжелой нагрузке,
то это не значит, что он неисправен - возможно, что он просто
недостаточно охлаждается. Вот несколько вещей, которые вы можете
проверить:
* Подключен ли вентилятор на вашем процессоре?
* Не забит ли он пылью?
* Вращается ли (и вращается ли с достаточной скоростью), когда вы
включаете питание компьютера?
* Правильно ли установлен радиатор на процессоре?
* Есть ли термопаста между радиатором и процессором?
* Достаточная ли вентиляция в самом корпусе компьютера?
Если все кажется в порядке, то вам стоит повторить тест с компиляцией
ядра с с открытым корпусом. Позвольте ядру компилироваться в течении
около пяти минут, а затем дотроньтесь до внешних металлических частей
блока питания чтобы заземлить себя. Затем, осторожно проверьте
температуру радиатора кончиком пальца. Если он очень горячий, то
скорее всего мощность вашего радиатора/вентилятора недостаточна для
такого процессора. В этом случае, замените вашу систему охлаждения -
надеюсь, вы не нанесете при этом процессору повреждений и он будет
продолжать работать.
Критический тест процессора
---------------------------
Тест с компилированием ядра - это отличный способ проверить
стабильность процессора, но есть еще более экстремальный тест, который
вы можете захотеть использовать. Я оставил его напоследок, потому что
если ваш процессор слабо охлаждается, то этот тест может перегреть его
и теоретически нанести ему серьезные повреждения. Этот тест
предназначен для систем, которые прошли тест с компилированием без
проблем. Если ваш процессор хорошо охлаждается, то он должен пройти и
этот тест, а если не пройдет, то вам нужно добавить ему охлаждения.
Для выполнения моего экстремального теста процессора, сначала нужно
посетить страницу Lm_sensors (смотри Источники) и загрузить пакет
с lm_sensors. Тарболл с исходниками содержит различные модули для
ядра, которые позволяют отслеживать параметры, доступные почти во всех
современных материнских платах. После установки пакета и загрузки
соответствующих модулей (используйте скрипт prog/detect/sensors-detect
для определения необходимых), вы увидите несколько новых файлов и
директорий в /proc/sys/dev/sensors. Эти файлы содержат полезную
информацию о скорости вращения вентилятора процессора, температурах
процессора и материнской платы, напряжения питания, все это
обновляется в реальном времени. Я рекомендую вам сконфигурировать этот
пакет чтобы скомпилировать его как модуль и использовать скрипт
sensors-detect для определения какие модули загружаются при включении
компьютера.
После загрузки модулей lm_sensors, я рекомендую установить графический
монитор сенсоров, который позволит вам следить за нагрузкой вашего
процессора и температурами в реальном времени без необходимости
повторять "cat" в /proc/sys/dev/sensors. Для этого я использую
отличную программу под названием gkrellm (смотри Источники). Есть
и другие графические утилиты, совместимые с lm_sensors; вы найдете
список таких утилит на домашней странице lm_sensors в разделе "links".
Последний подготовительный шаг - это загрузка программы для прожигания
процессора (смотри Источники). Эта маленькая программа использует
рукотворные инструкции для процессора, вызывающие у него максимальный
стресс - даже больший, чем повторное компилирование ядра. Входящие в
архив маленькие программы оптимизированы для процессоров P5- и P6-, а
также для AMD K6.
После распаковки тарболла прочтите файл README, в нем объясняется как
скомпилировать исходные файлы. После того, как вы все сделаете, вы
будете иметь свою собственную программу для нагрузки процессора.
Теперь, тест. Я обычно запускаю графический монитор сенсоров и под
root'ом программу для нагрузки процессора. Затем я слежу за ростом и
стабилизацией температуры процессора и оставляю программу в работе на
час или около того.
Если вы повторили эти шаги и температура вашего процессора продолжает
расти до невероятных пределов, то система охлаждения нуждается в
серьезном апгрейде. А если ваша система зависает или рушится или
программа умирает, то либо система охлаждения нуждается в замене, либо
ваш процессор "не готов". Но если все прошло отлично, то ваш компьютер
выдержит любые трудности. После часа или около того вы можете смело
убить программу загрузки процессора и восстановить нормальную работу
машины.
Проверка памяти
---------------
Очень важно иметь полностью рабочий процессор, но не менее важно иметь
и качественные чипы памяти. Некоторые люди думают, что чипы памяти не
ломаются и не нуждаются в тестировании. К сожалению, это не так -
плохая память встречается очень часто и за этим должен следить каждый.
Другие думают, что если бы память была плохой, то ее ошибки проявились
еще во время загрузочного теста BIOS. Это тоже не верно. Проверка
памяти биосом не тестирует всю память, поэтому не позволяйте себе
чувствовать слишком большую уверенность.
Симптомы плохой памяти
----------------------
Итак, поскольку плохая память существует, то она может стоять у
кого-то на компьютере. Вот несколько симптомов, которые могут
указывать на это
* Когда вы запускаете сразу несколько программ, некоторые из них
умирают вдруг ни с того, ни с сего.
* Иногда, когда вы открываете файл, он оказывается поврежден. Если
вы открываете его позже, то все в порядке.
* Когда вы распаковываете тарболл ("tar xzvf"), tar частенько
сообщает, что архив поврежден. Если попытаться открыть его позже,
то ни о каких ошибках сообщений нет. Похожие проблемы могут быть и
у gzip and bzip2.
Если у вас подобные проблемы, то, скорее всего, ваша оперативная
память неисправна. Вы стоит проверить ее, используя приведенный метод.
Если даже у вас нет опыта в решении подобных проблем, то стоит дать
хорошую встряску вашей оперативке, чтобы быть уверенным, что она не
доставит неприятностей в будущем. Вот эта методика.
memtest86
К счастью для нас, есть отличная программа для Linux, которая
устанавливается на загрузочный флоппи-диск. Она называется memtest86
(смотри Источники).
Создание дискеты для memtest.
Сначала закачайте тарболл. Затем, распакуйте архив и создайте двоичный
образ диска:
# tar xzvf memtest86-2.5.tar.gz # cd memtest86-2.5 # make
Затем вставьте пустую дискету в дисковод и введите: # make install
Через несколько секунд на вашем диске будет отличный маленький тестер
памяти, готовый к загрузке. Лучшим способом проверить этот тест - это
найти время, когда ваша машина будет свободна как минимум на шесть
часов - запустить тест перед тем, как идти спать. Для запуска теста
перезагрузите систему с флоппи диска. После запуска программа сразу
начнет работать. Большинство проблем памяти (таких как "мертвые" биты)
будут определены в течении секунд. Некоторые неполадки могут не
определяться в течение нескольких часов, но все равно будут
определены. Как только memtest86 определит дефектный бит, появится
сообщение внизу экрана, а тест продолжится. Когда вы утром включите
монитор, вы увидите, что тест закончен, а никаких сообщений нет, то
ваша память в порядке. Однако, если вы продолжаете испытывать
проблемы, описанные в разделе "Симптомы плохой памяти", то
возможно, что ваша память все-таки неисправна и нуждается в замене.
Разрешение проблем с памятью
----------------------------
Я надеюсь, что все работает хорошо. Однако, если вам не повезло, то не
отчаивайтесь - еще не все потеряно и кое-что можно попробовать
поправить. Сначала проверьте настройки BIOS. В некоторых BIOS есть
опция памяти "Turbo Mode" -- если у вас она включена, то стоит
отключить. Также возможно, что тайминги установлены не корректно - вы
можете попытаться изменить их (увеличив refresh rate, снизив CAS
setting) и перезапустив memtest86 чтобы проверить не исчезла ли
проблема. Если memtest все еще находит ошибки, то пришло время
определить неисправный SIMM или DIMM и удалить его из машины. Если у
вас более одного модуля памяти установлено, то удалите один из них
(или два в случае с SIMM), и запустите memtest86. Проверьте так все
модули и вы сможете определить, какой из них нуждается в замене - не
стоит выбрасывать хорошие модули в мусорку. :) В следующей статье мы
посмотрим как решать проблемы с конфигурацией, включая IRQ. Теперь,
возможно, вы захотите проверить следующие сайты.
Источники
---------
* Загрузите пакет lm_sensors http://www.netroedge.com/%7Elm78
* Возьмите копию gkrellm http://gkrellm.net/
* Возьмите программу cpuburn http://users.ev1.net/%7Eredelm/
* Подготовьте вашу собственную копию memtest86 http://www.memtest86.com/
* Подробную информацию о проблеме "signal 11" смотрите на сайте
Sig 11 FAQ http://www.bitwizard.nl/sig11/
* Вы можете найти много апплетов для Window-maker (некоторые из
которых выводят графики работы процессора и сенсоров) на
http://Linuxpowered.com's Window-maker links page.
* Если вы пытаетесь диагностировать проблему, связанную с вашей
видеокартой nVidia, прочтите GeForce FAQ. Там полно отличной
информации как для Linux так и для Windows http://www.geforcefaq.com/
* При проблемах с дополнительным разгоном драйвера nVidia, проверьте
Christian Zander's nVidia Troubleshooting Guide, который я
опубликовал на http://www.gentoo.org/doc/en/nvidia_tsg.xml
Вы можете получать самую свежую информацию, используя IRC и
присоединившись к irc.openprojects.net. Подключайтесь к каналу #nvidia,
а затем к "/msg ice-dcc xdcc list" чтобы получить список файлов,
которые вы можете запросить для автоматической загрузки dcc.
Об авторе
Живущий в Albuquerque, New Mexico, Daniel Robbins - President/CEO
Gentoo Technologies, Inc., создатель Gentoo Linux http://www.gentoo.org/
усовершенствованного Linux для PC, системы портов следующего поколения
для Linux. Он также является автором книг для Macmillan books Caldera
OpenLinux Unleashed, SuSE Linux Unleashed, и Samba Unleashed. Daniel
знаком с компьютерами со второго курса, когда он начал программировать
на Logo. Обожает проводить время со своей женой, Mary, и маленькой
дочуркой, Hadassah.
462 Прочтений • [Стабильность оборудования в Linux (hardware linux fault trouble memory cpu)] [08.05.2012] [Комментариев: 0]
Vova
