Tue, Oct 19, 1999 at 15:35:48, Martin wrote about "[inet-admins] FreeBSD on aplha":
> Интересно, а у кого-нибудь FreeBSD "живет" на альфе? И каковы
> вчепятления?
Живет. AlphaPC 164SX, процессор 21164PC 533MHz, SRM V5.3.
Впечатления - ну кроме того, что была куча проблем от того, что платформа
абсолютно новая и неизвестная - в общем, живет. Серьезную нагрузку пока не
заводили, наверно, на днях запасной сквид на нее загоню, тогда расскажу.
Но стресс-тесты выдерживает.
Главное из общего впечатления - все сырое. FreeBSD после долгого сидения
исключительно на i386 начала снова вводить многоплатформенность и натыкается
на грабли на каждом шагу. В kern_fork(), например, берется разность двух
указателей, но предварительно каждый из них преобразовывается в unsigned
int. На i386 все нормально, но на альфе sizeof(int)==4, sizeof(void*)==8
(причем это на всех unices какие виделись на альфах, включая osf/1),
посему значащие биты теряются, и один Ёр-Оол Гуй знает,
не страшно ли это. На PR ответил Дима Тейблюм -
"в current это пофиксено, а в stable мне облом". В 3.2
не мог жить не на GENERIC'е - разнообразные падения на этапе загрузки.
В 3.3 начались проблемы с кривым определением скорости процессора -
реально ~531 MHz, а оно определяет наобум от 420 до 320. Посмотрел
диффы, выбросил добавленный в 3.3-RC вызов calibrate_clocks() -
все ok. Пишу в freebsd-alpha - "что за нафиг?" - приходит ответ,
мол, "мне тут жаловались, что на старых srm'ах сам bios
неправильно сообщает частоту, так я решил сам пересчитать;
а у вас совсем новый, так что ничччччего не понимаю". Без calibrate_clocks()
лучше, но все равно уходит на -0.36 секунды каждые 3 минуты (как раз
мегагерц погрешности определения тактовой проца). На днях
просто стала дико тормозить на вызове kvm'овских поисков типа /usr/bin/w -
виснет процесс, и все. На некоторых сборках ядра начинает работать со
скоростью 386'й - долго жал плечами, стал спрашивать, получил
ответ (от Solar Designer'а), что это ядро обрабатывает
попытки доступа по невыровненному адресу, а такая программная обработка
жутко тормозит. gcc 2.95.1 собраться не захотел - его недопатчили.
2.91.66 (egcs-1.1.2) стоит, работает. Тот же joe не собирался
стандартным 2.7.2.3 - internal compiler error, и все. egcs
взял его. Ни один package из поставки 3.2 не работал, пришлось пересобрать
все. NFS наверняка дохлый - "struct nfssvc_sock bloated (> 256bytes) // Try
reducing NFS_UIDHASHSIZ // struct nfsuid bloated (> 128bytes) // Try
unionizing the nu_nickname and nu_flag fields"...
Куча прикладных программ на те же соотношения размеров int и void* ругается
черными словами. Когда это Джо Аллен в своем joe наворачивает дикие
совершенно куски кода вместо того чтобы вызвать memset() и при этом
преобразовывает указатель в int ради взятия значения младших битов - это не
так страшно, это просто анноит варнингами при сборке. Но есть и похуже
варианты - например, из GNU m4:
==={
/* xx why this test? */
if ((int) old_regend[r] >= (int) regstart[r])
regend[r] = old_regend[r];
===}
(old_regend - типа char**)
Наконец, мелкая злобная диверсия - на всех опробованных видяхах в текстовом
режиме красный и синий цвета меняются местами ;) Иксы кое-как собрались (с
рекомендованным напильником), но не запустились - сервер умирает по SIGSEGV.
Итого - пока игрушка. Наверно, с 4.1 только станет пригодной на боевой
сервер. ;(
-- --
Valentin Nechayev
netch@lucky.net
II:LDXIII/DCCCLXXIII.CCC
=============================================================================
"inet-admins" Internet access mailing list. Maintained by East Connection ISP.
Mail "unsubscribe inet-admins" to Majordomo@info.east.ru if you want to quit.
Archive is accessible on
