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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Проблема: скорее всего, задержка вызвана программным обеспечением на стороне сервера, которое пытается преобразовать 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.

Запустите 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

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

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

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

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

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

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