2
|
Linux секция за напреднали / Хардуерни и софтуерни проблеми / Re: Неработеща мрежова платка - state UNKNOWN
|
-: Feb 01, 2016, 14:47
|
root@vn:~# cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 0: 136 0 0 0 IO-APIC-edge timer 1: 0 0 0 0 IO-APIC-edge i8042 8: 7 6 8 7 IO-APIC-edge rtc0 9: 0 0 0 0 IO-APIC-fasteoi acpi 14: 0 0 0 0 IO-APIC-edge ata_piix 15: 104122 103905 103859 104202 IO-APIC-edge ata_piix 17: 127260 127121 127718 127332 IO-APIC 17-fasteoi aacraid 20: 0 1 1 1 IO-APIC 20-fasteoi i801_smbus 22: 0 0 0 0 IO-APIC 22-fasteoi uhci_hcd:usb3, uhci_hcd:usb5 23: 34 28 28 33 IO-APIC 23-fasteoi ehci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb4 26: 0 0 0 1 PCI-MSI-edge ioat-msi 27: 6746302 6745883 6746859 6744332 PCI-MSI-edge eth0 28: 8874951 8875745 8874201 8876774 PCI-MSI-edge eth1 NMI: 0 0 0 0 Non-maskable interrupts LOC: 16983150 20748146 18119945 17265400 Local timer interrupts SPU: 0 0 0 0 Spurious interrupts PMI: 0 0 0 0 Performance monitoring interrupts IWI: 0 0 2 1 IRQ work interrupts RTR: 0 0 0 0 APIC ICR read retries RES: 1558745 1681014 1166473 1247086 Rescheduling interrupts CAL: 819661 747299 677845 693111 Function call interrupts TLB: 5555 5848 5730 5947 TLB shootdowns TRM: 0 0 0 0 Thermal event interrupts THR: 0 0 0 0 Threshold APIC interrupts MCE: 0 0 0 0 Machine check exceptions MCP: 1420 1420 1420 1420 Machine check polls ERR: 0 MIS: 0
root@vn:~# cat /sys/class/net/eth2/carrier cat: /sys/class/net/eth2/carrier: Неправилен аргумент
root@vn:~# ls -la /sys/class/net/eth2/ общо 0 drwxr-xr-x 5 root root 0 фев 1 11:08 ./ drwxr-xr-x 3 root root 0 яну 27 12:41 ../ -r--r--r-- 1 root root 4096 фев 1 11:08 addr_assign_type -r--r--r-- 1 root root 4096 фев 1 11:08 addr_len -r--r--r-- 1 root root 4096 яну 27 12:41 address -r--r--r-- 1 root root 4096 фев 1 11:08 broadcast -rw-r--r-- 1 root root 4096 фев 1 11:03 carrier -r--r--r-- 1 root root 4096 фев 1 11:03 carrier_changes -r--r--r-- 1 root root 4096 фев 1 11:08 dev_id .....
root@vn:~# cat /sys/class/net/eth2/carrier_changes 0
Включването и изключването на кабела остава незабелязано за ядрото - никакви съобщения, никакви промени в carriar файловете, НО ... Реших да проверя съдържанието на operstate - down. Оказа се, че съм я оставил в "down". Зададох и IP и я вдигнах, при което съдържанието на operstate е вече "unknown", а на carrier е 1. Включването и изключването на кабела пак си остава незабелязано за ядрото, а съдържанието на никой от файловете не се променя. Светодиодите на портовете и от двете страни светват и премигват рядко, но предполагам, че това е по инициатива на суича, който пита за MAC адреса на платката, но такъв в таблицата на суича не се появява. И двете устройства казват, че връзката е 100Mbps FD.
Подозирам, че независимо от евентуален проблем с прекъсване или друго от страна на дънна платка, BIOS или OS, двете устройства трябваше да си научат MAC адресите.
Благодаря за подкрепата!
ПС: Оказа се, че при изваждане на кабела все пак нещо се променя: root@vn:~# cat /sys/class/net/eth2/duplex full root@vn:~# cat /sys/class/net/eth2/speed 100 root@vn:~# cat /sys/class/net/eth2/speed 10 root@vn:~# cat /sys/class/net/eth2/duplex half
Да, скоростта и дуплекса се четат чрез MDIO и няма общо с прекъсването, но това, че carrier не се засича и operstate-а не се променя определено означава, че прекъсването изобщо не е правилно и/или не успява да се setup-не. Интересното при тази карта е, че си поисква IRQ-то при up операция, а не при инициализация, т.е. като направиш ip link set dev eth2 up и тогава се setup-ва IRQ-to. Ако я смъкнеш и вдигнеш ръчно: $ ip link set dev eth2 down $ ip link set dev eth2 up Връща ли ти някаква грешка ? Това също означава, че cat /proc/interrupts и теста с кабела трябва да се правят, когато е up картата (e.g. след ip link set dev eth2 up) Още едно нещо - вдигни си нивото за съобщения на конзолата (echo 8 > /proc/sys/kernel/printk) и провери за debug съобщенията от драйвъра, може да изплюе някоя грешка или повече информация за това какво се случва. Edit: Сега забелязах, че трябва да му пуснеш дебъга при зареждане на модула: Да не те объркам, реда на стъпки е следния: 1. echo 8 > /proc/sys/kernel/printk 2. rmmod sundance (<- ако е зареден) 3. modprobe sundance debug=5 4. ip link set dev eth2 down 5. ip link set dev eth2 up Гледай за всякакви съобщения свързани с картата и драйвъра.
|
|
|
3
|
Linux секция за напреднали / Хардуерни и софтуерни проблеми / Re: Неработеща мрежова платка - state UNKNOWN
|
-: Jan 31, 2016, 20:14
|
Здравей, Според мен има малък шанс да се подкара тази карта щом се вижда изобщо. Този state е oper state на картата, който се получава според RFC 2863 (ifOperStatus) и се избира след link watch event, който сменя carrier състоянието или при инициализация без carrier (netif_carrier_off()). Това, че е UNKNOWN означава или че не е имала link event за смяна на carrier или не се е инициализирала без carrier. С две думи има вероятност IRQ-то наистина да е сгрешено, защото там се извършва проверката за carrier на този драйвър. Ако може да дадеш изхода от следните команди: cat /proc/interrupts cat /sys/class/net/<ethX, име на у-во>/carrier*
Като цяло това, че е в UNKNOWN не пречи да функционира, това просто означава, че не е инициализиран правилно oper state-а, все пак пробвай да смениш прекъсването от BIOS-а.
Edit: Лесен тест за прекъсването е ако изключиш кабела и го включиш, после провери пак oper state-а. Ако не се е променил вероятно ще означава, че е грешно (ако не е друг бъг в този стар драйвър).
|
|
|
5
|
Linux секция за напреднали / Хардуерни и софтуерни проблеми / Re: Управление на VLAN-ни
|
-: Jul 23, 2013, 03:35
|
<snip> Никога не съм реализирал нещо подобно и малко се притеснявам, дали ще има допълнителен товар върху машината от индивидуалното маршрутизиране за всяко IP. Повече се притеснява, че за всеки vlan интерфейс трябва да се вдигне tc qdisc и tc filter за да се ограничи скороста за сваляне. Има ли допълнителен товар от това нещо и евентуално колко?
Здравей отново, Радвам се, че си успял да си решиш проблема и си споделил подробно как за останалите. Относно въпросите ти - да, има допълнително натоварване разбира се. Рутирането на индивидуални адреси няма да ти е проблем, а ограниченията и правилата ще ти натоварят най - много машината. Всичко е относително и зависи от конфигурацията на филтрите, правилата, мрежовите настройки и естествено способностите на хардуера. Вероятно си стигнал до http://lartc.org/howto/ - това е един от най - изчерпателните ресурси за Линукс по тези теми Наблюдавай си натоварването както и броячите за различни грешки, закъснения на пакети в час пик и т.н.
|
|
|
6
|
Linux секция за напреднали / Хардуерни и софтуерни проблеми / Re: Управление на VLAN-ни
|
-: Jul 22, 2013, 02:58
|
Ще се опитам да обесня идеята с два примера:
1 Cisco 2950-24 портов без вдигнати vlan-ни, който е свързан към eth0 на линукс рутер. На eth0 са вдигнати две мрежи 10.111.1.1/24 и 10.111.2.1/24. Всичко работи, но има една голяма LAN мрежа, в която циркулира всичко - Broadcast, arp заявки от всеки до всеки, всичко каквото се сетите и всеки прави каквото си иска. Включително ако на някой му изтече интернета сканира за IP и MAC, сменя си IP-то и MAC-а и продължава да има интернет. Много грозна картина! 2 Cisco 2950-24 портов с вдигнати vlan-ни, който е свързан към eth0 на линукс рутер. На линукския рутер също са вдигнати две мрежи 10.111.1.1/24 и 10.111.2.1/24. Идеята е за всеки порт - отделен vlan, който идва до рутера. В рутера vlan-ните да не се смесват, но и да не са обвързани с конкретна мрежа. Всеки vlan да комуникира с един общ интерфейс, но да не може да комуникира с останалите vlan-ни, без да мине през общия интерфейс. По този начи го изброените недостатъци се свеждат до отделен порт - vlan.
inter-vlan routing (router on a stick) не е проблем да се направи, ако всеки vlan се обвърже с конкретна мрежа или част от мрежа. Това е неприемлив вариант.
Здравей, Едно от решенията на проблема ти се нарича proxy arp. Има много документация за това из интернет, няма да пресъздавам обяснения на български тук. На кратко идеята: Вдига се IP адрес X на N интерфейси (примерно в/у VLAN интерфейсите, които ти разделят мрежата) и се пуска proxy arp на същите интерфейси. След това чрез добавяне на статични пътища до използваните адреси по интерфейсите се постига свързаност м/у рутера и клиентите. Идеята на proxy arp е, че ако клиент от сегмент 1 търси клиент от сегмент 2, който е в същия subnet, то рутера ще се представи за търсения клиент (чрез ARP отговор) пред търсещия от сегмент 1 и ще започне да получава пакетите за него и да ги рутира към него в сегмент 2 (естествено ip_forwarding трябва да е пуснат). По този начин дори можеш да ограничиш скоростта м/у клиенти от един и същи IP subnet, които са в различни сегменти (VLAN-и). Ще ти дам една примерна конфигурация, която изпълнява това, което се опитваш да постигнеш ако съм те разбрал правилно. Можеш много лесно да постигнеш конфигурацията по точка 2. Ето един пример с мрежа 10.246.243.0/24 и VLAN 20 и 30: Рутер: echo 1 > /proc/sys/net/ipv4/ip_forward echo 1 > /proc/sys/net/ipv4/conf/eth0.20/proxy_arp echo 1 > /proc/sys/net/ipv4/conf/eth0.30/proxy_arp # Вдигаме адреса на рутера и на двата VLAN-а ip addr add 10.246.243.1/32 dev eth0.20 ip addr add 10.246.243.1/32 dev eth0.30 # Добавяме пътища до два клиента - единия във VLAN 20 (.2), другия в 30 (.3) ip route add 10.246.243.2/32 dev eth0.20 src 10.246.243.1 ip route add 10.246.243.3/32 dev eth0.30 src 10.246.243.1 След това можеш да пробваш от 10.246.243.2 зад VLAN 20 да достигнеш 10.246.243.3 във VLAN 30 и в ARP таблицата на клиентите ще забележиш, че .2 вижда .3 с MAC адрес рутера и същото за .3 към .2. Това е добре да го комбинираш със статичнa ARP таблица. За scale-ване, в момента в мрежа с 15000 клиента и ~ 2000 VLAN-a, подобна схема работи перфектно като в един broadcast domain има не повече от 10 човека. Не си защитен с/у крадене на интернет в отделните сегменти, но обикновено лесно се хваща крадеца ако е проблем. Ако в един сегмент някой си сложи адрес на клиент от друг сегмент, то той няма да постигне нищо, единствения проблем ще е, че хората от засегнатия сегмент няма да виждат въпросния адрес (тъй като вероятно крадеца ще отговаря с ARP отговори първи), което пак е доста лесно да се провери. Надявам се това да ти помогне Поздрави
|
|
|
7
|
Хумор, сатира и забава / Живота, вселената и някакви други глупости / Re: Ipad mini vs Nexus 7
|
-: Mar 25, 2013, 13:51
|
Здравей, имам нексус и iPad 4 с ретина и това, което ще кажа си е лично мое мнение и се отнася и за мини-то, тъй като впечатленията на един колега, който го ползва са същите. Според мен избери iPad. С Нексуса само проблеми както е написал предния юзър, а и батерията държи осезаемо по малко на активна работа от мини-то, а за големия да не говорим. Като offtopic ще напиша как използвам 4-ката, тъй като някои неща се отнасят и за мини: Трябва ми лаптоп, който държи поне 10 часа на активна работа с пуснат wi-fi, на който мога да закачам флашки и да имам vim + git (и да не тежи 100 кила). След jailbreak на 4-ката + клавиатурка, имам "лаптоп" с изключително висока резолюция, който издържа 14 часа на активна работа с пуснато wi-fi, на който имам git, vim и цялото git дърво на Линус (+ множество локални клонове) свалено, а и добро мултимедийно устройство След jailbreak с camera kit-a спокойно можеш да закачаш и флашки, до тук не съм имал проблем, въпреки че някои хора се оплакват, че флашките им не палят. Явно е въпрос на късмет :-) Та колкото и да не харесвам политиките на Apple, устройствата им определено ми допадат. Поздрави
|
|
|
10
|
Хардуер за Линукс / Сървъри / Re: Мрежова драма ...
|
-: Nov 28, 2012, 17:42
|
Даден interrupt може да бъде споределн м/у няколко устройства, не е задължително да имаш "конфликти" Не е лошо да са на отделни прекъсвания, може да си го оправиш от BIOS-а, въпреки че не мисля че това е проблема. А звуковата карта ако не я ползваш направо я спри от BIOS-a/махни от слота.
|
|
|
11
|
Хардуер за Линукс / Сървъри / Re: Мрежова драма ...
|
-: Nov 28, 2012, 16:56
|
Това за firmware-а няма общо. Това са показатели за различен тип натоварване най - общо казано. Може да видиш повече информация в man mpstat Запиши за 30тина (30 реда на mpstat 1) секунди тази информация докато се случва проблема, за да видим колко е натоварена машината по това време (докато се случва този проблем). Отделно е много важно да запишеш колко е общия трафик докато се случва това (и още по добре на всяка карта по отделно - input & output). Според мен (сега видях, че си писал, че картите ти са на PCI) проблема ти е в шината (заради повечето пакети/трафик). За това ти писах по горе да дадеш lspci -vv изход за картите, но като цяло щом ползваш 3 карти по 1G (предполагам правиш над 100 mbps на карта, за да има нужда) на PCI рано или късно ще имаш проблеми Добър инструмент за гледане на моментния трафик, който минава през машината (било то през 1 или през повече карти) е bmon (оригинално може да се намери на: http://www.infradead.org/~tgr/bmon/) Горе видях, че са ти препоръчали също и cacti (то е повече за агрегиран вариант на тази информация), но също ще свърши работа за тази цел, освен ако нямаш някакви странни кратки пикове. Инструмента си го избери, но е важно да видиш трафика, който минава докато се случва това и да се сметне дали тази шина (дори теоретично) може да издържи повече.
|
|
|
12
|
Хардуер за Линукс / Сървъри / Re: Мрежова драма ...
|
-: Nov 28, 2012, 15:49
|
Добре, тези карти имат доста малко броячи (това е между другото) Има един полезен пакет, който се казва sysstat (оригинално може да бъде намерен тук: http://pagesperso-orange.fr/sebastien.godard/) Разгледай инструментите, които предлага и най - вече виж mpstat (най - елементарния пример е mpstat 1 - което го кара да се ъпдейтва на всяка секунда за всички налични процесори). Не видях назад дали някой е питал за натоварване на машината докато се случва проблема, но чрез този инструмент (а и другите в пакета) може да провериш. Също така е важно да споделиш какъв трафик на карта/какъв трафик общо - докато се случва проблема. И все пак, за да проверим параметрите би ли споделил следното: lspci -vv Само частта за лан картите (няма нужда от целия изход).
|
|
|
13
|
Предложения и въпроси относно Linux-BG / Предложения за подобрения на сайта / Проблем с отварянето на linux-bg.org
|
-: Nov 28, 2012, 15:06
|
Здравейте, Имам проблем с пълното зареждане на http://www.linux-bg.org, тъй като браузъра се опитва да отвори ето това от сайта [img alt="GBG Офис" src=" http://gbgoffice.info/banners/gbg-90-30.gif" border="0" alt="gbgoffice"] Не се намирам в България, не знам как е през peering-а, но от мрежата на Ред Хат в Бърно не става. Опита евентуално timeout-ва, но това отнема доста време. Бих препоръчал да пуснете някакво елементарно скриптче, което да проверява елементите, които са извън ваш контрол, тъй като това не ми се случва за първи път. Този път просто реших да пиша по въпроса Поздрави Update: Всъщност сега пробвах и от машина в BG peering-а и състоянието е същото. Update 2: Добре вече работи, само се бави малко
|
|
|
14
|
Хардуер за Линукс / Сървъри / Re: Мрежова драма ...
|
-: Nov 28, 2012, 14:29
|
Здравей, от много голяма полза ще бъде ако покажеш изхода от следните команди: netstat -s и ethtool -S <interface> тази команда за всяка лан карта, която ползваш. и ethtool -k <interface> За всяка карта (това не е чак толкова важно, просто за информация). Интересно ще е да наблюдаваш чрез ethtool -S картата, където имаш проблем докато се случва и да се опиташ да забележиш дали някой от *_errors броячите се променя много/често по време на проблема (e.g. watch ethtool -S <interface> за всяка карта докато се случва проблема)
|
|
|
15
|
Програмиране / Общ форум / Re: Mouse driver
|
-: Nov 02, 2012, 18:38
|
Спецификация за проблема имах предвид, но сега видях, че от начало още искаш да е kernel модул На кратко drivers/input/input.c. А самата реализация вече може по много начини да се направи, най - лесния според мен е да редактираш input модула, който се използва за устройството и да се възползваш от input_inject_event() и другите експортнати функции от input. Успех
|
|
|
|