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

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


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

ЕСТЬ!

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

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

 

kernel/driver/ppp.c

 

333 строка

сейчас:

hdr->ack = seq_recv;

 

надо:

hdr->ack = htonl(seq_recv);

 

 

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

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

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


Ссылка на сообщение
Поделиться на другие сайты
Могу залить на 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

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

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


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

Странно при сборке новой версии 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 из другой папки собирается без проблем....

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


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

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

 

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

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

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

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

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

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


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

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

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

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

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

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


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

Так... вот что 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() т.к. я с ней еще толком не разобрался (для чего оно и как работает) комментов маловато :-(

 

....

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

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


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

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

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

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

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

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


Ссылка на сообщение
Поделиться на другие сайты
нет, ты не прав, нет там ни каких прерываний, всё работает в 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

 

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

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

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


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

Ладно...

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

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

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


Ссылка на сообщение
Поделиться на другие сайты
А какая разница - софтирк или не софт....
большая
но ведь нигде не написано что ядро вызывает хмит ГАРАНТИРОВАНО в софтирке
кури сорцы
и все-ж меня еще сильно беспокоет отсутвие блкоировки chan (а имеено опт) при хмит и ресив... ну где гарантия что кто-то начнет закрывать канал и тут произойдет прерывание......
над этим нужно подумать ...
ХЕВ - а у тебя аська есть, а то кое-что не понятно по буфер_ворк....
а в профиль заглянуть ?

 

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

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


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

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

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


Ссылка на сообщение
Поделиться на другие сайты
 r50 | xeb | 2009-01-31 14:07:48 +0300 (Сбт, 31 Янв 2009) | 4 lines

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

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


Ссылка на сообщение
Поделиться на другие сайты
[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)

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


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

обычный 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, падает исключительно с карточками от Intel? Или других просто нет?

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

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


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

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

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

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

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

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

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


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

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

 

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

 

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

06022009.jpg

06022009_004_.jpg

06022009_003_.jpg

06022009_002_.jpg

06022009_001_.jpg

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

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


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

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

pptp.c строка 158

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

 

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

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

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


Ссылка на сообщение
Поделиться на другие сайты
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

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


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

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!


Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.


Войти