Перейти к содержимому
Калькуляторы

FreeBSD 7.2 падение из-за dummynet trap 12, page fault, etc...

После апгрейда системы на 7.2 периодически стала выплывать следующая фича.

 

ipfw: ouch!, skip past end of rules, denying packet
ipfw: ouch!, skip past end of rules, denying packet
ipfw: ouch!, skip past end of rules, denying packet
ipfw: ouch!, skip past end of rules, denying packet
ipfw: ouch!, skip past end of rules, denying packet
ipfw: ouch!, skip past end of rules, denying packet
ipfw: ouch!, skip past end of rules, denying packet


Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address   = 0xd
fault code              = supervisor read, page not present
instruction pointer     = 0x20:0xc08ce8f6
stack pointer           = 0x28:0xe5b16770
frame pointer           = 0x28:0xe5b16aa0
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 47 (dummynet)
trap number             = 12
panic: page fault
cpuid = 1
Uptime: 7h6m59s
Physical memory: 2034 MB
Dumping 205 MB:

 

google по запросу dummynet page fault выдает много чего интересного, но мало решений, из которых до сути проблемы мало кто дошел, а все решения на уровне колдовства с sysctl, без объяснения причин, опять же.

Одной из первых вылазит такая статья:

http://opennet.ru/base/sys/freebsd_panic_solution.txt.html

 

И как оказалось, СИСТЕМА ПАДАЕТ КОГДА УДАЛЯЕТСЯ ПРАВИЛО КОТОРОЕ

ОТПРАВЛЯЕТ ПАКЕТЫ НА DUMMYNET, причем без разницы, есть ли в данный

момент пакеты на обработке dummynet. Причем, когда загрузка меньше 1 (в

еденицах из top), то все нормально, а когда загрузка превышает 1 -

вероятность падежа повышается прямо пропорционально загрузке.

 

Решение:

 

Никогда не удалять правила фаервола, которые отправляют пакеты в DUMMYNET.

Создать при старте или при необходимости, определить пайпы или

queue и не торгать их больше. Надо запретить пакеты - или deny раньше по

фаерволу или дать пользователю пару бит в сек. Надо отменить шейпинг -

говорим "bw 0" или сказать skipto. Да, есть мнение, что наличее ненужных

pipe (так как скорость на них не лимитируется) только уменьшает

производительность (занимают память и dummynet с частотой Hz (из

параметров ядра) их обходит), но лучше так, чем kernel panic.

 

После замены логики - сервер без перезагрузок более недели.

 

P.S. Не пробывали только менять правила фаэрвола через сеты (ipfw set

см. man ipfw) - быть может там другая ситуация.

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

 

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

 

Господа на фре 8.0 никто с таким не сталкивался?

Самое простое мне сейчас конечно заапгредиться до 8.0.

 

Нагрузки не очень большие: 10-20 Кппс.

 

Или все же проблема в прокладке? :)

Такое происходит при выстановлении этого параметра в 0

/sbin/sysctl net.inet.ip.fw.one_pass=0

Т.е. когда пакет проходит через все правила фаервола.

В момент перезапуска скрипта он у вас скорее всего флушит все правила, пайпы и очереди в результате появляются пакеты которые не знают куда заворачивать, если таких пакетов много ядро уходит в паник :-)

Ушел копать как у нас там правила меняются, похоже на правду.

 

НО: все равно, у меня будет необходимость удалять клиента из трубы и вносить его в нее.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А правило то зачем удалять ?

 

ipfw add XXX pipe tablearg ip from any to table\(1\) out

ipfw add XXX pipe tablearg ip from table\(2\) to any out

(поправить по месту)

 

набейте table 1 и 2 списком IP с номерами пайпов, как параметры. и НИКОГДА не удаляйте эти 2 правила. Сделайте table 1 flush, если никого больше шейпить вдруг не надо. смена пайпа проходит через table delete, table add

 

И проблема стара. на 6 точно также бывало. Если у Вас не случалось раньше, то просто везло. Оно от нагрузки зависит.

Изменено пользователем st_re

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А правило то зачем удалять ?

 

ipfw add XXX pipe tablearg ip from any to table\(1\) out

ipfw add XXX pipe tablearg ip from table\(2\) to any out

(поправить по месту)

 

набейте table 1 и 2 списком IP с номерами пайпов, как параметры. и НИКОГДА не удаляйте эти 2 правила. Сделайте table 1 flush, если никого больше шейпить вдруг не надо. смена пайпа проходит через table delete, table add

 

И проблема стара. на 6 точно также бывало. Если у Вас не случалось раньше, то просто везло. Оно от нагрузки зависит.

Спасибо, буду копать.

Мне стыдно признаться, но у нас поменьше чем 6 до этого было :)

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.