Глава 5. Устранение некоторых проблем

Наиболее вероятная причина заключается в различии между адресами физической и виртуальной памяти.

Существующее соглашение для большинства оборудования ПК заключается в использовании пространства памяти, лежащей в диапазоне между 3.5 ГБ и 4 ГБ для специальных нужд (обычно для нужд PCI). Это пространство адресов используется для доступа к PCI оборудованию. Как результат, реальная физическая память не может быть получена в данном адресном пространстве.

Какие действия выполняются с памятью в данном регионе, зависит от оборудования. К сожалению, некоторое оборудование ничего не выполняет и возможность использовать эти 500 МБ ОЗУ полностью потеряна.

К счастью, большинство оборудования перераспределяет память к более верхней позиции, так что она всё ещё может использоваться. Тем не менее, это может вызвать некоторое замешательство при просмотре сообщений, выдаваемых при загрузке.

На 32-битной версии FreeBSD кажется, что эта память потерялась, поскольку она переназначится в диапазон выше 4 ГБ, который не доступен для 32 битного ядра. В данном случае, решение заключается в сборке ядра с PAE. За дополнительной информацией обращайтесь к статье об ограничениях памяти.

На 64nbsp;битной версии FreeBSD или в случае использования ядра с включённым PAE FreeBSD корректно определит и перераспределит память, так, что она станет годной к использованию. Тем не менее, во время загрузки может показаться, что FreeBSD определяет больше памяти, чем реально имеется в системе из-за описанного перераспределения. Это нормально, и информация о доступной памяти будет скорректирована по окончанию процесса загрузки.

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

Эти проблемы могут быть классифицированы следующим образом:

Вероятно, это не связано с ошибкой во FreeBSD, если проблема проявляется при компиляции программы, и при этом ошибка компилятора каждый раз разная.

Например, если запуск make buildworld завершился неудачей при попытке компиляции ls.c в ls.o и при повторном запуске компиляция снова прервалась на том же месте, то это ошибка процесса построения. Обновите исходные тексты и попробуйте снова. Если же компиляция прерывается в каком-то другом месте, то причина наиболее вероятно кроется в оборудовании.

В первом случае воспользуйтесь отладчиком, к примеру, gdb(1), для нахождения точки программы, в которой делается попытка доступа к неверному адресу, и исправьте эту ошибку.

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

Среди часто приводящих к этому причин:

Прочитайте раздел про Signal 11 для дальнейшего объяснения и обсуждения, как аппаратура или программное обеспечение для тестирования памяти могут пропускать сбойную память. Подробная информация по этому вопросу содержится в FAQ по проблеме SIG11.

Наконец, если ничего не помогает, то, возможно, это из-за ошибки во FreeBSD. Следуйте этим инструкциям для отправки сообщения о проблеме.

Разработчики FreeBSD интересуются такими ошибками, но им нужно больше информации, чем просто текст ошибки. Скопируйте весь текст сообщения. Затем обратитесь к разделу FAQ об аварийных завершениях работы ядра, постройте отладочное ядро и получите трассу вызовов. Это может звучать трудной задачей, зато не требует навыков программирования. Просто следуйте указаниям.

Ядро FreeBSD позволяет одновременно существовать ограниченному числу процессов. Это зависит от значения переменной sysctl(8) kern.maxusers. kern.maxusers также влияет на другие ограничения ядра, такие как буферы работы с сетью. Если система сильно загружена, поднимите kern.maxusers. Кроме максимального числа процессов это также увеличит значения других параметров, ограничивающих систему.

Для корректировки значения kern.maxusers обратитесь к разделу Ограничения файлов/процессов Руководства. В нём говорится об открытых файлах, но те же ограничения касаются процессов.

Если система загружена слабо, но в ней запущено слишком много процессов, поправьте параметр kern.maxproc, определив его значение в /boot/loader.conf. Изменение не вступит в силу до перезагрузки системы. За дополнительной информацией, касающейся настройки параметров, обращайтесь к странице Справочника loader.conf(5). Если эти процессы запущены одним и тем же пользователем, поправьте значение kern.maxprocperuid, чтобы оно было на единицу меньше, чем новое значение kern.maxproc. Оно должно быть меньше по крайней мере на единицу, потому что системная программа init(8) должна работать всегда.

На удалённой машине тип терминала может отличаться от xterm, который требуется для использования консоли FreeBSD. Либо же ядро может иметь неправильные значения ширины и высоты терминала.

Проверьте, чтобы переменная окружения TERM имела значение xterm. Если удалённая машина его не поддерживает, попробуйте vt100.

Запустите stty -a, чтобы узнать, какие размеры терминала заданы в ядре. Если значения неправильные, их можно поменять командой stty rows RR cols CC.

Либо же, если на клиентской машине установлен x11/xterm, запуск resize позволит узнать у терминала правильные размеры и применить эти значения.

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

Проблема: скорее всего, задержка вызвана программным обеспечением на стороне сервера, которое пытается преобразовать IP-адрес клиента в имя хоста. Многие серверы, включая Telnet и SSH, поставляемые с FreeBSD, делают это для того, чтобы, кроме всего прочего, записать имя хоста в файле журнала для справки администратора.

Лечение: Если проблема возникает при подключении клиента к любому серверу, то причина в клиенте. Если проблема возникает только при чьей-либо попытке подключиться к серверу, то проблема в сервере.

Если проблема с клиентом, то единственным методом ее решения является исправление DNS, чтобы сервер смог распознать вашу машину. Если это происходит в локальной сети, то предположите, что это проблема с сервером, и продолжайте чтение. Если это происходит в сети Интернет, обратитесь к вашему провайдеру.

Если проблема с сервером в локальной сети, настройте сервер для разрешения запросов на преобразование адреса в имя хоста в диапазоне локальных адресов. Обратитесь к страницам Справочника по hosts(5) и named(8) для получения более подробной информации. Если это происходит в сети Интернет, то проблема может заключаться в некорректной работе ресолвера локального сервера. Для проверки попробуйте получить адрес другого хоста, такого как www.yahoo.com. Если это не работает, то в этом и состоит проблема.

Из-за свежей установки FreeBSD, также возможно, что информация о домене и сервере имён отсутствует в /etc/resolv.conf. Это часто будет вызывать задержку в работе SSH, так как опция UseDNS по умолчанию установлена в значение yes в /etc/ssh/sshd_config. Если именно это является причиной проблемы, то добавьте недостающую информацию в /etc/resolv.conf, либо в качестве временной меры установите UseDNS в no в файле sshd_config.

Такое сообщение об ошибке сигнализирует о том, что в системе закончились доступные файловые дескрипторы. Обратитесь к разделу kern.maxfiles главы о Настройке ограничений ядра Руководства для выяснения всех подробностей и устранения этой проблемы.

На компьютере установлено по меньшей мере два таймера, и FreeBSD выбрала не тот.

Запустите dmesg(8) и посмотрите строки, содержащие слово Timecounter. FreeBSD выбирает таймер с наибольшим значением качества.

# dmesg | grep Timecounter
Timecounter "i8254" frequency 1193182 Hz quality 0
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
Timecounter "TSC" frequency 2998570050 Hz quality 800
Timecounters tick every 1.000 msec

Удостоверьтесь в этом, проверив sysctl(3)-переменную kern.timecounter.hardware.

# sysctl kern.timecounter.hardware
kern.timecounter.hardware: ACPI-fast

Это может быть неработающий таймер ACPI. Самым простым решением будет отключить таймер ACPI в /boot/loader.conf:

debug.acpi.disabled="timer"

Либо же BIOS может изменить частоту TSC-может, для изменения скорости работы процессора при работе от батареек или переводя в режим пониженного электропитания, но FreeBSD не отслеживает это и в результате часы начинают спешить или отставать.

В этом примере имеется также и таймер i8254, и он может быть выбран записью его имени в sysctl(3)-переменную kern.timecounter.hardware.

# sysctl kern.timecounter.hardware=i8254
kern.timecounter.hardware: TSC -> i8254

Теперь компьютер должен аккуратнее следить за временем.

Чтобы это изменение вступало в силу во время загрузки системы, добавьте в файл /etc/sysctl.conf такую строчку:

kern.timecounter.hardware=i8254

Это значит, что процесс пытается сбросить страницу памяти на диск, и попытка сделать это оканчивается неудачно в течение более 20 секунд. Это может быть вызвано испорченными блоками на диске, кабелями, подключением или другим оборудованием ввода/вывода. Если диск сам по себе испорчен, вы также увидите ошибки работы с диском в /var/log/messages и в выводе dmesg. В противном случае проверьте кабели и подключения.

Ядро FreeBSD использует несколько блокировок для арбитража доступа к соответствующим ресурсам. Когда несколько потоков в ядре пытаются захватить несколько блокировок подряд, всегда существует возможность появления мёртвой блокировки (deadlock), где два потока захватили по одной блокировке и заблокированы в ожидании освобождения другим потоком второй блокировки. Такой проблемы синхронизации можно избежать, если все потоки захватывают блокировки в одинаковом порядке.

Система диагностирования блокировок witness(4), которая по умолчанию включена во FreeBSD-CURRENT и выключена для стабильных веток и релизов, определяет возможность появления мёртвых блокировок из-за ошибок их использования, включая захват нескольких блокировок в различном порядке в разных частях ядра. Инфраструктура witness(4) пытается обнаруживать эту проблему по мере её появления и сообщает о ней на системную консоль в сообщении lock order reversal (которое также часто называют LOR).

В силу консервативности witness(4) возможны ложные срабатывания. При правильном срабатывании такое сообщение не означает, что система находится в состоянии мёртвой блокировки; его следует рассматривать как предупреждение о том, что в этом месте могла бы произойти мёртвая блокировка.

Это означает, что функция, которая может находиться в <<спящем>> состоянии была вызвана во время использования мьютекс (или другого не <<засыпающего>>) блокирования.

Причина этого - ошибка, потому что мьютексы не предполагают находиться в удерживаемом состоянии длительные промежутки времени, а блокировать только на короткие периоды синхронизации. Это правило позволяет драйверам устройств использовать мьютексы для синхронизации с остальной частью ядра во время прерываний. Прерывания (во FreeBSD) могут находиться не в <<спящем состоянии>>. Следовательно необходимо, чтобы не было подсистем в ядре, которые бы занимались блокировкой длительный период, используя мьютекс.

Для нахождения таких ошибок в ядро могут быть добавлены assertions, которые будут взаимодействовать с подсистемой witness(4) для генерирования предупреждения или фатальной ошибки (в зависимости от системной конфигурации) в случаях когда производится потенциально блокирующий вызов с удержанием мьютекса.

В общем, такие предупреждения не критичны, но тем не менее, с неудачной синхронизацией (timing) они могут вызвать нежелательные эффекты, начиная от незначительной задержки в ответной реакции системы до полной блокировки системы.

Дополнительная информация о синхронизации во FreeBSD находится на странице Справочника locking(9).

Эта ошибка не означает, что не найдена утилита touch(1). Ошибка наверняка появляется из-за того, что даты модификации файлов установлены в будущем. Если CMOS часы установлены на локальное время, отрегулируйте часовой механизм ядра, запустив команду adjkerntz -i в однопользовательском режиме.