Как исправить зависания сетевой карты?

[jakshi]

Возможно заголовок ошибочный. Расскажу по порядку.

Есть компьютер с установленным на нем FreeBSD 8.1.
В него воткнута 1 сетевая карта D-link DFE 520TX (смотрит в интернет) + 1 встроенная сетевая (смотрит в домашнюю сеть).
Компьютер служит шлюзом в интернет для домашней сети.
При определенных обстоятельствах, например: backup сервера с помощью rsync, просмотр iptv на одном из компьютеров домашней сети, пропадает связь сервера с интернетом. Связь появляется после выполнения команды:

Код: Выделить всё

 /etc/rc.d/netif restart && /etc/rc.d/routing restart 

Любопытная деталь - торренты скачиваемые через сервер, на скорости около 10 мегабайт в секунду, оказывают 0-ое влияние на состояние сервера, все работает хорошо.

Вопрос в том, есть ли программные решения проблемы? Я новичок в FreeBSD, поэтому многое в ней для меня ново, и возможно есть просто какой то параметр в конфигурационных файлах и т.п. который запросто решает мою проблему, и мне просто нужно знать его. Потому написал вопрос на этом форуме, возможно кто то из специалистов подскажет интересную мысль (заранее спасибо).

С другой стороны конечно эта мелкая проблема, которая на сегодняшний день решается скриптом в crontab который выполняет вышеуказанную команду при пропадании ping-а.
Так что советы поменять сервер вместе с сетевыми картами, будут чрезмерными. Впрочем отзывы о качестве работы в FreeBSD тех или иных сетевых карт, доступных на рынке, конечно очень интересны.

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[Гость]

ну и причем тут сетевая карта

[Alex Keda]

найдите старенькие xl0 или fxp0
если у вас 100 мегабит
или em0/bge0 если 1000
и будет вам щассье

[jakshi]

ну и причем тут сетевая карта

(Пожимает плечами) как уже сообщил, это только предположение, выскажите ваше мнение, пожалуйста.

[jakshi]

найдите старенькие xl0 или fxp0
если у вас 100 мегабит
или em0/bge0 если 1000
и будет вам щассье

Требует финансовых вложений. Думал о покупке пары гигабитных карт, но это пока дело будущего.
Благодарю за рекомендации.

[Гость]

При определенных обстоятельствах, например: backup сервера с помощью rsync, просмотр iptv на одном из компьютеров домашней сети, пропадает связь сервера с интернетом. Связь появляется после выполнения команды

ну дергать сеть каждый может
я знаю таких умников которые тоже не любили разбиратся
а просто ребутили машину, причем по ресету, потом я поругал, начали ребутить по ctrl+alt+del
но все равно это не выход

вообщем когда пропадает сеть
нужно смотреть
ifconfig -a
dmesg
tcpdump
итд
разбиратся нужно что да отчего

[jakshi]

При определенных обстоятельствах, например: backup сервера с помощью rsync, просмотр iptv на одном из компьютеров домашней сети, пропадает связь сервера с интернетом. Связь появляется после выполнения команды

ну дергать сеть каждый может
я знаю таких умников которые тоже не любили разбиратся
а просто ребутили машину, причем по ресету, потом я поругал, начали ребутить по ctrl+alt+del
но все равно это не выход

вообщем когда пропадает сеть
нужно смотреть
ifconfig -a
dmesg
tcpdump
итд
разбиратся нужно что да отчего

Во время пропадания сети:
ifconfig -a -- точно такой же как во время работы сети, один в один,
в dmesg - отсутствуют какие либо новые сообщения
в tcpdump наступает полная тишина и пустота.

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

[Гость]

для начала прекратите меня цитировать
есть кнопка ответить

во вторых
если разбиратся
то мы тоже хотим видеть вывод всех тех команд в то время когда пропадает сеть

если сбивается DMA то можно попробовать сделать ifconfig fxp0 down && ifconfgi fxp0 up
к примеру для fxp0, если у вас какойто другой то подставте нужный
а не делать полную переинициализацию как делаете вы

[Гость]

в третьих вы не показали ваш
uname -a
может там банально обновится до стеибла будет решением

[jakshi]

Код: Выделить всё

[root@proxy ~]# uname -a
FreeBSD proxy 8.1-RELEASE-p2 FreeBSD 8.1-RELEASE-p2 #0: Sat Feb 19 23:04:44 EET 2011     root@proxy:/usr/obj/usr/src/sys/PROXY_KERNEL  i386

У меня версия 8.1 RELEASE.
Вы считаете это плохой выбор?
Думал что STABLE - включает в себя экспериментальные вещи которые могут сбоить и потому для стабильности лучше оставаться на RELEASE, это мнение ошибочно?

[Гость]

екпериментальное то другое
а стеибл это все фиксы которые вышли после релиза
поищите в теме, недавно обсуждали о том как через svn обновится до стеибла

[jakshi]

Вывод ifconfig -a во время работы сети:

Код: Выделить всё

[root@proxy ~]# ifconfig
vr0: flags=8b43<UP,BROADCAST,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=82808<VLAN_MTU,WOL_UCAST,WOL_MAGIC,LINKSTATE>
        ether 00:24:e8:a7:65:b3
        inet 178.165.65.79 netmask 0xfffffc00 broadcast 178.165.67.255
       media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
vr1: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=82808<VLAN_MTU,WOL_UCAST,WOL_MAGIC,LINKSTATE>
        ether 00:22:b0:e1:e6:cf
        media: Ethernet autoselect (none)
        status: no carrier
vr2: flags=8a43<UP,BROADCAST,RUNNING,ALLMULTI,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=82808<VLAN_MTU,WOL_UCAST,WOL_MAGIC,LINKSTATE>
        ether 00:14:2a:94:31:cb
        inet 192.168.78.254 netmask 0xffffff00 broadcast 192.168.78.255
        inet 192.168.1.254 netmask 0xffffff00 broadcast 192.168.1.255
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
plip0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> metric 0 mtu 1500
ipfw0: flags=8800<SIMPLEX,MULTICAST> metric 0 mtu 65536
pflog0: flags=100<PROMISC> metric 0 mtu 33200
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=3<RXCSUM,TXCSUM>
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x7 
        inet6 ::1 prefixlen 128 
        inet 127.0.0.1 netmask 0xff000000 
        nd6 options=3<PERFORMNUD,ACCEPT_RTADV>

Во время сбоя в работе сети:

Код: Выделить всё

[root@proxy ~]# ifconfig
vr0: flags=8b43<UP,BROADCAST,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=82808<VLAN_MTU,WOL_UCAST,WOL_MAGIC,LINKSTATE>
        ether 00:24:e8:a7:65:b3
        inet 178.165.65.79 netmask 0xfffffc00 broadcast 178.165.67.255
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
vr1: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=82808<VLAN_MTU,WOL_UCAST,WOL_MAGIC,LINKSTATE>
        ether 00:22:b0:e1:e6:cf
        media: Ethernet autoselect (none)
        status: no carrier
vr2: flags=8a43<UP,BROADCAST,RUNNING,ALLMULTI,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=82808<VLAN_MTU,WOL_UCAST,WOL_MAGIC,LINKSTATE>
        ether 00:14:2a:94:31:cb
        inet 192.168.78.254 netmask 0xffffff00 broadcast 192.168.78.255
        inet 192.168.1.254 netmask 0xffffff00 broadcast 192.168.1.255
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
plip0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> metric 0 mtu 1500
ipfw0: flags=8800<SIMPLEX,MULTICAST> metric 0 mtu 65536
pflog0: flags=100<PROMISC> metric 0 mtu 33200
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=3<RXCSUM,TXCSUM>
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x7
        inet6 ::1 prefixlen 128
        inet 127.0.0.1 netmask 0xff000000
        nd6 options=3<PERFORMNUD,ACCEPT_RTADV>

вывод dmesg (последние строки), он остается все время тем же самым:

Код: Выделить всё

Root mount waiting for: usbus4 usbus3 usbus2 usbus1 usbus0
uhub0: 2 ports with 2 removable, self powered
uhub1: 2 ports with 2 removable, self powered
uhub2: 2 ports with 2 removable, self powered
uhub3: 2 ports with 2 removable, self powered
Root mount waiting for: usbus4
Root mount waiting for: usbus4
Root mount waiting for: usbus4
uhub4: 8 ports with 8 removable, self powered
Trying to mount root from ufs:/dev/ad4s1a
vr0: promiscuous mode enabled

Последний вывод tcpdump перед пропаданием сети:

Код: Выделить всё

01:45:35.396923 IP ns.maxnet.ua.domain > undef-gukov-kh.maxnet.ua.13863: 8339 NXDomain[|domain]
01:45:35.397208 IP undef-gukov-kh.maxnet.ua.45921 > ns.maxnet.ua.domain: 8340+ PTR? 92.101.221.95.in-addr.arpa. (44)
01:45:35.399077 IP ednikdk1.la.net.ua.50497 > 178.165.66.95.44307: Flags [S], seq 2540192321, win 8192, options [mss 1460,nop,nop,sackOK], length 0
01:45:35.399347 IP 10.101.32.137.1203 > 239.0.1.101.1234: UDP, length 1316
01:45:35.401494 IP 10.101.32.137.1203 > 239.0.1.101.1234: UDP, length 1316
01:45:35.404144 IP 10.101.32.137.1203 > 239.0.1.101.1234: UDP, length 1316
01:45:35.405765 IP 10.101.32.137.1203 > 239.0.1.101.1234: UDP, length 1316
01:45:35.407738 IP 10.101.32.137.1203 > 239.0.1.101.1234: UDP, length 1316
01:45:35.409731 IP 10.101.32.137.1203 > 239.0.1.101.1234: UDP, length 1316
01:45:35.417249 IP n122z172l103.bb122100.ctm.net.14575 > undef-gukov-kh.maxnet.ua.6881: UDP, length 14
01:45:35.422621 IP 101.106.32.95.dsl-dynamic.vsi.ru.58779 > undef-gukov-kh.maxnet.ua.31892: UDP, length 103
01:45:35.435538 IP 10.101.32.137.1203 > 239.0.1.101.1234: UDP, length 1316
01:45:35.435555 IP 10.101.32.137.1203 > 239.0.1.101.1234: UDP, length 188
01:45:35.436636 IP 64.34.22.229.42020 > 178.165.66.56.19791: UDP, length 103
01:45:35.448715 IP 10.101.32.137.1203 > 239.0.1.101.1234: UDP, length 1316
01:45:35.449300 IP dsl-189-134-184-24-dyn.prod-infinitum.com.mx.17737 > 178.165.66.56.19791: UDP, length 103
01:45:35.450346 ARP, Request who-has undef-gukov-kh.maxnet.ua tell gw-gukov-kh.maxnet.ua, length 46
01:45:35.453133 IP 10.101.32.137.1203 > 239.0.1.101.1234: UDP, length 1316
01:45:35.457200 IP 10.101.32.137.1203 > 239.0.1.101.1234: UDP, length 1316
01:45:35.460303 IP 10.101.32.137.1203 > 239.0.1.101.1234: UDP, length 1316
01:45:35.465822 IP 10.101.32.137.1203 > 239.0.1.101.1234: UDP, length 1316
01:45:35.468781 IP 10.101.32.137.1203 > 239.0.1.101.1234: UDP, length 1316
01:45:35.471492 IP 10.101.32.137.1203 > 239.0.1.101.1234: UDP, length 1316
01:45:35.473568 IP 10.101.32.137.1203 > 239.0.1.101.1234: UDP, length 1316
01:45:35.475768 IP 10.101.32.137.1203 > 239.0.1.101.1234: UDP, length 1316
01:45:35.478652 IP 10.101.32.137.1203 > 239.0.1.101.1234: UDP, length 1316
01:45:35.479112 IP 221-51-124-92.pppoe.irtel.ru.21686 > 178.165.66.141.54398: UDP, length 106
01:45:35.479939 IP 93-80-229-212.broadband.corbina.ru.20849 > 178.165.66.95.44307: UDP, length 67
01:45:35.480711 IP 10.101.32.137.1203 > 239.0.1.101.1234: UDP, length 1316
01:45:35.482698 IP 10.101.32.137.1203 > 239.0.1.101.1234: UDP, length 1316
01:45:35.484672 IP 10.101.32.137.1203 > 239.0.1.101.1234: UDP, length 1316
01:45:35.487362 IP 10.101.32.137.1203 > 239.0.1.101.1234: UDP, length 1316
01:45:35.489126 IP 10.101.32.137.1203 > 239.0.1.101.1234: UDP, length 1316
01:45:35.489187 IP ns.maxnet.ua.domain > undef-gukov-kh.maxnet.ua.45921: 8340 1/2/2 (159)
01:45:35.489504 IP undef-gukov-kh.maxnet.ua.58260 > ns.maxnet.ua.domain: 8341+ PTR? 169.125.171.79.in-addr.arpa. (45)
01:45:35.490145 IP ns.maxnet.ua.domain > undef-gukov-kh.maxnet.ua.58260: 8341* 1/2/4 (201)
01:45:35.490348 IP undef-gukov-kh.maxnet.ua.27942 > ns.maxnet.ua.domain: 8342+ PTR? 47.222.122.178.in-addr.arpa. (45)
01:45:35.490501 IP ntt9-ppp1862.osaka.sannet.ne.jp.25229 > 178.165.66.169.23579: UDP, length 98
01:45:35.491451 IP 10.101.32.137.1203 > 239.0.1.101.1234: UDP, length 1316
01:45:35.493381 IP 10.101.32.137.1203 > 239.0.1.101.1234: UDP, length 1316
01:45:35.506597 IP DCRP-curs00141.dhcp.unc.edu.https > undef-gukov-kh.maxnet.ua.57634: Flags [.], ack 16, win 64154, options [nop,nop,TS val 304006 ecr 378625177], length 0
01:45:35.515238 IP 10.101.32.137.1203 > 239.0.1.101.1234: UDP, length 1316
01:45:35.518404 IP 10.101.32.137.1203 > 239.0.1.101.1234: UDP, length 1316
01:45:35.523533 IP 10.101.32.137.1203 > 239.0.1.101.1234: UDP, length 1316
01:45:35.526799 IP 10.101.32.137.1203 > 239.0.1.101.1234: UDP, length 1316
01:45:35.529604 IP 10.101.32.137.1203 > 239.0.1.101.1234: UDP, length 1316
01:45:35.531358 IP 10.101.32.137.1203 > 239.0.1.101.1234: UDP, length 1316
01:45:35.533332 IP 10.101.32.137.1203 > 239.0.1.101.1234: UDP, length 1316
01:45:35.535327 IP 10.101.32.137.1203 > 239.0.1.101.1234: UDP, length 1316
01:45:35.537730 IP ns.maxnet.ua.domain > undef-gukov-kh.maxnet.ua.27942: 8342 NXDomain 0/1/0 (105)
01:45:35.538122 IP undef-gukov-kh.maxnet.ua.14494 > ns.maxnet.ua.domain: 8343+ PTR? 95.142.148.78.in-addr.arpa. (44)
01:45:35.546692 IP 10.101.32.137.1203 > 239.0.1.101.1234: UDP, length 1316
01:45:35.546719 IP 10.101.32.137.1203 > 239.0.1.101.1234: UDP, length 188
01:45:35.546732 IP 10.101.32.137.1203 > 239.0.1.101.1234: UDP, length 188
01:45:35.550407 IP 10.101.32.137.1203 > 239.0.1.101.1234: UDP, length 1316
01:45:35.552479 IP 10.101.32.137.1203 > 239.0.1.101.1234: UDP, length 1316
01:45:35.554254 IP 10.101.32.137.1203 > 239.0.1.101.1234: UDP, length 1316
01:45:35.554540 IP pc359h3023i25.med.unc.edu.https > undef-gukov-kh.maxnet.ua.65313: Flags [.], ack 1059, win 257, options [nop,nop,TS val 80324202 ecr 378625184], length 0
01:45:35.556158 IP 10.101.32.137.1203 > 239.0.1.101.1234: UDP, length 1316
01:45:35.558320 IP 10.101.32.137.1203 > 239.0.1.101.1234: UDP, length 1316
01:45:35.559349 IP epgw.tech-club.ru.59285 > undefined.maxnet.ua.61288: Flags [S], seq 1089630007, win 8192, options [mss 1440,sackOK,eol], length 0
01:45:35.560057 IP 10.101.32.137.1203 > 239.0.1.101.1234: UDP, length 1316
01:45:35.562501 IP 10.101.32.137.1203 > 239.0.1.101.1234: UDP, length 1316
01:45:35.564711 IP 10.101.32.137.1203 > 239.0.1.101.1234: UDP, length 1316
01:45:35.566555 IP 10.101.32.137.1203 > 239.0.1.101.1234: UDP, length 1316
01:45:35.568601 IP 10.101.32.137.1203 > 239.0.1.101.1234: UDP, length 1316
01:45:35.572754 IP 10.101.32.137.1203 > 239.0.1.101.1234: UDP, length 1316
01:45:35.575285 IP 10.101.32.137.1203 > 239.0.1.101.1234: UDP, length 1316
01:45:35.579559 IP 10.101.32.137.1203 > 239.0.1.101.1234: UDP, length 1316
01:45:35.581739 IP net24.181.94-167.chel.ertelecom.ru.16184 > undefined.maxnet.ua.57756: UDP, length 30
01:45:35.582123 IP 10.101.32.137.1203 > 239.0.1.101.1234: UDP, length 1316
01:45:35.583965 IP 41.218.236.142.12902 > undef-gukov-kh.maxnet.ua.35691: UDP, length 103

После команды

Код: Выделить всё

 ifconfig vr0 down && ifconfig vr0 up 

Сеть начинает работать снова.

Должен заметить что команда

Код: Выделить всё

 ifconfig fxp0 down && ifconfgi fxp0 up 

довольно забавная для удаленно управляемого сервера. хорошая штука. (смеется)

[Гость]

ifconfig vr0 down && ifconfig vr0 up
Сеть начинает работать снова.

попробуйте сменить 100 full-duplex
на half
при больших коллизиях сетевка может входить в ступор
но вот были ли фиксы по vr драйверу, я не помню
смотреть надо вашу
release 8.1
и дифф на stable 8.1

если не хлопотно
то лучше обновитесь до стеибла 8
svn co http://svn.freebsd.org/viewvc/base/stable/8/ /usr/src8/
а потом сделаете
diff -urN путь1 путь2
где путь1 путь2 - пути до драйвера vr в /usr/src и /usr/src8/
и посмотрите были ли изенения
если были можно или их перенести
или обновлять полностью фряху
если небыло
нужно включать дебаг сетевки и смотреть что именно там слетает
можно будет даже в рассылку написать
должны пофиксить, там на сетевках очень отзывчивый чел девелопер

[jakshi]

В своих суждениях насчет выбора RELEASE ветки, вместо STABLE руководствовался строками из handbook:

24.5.2.1 What Is FreeBSD-STABLE?

FreeBSD-STABLE is our development branch from which major releases are made. Changes go into this branch at a different pace, and with the general assumption that they have first gone into FreeBSD-CURRENT for testing. This is still a development branch, however, and this means that at any given time, the sources for FreeBSD-STABLE may or may not be suitable for any particular purpose. It is simply another engineering development track, not a resource for end-users.

24.5.2.2 Who Needs FreeBSD-STABLE?

If you are interested in tracking or contributing to the FreeBSD development process, especially as it relates to the next “point” release of FreeBSD, then you should consider following FreeBSD-STABLE.

While it is true that security fixes also go into the FreeBSD-STABLE branch, you do not need to track FreeBSD-STABLE to do this. Every security advisory for FreeBSD explains how to fix the problem for the releases it affects [1], and tracking an entire development branch just for security reasons is likely to bring in a lot of unwanted changes as well.

Although we endeavor to ensure that the FreeBSD-STABLE branch compiles and runs at all times, this cannot be guaranteed. In addition, while code is developed in FreeBSD-CURRENT before including it in FreeBSD-STABLE, more people run FreeBSD-STABLE than FreeBSD-CURRENT, so it is inevitable that bugs and corner cases will sometimes be found in FreeBSD-STABLE that were not apparent in FreeBSD-CURRENT.

For these reasons, we do not recommend that you blindly track FreeBSD-STABLE, and it is particularly important that you do not update any production servers to FreeBSD-STABLE without first thoroughly testing the code in your development environment.

If you do not have the resources to do this then we recommend that you run the most recent release of FreeBSD, and use the binary update mechanism to move from release to release.

И поскольку тут написано что это ветка для разработчиков, а не для конечных пользователей, и что главное назначение этой ветки - тестирование новых фич, думал что ее надо избегать на стабильных машинах.

То что написано в handbook о STABLE ветке и то чем она является в реальности, отличается?

т.е. вы на самом деле STABLE - это ветка для конечных пользователей где выкладываются исправления ошибок?

[Гость]

ок тогда так
http://www.freebsd.org/doc/en_US.ISO885 ... -tags.html

поскольку у вас была 8.1 RELEASE
иметт смысл обновится до 8.2 RELEASE в любом случае

в целом же вам нужно смотреть когда и были ли изменения в драйвере vr
если изменения были уже и в 8.2 RELEASE
то можно еще смелее обновляться и ожидать профита
если профит не помог
и найдете что изменения были и в 8 STABLE, то имеет смысл обновится и до него
и ожидать дальнейший профит

если профита не последует
псмотреть на HEAD и были ли там изменения


в целом же вам нужно только драйвер vr и его изменения
а что держать у себя на сервере это дело каждого)
все стараются держать RELEASE с фиксами

тоесть если через cvs
То это
RELENG_8_1
или
RELENG_8_2

RELENG_8 - это STABLE который сечас по немного движется в 8.3

[Гость]

т.е. вы на самом деле STABLE - это ветка для конечных пользователей где выкладываются исправления ошибок?

увы нет

http://lists.freebsd.org/pipermail/free ... 10617.html
http://www.opennet.ru/openforum/vsluhfo ... 87542.html

[jakshi]

Скачаю release и stable и посмотрю были ли какие то изменения в драйверах для vr сетевых карт. Спасибо за подсказку.
Тоже думал насчет - исчезнет ли проблема с сетью в FreeBSD 8.2, думаю обновиться как только будет официальный анонс.

Завтра попробую (спать уже хочется) пропадает ли сеть с half duplex - но мне думается это так себе выход, отключить дуплекс, чем он лучше перезагрузки сети по расписанию в случае сбоя?

[Гость]

half дуплекс лучше тем что не будет создавать коллизии

half /full асинхронные передачи итд
мне тоже уже лень рассказывать)
вы тогда уже сравнивайте изменения с HEAD по вашем драйверу
а еще лучше можете и не стагивать себе
а через svn.freebsd.org/ все полистать и посмотреть были изменения и когда
и в какую ветку уходили

[jakshi]

Попробовал включить half-duplex:

Код: Выделить всё

[root@proxy ~]# ifconfig vr0 media 100BaseTX mediaopt half-duplex
[root@proxy ~]# ifconfig -a
vr0: flags=8a43<UP,BROADCAST,RUNNING,ALLMULTI,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=82808<VLAN_MTU,WOL_UCAST,WOL_MAGIC,LINKSTATE>
        ether 00:24:e8:a7:65:b3
        inet 178.165.65.79 netmask 0xfffffc00 broadcast 178.165.67.255
        media: Ethernet 100baseTX
        status: no carrier

Сеть по прежнему пропадает иногда, при обстоятельствах описанных выше.

У меня есть сомнения что в FreeBSD эта карта работает в режиме half-duplex, потому что:

Код: Выделить всё

[root@proxy ~]# ifconfig -m vr0
vr0: flags=8a43<UP,BROADCAST,RUNNING,ALLMULTI,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=82808<VLAN_MTU,WOL_UCAST,WOL_MAGIC,LINKSTATE>
        capabilities=82808<VLAN_MTU,WOL_UCAST,WOL_MAGIC,LINKSTATE>
        ether 00:24:e8:a7:65:b3
        inet 178.165.65.79 netmask 0xfffffc00 broadcast 178.165.67.255
        media: Ethernet 100baseTX
        status: active
        supported media:
                media autoselect
                media 100baseTX mediaopt full-duplex
                media 100baseTX
                media 10baseT/UTP mediaopt full-duplex
                media 10baseT/UTP
                media none

Тут отсутствует надпись half-duplex (хотя конечно могу заблуждаться, может она подразумевается...)

Посмотрел изменился ли драйвер vr со времен 8.1 RELEASE в 8.2 RELEASE, STABLE и HEAD, изменения есть, но на мой взгляд, они вряд ли помогут в моей проблеме, но на 8.2 RELEASE конечно обновлюсь:

Код: Выделить всё

Revision 214909 - (view) (annotate) - [select for diffs]
Modified Sun Nov 7 11:12:29 2010 UTC (3 months, 2 weeks ago) by marius
File length: 68975 byte(s)
Diff to previous 213128

MFC: r213893, r213908, r214566, r214605, r214846

Convert the PHY drivers to honor the mii_flags passed down and convert
the NIC drivers as well as the PHY drivers to take advantage of the
mii_attach() introduced in r213878 (MFC'ed to stable/8 in r214684) to
get rid of certain hacks. For the most part these were:
- Artificially limiting miibus_{read,write}reg methods to certain PHY
  addresses; we now let mii_attach() only probe the PHY at the desired
  address(es) instead.
- PHY drivers setting MIIF_* flags based on the NIC driver they hang
  off from, partly even based on grabbing and using the softc of the
  parent; we now pass these flags down from the NIC to the PHY drivers
  via mii_attach(). This got us rid of all such hacks except those of
  brgphy() in combination with bce(4) and bge(4), which is way beyond
  what can be expressed with simple flags.

While at it, I took the opportunity to change the NIC drivers to pass
up the error returned by mii_attach() (previously by mii_phy_probe())
and unify the error message used in this case where and as appropriate
as mii_attach() actually can fail for a number of reasons, not just
because of no PHY(s) being present at the expected address(es).

Reviewed by:	jhb, yongari

Revision 213128 - (view) (annotate) - [select for diffs]
Modified Fri Sep 24 19:24:45 2010 UTC (5 months ago) by yongari
File length: 69054 byte(s)
Diff to previous 213126

MFC r211766:
  vr_init_locked() will stop and reset the controller. Remove
  unnecessary vr_stop()/vr_reset() calls.

Revision 213126 - (view) (annotate) - [select for diffs]
Modified Fri Sep 24 19:19:53 2010 UTC (5 months ago) by yongari
File length: 69114 byte(s)
Diff to previous 196045

MFC r211765:
  Remove unnecessary controller reinitialization.
  CAM filter handling was rewritten long time ago so it should not
  require controller reinitialization.

  PR:	kern/87506

Если у кого то есть еще идеи, то буду благодарен. Заранее спасибо.

[Гость]

напишите в рассылку фрибсд
в freebsd-net

[jakshi]

После обновление до FreeBSD 8.2 RELEASE проблема по прежнему на лицо.

[Гость]

half дуплекс лучше тем что не будет создавать коллизии

half /full асинхронные передачи итд

и в какую ветку уходили

что за ересь, коллизии никакого отношения к дуплексу не имеют.

[jakshi]

Купил за 4$ б\у сетевую карту 3com 905c.
Зависания при просмотре iptv исчезли.
Зависания при выполнении backup-а компьютера по rsync тоже пока отсутствуют.

Зависания наблюдались при использовании карты D-link DFE 520TX на чипе VIA Rhine III. Что любопытно, встроенная сетевая карта на базе VIA Rhine II чипсета, работает без каких либо нареканий.

Вывод: Может быть что FreeBSD драйвер для VIA Rhine чипсетов в порядке, а проблемы в сетевой карте D-link, а может проблема и там и там. В любом случае теперь буду относиться к сетевым картам D-Link с опаской.

[jakshi]

Спасибо Alex Keda за дельный совет.

[snorlov]

supported media:
media 100baseTX
media 10baseT/UTP

это и есть half режимы карты.... Поскольку карточки у тебя pci-ные можно было посмотреть на какие прерывания они садятся....