dadv

Официально не поддерживается пересборка ядра без пересборки ядерных модулей как раз вот из-за таких штук: опции сборки ядра могут сделать бинарно несовместимым его со старыми модулями. Поможет пересборка модуля с WITHOUT_INET6.

Проблема зависания mpd5 официально считается решенной. Для получения всех фиксов нужно обновиться до 10.3-STABLE или 11.1-RELEASE или 11.1-STABLE и обновить порт до mpd5-5.8_1 или новее. Если кому интересны технические детали, они есть тут: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=186114

Обошелся этим uboot recovery для 5000P: зашел через telnet на живую плату 1500P, скопировал /bin/upgrade в /ramdisk, по ftp скачал этот бинарник upgrade с живой платы, по ftp опять же загрузил этот upgrade на проблемную плату после выполнения uboot recovery прошивкой от 5000P и убийства процесса pbi плюс загрузил туда же target1.cod от прошивки 15PR002C и с консоли запустил /ramdisk/upgrade. Оно успешно прошило target1.cod, перезагрузило плату и потом уже штатным образом прошил оставшиеся target2.cod и target3.cod по официальной инструкции. Вопрос снят.

Удалось прошить - выполнить uboot recovery через http://data.nag.ru/PBI/Recovery/5000P%20upgarde.rar, после чего плата загрузилась и подняла прежний IP-адрес, можно зайти на неё по telnet и по ftp. Но эта прошивка для 5000P всё-таки не подходит для 1500P - в ней нет web-интерфейса и команда upgrade в ней не может корректно прошить файлы target[123].cod от 1500P. Всё ещё нужен правильный uboot recovery для 1500P.

Попробовал восстановить прошивку, воспользовавшись uboot_recovery.zip с файлами и инструкцией для 1400P. Теперь загрузчик больше не ругается на Bad Magic Number и начинает грузить прошивку и успешно стартует ядро Linux. Но так как прошивка всё-таки для немного другой железки, то она тоже не грузится до конца, ругаясь "load parameter error" и вываливаясь в shell, где не принимает ни одной команды и даже ругань выдаёт битую, типа такого: "so s!ch eile!or eirestor" вмеcто "No such file or directory". Очень нужен uboot_recovery для DMM-1500P

Дополню вопрос коллеги chopsuey12. На самом деле проблема в запоротой прошивке, так как U-Boot теперь ругается так в свой консольный порт на этой железке: U-Boot 1.1.3 (Nov 29 2006 - 08:31:49) U-Boot code: 007D0000 -> 007E76B0 BSS: -> 007F1B08 IRQ Stack: 007aef7c FIQ Stack: 007adf7c RAM Configuration: Bank #0: 00000000 16 MB Flash: 8 MB In: serial Out: serial Err: serial Hit any key to stop autoboot: 0 ## Booting image at 01030000 ... Bad Magic Number # iminfo ## Checking Image at 00000000 ... Bad Magic Number DCH-4000P # imls DCH-4000P # DCH-4000P # help tftp tftpboot [loadAddress] [bootfilename] Сам U-Boot не поврежден и может пинговать наш tftp-сервер. Весь вопрос теперь в том, где взять корректный loadAddress для команды tftpboot и аргументы для команд erase и cp.b, чтобы восстановить прошивку через U-Boot.

flowid_shift это решение другой проблемы, топик-стартеру это не поможет.

http://dadv.livejournal.com/139170.html#lagg http://dadv.livejournal.com/161010.html

Ни на что не намекаю. Просто уточнил, что это skipto ничего кардинально изменить и не мог.

Этот skipto не отменяет поиска по таблицам в правилах 1300 и 41000.

Функции rn_match и ipfw_chk, которые у вас в топе при профилировании это и есть поиск по таблицам ipfw, как и _rw_rlock. rn_match делает непосредственное сравнивание, а цепочка вызовов выглядит примеро так: ip_output > pfil_run_hooks > ipfw_check_hook > ipfw_chk > ipfw_lookup_table > rn_match > ... Делайте выводы.

Ещё один труднонаходимый источник проблем это dummynet, который не параллелится. Почитайте тут: http://forum.nag.ru/forum/index.php?showtopic=82298&view=findpost&p=810794

У нас нет NAT под такой нагрузкой, но несколько замечаний общего плана всё-таки дам. 1. В ipfw операция поиска по таблице ДОРОГАЯ. Старайтесь по возможности делать таблицы поменьше и по таким правилам не прогонять пакеты, которые заведомо не предназначены для этих правил. 2. Количество инстансов ipfw nat лучше всего сделать равным количеству физических ядер системы, как и количество тредов драйвера сетевой карты - для уменьшения lock contention, что и приводит к нелинейному росту загрузки процессора за счет ненужного оверхеда. 3. Обновите систему до STABLE, в интелевских драйверах были нужные обновления. 4. Прочитайте главу в Handbook про DTRace: http://www.freebsd.org/doc/handbook/dtrace.html Не пренебрегайте этим замечательным инструментом, он в неактивированном состоянии практически не сказывается на производительности системы. Прогоните профилирование хотя бы в течение пары минут в час наибольшей нагрузки, как написано в Handbook - узнаете, куда копать надо именно вам. 5. Почитайте Черникова: http://lists.freebsd.org/pipermail/freebsd-hackers/2012-July/039640.html

IPMI используется? Если да, тогда вам сюда: http://dadv.livejournal.com/173258.html

Могу добавить только одно - пробуйте