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

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

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

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

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

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

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

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

Для включения переадресации запорченных блоков, измените режим работы устройства, что может быть выполнено пользователем root по команде

# camcontrol modepage sd0 -m 1 -e -P 3

и изменить значения параметров AWRE и ARRE с 0 на 1:-

AWRE (Auto Write Reallocation Enbld):  1
ARRE (Auto Read Reallocation Enbld):  1

Контроллеры современных IDE-дисков имеют встроенную функцию переадресации запорченных блоков, которая на момент продажи включена.

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

В общем-то это известная проблема. EISA-контроллеры SCSI, расположенные на материнской плате машин HP Netserver, занимают EISA-слот номер 11, так что все ''настоящие'' слоты EISA будут ему предшествовать. Так как адресное пространство для слотов EISA выше 10 пересекается с адресным пространством, предназначенным для PCI, то автоконфигуратор FreeBSD в настоящее время не может эту проблему нормально обойти.

Так что пока лучшее, что вы можете предпринять, это попытаться указать, что пересечения диапазонов адресов нет :), установив опцию ядра EISA_SLOTS в значение 12. Отконфигурируйте и откомпилируйте ядро так, как это описано в разделе Руководства о конфигурировании ядра.

Конечно, это даст вам типичную ситуации "курица или яйцо" при установке системы на такой машине. Для обхода этой проблемы внутри UserConfig есть специальный хак. Не используя ''визуального'' интерфейса, а только интерфейс командной строки, просто наберите

eisa 12
quit

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

Надеемся, что будущие версии будут содержать полное решение этой проблемы.

Обычно это вызвано конфликтом прерываний (например, двух адаптеров, использующих один и тот же IRQ). Загрузите систему с опцией -c и смените строку, описывающую ed0/de0/... на соответствующую вашей системе.

Если вы используете разъём BNC сетевого адаптера, таймауты устройства могут быть вызваны плохим терминированием. Чтобы это проверить, подключите терминатор к адаптеру (без кабеля) и посмотрите, не исчезли ли сообщения об ошибках.

Некоторые NE2000-совместимые адаптеры выдают такую ошибку, если нет связи по UTP-порту или отключен кабель.

Этот адаптер имеет странную привычку терять информацию о своих настройках. Обновите настройки вашего адаптера при помощи утилиты 3c5x9.exe из DOS.

Если проблема только в том, что принтер работает ужасно медленно, попробуйте сменить режим работы порта принтера так, как это описано в разделе Настройка принтера Руководства.

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

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

1. Если проблема возникает только в определённом приложении, которое было самостоятельно вами разработано, то, скорее всего, это ошибка в вашем коде.

2. Если это проблема в части базового комплекта системы FreeBSD, то это тоже может быть ошибка в программном коде, хотя в большинстве случаев такие проблемы обнаруживаются и ошибки исправляются задолго до того, как обычным читателям FAQ доводится использовать этот код (именно для этого предназначена версия -current).

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

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

Что вы должны сделать:

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

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

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

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

2. Работающий процессор перегревается: Это может произойти из-за выхода частоты процессора за рабочие границы или поломки вентилятора на процессоре. В любом случае вам нужно убедиться, что ваше оборудование работает так, как ему положено, по крайней мере, на момент поиска причин неисправности, другими словами, установите частоту работы на настройки по умолчанию.

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

3. Хитрая память: Если у вас установлено множество микросхем SIMM/DIMM, то вытащите их все и попытайтесь поработать индивидуально с каждой микросхемой SIMM или DIMM и локализовать проблему либо до проблематичной микросхемы DIMM/SIMM, либо даже их комбинации.

4. Чересчур оптимистические настройки материнской платы: При настройке вашей BIOS и выборе положения перемычек на материнской плате вы имеете возможность задать различные частоты и задержки, и в большинстве случаев настройки по умолчанию достаточны, но иногда установка слишком малых периодов ожидания для ОЗУ, установка параметра ''RAM Speed: Turbo'' и подобных параметров в BIOS вызовет странное поведение. Возможным решением может стать установка параметров BIOS по умолчанию, но сначала стоит записать ваши настройки!

5. Неустойчивое или недостаточное электропитание материнской платы. Если в вашей системе есть неиспользуемые адаптеры ввода/вывода, винчестеры или приводы компакт-дисков, попробуйте временно их убрать или отключить от кабеля электропитания, чтобы посмотреть, сможет ли ваш блок питания работать с меньшей нагрузкой. Или попробуйте воспользоваться другим блоком питания, желательно большей мощности (например, если имеющийся блок питания рассчитан на 250 Ватт, попробуйте другой мощностью 300 Ватт).

Вы также должны прочитать FAQ по SIG11 (ссылка дана ниже), в котором даны прекрасные описания всех этих проблем, хотя и с точки зрения Linux®. Также обсуждается, как аппаратура или программное обеспечение для тестирования памяти могут пропускать сбойную память.

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

Подробная информация по этому вопросу содержится в FAQ по проблеме SIG11.

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

Это известная проблема с видеоадаптерами ATI Mach 64. Она вызвана тем, что этот адаптер использует адрес 2e8, как и четвёртый последовательный порт. Из-за ошибки (или особенности работы?) в драйвере sio(4) он обращается к порту, даже если он не существует, и даже если вы отключите sio3 (четвёртый порт), который, как правило, использует этот адрес ввода/вывода.

Пока это не исправлено, используйте следующий метод:

1. В приглашении загрузчика наберите -c. (Это переведёт ядро в режим конфигурации).

2. Отключите устройства sio0, sio1, sio2 и sio3 (все их). После этого драйвер sio не будет активизироваться и проблем не будет.

3. Для продолжения загрузки наберите exit.

Если вам нужно использовать последовательные порты, вы должны построить новое ядро со следующей модификацией: в файле /usr/src/sys/i386/isa/sio.c найдите строчку, содержащую число 0x2e8 и удалите её вместе с предшествующий запятой (оставив следующую). После этого следуйте обычным указаниям по построению ядра.

Даже после этих изменений вы можете обнаружить, что X Window работает ненормально. Если это произошло, удостоверьтесь, что вы используете XFree86™ версии не ниже 3.3.3. Этот и последующие релизы имеют встроенную поддержку адаптеров Mach64 и даже отдельный X-сервер для таких адаптеров.

Так как для определения объёма памяти FreeBSD использует информацию BIOS, она ограничена 16 битами, используемыми для выражения размера ОЗУ в килобайтах (65535 Кбайт = 64 Мбайт) (или меньше... некоторые BIOS ограничивают размеры памяти до 16 Мбайт). Если у вас больше чем 64 Мбайт ОЗУ, FreeBSD будет пытаться обнаружить эту память; однако эта попытка может и не удаться).

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

options "MAXMEM=n"

Здесь n - это объём памяти в килобайтах. Для машины со 128 Мбайт ОЗУ вам нужно использовать значение 131072.

Как правило, FreeBSD определяет параметры ядра, в частности, максимальное количество одновременно открытых файлов, исходя из объёма памяти, установленного в системе. В системах, имеющих 1 Гбайт или больший объём оперативной памяти, этот механизм ''автоматического определения параметров'' может выбрать слишком большие значения: при запуске ядро выделяет пространство под различные таблицы и другие структуры, которые заполняют основной объём доступной ядру памяти. В дальнейшем при работе системы у ядра не остаётся пространства для динамического распределения памяти, и оно завершает работу аварийно.

Скомпилируйте новое ядро, добавив параметр VM_KMEM_SIZE_MAX в конфигурационный файл ядра, увеличив его максимальный размер до 400 Мбайт (options VM_KMEM_SIZE_MAX=419430400). 400 Мбайт должно быть достаточно для машин с объёмом оперативной до 6 Гбайт.

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

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

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

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

Чтобы сохранить значения sysctl, задайте их в /etc/sysctl.conf. Дополнительную информацию о настройке системы с помощью sysctl(8) можно найти в главе Руководства Настройка с помощью sysctl

Процедура определения устаревших файлов /var/db/kvm_*.db иногда даёт сбой и использует не те файлы, что может вызвать аварийный останов системы.

Если это случилось, перезагрузитесь в однопользовательском режиме и выполните команду:

# rm /var/db/kvm_*.db

Это - результат конфликта со SCSI-адаптером Ultrastor.

Во время загрузки войдите в меню конфигурации ядра и выключите устройство uha0, являющееся источником этой проблемы.

На вашей материнской плате отсутствует внешняя логика поддержки автоматического терминирования. Установите в вашем SCSI BIOS правильное терминирование для вашей конфигурации вместо автоматического терминирования. Драйвер AIC7XXX не может определить, есть ли внешняя логика для распознавания кабеля (и, соответственно, автоматического терминирования). Драйвер просто полагает, что эта поддержка должна быть, если конфигурация, содержащаяся в EEPROM, установлена в "automatic termination". Без внешней логики распознавания кабеля драйвер часто будет ошибаться при настройке терминирования, что может сказаться на надежности шины SCSI.

В FAQ по sendmail на это дан такой ответ:-

        * Выдаются сообщения "Local configuration error", примерно такие:

        553 relay.domain.net config error: mail loops back to myself
        554 <user@domain.net>... Local configuration error

        Как можно решить эту проблему?

        Согласно записям MX, почта для домена (скажем, domain.net) была
        перенаправлена на указанный хост (в нашем случае relay.domain.net),
        но он не распознаётся как domain.net.  Добавьте строку domain.net в
        файл /etc/mail/local-host-names (если вы используете
        FEATURE(use_cw_file)) или добавьте "Cw domain.net"
        в /etc/mail/sendmail.cf.
          

Текущая версия FAQ по sendmail больше не поставляется вместе с sendmail. Однако этот документ регулярно помещается в конференции comp.mail.sendmail, comp.mail.misc, comp.mail.smail, comp.answers и news.answers. Вы можете получить копию по электронной почте, послав сообщение, содержащее команду send usenet/news.answers/mail/sendmail-faq в теле письма, в адрес <mail-server@rtfm.mit.edu>.

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

Есть несколько возможных способов решения этой проблемы:

• После входа на другую машину установите значение переменной окружения TERM равным ansi или sco, если эта машина знает об этих типах терминалов.

• Используйте эмулятор VT100, например screen на консоли FreeBSD. Screen даёт вам возможность открывать несколько рабочих сеансов на одном терминале, и она имеет ещё ряд полезных особенностей. Каждое окно программы screen ведёт себя как терминал VT100, так что переменная TERM на удалённой машине должна быть установлена в значение vt100.

• Опишите терминал cons25 в базе данных характеристик терминалов на удалённой машине. Способ описания зависит от используемой на этой машине операционной системе. Вам может помочь чтение руководств по администрированию удалённой системы.

• Запустите X-сервер на стороне FreeBSD и войдите на удалённую систему с помощью какого-либо эмулятора терминала, работающего в X Window, такого, как xterm или rxvt. Переменная окружения TERM на удалённой машине должна быть установлена в значение xterm или vt100.

Это может быть вызвано различными аппаратными или программными проблемами, связанными с прерываниями. Это может быть связано как с ошибками при программировании, так и с природой самих устройств. Например, работа с TCP/IP по параллельному порту с использованием большого MTU приводит к этой проблеме, также как использование графических акселераторов; в последнем случае вы должны проверить настройку прерываний на графическом адаптере.

Одним из проявлений этой проблемы является прерывание работы процессов с диагностическим сообщением ''SIGXCPU exceeded cpu time limit''.

Если эта проблема не может быть решена, измените значение системной переменной:

# sysctl -w kern.timecounter.method=1

Это коснётся производительности системы, но, принимая во внимание источник этой проблемы, это будет незаметно. Если проблема всё ещё даёт о себе знать, оставьте значение этой переменной равным единичке и увеличьте значение параметра NTIMECOUNTER в файле конфигурации вашего ядра. Если в конце концов вы достигнете значения NTIMECOUNTER=20, то вам эту проблему решить не удастся, прерывания дают слишком большую нагрузку на процессор, чтобы обеспечить отслеживание времени.

FreeBSD 4.X теперь гораздо более PnP-центрична, что отражается на некоторых устройствах PnP (к примеру, звуковых адаптерах и внутренних модемах), перестающих работать, хотя они функционировали в системе FreeBSD 3.X.

Причины такого поведения объясняются в следующем сообщении электронной почты, опубликованном в Список рассылки, посвящённый вопросам и ответам пользователей FreeBSD Питером Уэммом (Peter Wemm) в ответ на вопрос о внутреннем модеме, который перестал распознаваться после обновления до FreeBSD 4.X (комментарии внутри [] были добавлены для пояснения контекста послания.

BIOS, поддерживающая PNP, предварительно отводит и оставляет ему [модему] место в адресном пространстве портов, так что [в 3.X] процедура обнаружения в старом стиле ISA ''находит'' его здесь.

В 4.0 код для работы с ISA гораздо более PnP-центричен. [В 3.X] было возможно при распознавании ISA найти ''беспризорное'' устройство и затем по идентификатору PNP-устройства произвести поиск и получить ошибку из-за конфликта ресурсов. Поэтому для предотвращения повторной процедуры распознавания в нём сначала выключаются все управляемые адаптеры. Это также означает, что для поддерживаемого оборудования PnP нужно знать их PnP-идентификаторы. Имеются планы на обеспечение возможности настройки этого со стороны пользователя.

Чтобы заставить устройство работать снова, требуется определить его PnP-идентификатор и добавить его в список, который используется процедурой распознавания ISA для идентификации устройств PnP. Этот идентификатор можно получить при помощи программы pnpinfo(8), найдя устройство в её выдаче, вот, например, вывод команды pnpinfo(8) в случае внутреннего модема:

# pnpinfo
Checking for Plug-n-Play devices...

Card assigned CSN #1
Vendor ID PMC2430 (0x3024a341), Serial Number 0xffffffff
PnP Version 1.0, Vendor Version 0
Device Description: Pace 56 Voice Internal Plug & Play Modem

Logical Device ID: PMC2430 0x3024a341 #0
    Device supports I/O Range Check
TAG Start DF
    I/O Range 0x3f8 .. 0x3f8, alignment 0x8, len 0x8
    [16-bit addr]
    IRQ: 4  - only one type (true/edge)

[лишние строки TAG исключены]

TAG End DF
End Tag

Successfully got 31 resources, 1 logical fdevs
-- card select # 0x0001

CSN PMC2430 (0x3024a341), Serial Number 0xffffffff

Logical device #0
IO:  0x03e8 0x03e8 0x03e8 0x03e8 0x03e8 0x03e8 0x03e8 0x03e8
IRQ 5 0
DMA 4 0
IO range check 0x00 activate 0x01

Информация, которая вам нужна, находится в строке ''Vendor ID'' в самом начале вывода команды. Шестнадцатеричное число в скобках (в этом примере 0x3024a341) является PnP-идентификатором, а строчка, идущая прямо перед ним (PMC2430) является уникальным ASCII-идентификатором.

Либо, если в списке, выдаваемом pnpinfo(8), адаптера нет, можно воспользоваться утилитой pciconf(8). Вот часть выдачи команды pciconf -vl для интегрированного в материнскую плату звукового адаптера:

# pciconf -vl
chip1@pci0:31:5:        class=0x040100 card=0x00931028 chip=0x24158086 rev=0x02hdr=0x00
    vendor   = 'Intel Corporation'
    device   = '82801AA 8xx Chipset AC'97 Audio Controller'
    class    = multimedia
    subclass = audio

В данном случае вам нужно использовать значение для chip, ''0x24158086''.

Эту информацию (ID производителя или номер микросхемы) нужно добавить в файл /usr/src/sys/isa/sio.c.

Сначала вы должны сделать резервную копию файла sio.c просто на тот случай, если что-то пойдёт не так. Эта копия также может потребоваться для создания патча для посылки его вместе с вашим PR (вы же собираетесь послать PR, не правда ли?) отредактировав файл sio.c и поискав строчку

static struct isa_pnp_id sio_ids[] = {

после чего переместитесь ниже и найдите подходящее место, чтобы добавить строчку для вашего устройства. Записи имеют примерно такой вид, и они отсортированы по ASCII-строкам Vendor ID, которые должны быть помещены в поле комментария справа от строки кода вместе с полным описанием устройства (если оно поместится) или частью из Device Description вывода программы pnpinfo(8):

{0x0f804f3f, NULL},    /* OZO800f - Zoom 2812 (56k Modem) */
{0x39804f3f, NULL}, /* OZO8039 - Zoom 56k flex */
{0x3024a341, NULL}, /* PMC2430 - Pace 56 Voice Internal Modem */
{0x1000eb49, NULL}, /* ROK0010 - Rockwell ? */
{0x5002734a, NULL}, /* RSS0250 - 5614Jx3(G) Internal Modem */

Добавьте шестнадцатеричный идентификатор Vendor ID вашего устройства в соответствующее место, сохраните файл, перестройте ядро и выполните перезагрузку. Ваше устройство должно теперь быть найдено в виде устройства sio, как это и было во FreeBSD 3.X

Проблема в том, что приложение, которое вы пытаетесь запустить, ищет специфические ссылки в ядре, но по каким-либо причинам не может их найти; эта ошибка происходит от одной из следующих проблем:

• Ваше ядро и программы пользователей не соответствуют друг другу (например, вы построили ядро, но не выполнили команду installworld, или наоборот), и поэтому таблица имен отличается от того, что думают о ней пользовательские приложения. Если это ваш случай, просто завершите процесс обновления (обратитесь к файлу /usr/src/UPDATING для выяснения правильной последовательности действий).

• Для загрузки ядра вы не используете /boot/loader, а делаете это непосредственно из boot2 (обратитесь к справочно странице по boot(8)). Хотя нет ничего плохого в обходе /boot/loader, обычно работу по доступности символьной информации ядра из пользовательских приложений он выполняет лучше.

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

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

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

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

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

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

Потерянные IRQ являются признаком странностей в работе аппаратных IRQ, в основном оборудования, которое удаляет свои запросы на прерывание посреди цикла подтверждения запроса на прерывание.

Имеется три варианта работы с такими ситуациями:

• Примириться с сообщениями. В любом случае подавляются все сообщения, кроме каждых первых 5 на IRQ.

• Убрать предупреждающие сообщения, изменив параметр 5 на 0 в функции isa_strayintr(), так что все предупреждения будут подавлены.

• Избавиться от предупреждений, установив параллельный порт, использующий IRQ 7 и драйвер PPP для него (это есть на большинстве систем), и установив диск IDE или другое оборудование, использующее IRQ 15 и подходящий драйвер.

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

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

Запустите dmesg(8) и посмотрите строки, содержащие слово Timecounter. В последней из них указан таймер, выбранный системой, и, скорее всего, это будет TSC.

# dmesg | grep Timecounter
Timecounter "i8254"  frequency 1193182 Hz
Timecounter "TSC"  frequency 595573479 Hz

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

# sysctl kern.timecounter.hardware
kern.timecounter.hardware: TSC

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

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

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

Теперь ваш лэптоп будет аккуратнее следить за временем.

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

kern.timecounter.hardware=i8254

Эта проблема часто встречается на лэптопах, которые работают более чем с одной операционной системой. Некоторые не-BSD операционные системы оставляют аппаратную часть PC-карт в неустойчивом состоянии. pccardd распознает карту как “"(null)""(null)"”, а не как реально используемую модель.

Вы должны убрать всё питание со слота PC-карты для полного сброса аппаратуры. Полностью выключите лэптоп. (Не переводите его ни в спящий, ни в ждущий режим; питание должно быть выключено полностью.) Подождите несколько секунд и перезагрузитесь. Теперь ваша PC-карта должна заработать.

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

Начальный загрузчик FreeBSD неверно определяет параметры винчестера. Их можно установить вручную утилитой fdisk при создании или изменении параметров слайса FreeBSD.

Правильные значения параметров диска можно посмотреть в BIOS. Обратите внимание на число дорожек, головок и секторов для этого диска.

В подпрограмме fdisk утилиты sysinstall(8) нажмите G для установки параметров диска (disk geometry).

Появится диалоговое окно, запрашивающее количество дорожек, головок и секторов. Задайте значения, взятые из BIOS и разделяемые символами слэша. Например, 5000 дорожек, 250 головок и 60 секторов будут введены как 5000/250/60.

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

Запустите утилиту sysinstall(8) и выберите пункт Configure, а затем Fdisk. Выберите диск, на котором ранее находился менеджер загрузки, при помощи клавиши пробел. Нажмите W для записи изменений на диск. Появится диалоговое окно для выбора устанавливаемого начального загрузчика. Выберите нужный, и он будет восстановлен.

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

Драйвер ata(4) сообщает об ошибках ''UDMA ICRC'', когда нарушается передача в или с диска в режиме DMA. Драйвер будет повторять передачу несколько раз. Если повторные попытки окончатся неудачей, он переключится из режима DMA в более медленный режим PIO взаимодействия с устройством.

Проблема может возникать по многим причинам, хотя самым распространённой является неправильное или сбоящее подключение кабелей. Проверьте кабели ATA на наличие повреждений и соответствие используемому режиму Ultra DMA. Если вы используете диски на съёмных салазках, они также должны быть совместимыми с этим режимом. Удостоверьтесь, что все соединения подключены хорошо. Проблемы также наблюдались, когда старый диск устанавливался на тот же самый канал ATA, что и Ultra DMA 66 (или более быстрый) диск. Наконец, такие ошибки могут указывать на сбойность самого диска. Большинство производителей дисков предоставляют программное обеспечение для тестирования своих дисков, так что проверьте свой диск, и, если это необходимо, сделайте резервную копию данных и замените его.

Для просмотра и выбора режимов DMA или PIO для каждого устройства ATA можно использовать утилиту atacontrol(8). В частности, команда atacontrol mode channel выдаст режимы, используемые заданным каналом ATA, причём первичный канал нумеруется нулём, и так далее.

Robert Watson <rwatson@FreeBSD.org> очень кратко ответил на этот вопрос в списке рассылки freebsd-current в теме ''lock order reversal - что это означает?''

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

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

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

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

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