ASUS CUR-DLS и FreeBSD - Железные призраки прошлого

Хочу рассказать про серверную материнскую плату ASUS CUR-DLS и проблемы, которые я получил при запуске на ней FreeBSD. Ну и конечно, про возможные пути решения этих проблем. Эта плата представляет собой двухпроцессорное серверное решение для Socket370 (поддерживаются только процессоры на ядре Coppermine), чипсет от компании ServerWorks - ServerSet III LE. Этот чипсет предназначен для построения серверных платформ начального уровня с процессорами Pentium II/III (а также Pentium II/III Xeon), LE означает Low End. В статье также будут упомянуты некоторые общие особенности чипсетов компании ServerWorks поколения ServerSet III и рассмотрены некоторые другие платы на ServerSet III LE. Приношу извинения за невысокое качество фотографий.

ServerSet III - это третье поколение чипсетов ServerSet. В семейство ServerSet III входят чипсеты LE, HE и HE-SL. Часто эти чипсеты называют просто по имени компании, т.е., например, ServerWorks III LE chipset, или же полностью: ServerWorks ServerSet III LE chipset. Далее для определенности я буду в основном именовать эти чипсеты как ServerSet III. Отмечу, что ранее компания ServerWorks называлась Reliance Computer Corporation (RCC), а впоследствии она была куплена Broadcom.

2. Краткий обзор платы ASUS CUR-DLS

Я давно хотел найти плату на чипсете от компании ServerWorks, и это наконец удалось сделать в 2013 году. Тогда была куплена ASUS CUR-DLS старой ревизии rev 1.03, с поврежденным BIOS от HP (из-за чего не работало встроенное видео). В дальнейшем удалось приобрести еще две платы на чипсете ServerSet III LE, что конечно помогло в выявлении их особенностей. К сожалению, документация на чипсеты компании ServerWorks засекречена (даже наименование их в разных источниках отличается), многие вещи так и остались загадкой, поэтому расскажу о том, что удалось разобрать. Буду весьма признателен, если кто-либо владеет и может поделиться какой-либо технической информацией по этим чипсетам (особенно на северные мосты). Я нашел лишь общие обзоры и блочные схемы материнских плат.

А вот что представляет собой плата ASUS CUR-DLS.

Плата ASUS CUR-DLS (фото из manual-а от ASUS)

Плата оснащена двумя 64-битными PCI слотами (они на 33MHz, но есть и редкая версия платы с 64-битными PCI на 66MHz) и 5 обычными; двухканальным SCSI контроллером от LSI; двумя IDE каналами; floppy; LPT; двумя COM портами; 4-мя портами USB1 (два разъема USB стандартно впаяны на плате сзади и еще два можно подключить с помощью внешнего удлинителя); встроенным видео Ati Rage XL 4MB и встроенной сетью Intel 82559.

Плата оснащена пропиетарным разъемом ASMC, напоминающим AGP. Он предназначен для установки пропиетарной карты от ASUS реализующей IPMI (Intelligent Platform Management Interface). Какой-либо информации об этой карте у меня нет.

CUR-DLS встречается под тремя "brand name" (не исключено, что есть и другие):

1. Родной ASUS (с пропиетарным Award BIOS от ASUS, движок такой же, как например на знаменитой ASUS P3B-F и многих других). По факту он ближе к версии Award 4.5.

2. В составе сервера GateWay 6400/7400, BIOS AMI core7.

3. В составе сервера HP E800, BIOS Phoenix. В HP варианте используется специальный коннектор передней панели (он предусмотрен дизайном платы), где есть только power LED, HDD LED и power switch, reset-а естественно нет:)

В варианте от HP и GateWay разъем ASMC может не устанавливаться.

Мне попался вариант для HP, но на плате были распаяны оба коннектора - как для HP, так и стандартный (для ASUS) полный коннектор передней панели. ASMC разъем установлен.

Кроме того, эта плата выпускалась ASUS-ом в трех вариантах исполнения:

1. С Ultra2 SCSI (80MB/s) контроллером LSI 896 и PCI64 на 33MHz (это мой вариант).

2. С Ultra160 SCSI (160MB/s) контроллером LSI 53C1010-33 и PCI64 на 33MHz.

3. С Ultra160 SCSI (160MB/s) контроллером LSI 53C1010-66 и PCI64 на 66MHz, при этом не запаивается нижний PCI слот. Этот вариант крайне редкий, его я не видел даже на картинке. Собственно, скорость PCI в первых двух вариантах ограничивает встроенный SCSI, и в принципе возможна доработка платы с переводом шины PCI64 на 66MHz, но ценой отказа от SCSI. Этот вариант я не рассматривал, т.к. для меня отказ от встроенного SCSI неприемлем, а скорости PCI64/33MHz мне вполне хватает.

SCSI контроллер на плате двухканальный, т.е. фактически в корпусе одного чипа два контроллера, что теоретически дает возможность подключать до 30 устройств, т.е. по 15 устройств на каждом канале. В моей практике оказалось удобным подключать по два диска к разным каналам, не беспокоясь об их SCSI ID.

Северный мост чипсета ServerSet III LE, CNB30LE (Champion North Bridge, надпись на нем RCC-NB6635-P02, P02, видимо, ревизия) обеспечивает две шины PCI - Primary и Secondary.

Primary PCI - обычная 32-битная шина частотой 33MHz, на которой находятся PCI слоты 1-4, встроенная видеокарта Ati, сеть Intel и PCI устройства, интегрированные в южный мост ROSB4 (RCC-IB6566): это IDE, USB и мост PCI->ISA (разъемы ISA на плате отсутствуют). Южный мост соединяется с северным по обычной 32-битной 33MHz PCI шине, специальных интерфейсов (типа Intel hub interface, VIA V-Link итп) здесь не используется, т.к. скоростные устройства обслуживаются шиной Secondary PCI, которую обеспечивает северный мост.

Secondary PCI - 64-битная шина частотой 33MHz или 66MHz (как уже упоминалось, в большинстве ревизий платы скорость Secondary PCI ограничена до 33MHz), на этой шине находятся два 64-битных PCI слота, встроенный SCSI контроллер и один 32-битный PCI слот 7 (это самый нижний слот, он не запаивается в варианте платы с PCI64/66MHz).

Блок-схема организации шины PCI для ASUS CUR-DLS

Максимально поддерживаемый объем оперативной памяти - 4GB (реально, естественно, несколько меньше, что является обычным делом для 32-х разрядных платформ без поддержки PAE), в конфигурации 4 модуля по 1GB каждый. Поддерживается только регистровая SDRAM память с ECC и частотная спецификация памяти должна быть не ниже, чем FSB установленного процессора, т.к. чипсет синхронный. Модули памяти рекомендуется ставить одинаковые.

Отмечу, что недостатком платы является невозможность отключения встроенного видео, из-за чего я с некоторыми PCI VGA картами получал странности в консоли FreeBSD и сложности с настройкой Xorg. Расследования в этом направлении не проводились, тк я хотел использовать именно встроенное видео. У следующей платы от ASUS на том же чипсете - TR-DLS (уже с поддержкой Tualatin) этот недостаток устранили, добавив перемычку для отключения встроенного видео.

Плата (по крайней мере в rev 1.03) имеет уникальную особенность - питание +5V на USB порты подается только после загрузки драйвера USB контроллера, и наоборот, снимается при выгрузке драйвера. Для сравнения: современные платы часто подают питание на USB даже в дежурном режиме (иногда это настраивается перемычками); большинство же старых плат дает питание на USB только в рабочем режиме (питание USB просто берется с линии +5V блока питания). На CUR-DLS же питание на USB порты включается только во время загрузки OS (когда загружается USB драйвер). Т.е. если OS не поддерживает USB, питания на портах не будет! Ни у одной другой платы такой особенности я пока не встречал.

3. Установка частоты FSB

На моем экземпляре платы распаян DIP переключатель CLKSW для установки частоты FSB. Частоту нужно ставить вручную, однако manual от ASUS рассчитан на версию платы с автоопределением FSB и незапаянным CLKSW. Руководства по установке CLKSW я не нашел, но обратившись к документации на clocker ICS9248, таблица частот была найдена. Вот страница из datasheet на clocker, её можно использовать как руководство к установке частоты (я проверял ее в нескольких "не-разгонных" точках - совпало). "0" соответствует положению переключателя ON, "1"-OFF; FS0 в таблице соответствует SW1, FS4 - SW5.

Таблица установки частот FSB, PCI, IOAPIC

Практически основные положения CLKSW это:

для 133MHz SW1-SW5 <on off on off on> (и еще одно дублирующее SW1-SW5 <on on on on off> );

для 100MHz SW1-SW5 <off on on on on>

Однако принудительно установить FSB 100MHz, при процессоре на FSB 133MHz по невыясненным причинам не удалось, плата не стартует. Интересно, что при установке FSB 66MHz плата запустилась, но память не определялась, непрерывные гудки.

4. Проблема с IDE контролером южного моста ROSB4

Остановлюсь на работе IDE каналов. CUR-DLS, как и большинство других плат для процессоров Pentium II/III на чипсетах семейства ServerSet III использует южный мост ROSB4 (RCC Open South Bridge 4, часто его называют просто OSB4), надпись на чипе RCC-IB6566-P03, P03 это, по видимому, ревизия. IDE контроллер этого моста поддерживает максимум UDMA33, но этот режим фактически нерабочий! Собственно, проблему дает любой режим UDMA, даже UDMA0 (16,7MB/s).

Проявляется проблема например в том, что при копировании больших файлов (например между двумя дисками, подключенными к разным IDE каналам или даже в пределах одного диска) файлы иногда портятся: искажается блок из нескольких байтов, причем зачастую это происходит даже без сообщений об ошибках UDMA. Отмечу особую "нелюбовь" моста к HDD фирмы Fujitsu и проблемы с некоторыми ATAPI CDROM на вторичном (Secondary) IDE канале.

Интенсивность проявления проблем с ROSB4 зависит и от аппаратной реализации платы, и от драйвера, и от того насколько "агрессивно" ядро OS и приложение использует диск. К примеру, FreeBSD 6.4 в режиме UDMA работает почти нормально, а версия 8.x даже не может загрузиться.

К счастью, режим WDMA2 (16,7MB/s) работает нормально, поэтому, начиная с FreeBSD версии 8.1, максимальный режим ограничен до WDMA2, а UDMA отключен. Мост ROSB4 часто можно встретить и на платах с другими чипсетами от ServerWorks, например ServerSet III HE-SL.

Следовательно, для полноценной работы с IDE на многочисленных платах с таким мостом следует использовать внешний PCI IDE UDMA контроллер. Я также проверял режим UDMA33 на плате с ROSB4 более свежей ревизии (P-05), уже с логотипом ServerWorks, а не RCC. К сожалению, в новой ревизии моста эта ошибка не была исправлена.

Южный мост ROSB4 с логотипом RCC, ревизия P03

Южный мост ROSB4 с логотипом ServerWorks, ревизия P05

Существует более современный южный мост от ServerWorks - CSB5 (Champion South Bridge 5). IDE контроллер этого моста, в зависимости от ревизии обеспечивает UDMA66 или UDMA100, причем без проблем!

Южный мост CSB5

У меня есть плата Intel SAI2 с мостом CSB5, IDE на нем UDMA100. Его IDE контроллер был проверен и проблем не было выявлено. К сожалению, серверных плат поколения Pentium II/III с таким новым мостом не слишком много. Из числа стандартных ATX плат (в смысле плата не из состава проприетарного сервера, а нормальная ATX плата от известного производителя) приведу примеры - Intel SAI2, ASUS TR-DLS и TRL-DLS (последняя построена на чипсете ServerWorks ServerSet III HE-SL).

Плата Intel SAI2 с установленными процессорами

Плата ASUS TR-DLS (фото из manual-а от ASUS)

Плата ASUS TRL-DLS (фото из manual-а от ASUS)

5. Первоначальный запуск и первая проблема

Первоначальный запуск CUR-DLS я проводил, установив одну планку регистровой PC133 ECC памяти, один 733MHz Pentium III (в socket CPU1) и специальную заглушку (терминатор) в socket CPU2, т.к. для этой платы нужно ставить терминатор, если устанавливается только один процессор. Без заглушки стабильность работы с одним процессором не гарантируется.

Терминатор, необходимый в случае использование одного процессора

Замечу, что для двухпроцессорных плат под socket370 не всегда нужен терминатор в случае установки только одного процессора. У многих плат терминация уже разведена на плате. В таком случае, установка заглушки не только не нужна, но даже вредна! Такова, например, Intel SAI2.

Плата запустилась с одним процессором, но поскольку я получил плату с частично поврежденным BIOS от HP (не работало встроенное видео), я решил начать работу с прошивки нового BIOS. Штатной (для HP варианта) утилитой phlash.exe я записал новый BIOS (от HP). Плата после прошивки запустилась нормально, встроенное видео заработало, но BIOS от HP оказался очень неудобным и капризным. Его единственным достоинством была возможность выбирать загрузочный диск из числа даже тех, которые подключены к внешним контроллерам (все обнаруженные диски образуют список, из которого можно выбирать желаемый).

BIOS от HP не поддерживал имеющийся на плате hardware monitor (далее по тексту HWM). HWM находится в микросхеме AS99127F, которая выполняет и другие функции, программная модель HWM части очень близка к Winbond W83782). Внешней программой (это был mbmon от Yoshifumi R. Shimizu, впоследствии он был немного переделан мной), удалось "добраться" до датчиков напряжений и температур, но из-за отсутствия инициализации HWM показания температур были бредовые (это легко поправимо в коде программы, но хотелось нормальный BIOS с правильной инициализацией HWM и страницей "Hardware Monitor" в SETUP).

Было решено заменить BIOS на родной, от ASUS. Но пока еще был прошит Phoenix BIOS от HP и могла работать только утилита прошивки phlash.exe. Эта утилита отказывалась прошивать "не свой" BIOS от ASUS. Для прошивки "чужого" BIOS потребовалось ввести ключ "/O" в командной строке запуска phlash.exe. Прошивка прошла успешно, и плата запустилась с BIOS от ASUS! После этого плату уже можно при необходимости прошивать по нормальному, утилитой aflash.exe от ASUS.

Напомню, что все это проводилось с одним процессором. Казалось бы, осталось снять терминатор, поставить второй процессор на его место и все, но не тут то было! Установка второго процессора (в сокет CPU2) привела к противному непрерывному писку встроенного speaker и мигающему курсору, плата не проходила POST!

В процессе экспериментов я пробовал прошивать более старые версии BIOS от ASUS, с ними с двумя процессорами плата проходила POST, даже загружалась OS, но speaker по прежнему издавал непрерывный противный писк. То же самое происходило, если поставить единственный процессор в сокет CPU2, а в сокет CPU1 - терминатор.

Я предположил, что как-то влияет встроенный HWM, но как именно? Мой коллега объяснил, что причина в отсутствии контроля температуры CPU2, и для устранения проблемы следует соединить проводником анод встроенного в процессор термодиода с соответствующим входом микросхемы HWM. Я внимательно обследовал плату, и обнаружил дорожку, идущую от ножки AL31 CPU (THERMDP, анод встроенного в процессор термодиода) к входу HWM, но на пути дорожки было предусмотрено место для чип-перемычки R124 (резистор с нулевым сопротивлением, расположен снизу третьего PCI слота), и эта перемычка не была установлена. Но зато вход HWM был подключен к терморезистору TR2 (находится около разъема CPU_FAN2) для замера температуры материнской платы.

Я установил чип-перемычку. Дополнительно, чтобы температура второго процессора правильно отображалась, было решено снять терморезистор (так как он оказался бы подключен параллельно термодиоду и вносил бы погрешность). Я также изменил номинал резистора R194, включенного между входом HWM и опорным напряжением (R194 расположен сверху микросхемы AS99127F) от 10Ком до 30КОм. Правильный номинал я "подсмотрел" в канале измерения температуры CPU1, а заменить резистор было необходимо для правильной передаточной характеристики делителя, и идентичности обеих каналов измерения температуры.

После этого - старт с двумя процессорами успешен! Температуры процессоров совпали очень точно (естественно, при равномерной нагрузке на процессоры под OS). Отмечу что пока мы в SETUP, то фактически работает только один процессор (CPU2, не CPU1 для этой платы) и температура второго CPU на странице "Hardware Monitor" всегда будет выше первого.

Почему же плата в заводском варианте оказалась фактически неработоспособной с двумя процессорами? Неужели компания ASUS забыла протестировать серверную двухпроцессорную плату с двумя процессорами? Конечно же нет! Просматривая единственную доступную инструкцию для этой платы - curdls-100.pdf (инструкция написана по видимому для ранних ревизий платы), я обратил внимание на фото страницы "Hardware Monitor" в BIOS SETUP.

Страница Hardware Monitor в SETUP CUR-DLS, старая версия BIOS

Хорошо видно, что контролируется температура лишь одного процессора, зато температура материнской платы имеет две точки контроля - MB и MB2. По видимому, ранняя (самая первая) версия BIOS была рассчитана на контроль температуры только одного процессора, а с новыми BIOS контролируется температура обоих CPU (но температура платы контролируется лишь в одной точке).

Страница Hardware Monitor в SETUP CUR-DLS, новые версии BIOS

Моя плата, видимо, была рассчитана на старый BIOS. Или просто её делали для HP, не думая об этом, т.к. HP не использует встроенный HWM (что для серверной платы довольно глупое решение).

Поскольку вольт-амперные характеристики терморезистора и диода не совпадают, а тип датчика температуры настраивается новым BIOS (программируются регистры HWM) на термодиод, то фиксировалась ненормальная температура процессора CPU2 и включался предупреждающий гудок. По сути, с "точки зрения" HWM, плата находилась при отрицательной температуре, т.к. напряжение на термодиоде в среднем около 0.7V, а на терморезисторе 1.7V.

В принципе, решить проблему видимо можно было, прошив самую старую версию BIOS (она размером 256KB, а все более новые - 512KB). Но судя по истории изменений, в новых версиях были исправлены многочисленные ошибки, да и по-любому хотелось бы контролировать температуру обоих CPU, тем более что это предусмотрено разводкой платы.

С HWM разобрались, можно запускать FreeBSD и проверять работу платы с двумя процессорами. Здесь упомяну, что на этой плате (по крайней мере в rev 1.03) не самым удачным образом размещены конденсаторы, из-за чего многие кулеры (в том числе и многие боксовые от Intel) просто невозможно установить. Я в конечном итоге остановился на небольших, но зато медных радиаторах с вентиляторами Sunon MagLev. С двумя Pentium III 1000MHz (SL52R) тепловой режим мне показался тяжеловатым, при большой нагрузке температура превышала 50 градусов, и понятно, что в летнюю жару будет еще больше. Это в принципе в рамках допустимого (максимальная температура для них 75 градусов), но для своего спокойствия я решил остановиться на варианте двух Pentium III 800MHz (SL4CD). Итоговая производительность меня вполне устроила, и температура процессоров не превышает 50 градусов (максимально допустимая температура для Pentium III 800MHz 80 градусов).

6. Проблема со стабильностью системы с двумя процессорами

В процессе тестирования платы во FreeBSD с двумя процессорами на первый взгляд все было хорошо, но при более тщательном тестировании обнаружилась проблема в виде сбоев, причем весьма разнообразных. Эти сбои случались только в двухпроцессорном (SMP) режиме, и только при запущенной XWindow (хотя на первых порах влияние XWindow было неочевидно, т.к. сбои в основном были не в видеосистеме). С одним процессором (или если просто программно отключить SMP, "kern.smp.disabled=1"), система была, как говорится "Rock Solid".

Ошибки случались в основном во время интенсивных прерываний от аппаратных устройств. Для того, чтобы быстрее вызвать сбой, я переводил диск(и) в режим PIO4 (в PIO режиме генерируется больше прерываний в единицу времени и больше нагрузка на процессор, чем в DMA) и начинал копировать файлы с одного диска на другой, а параллельно еще запускал программы с графическим выводом. Похожий эффект давало копирование больших файлов по сети. Сбои проявлялись по-разному, например, как остановка при копировании файлов, система как будто бы работала, но при необходимости доступа к HDD (например, даже просто дать простую команду типа ls), система уже не возвращалась обратно в командный промпт, и не было реакции на Ctrl+C. Обычно через некоторое время после этого система вообще переставала реагировать на нажатия клавиш. Иногда наблюдались ошибки swapper-а, разные ошибки контроллера APIC <local APIC error>, случались даже внезапные мгновенные перезагрузки (без kernel panic) и т.п. Всего уже и не упомнишь:)

При отключении ACPI, DPMS, разных опций для ускорения видео, использовании стандартного vesa видеодрайвера, система была чуть стабильнее, но проблему это не решило. Интересно, что если запускать XWindow командой xinit, а не startx, система была заметно более стабильна, но опять-таки, при интенсивных прерываниях рано или поздно система ломалась, помогал только аппаратный RESET с последующей проверкой файловых систем.

7. Поиск решения

Мы с коллегой долго ломали голову над этой проблемой, перепробовано было, казалось бы, все - как программные, так и аппаратные решения (смена процессоров, проверка с внешней видеокартой), но безрезультатно. Работа платы с двумя процессорами проверялась также с BIOS от HP и GateWay, сбои были с любым BIOS. BIOS от GateWay не совсем подходящий, тк рассчитан на версию платы с Ultra160 SCSI. Исправить это заменой модуля SCSI несложно, но это не было первостепенной задачей, так как этот BIOS все равно не решал проблему.

В сети были найдены сообщения от Oliver Hartmann о похожих проблемах с CUR-DLS, но еще с FreeBSD 5.3

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

Однако летом 2014 года мне неожиданно подарили вышеупомянутую Intel SAI2 - Dual Tualatin на том же ServerSet III LE (северный мост более свежей ревизии, чем на CUR-DLS, а южный мост другой - CSB5). Эта плата проверялась как с 2xPentium III 1000MHz (Coppermine), так и с 2xPentium III-S 1400MHz (Tualatin) - работало все очень стабильно с XWindow и двумя процессорами, проблема не проявлялась!

Меня, конечно, очень обрадовало, что наконец-то нашлась полностью рабочая плата на ServerSet, но CUR-DLS не давала покоя, тем более что судя по сообщениям от Oliver такая проблема не только у меня, и стало быть это скорее всего не дефект конкретного экземпляра, а какая-то общая особенность, которую наверняка можно преодолеть в software!

В очередной раз вернувшись к плате, я стал экспериментировать с исходными текстами Xorg, благо они легко доступны. Потерпев очередную неудачу, стал уже смотреть исходники mach64: это драйвер старых видеокарт Ati Rage (напомню, что на плате распаяна Ati Rage XL), я пробовал экспериментировать с настройками драйвера, но тоже безуспешно. Опять тупик!

Однако спустя некоторое время я вспомнил, что для области адресов памяти, отображаемых на память видеокарты, часто применяется технология Write Combining (далее по тексту - WC). По этой технологии последовательность операций записи слабоупорядочена (Weak Ordering). Запись данных в WC память не кэшируется в привычном смысле. Записываемые данные накапливаются во внутреннем буфере (32 байта для P6), который отделен от внутреннего L1 и L2 кэша. Данные задерживаются в буфере на некоторое время (например, до того, как программное обеспечение запишет данные в область адресов памяти за пределами диапазона текущего 32-байтного буфера), а затем уже готовым пакетом отдаются на шину. В отличие от кэша, буфер не обеспечивает когерентности данных. Буферизация записей в WС имеет еще одну особенность: при последовательной записи по одному адресу нескольких значений, в буфере останутся последние данные, записанные по этому адресу, а остальные записи могут быть потеряны. Понятно, что вряд ли можно применять такую технологию для чего-нибудь отличного от устройств управления видеовыводом (видеокарт).

В процессорах P6+ настройками кеширования регионов памяти управляют так называемые MTRRрегистры. Поддерживаются режимы: UnCacheable (UC); Write Combining (WC); Write-Through (WT); Write-Protected (WP); Write Back (WB). Для смены настроек кеширования во FreeBSD есть утилита memcontrol.

С помощью утилиты memcontrol я выяснил, что после запуска XWindow, драйвер mach64 включает WC для области адресов отображаемых на память видеокарты. Здесь идет речь об отображении памяти видеокарты как PCI устройства, под границей 4GB. В данном случае диапазон адресов 0xfb000000-0xfb3fffff (Начальный адрес может меняться при установке/снятии PCI карт). Вот эта строка в выводе memcontrol:

======================================================================================
0xfb000000/0x400000 pciacce write-combine active
======================================================================================

Интересно, что WC включается даже в драйвере vesa - это стандартный (GENERIC) драйвер vga, без модельно-специфических наворотов. Я предположил, что возможно, WC плохо работает в SMP режиме. Для проверки этого предположения я отключил WC следующей командой, которую надо давать после запуска XWindow:

======================================================================================
memcontrol set -b 0xfb000000 -l 0x400000 uncacheable
======================================================================================

"-b" устанавливает начальный адрес, "-l" длину области, правильные значения можно посмотреть, например, в вышеприведенном выводе "memcontrol list" (после запуска XWindow).

После этого несколько часов интенсивных тестов - нет проблем! Причина наконец найдена!!

Некоторое время для отключения WC я использовал простейший скрипт (его, конечно, надо запускать после запуска XWindow):

======================================================================================

#!/bin/sh
memcontrol set -b 0xfb000000 -l 0x400000 uncacheable

sleep 1

memcontrol list

======================================================================================

Однако такое решение нельзя назвать правильным, т.к. скрипт, во-первых, надо каждый раз запускать вручную после запуска XWindow; во-вторых, в промежуток времени между запуском XWindow и ручным отключением WC система будет находиться в нестабильном состоянии.

Анализ исходных текстов драйвера mach64 показал, что WC в нем всегда просто включается (в файле ati-vidmem.c), и для его отключения достаточно просто закомментировать или удалить включение атрибута WC (PCI_DEV_MAP_FLAG_WRITE_COMBINE).

В дальнейшем для драйвера mach64 был разработан более сложный патч, в котором вводится новая булева переменная, управляющая включением WC, (я назвал её "no_wc"). После этого режимом WC можно управлять из конфигурационного файла Xorg - xorg.conf.

Побочным эффектом отключения WC стало некоторое снижение производительности видео, но для меня это не особо критично, самое главное - замечательная SMP плата наконец-то заработала!

Отмечу, что драйвер видеокарт Matrox (mga) не использует WC, и такие видеокарты можно использовать без каких-либо доработок драйвера mga.

Одно разъяснение.

В SETUP CUR-DLS имеется опция <Video Memory Cache Mode>, которая может принимать значения: UC (UnCacheable) и USWC (UnCacheable, Speculative Write Combining). Эта настройка управляет включением WC для диапазона 0xb000-0xbffff. Вот часть вывода memcontrol при установке USWC:

======================================================================================


...

0xb0000/0x4000 BIOS write-combine fixed-base fixed-length set-by-firmware active 

0xb4000/0x4000 BIOS write-combine fixed-base fixed-length set-by-firmware active 

0xb8000/0x4000 BIOS write-combine fixed-base fixed-length set-by-firmware active 

0xbc000/0x4000 BIOS write-combine fixed-base fixed-length set-by-firmware active 

...

======================================================================================

Отсюда видно, что эта настройка в SETUP влияет на включение WC в наследуемых (legacy) адресах видеопамяти и на WC в диапазоне старших адресов (под границей 4GB) не влияет. Более того, после запуска XWindow, WC в диапазоне адресов 0xb000-0xbffff будет принудительно установлена в UnCacheable (даже если использовать стандартный видеодрайвер, включающий WC). Таким образом, попытки побороть баг изменением этой настройки бесполезны, да и по умолчанию эта опция в SETUP установлена как UC.

8. SuperMicro 370DL3

История с WC багом недавно получила неожиданное продолжение. Удалось приобрести отличную плату SuperMicro 370DL3 rev 1.21, за что отдельное спасибо Alex_Vac. Плата эта построена на том же чипсете, что и CUR-DLS, но исполнение заметно отличается в лучшую сторону – в частности, нет проблем с установкой вентиляторов, шина PCI64 может работать как на 66MHz, так и на 33MHz (настраивается джампером). Ревизия чипсета такая же. Я тестировал плату с PCI видеокартой Ati 3D Rage II +DVD (встроенного видео у 370DL3 нет). С двумя процессорами и включенном WC я также обнаружил сбои, но не такие частые, как было у CUR-DLS. После отключения WC система стала совершенно стабильна в SMP, и работает уже около ~2-х месяцев, собственно, эти строки пишутся с нее. Отмечу, что субъективно я не заметил снижения производительности у этой платы после отключения WC, тогда как на CUR-DLS это немного заметно. Я не знаю, как провести объективные тесты производительности видеокарты в среде FreeBSD, но честно говоря, это не так уж и важно, т.к. скорости видеокарты для моих задач достаточно.

SuperMicro 370DL3 с установленной Ati 3D Rage II +DVD

9. Выводы о причине проблемы со стабильностью

Я сделал вывод, что чипсеты ServerSet III в некоторых случаях плохо работают в SMP, если используется Write Combining для области памяти видеокарты. Похожий баг был обнаружен и у чипсета ServerWorks ServerSet III HE-SL, но этот чипсет - уже тема для отдельной статьи.

К сожалению, пока неясно, в каких случаях этот баг проявляется, в каких нет. У меня есть три предположения:

1. Этому багу подвержены определенные ревизии чипсетов;

2. Intel был осведомлен об этом баге, и при разработке своей платы SAI2 каким-то образом решил проблему, аппаратно и/или программно;

3. Виной всему - южный мост ROSB4. Он, правда, не является управляющим для PCI шины, но все же подключен к той же шине PCI, что и видеокарта, и в принципе, его влияние не исключено (тем более, что он уже "проштрафился" с IDE). Напомню, что на плате Intel SAI2 (где баг с WC не был обнаружен) используется новый мост CSB5, а не ROSB4.

Осталось непонятным, почему включение WC приводит к таким проблемам в SMP режиме, ведь WC используется лишь для области памяти VGA, и некорректная работа WC потенциально может приводить к проблемам с графикой, но не к таким, как описано выше. Могу предположить, что из-за аппаратного бага в чипсете использование WC в SMP режиме приводит иногда к записи по неправильным адресам, попадая на области памяти, занятые другими устройствами. Возможно, некоторая ясность будет внесена, если мне удастся приобрести плату ASUS TR-DLS (как я уже упоминал, это еще одна из немногих плат с южным мостом CSB5).

10. Собранная система

Северный мост платы CUR-DLS довольно сильно нагревался во время работы. Производители плат почему-то иногда ставят радиаторы на эти мосты в "Tualatin ready" платах, а для плат "Coppermine only" радиаторов обычно не предусмотрено, хотя греются мосты на них ничуть не меньше, а возможно, даже больше, из-за большего напряжения Vtt (1.5V для Coppermine и 1.25V для Tualatin). Северные мосты ServerSet III чипсетов имеют весьма необычную конструкцию – мост сам очень тонкий и закрыт металлической крышкой, покрытой лаком, в которой сделано четыре отверстия.

Северный мост CNB30LE (RCC-NB6635)

На CUR-DLS предусмотрены отверстия крепления радиатора, правда, не совсем стандартные, но мне удалось найти точно подходящий радиатор. Так как мост тонкий, то во избежание касания радиатором близлежащих SMD элементов между мостом и радиатором была проложена теплопроводная резинка, она также защищает лакированную поверхность моста от царапин. Термопасту я не применял во избежание затекания ее в отверстия на мосте. Теплоотвод, конечно, получился далеким от идеала, но радиатор заметно прогревается при интенсивной работе с памятью, т.е. некоторый теплоотвод имеется. Ну а вот фото платы в корпусе, это одна из моих рабочих станций (из-за кабелей, правда, плохо видно плату).

Я использую разнообразные дисковые интефейсы, поэтому установлены дополнительные контроллеры IDE и SATA. К встроенному в ROSB4 IDE подключен DVD привод и старый 1GB диск с DOS.

Система показала себя быстрой и стабильной. Хотя тестирование производительности не является темой данной статьи, тем не менее, отмечу высокую скорость контроллера памяти ServerSet III LE (CUR-DLS немного медленнее, чем SuperMicro 370DL3 или Intel SAI2). Также отмечу хорошую работу чипсета с PCI шиной, скорость линейного чтения, например, была близка к теоретически предельно возможной. Впрочем, об этом в другой раз.

11. Благодарности

Ну и самое главное - выражаю благодарности!

1. Моему коллеге, щедро делившемуся своим огромным опытом, без ценных советов которого ничего бы не получилось.

2. Max1024, постоянно помогающему с приобретением оборудования и ценными советами.

3. Alex_Vac, у которого я приобрел SuperMicro 370DL3.

4. Товарищу, подарившему мне плату Intel SAI2

Прилагаю архив с патчем для драйвера mach64 (с новой булевой переменной "no_wc") в стандартном "diff -u" формате. Патч делался для FreeBSD 8.4, но несложно перенести и на другие версии.

Надеюсь, этот материал будет кому-нибудь полезным.

Обсудить статью в специально созданной ветке форума. Эта статья прислана на конкурс.

Опубликовано 09.04.2017 г.

Дополнения или поправки на phantom@sannata.ru

На главную страницу сайта

На страницу конкурсов

Авторские права и условия копирования материалов