Jump to content
Калькуляторы

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

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

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

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

 

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

Share this post


Link to post
Share on other sites

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

 

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 точно также бывало. Если у Вас не случалось раньше, то просто везло. Оно от нагрузки зависит.

Edited by st_re

Share this post


Link to post
Share on other sites
А правило то зачем удалять ?

 

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 до этого было :)

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this