FreeBSD for AMD64 & Mylex AcceleRAID 170

[yohimba]

Привет всем! Помогите решить одну проблемку с фрей.

Конфа машины: мать INTEL DG33FB, CPU Intel(R) Core(TM)2 Quad CPU @ 2.40 GHz, RAM 8 GB, сказевый контроллер Mylex AcceleRAID 170, FreeBSD 7. Система установлена на отдельном IDE диске, на рейде находилась только база данных PostgreSQL.
RAID 0+1 из пяти дисков (Enhanced Mirroring).

Долгое время я использовал FreeBSD (4.x, 5.x, 6.x жила на материнке Intel STL2), (7.0 на Intel DG33FB) с Mylex AcceleRAID 170.
mly0@pci0:6:1:0: class=0x010400 card=0x00521069 chip=0x00501069 rev=0x02 hdr=0x00

На архитектуре i386 все работало замечательно. Фирмваре контроллера самый последний из доступных.

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

Пришло время добавить в сервер памяти до 8 гигабайт, драйвер mly не умеет работать в режиме PAE и пришлось ставить FreeBSD 7.0 для amd64. FreeBSD ставилась с нуля, не апдейтом.

И вот тут началось, на загрузке сыплется:

Код: Выделить всё

kernel: SMP: AP CPU #1 Launched!
kernel: SMP: AP CPU #2 Launched!
kernel: SMP: AP CPU #3 Launched!
kernel: da0 at mly0 bus 1 target 0 lun 0
kernel: da0: <RAID 6 online > Fixed Direct Access SCSI-3 device
kernel: da0: 135.168MB/s transfers
kernel: da0: 87465MB (179128320 512 byte sectors: 255H 63S/T 11150C)
kernel: (da0:mly0:1:0:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0
kernel: (da0:mly0:1:0:0): Sense Error Code 0x0
kernel: (da0:mly0:1:0:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0
kernel: (da0:mly0:1:0:0): Sense Error Code 0x0
...

Но в итоге диск виден как /dev/da0. vmstat -i показывает, что контроллер mly0 живет один на прерывании 22, не с кем не соседствуя.


Попытка создать новый слайс на диске, а потом на нем создать файловые системы ни к чему не приводит.
Только что созданные файловые системы, не монтируются.
Попытка выполнить на них fsck, говорит что нет супер блока и мол все плохо.

Если же создать файловые системы из под i386, но потом начать их использовать под amd64, это приводит со временем к панике:

Код: Выделить всё

bad block 123456789, ino 176
dev = da0s1d, block = 4, fs = /mnt/da0/d
panic: ffs_blkfree: freeing free block
cpuid = 3
Uptime: 34 min...

После паники, на загрузке ядро точно также ругается на SUPER BLOCK у файловых систем на рейде, но если их убрать из fstab и дать системе загрузиться, то на загруженной системе fsck -y для этих файловых систем нормально выполняется. (вот этот факт меня в полный ступор вводит, может кто-нибудь объяснить такое поведение?)

Обратно на i386 ходу нету, так как сервер с 4 гигами памяти уже не справляется, пока все что раньше было на рейде, живет на SATA винте.

Что было уже сделано:

• Обновлен BIOS матери до последней версии - не помогает.
• Обновился до RELENG_7_1 (от 12 декабря 2008) - не помогает.
• Контроллер вставлялся в разные PCI-слоты на матери - не помогает.
• Вынимал память оставляя только 4 гига - не помогает.
• Менял геометрию в контроллере с 2G на 8G, пробовал оба варианта - не помогает.
• Пытался грузиться без ACPI - не грузится, падает панику, ругаясь как раз на Mylex, что не может занять 11-ое прерывание.

P. S.
Ради теста забивал первые 8 гигов диска нулями:

Код: Выделить всё

dd if=/dev/zero of=/dev/da0 bs=1024k count=8192

Все выполняется, но в процессе работы сей команды, также иногда сыплется:

Код: Выделить всё

kernel: (da0:mly0:1:0:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0
kernel: (da0:mly0:1:0:0): Sense Error Code 0x0

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[Alex Keda]

настоятельно рекомендую баг-репорт накатать....
========
сменить контроллер на что-то нормально работающее - нет возможности?

[yohimba]

сменить контроллер на что-то нормально работающее - нет возможности?

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

Валяется под рукой Intel SRCU31L (железка явно хуже на мой взгял), но man iir говорит что ему надо фирмваре обновлять, чтобы он превратился в SRCU31La. Я об него честно говоря голову совсем сломал, скачал новую прошивку с сайта Intel'а выставил перемычку на нем в режим обновления фирмваре. Запускаю перепрошивальщик он делает вид что обновляет, потом бодренько рапортует, что типа все обновлено, машину говорит перегружай. Выключаю, вставляю перемычку на место, гружусь - фирмваре старый. Занавес... Потерял несколько дней на него, в итоге плюнул.

[Alex Keda]

интел - ф топку...
они вообще странные какие-то...

[yohimba]

интел - ф топку...
они вообще странные какие-то...

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

В файлике сырцов src/sys/cam/scsi/scsi_da.c наткнулся на так называемые "выверты" для таких проблемных устройств. И хотя конечно, это не совсем правильное решение, но все таки хотелось бы проверить в этом ли проблема.

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

Во пример для какого-то CISS райд:

Код: Выделить всё

	{
		/*
		 * The CISS RAID controllers do not support SYNC_CACHE
		 */
		{T_DIRECT, SIP_MEDIA_FIXED, "COMPAQ", "RAID*", "*"},
		/*quirks*/ DA_Q_NO_SYNC_CACHE
	},

Компилить или не компилить, надо видимо как-то препроцессором проверять битность системы. Видимо с помощью #ifdef #endif ?

[zingel]

вписать нужно id в *.h и потом ещё поправить мейкфал для сборки, в общем, проще отпиши в PR

[yohimba]

вписать нужно id в *.h и потом ещё поправить мейкфал для сборки, в общем, проще отпиши в PR

Можешь пример для da_quirk_table[] чиркнуть? Если будет с патчем то думаю разработчики быстрее PR рассмотрят, хоть это будет и не совсем тот патч который нужен, но хоть поймут куда рыть...

[paradox]

что это бутчер не отреагировал на пост)

[zingel]

ты мне предлагаешь патч за тебя написать наивный чукотский юноша?

[yohimba]

ты мне предлагаешь патч за тебя написать наивный чукотский юноша?

Нет, не предлагаю. Пример я привел... Если не хотелось отвечать, то можно было и не отвечать. Я просто спросил что туда надо вписать? Первым параметром я так понимаю "MYLEX", вторым "AcceleRAID" ?

[zingel]

это смотря что ты напишешь в инклуде

[yohimba]

это смотря что ты напишешь в инклуде

А при чем инклуд, если это строки?

Код: Выделить всё

{T_DIRECT, SIP_MEDIA_FIXED, "COMPAQ", "RAID*", "*"},

[zingel]

а я понял, ну тогда добавть просто как хотел только новую строку, да, но насчёт

Код: Выделить всё

"RAID*"

сомневаюсь, не нашел пока его

Есть где потестить?

[yohimba]

То есть, писать надо:

Код: Выделить всё

{T_DIRECT, SIP_MEDIA_FIXED, "MYLEX", "RAID*", "*"},

Просто я так понимаю, если указать название неправильно, то эффекта никакого заметно не будет, поэтому меня и интересует сильно, что именно надо сюда писать.

Железка про себя говорит:

Код: Выделить всё

# pciconf -lv
...
mly0@pci0:6:1:0:        class=0x010400 card=0x00521069 chip=0x00501069 rev=0x02 hdr=0x00
    vendor     = 'Mylex Corp'
    device     = 'AcceleRAID Disk Array'
    class      = mass storage
    subclass   = RAID

[paradox]

если думаешь что поможет
проверь так

Код: Выделить всё

         * See if this device has any quirks.
         */
        match = cam_quirkmatch((caddr_t)&cgd->inq_data,
                               (caddr_t)da_quirk_table,
                               sizeof(da_quirk_table)/sizeof(*da_quirk_table),
                               sizeof(*da_quirk_table), scsi_inquiry_match);

        if (match != NULL)
                softc->quirks = ((struct da_quirk_entry *)match)->quirks;
        else
                softc->quirks = DA_Q_NONE;
+             softc->quirks = DA_Q_NO_SYNC_CACHE;

[yohimba]

если думаешь что поможет
проверь так

Thx! Уже компилю новое ядро, скоро узнаем, оно или не оно... Еще идея посетила SMP отрубить и посмотреть, что будет... Но это следующим шагом.

[zingel]

дифф выложи сюда потом если не сложно

[paradox]

если у тебя на 5 и 6 работал контроллер нормально
то лучше сделай дифф с них на 7
и посмотри сколько и много ли и что именно поменяли
так проще будет

[yohimba]

если у тебя на 5 и 6 работал контроллер нормально
то лучше сделай дифф с них на 7
и посмотри сколько и много ли и что именно поменяли
так проще будет

Он у меня на 64-битной версии фри никогда не работал... А на i386 он и под семеркой, и под шестеркой, пятеркой и четверкой нормально работал. Проблемы возникли только при переходе на 64 бита.

[paradox]

тогда смело пиши PR
думаю если это пофикстят разработчики будет лучше
чем ты будешь ломать контроллер))

[yohimba]

тогда смело пиши PR
думаю если это пофикстят разработчики будет лучше
чем ты будешь ломать контроллер))

PR напишу конечно обязательно. Надо только проблему досконально изучить. Имея опыт общения с разработчиками фри, я заметил, что они охотнее общаются когда уже к ним приходишь с чем-то, а не пустой.

Ну а теперь о патче. Во первых, paradox огромное тебе спасибо за подсказку, как точно врубить DA_Q_NO_SYNC_CACHE.

До отключения SMP не дошло слава Богу.
При новом ядре на загрузке нету злобных "SYNCHRONIZE CACHE. CDB: 35 0 0 0 ... Sense Error Code 0x0"
Диск без проблем также забился нулями с помощью команды dd if=/dev/zero of=/dev/da0 bs=1024k count=8192, тоже ни одного сообщения в логах про синхронизацию кеша.
После без проблем создал на диске слайс da0s1 и партицию da0s1d, монтируется размонтируется без проблем.
Создал на нем файл test размером 1GB.

Код: Выделить всё

# cd /mnt/da0/d
# dd if=/dev/zero of=test bs=1024k count=1024
1024+0 records in
1024+0 records out
1073741824 bytes transferred in 40.010031 secs (26836816 bytes/sec)

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

Теперь бы понять, что такого опасного есть в версии для 64-бит... Ведь в 32-ух битной все работает на ура, без всяких патчей.

[paradox]

покажи pciconf -lvc на твой контроллер

[yohimba]

покажи pciconf -lvc на твой контроллер

Код: Выделить всё

mly0@pci0:6:1:0:        class=0x010400 card=0x00521069 chip=0x00501069 rev=0x02 hdr=0x00
    vendor     = 'Mylex Corp'
    device     = 'AcceleRAID Disk Array'
    class      = mass storage
    subclass   = RAID
    cap 01[80] = powerspec 2  supports D0 D3  current D0

[paradox]

может он и под i386 должен без включеного кеша работать
тоесть с таким же флагом

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

значит твой винт доволен
и глючить небудет....

[yohimba]

может он и под i386 должен без включеного кеша работать
тоесть с таким же флагом

Но ведь работал под i386 без патча, при чем не день, не два, а несколько лет. И жила на этом рейде отнюдь не фигня какая-нибудь, а база PostgreSQL с не маленькой нагрузкой довольно.

Я вот чо подумал, из-за нехватки мощности блока питания такая фигня могла произойти? Ну предположим, что в 64-битном режиме может вдруг мощность БП надо поболее?