Изпечатай

[scorpio]

Май имам някаква лан карта из къщи...обаче няколко месеца ползвам линукс със същата вградена карта и нямаше проблеми...незнам откъде се получи тоя проблем, сигурно съм направил нещо аз...но немога да се сетя. Проблема обаче според мен не е в /etc/rc.d или /etc/sysconfig. Замених целите директории с тези от един backup...промяна не настъпи, а по времето на backup-а мрежата си бачкаше.
Иначе за временно решение на проблема сложих в /etc/rc.d/rc.local:
/sbin/ifdown eth0
/sbin/ifup /etc/sysconfig/network-scripts/ifcfg-eth0

[buboleck]

@teleport
И как реши, че проблема е в forcedeth драйвера? Ползвам nForce от от ~4 години. Имал съм nForce2, сега съм с nForce4 за интел, от другата седмица ще съм с nForce5 (570 про) за АМД, инсталирал съм линукс на доста машини с nForce чипсет, като поне 5-6 са били с различни дъна, и не съм имал абсолютно никакви проблеми с лан-а (да не говорим, че изобщо не съм имал проблеми с тях).

[teleport]

Цитат (buboleck @ Сеп. 09 2006,15:59)

@teleport И как реши, че проблема е в forcedeth драйвера? Ползвам nForce от от ~4 години. Имал съм nForce2, сега съм с nForce4 за интел, от другата седмица ще съм с nForce5 (570 про) за АМД, инсталирал съм линукс на доста машини с nForce чипсет, като поне 5-6 са били с различни дъна, и не съм имал абсолютно никакви проблеми с лан-а (да не говорим, че изобщо не съм имал проблеми с тях).

Ами поне на моята машина има проблем ( Nvidia Nforce 4 Ultra, Athlon64-3200+ ). "Проблема" се изразява в това, че и с forcedeth и с nvlan модули при трафик около и над 3Mbytes/sec без значение посоката натоварването на процесора скача над 50%. За стабилна скорост над 6Mbytes/sec изобщо не може да става дума. При същите условия само че с intel pro/1000 на pci шина натоварването на процесора е около 5% за стабилен трафик от 9.6-10.5 Mbytes/sec, пак без значение посоката.

Вярно е че тестовете са правени само на CentOS 3-3.7 и CentOS 4-4.4 с оригиналния кернел. Възможно е на други дистрибуций forcedeth драйвера да е значително по-нов и да работи по-стабилно, но аз държа машината ми да е със stock кернел, за да съм сигурен в пренасянето на нови неща на production машините....

[buboleck]

@teleport

CentOS е на базата на Redhat нали? Замислял ли си се да тестваш с друга дистрибуция? Лично аз съм ползвал с тези дъна Slackware с 2.6 ядро и Gentoo (с vanilla kernel и gentoo-sources).

P.S. И някога много отдавна Редхат 9.0 на дъно Abit с nForce2. От тогава не съм се ипробвал да инсталирам драйверите на Nvidia за чипсета им, а също и тогава се отказах да ползвам някога рпм базирана дистрибуция.

[teleport]

Няма смисъл да се разгаря спор за дистрибуций. Аз нямам проблем да тествам forcedeth драйвера докато намеря подходяща версия работеща коректно точно с моя чипсет/биос. Но както написах това е машина на която се тестват всички неща, които после се разнасят върху значителен брой CentOS базирани сървъри.

Съвета да се деактивира вградения лан и да се ползва външна карта е защото мисля че преди време mandrake беше редхат базирано. Нищо чудно сега mandriva да е федора базирана и съответно да има неподходяща версия на forcedeth в ядрото.

Отделно от това идеята scorpio да е в лан мрежа и да ползва вградения лан е изключително лоша поради чисто електрически съображения. На повечето вградени лан карти трансформаторчето е с ниска мощност и обикновенно не е залято със силикон. Тези трансформаторчета имат пробивно напрежение около 100 волта ( по стандарт трябва да е > 3000V ). Адски лесно е някоя утечка по лан мрежата да вдигне пик с подобно или по-голямо напрежение. Резултата е изгорял чипсет.

Външните лан карти го нямат този проблем ( поне засега ). При сериозен токов удар обикновенно прекъсва самото трансформаторче и пораженията са на стойност 5-6лв ( цената на една realtec 8139 базирана карта ).

[buboleck]

@teleport

Да, няма смисъл да спорим. Някога преди доста време Мандрейк беше на Редхат база, сега няма нищо общо (като изключим рпм пакетната система). Мисълта ми беше дали си тествал с чисто ядро.

[teleport]

Цитат (buboleck @ Сеп. 09 2006,18:36)

@teleport Да, няма смисъл да спорим. Някога преди доста време Мандрейк беше на Редхат база, сега няма нищо общо (като изключим рпм пакетната система).

Според мене имат доста общо. Рядко ми се случва мандрейк/мандрива .src.rpm да не се компилира и тръгне безпроблемно под CentOS/RHEL. Което не може да се каже за tgz пакети на слак/дебиан/генто където постоянно изскачат проблеми с библиотеки, каквито под centos или няма, различават се като имена или са значително по-стари. Примерно пакети базирани на boost или libsigc++ нямат почти никакъв шанс за директно компилиране на базовата система.

Цитат (buboleck @ Сеп. 09 2006,18:36)

Мисълта ми беше дали си тествал с чисто ядро.

Скоро не съм. Последно тествах с 2.6.14 доколкото помня. Подобрение в работата на forcedeth нямаше, но пък спря да работи коректно quagga-та и моментално се върнах на базовия кернел, защото рутинга ми е основно нещо, върху което трябва да работя и после да пренеса върху сървърите.

[scorpio]

Ааа...я не се карайте '> Просто понеже преди със същата хардуерна конфигурация нямах проблем, затова си мисля че друга лан карта няма да помогне...обаче сега от гледна точка на токовите удари - ако наистина е така то по-добре да слагам веднага външна лан карта...Утре ще я изровя и ще я слагам...дано да нямам проблеми с инсталацията и...

[redcure]

Би ли показал изходите от lsmod и lspci ?

[buboleck]

@scorpio

Вярно е за токовите удари. Ако имаш друга карта направо я слагай.

[scorpio]

# lsmod

Module                  Size  Used by
appletalk              33360  2
ipx                    25040  2
nvidia               4831060  8
raw                     9736  1
md5                     4480  1
ipv6                  244960  10
snd_seq_dummy           3332  0
snd_seq_oss            31460  0
snd_seq_midi_event      6912  1 snd_seq_oss
snd_seq                50520  5 snd_seq_dummy,snd_seq_oss,snd_seq_midi_event
snd_seq_device          7952  3 snd_seq_dummy,snd_seq_oss,snd_seq
snd_pcm_oss            51360  0
snd_mixer_oss          16384  1 snd_pcm_oss
snd_intel8x0           30240  1
snd_ac97_codec         88516  1 snd_intel8x0
snd_pcm                84748  3 snd_pcm_oss,snd_intel8x0,snd_ac97_codec
snd_timer              21000  2 snd_seq,snd_pcm
snd_page_alloc          9360  2 snd_intel8x0,snd_pcm
snd                    48896  11 snd_seq_oss,snd_seq,snd_seq_device,snd_pcm_oss,snd_mixer_oss,snd_intel8x0,snd_ac97_codec,s

nd_pcm,snd_timer
soundcore               8352  1 snd
ipt_REJECT              5120  4
ipt_LOG                 7168  8
ipt_state               2048  7
ipt_pkttype             1792  4
ipt_set                 2560  0
iptable_raw             2048  0
ipt_CLASSIFY            2304  0
ipt_CONNMARK            2304  0
ipt_ipp2p               9728  0
ipt_connmark            1792  0
ipt_owner               2944  0
ipt_recent             10264  0
ipt_iprange             1920  0
ipt_physdev             2320  0
ipt_multiport           2816  5
ipt_conntrack           2432  0
iptable_mangle          2816  1
ip_set_portmap          4736  0
ip_set_macipmap         4488  0
ip_set_ipmap            4480  0
ip_set_iphash           6536  0
ip_set                 19376  9 ipt_set,ip_set_portmap,ip_set_macipmap,ip_set_ipmap,ip_set_iphash
ip_nat_irc              2688  0
ip_nat_tftp             1920  0
ip_nat_ftp              3840  0
iptable_nat            23000  3 ip_nat_irc,ip_nat_tftp,ip_nat_ftp
ip_conntrack_irc       71616  1 ip_nat_irc
ip_conntrack_tftp       4160  1 ip_nat_tftp
ip_conntrack_ftp       72512  1 ip_nat_ftp
ip_conntrack           44972  9 ipt_state,ipt_conntrack,ip_nat_irc,ip_nat_tftp,ip_nat_ftp,iptable_nat,ip_conntrack_irc,ip_

conntrack_tftp,ip_conntrack_ftp
iptable_filter          2944  1
ip_tables              21632  19 ipt_REJECT,ipt_LOG,ipt_state,ipt_pkttype,ipt_set,iptable_raw,ipt_CLASSIFY,ipt_CONNMARK,ipt

_ipp2p,ipt_connmark,ipt_owner,ipt_recent,ipt_iprange,ipt_physdev,ipt_multiport,ipt_conntra

ck,iptable_mangle,iptable_nat,iptable_filter
af_packet              18316  2
ide_cd                 39200  0
loop                   14992  0
forcedeth              17664  0
tsdev                   7424  0
ehci_hcd               28936  0
ohci_hcd               19204  0
usbcore               114732  3 ehci_hcd,ohci_hcd
evdev                   9088  0
ext3                  124048  2
jbd                    50864  1 ext3

# lspci

00:00.0 Host bridge: nVidia Corporation nForce3 250Gb Host Bridge (rev a1)
00:01.0 ISA bridge: nVidia Corporation nForce3 250Gb LPC Bridge (rev a2)
00:01.1 SMBus: nVidia Corporation nForce 250Gb PCI System Management (rev a1)
00:02.0 USB Controller: nVidia Corporation CK8S USB Controller (rev a1)
00:02.1 USB Controller: nVidia Corporation CK8S USB Controller (rev a1)
00:02.2 USB Controller: nVidia Corporation nForce3 EHCI USB 2.0 Controller (rev a2)
00:05.0 Bridge: nVidia Corporation CK8S Ethernet Controller (rev a2)
00:06.0 Multimedia audio controller: nVidia Corporation nForce3 250Gb AC'97 Audio Controller (rev a1)
00:08.0 IDE interface: nVidia Corporation CK8S Parallel ATA Controller (v2.5) (rev a2)
00:0b.0 PCI bridge: nVidia Corporation nForce3 250Gb AGP Host to PCI Bridge (rev a2)
00:0e.0 PCI bridge: nVidia Corporation nForce3 250Gb PCI-to-PCI Bridge (rev a2)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
01:00.0 VGA compatible controller: nVidia Corporation NV18 [GeForce4 MX 440 AGP 8x] (rev a2)

Засега реших проблема като сложих драйвера (forcedeth) в /etc/modprobe.preload

[petcu5]

Пробва ли в контролния панел на мандривата да настроиш мрежовия интерфейс да се вдига при стартиране на машината? Опцията трябва да е в секцията мрежови карти/устройства, ако не се лъжа.

[gat3way]

Цитат

Скоро не съм. Последно тествах с 2.6.14 доколкото помня. Подобрение в работата на forcedeth нямаше, но пък спря да работи коректно quagga-та и моментално се върнах на базовия кернел, защото рутинга ми е основно нещо, върху което трябва да работя и после да пренеса върху сървърите.

Имах подобен проблем със същия контролер, върху nforce3 дъно на старата ми домашна машинка: не правеше огромна процесорна утилизация, но броя получени фреймове с преебан CRC или нестандартен размер (под 48/над 1500) беше висок. Пуснах го на half-duplex и изненадващо се реши проблема. Убедих се че не е от кабели и суичове, защото ги сменях, вкл. го връзвах директно с crossover кабел с друга машина...навсякъде правеше мизерии при FD. Нямам идея защо прави така и никъде не намерих информация защо. Правеше мизерията и под уиндоус със уиндоуските драйвери.

Добре че ми изгоря дъното и взех nforce4, сега нямам такъв проблем (което пак доказва тезата че кабеляците и суичовете са си ок).

Телепорт, ти поверяваш на тая мизерия работа с динамични рутинг протоколи?!? Бахмааму, мога да си представя колко flapping причинява тоя боклук...стига да е като това на старото ми дъно де, д*ба мама им на тия гамени от нвидия #@$#@%#$!#%#@

едит: но пък от това върху nforce4 дъното не се оплаквам, засега работи добре...и не съм забелязал cpu overhead при големи трафици.

[teleport]

Цитат (gat3way @ Сеп. 18 2006,11:27)

Телепорт, ти поверяваш на тая мизерия работа с динамични рутинг протоколи?!? Бахмааму, мога да си представя колко flapping причинява тоя боклук...стига да е като това на старото ми дъно де, д*ба мама им на тия гамени от нвидия #@$#@%#$!#%#@

Не разбира се. Проблема с quagga-та дойде от ядрото, не от лан картата. Пък и при новичка домашна машина с athlon64 естествено не останаха пари за свястна лан карта.

Истината за мене е Intel. Имам един кашон с марвели и броадкоми. Пазя ги са спомен и за подсещане никога повече да не поглеждам към подобни гадости.
01:04.0 Ethernet controller: Intel Corporation 82541GI/PI Gigabit Ethernet Controller
01:05.0 Ethernet controller: Intel Corporation 82541GI/PI Gigabit Ethernet Controller

Иначе работните машини са с Intel на pci-express и драйверите от sourceforge.