Re: странности с GCP+linux+intel_e1000

От: Vladimir A. Butenko <CGatePro_at_mx_ru>
Дата: Tue 18 Nov 2003 - 12:22:53 MSK


On Tue, 18 Nov 2003 14:04:31 +0500
  <CGatePro@mx.ru> (Sergei Golod) wrote:
> Добрый день.
>
> 1) В процессе перехода с различных версий 4.1.* до 4.1.7 не обращал
> внимание, но сейчас только заметил что в списке процессов CGServer стал
> показываться одной строкой (одним процессом?), а не несколько (треды?) как
> раньше.

А это не от CGatePro зависит. Это Вы поставили штучку под названием redHat 9.0. В которой есть так называемая "новая тредовая библиотека". Она очень хорошая, почти как в "настоящем Унихе", одна только проблема - ошибок в ней тьма. И поэтому RedHat 9.0 официально не поддерживается. На их сайте написано, что они пофиксили с пяток существенных багов в этой библиотеке, но шансов на то, что пофиксили более-менее все - пока исчезающе мало.

> 2) более важный вопрос. Чем отличается CGP от других приложений, так что
> при
> работе клиента с CGP формируются битые tcp-пакеты. Я прекрасно понимаю,
> что
> сам цгп не занимается формированием tcp пакетов, это задача ядра, но
> почему
> именно эта ошибка вылазит только при работе с ним? (на сервере работает
> еще
> множество сервисов, но там такого нет.

И много из этих "сервисов" малтитредовые?

> вот пример сессии (самая важная строка самая последняя). Я согласен, что
> ошибка скорее всего окажется в ядре, но ПОЧЕМУ только с CGP я ее вижу? Все
> остальные программы работают на ура!

А кто его знает, как эта "новая тредовая библиотека" работает с ядром... Может, она ухитряется и в нем что-то прервать "не вовремя".   

> linux-2.6.0-test9/glibc-2.3/CGP-4.1.7+Intel Corp. 82545EM Gigabit Ethernet
> Controller
> при работе с другой картой (e100) все порядке. Можно хоть какой-то
> комментарий или направление поисков.
>
> tcpdump: listening on any
> 12:04:14.172321 80.237.69.225.1024 > 80.237.68.13.110: S [tcp sum ok]
> 150484900:150484900(0) win 5840 <mss 1460,sackOK,timestamp 14350
> 0,nop,wscale 0> (DF) (ttl 63, id 4010, len 60)
> 12:04:14.172390 80.237.68.13.110 > 80.237.69.225.1024: S [tcp sum ok]
> 1612337521:1612337521(0) ack 150484901 win 5792 <mss 1460,sackOK,timestamp
> 3142681 14350,nop,wscale 0> (DF) (ttl 64, id 0, len 60)
> 12:04:14.175691 80.237.69.225.1024 > 80.237.68.13.110: . [tcp sum ok]
> 150484901:150484901(0) ack 1612337522 win 5840 <nop,nop,timestamp 14350
> 3142681> (DF) (ttl 63, id 4011, len 52)
> 12:04:14.177464 80.237.68.13.110 > 80.237.69.225.1024: P
> 1612337522:1612337594(72) ack 150484901 win 5792 <nop,nop,timestamp
> 3142686
> 14350> (DF) (ttl 64, id 42350, len 124)
> 12:04:14.181309 80.237.69.225.1024 > 80.237.68.13.110: . [tcp sum ok]
> 150484901:150484901(0) ack 1612337594 win 5840 <nop,nop,timestamp 14351
> 3142686> (DF) (ttl 63, id 4012, len 52)
> 12:04:20.023640 80.237.69.225.1024 > 80.237.68.13.110: P [tcp sum ok]
> 150484901:150484924(23) ack 1612337594 win 5840 <nop,nop,timestamp 14935
> 3142686> (DF) (ttl 63, id 4013, len 75)
> 12:04:20.023695 80.237.68.13.110 > 80.237.69.225.1024: . [tcp sum ok]
> 1612337594:1612337594(0) ack 150484924 win 5792 <nop,nop,timestamp 3148532
> 14935> (DF) (ttl 64, id 42351, len 52)
> 12:04:20.026560 80.237.68.13.110 > 80.237.69.225.1024: P [tcp sum ok]
> 1612337594:1612337620(26) ack 150484924 win 5792 <nop,nop,timestamp
> 3148535
> 14935> (DF) (ttl 64, id 42352, len 78)
> 12:04:20.030002 80.237.69.225.1024 > 80.237.68.13.110: . [tcp sum ok]
> 150484924:150484924(0) ack 1612337620 win 5840 <nop,nop,timestamp 14936
> 3148535> (DF) (ttl 63, id 4014, len 52)
> 12:04:23.427247 80.237.69.225.1024 > 80.237.68.13.110: P [tcp sum ok]
> 150484924:150484936(12) ack 1612337620 win 5840 <nop,nop,timestamp 15275
> 3148535> (DF) (ttl 63, id 4015, len 64)
> 12:04:23.443311 80.237.68.13.110 > 80.237.69.225.1024: P
> 1612337620:1612337653(33) ack 150484936 win 5792 <nop,nop,timestamp
> 3151952
> 15275> (DF) (ttl 64, id 42353, len 85)
> 12:04:23.446858 80.237.69.225.1024 > 80.237.68.13.110: . [tcp sum ok]
> 150484936:150484936(0) ack 1612337653 win 5840 <nop,nop,timestamp 15277
> 3151952> (DF) (ttl 63, id 4016, len 52)
> 12:04:25.779515 80.237.69.225.1024 > 80.237.68.13.110: P [tcp sum ok]
> 150484936:150484943(7) ack 1612337653 win 5840 <nop,nop,timestamp 15510
> 3151952> (DF) (ttl 63, id 4017, len 59)
> 12:04:25.779744 80.237.68.13.110 > 80.237.69.225.1024: P
> 1612337653:1612337682(29) ack 150484943 win 5792 <nop,nop,timestamp
> 3154288
> 15510> (DF) (ttl 64, id 42354, len 81)
> 12:04:25.783252 80.237.69.225.1024 > 80.237.68.13.110: . [tcp sum ok]
> 150484943:150484943(0) ack 1612337682 win 5840 <nop,nop,timestamp 15511
> 3154288> (DF) (ttl 63, id 4018, len 52)
> 12:04:25.986225 80.237.68.13.110 > 80.237.69.225.1024: .
> 1612337682:1612337630(4294967244) ack 150484943 win 5792
> <nop,nop,timestamp
> 3154495 15511> (DF) (ttl 64, id 42359, len 0, bad cksum 0!)
>
> ---
> Sergei Golod. SIG11-RIPE. Computers Technologies Ltd. Tobolsk, Russia.
> http://www.tob.ru Tobolsk : +7 345 1151200, Mobile : +7 902 8503999
>
>
>
> ##################################################################
> Вы получили это сообщение потому, что подписаны на список рассылки
> <CGatePro@mx.ru>.
>
> Чтобы отписаться, отправьте сообщение на адрес <CGatePro-off@mx.ru>
> Чтобы переключиться в режим дайджеста - mailto:<CGatePro-digest@mx.ru>
> Чтобы переключиться в индексный режим - mailto:<CGatePro-index@mx.ru>
> Для административных запросов адрес <CGatePro-request@mx.ru>
>
>
>

Sincerely,
Vladimir Получено Tue Nov 18 09:25:12 2003

Этот архив был сгенерирован hypermail 2.1.8 : Fri 24 Apr 2015 - 16:12:52 MSK