[martin74]

Эх... А spec под centos-5.2 можно? ;)

[sdy_moscow]

ЕСТЬ!

2 дня дебага и вот оно!

Решение траблы с Макинтошами... (обидно что сразу не попалось на глаза, в итоге расковырял УСЁ!)

 

kernel/driver/ppp.c

 

333 строка

сейчас:

hdr->ack = seq_recv;

 

надо:

hdr->ack = htonl(seq_recv);

 

 

Могу залить на SVN, если кто-нибудь даст пароль :-)

Изменено 27 января, 2009 пользователем sdy_moscow

[xeb]

Могу залить на SVN, если кто-нибудь даст пароль :-)

может еще дать ключи от квартиры где деньги лежат ? :)

------------------------------------------------------------------------
r46 | xebd | 2009-01-27 10:45:33 +0300 (Втр, 27 Янв 2009) | 2 lines

fixed network bitorder bug (thanks to sdy_moscow)

 

https://sourceforge.net/project/showfiles.p...lease_id=656551

Изменено 27 января, 2009 пользователем xeb

[sdy_moscow]

Странно при сборке новой версии 0.8.2 взятой из SVN командой

 

make server

 

получаю:

 

(cd pptpd-1.3.3; ./configure)

/bin/sh: ./configure: Permission denied

make: *** [pptpd-1.3.3/Makefile] Error 126

 

 

при это 0.8.1 из другой папки собирается без проблем....

[sdy_moscow]

Да вот теперь я РЕАЛЬНО СЧАСТЛИВ - перевел все 5 серверов! И вот оно - ЧУДО загрузка на серверах где до 300-400 абонентов больше 20% не поднимается, а где железо поприличнее - вообще 7%, (НЕТ, ВРУ! 3%) , а было то 80-90!!

 

Огромное спасибо ХЕВ!!!!

Огромное спасибо ХЕВ!!!!

Огромное спасибо ХЕВ!!!!

Огромное спасибо ХЕВ!!!!

Изменено 28 января, 2009 пользователем sdy_moscow

[sdy_moscow]

такс... новая подтвержденная проблема... на 2-х разных машинах....

кернел паник если есть сетевухи интел...

походу происходит если накладываются софт-прерывания считывания и записи :-)

будем ковырять....

[sdy_moscow]

Так... вот что 1 наковырял...

 

ПОПРАВЬТЕ МЕНЯ ЕСЛИ Я НЕ ПРАВ!

 

Для начала (rcv и xmit) фактически вызываются из прерываний... по крайней мере xmit - может

(написано тут)

http://www.mjmwired.net/kernel/Documentati...generic.txt#223

 

а rcv - как заглушка к протоколу...

http://book.chinaunix.net/special/ebook/or...-24-SECT-3.html

 

вот значит-ся как написано тут:

http://www.linuxgrill.com/anonymous/fire/n...ng-HOWTO-5.html

 

spin_lock_bh - служит для локировок между юзер левел и хард левелом... а значит - нам ПО ИДЕИ для локировок нам надо-бы юзать spin_lock_irqsave().... кстати тут-же описаны атомик операции -не лучше ли использовать их вместо локировок?

 

spin_lock_bh(&opt->rcv_lock) - похоже надо менять на spin_lock_irqsave(&opt->rcv_lock),

spin_lock_bh(&opt->xmit_lock) - тоже похоже надо менять на spin_lock_irqsave(&opt->xmit_lock),

 

т.к. rcv-зовется из прерывания а буфер_ворк и хмит из ядра или из прерывания....

 

что касательно lookup_chan и del_chan - то тут похоже все ок, т.к. связки сессий в прерываниях мы вроде как не меняем...

а вот что касательно add_chan - то тут похоже надо менять write_lock_bh(&chan_lock) на write_lock_irqsave(&chan_lock)

т.к. из прерываний мы эту инфу получить пытаемся...

 

что касется lock_sock- то тут похоже тоже проблем нет т.к. как я понял - это сокет управления....

 

Так то с локировками вроде понятно - однако больше всего пугает как-бы это была не проблем перехлестывания работы с буфером skb

 

еще смущает работа с полем opt сруктуры приват.... надо тщательно проверить что ее нигде не надо локировать.... все-таки она используется в 2-хразных прерываниях на разных процессорах да еще и при изменени некоторых праметров + из iocontrol, к счетчиком может надо применить атомик?

 

самое главное остается вопрос с работой do_buf_work() т.к. я с ней еще толком не разобрался (для чего оно и как работает) комментов маловато :-(

 

....

Изменено 29 января, 2009 пользователем sdy_moscow

[xeb]

нет, ты не прав, нет там ни каких прерываний, всё работает в Softirq/BH

хотя похоже лучше использовать spin_lock вместо spin_lock_bh в xmit/rcv функциях

расскажи в каком месте упало

Изменено 29 января, 2009 пользователем xeb

[Ivantey]

EIP:[<f91f785e>] pptp_rcv

[sdy_moscow]

нет, ты не прав, нет там ни каких прерываний, всё работает в Softirq/BH

хотя похоже лучше использовать spin_lock вместо spin_lock_bh в xmit/rcv функциях

расскажи в каком месте упало

А какая разница - софтирк или не софт....

Вот если-бы ОБА ПРОЦЕССА чтения и записи работали в софт_иркна одном процессоре -то да.... но ведь нигде не написано что ядро вызывает хмит ГАРАНТИРОВАНО в софтирке, а значит он может быть легко прерван софтирк чтения..., а если даже хмит живет и в софт_ирк то один фиг может быть софт_ирк на другом процессоре (правда для локировок это не так критично, с точки зрения деадов, а вот совместному использованию буферов может прийти ПОЛНЫЙ кирдык ...

или я не прав?

 

и все-ж меня еще сильно беспокоет отсутвие блкоировки chan (а имеено опт) при хмит и ресив... ну где гарантия что кто-то начнет закрывать канал и тут произойдет прерывание......

например строчки

skb_queue_purge(&opt->skb_buf);

del_chan(po);

в pptp_release

помоему - это подвиг камикадзе - повезет не повезет, надо их местами поменять...

 

http://www.mjmwired.net/kernel/Documentation/spinlocks.txt

 

http://www.marathon.ru/~fedor/doc/progr/ke...g/glossary.html

 

ХЕВ - а у тебя аська есть, а то кое-что не понятно по буфер_ворк....

Изменено 29 января, 2009 пользователем sdy_moscow

[sdy_moscow]

Ладно...

я начинаю делать маленькое ответвление для кернел драйвера... 0.8.2.sdy

Изменено 29 января, 2009 пользователем sdy_moscow

[xeb]

А какая разница - софтирк или не софт....

большая

но ведь нигде не написано что ядро вызывает хмит ГАРАНТИРОВАНО в софтирке

кури сорцы

и все-ж меня еще сильно беспокоет отсутвие блкоировки chan (а имеено опт) при хмит и ресив... ну где гарантия что кто-то начнет закрывать канал и тут произойдет прерывание......

над этим нужно подумать ...

ХЕВ - а у тебя аська есть, а то кое-что не понятно по буфер_ворк....

а в профиль заглянуть ?

 

Изменено 29 января, 2009 пользователем xeb

[sdy_moscow]

такс... про профиль не догадался... щас буду... стучать!

[xeb]

 r50 | xeb | 2009-01-31 14:07:48 +0300 (Сбт, 31 Янв 2009) | 4 lines

* code cleanup
* changed packet receiving code
* more secure chan_lookup

[martin74]

[root@build ~]# svn checkout https://accel-pptp.svn.sourceforge.net/svnroot/accel-pptp/branch/0.8 accel-pptp-0.8
A    accel-pptp-0.8/kernel
...
...
A    accel-pptp-0.8/Makefile
A    accel-pptp-0.8/README
Checked out revision 52.


[root@build accel-pptp-0.8]# make server
echo Building kernel module
Building kernel module
(cd kernel/driver; make )
make[1]: Entering directory `/root/accel-pptp-0.8/kernel/driver'
using "/lib/modules/2.6.18-92.1.22.el5/build" kernel headers
make -C /lib/modules/2.6.18-92.1.22.el5/build SUBDIRS=/root/accel-pptp-0.8/kernel/driver modules
make[2]: Entering directory `/usr/src/kernels/2.6.18-92.1.22.el5-x86_64'
  CC [M]  /root/accel-pptp-0.8/kernel/driver/pptp.o
/root/accel-pptp-0.8/kernel/driver/pptp.c: In function 'pptp_rcv':
/root/accel-pptp-0.8/kernel/driver/pptp.c:530: ошибка: слишком много аргументов в вызове функции 'sk_receive_skb'
make[3]: *** [/root/accel-pptp-0.8/kernel/driver/pptp.o] Ошибка 1
make[2]: *** [_module_/root/accel-pptp-0.8/kernel/driver] Ошибка 2
make[2]: Leaving directory `/usr/src/kernels/2.6.18-92.1.22.el5-x86_64'
make[1]: *** [all] Ошибка 2
make[1]: Leaving directory `/root/accel-pptp-0.8/kernel/driver'
make: *** [module] Ошибка 2

[root@build accel-pptp-0.8]# uname -a
Linux build.lds.net.ua 2.6.18-92.1.22.el5 #1 SMP Tue Dec 16 11:57:43 EST 2008 x86_64 x86_64 x86_64 GNU/Linux
[root@build accel-pptp-0.8]# cat /etc/*rele*
CentOS release 5.2 (Final)

[sdy_moscow]

ядро старовато.... там видать по иному было :-(...

[martin74]

обычный centos. Обжегся я на новых ядрах, надоело. На этом же железе debian мало того, что ставится с бубном, так еще и зависает раз в два три дня... А под центосом - работает себе, не трогает никого....

 

[root@vpn5 ~]# lspci

00:00.0 Host bridge: Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller (rev 02)

00:02.0 VGA compatible controller: Intel Corporation 82G33/G31 Express Integrated Graphics Controller (rev 02)

00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 02)

 

[root@vpn5 ~]# cat /proc/cpuinfo

processor : 0

vendor_id : GenuineIntel

cpu family : 6

model : 15

model name : Intel® Pentium® Dual CPU E2180 @ 2.00GHz

 

root@vpn5 ~]# free

total used free shared buffers cached

Mem: 1016676 887408 129268 0 154516 417516

-/+ buffers/cache: 315376 701300

Swap: 2096472 0 2096472

 

 

сетевые интел гигабитки... Стоит 6 vpn серверов, на одном mppe отключено, на остальных - включено. По 500-600 коннектов тянут. Собсно и accel-pptpd хочется чтобы поднять цифирку. Пусть сервер стабильно работает до 1000 коннектов, это ж хорошо будет ;)

[sdy_moscow]

с интел гигабитками пока не все хорошо - падает в кернел панике....

[martin74]

ну я до падает еще не дошел - у меня не компилится ;)

[Умник]

sdy_moscow, падает исключительно с карточками от Intel? Или других просто нет?

В любом случае, нужен полный вывод паники с консоли (да хотя бы в виде фотки с монитора).

[sdy_moscow]

фотки есть в двух словах падает где-то в рсв...

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

там макефайл тянет типовой ядра....

я с гсс не силен.... поборюсь - скажу точно...

а фотки щас с тедефона вытащу :-(...

[Ivantey]

А ты еще сфоткать успел

[sdy_moscow]

а вот и фотки...

 

А ты еще сфоткать успел

я много чего успеваю... всего то было пол второго ночи... ;-)

 

еще б кто подсказал как дамп организовать...

Изменено 6 февраля, 2009 пользователем sdy_moscow

[sdy_moscow]

такс нашел где происходит гадость

pptp.c строка 158

if (opt->dst_addr.sin_addr.s_addr!=s_addr) sock=NULL;

 

похоже все-таки структура оказывается не залокированной .... :-(

Изменено 6 февраля, 2009 пользователем sdy_moscow

[xeb]

r53 | xeb | 2009-02-06 23:25:32 +0300 (Птн, 06 Фев 2009) | 3 lines
* fixed compilation issue for 2.6.18 kernel
* additional channel delete when sock is being freed