Титла: Неработеща мрежова платка - state UNKNOWN
Публикувано от: laskov в Jan 25, 2016, 15:36
# ip address list
2: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc mq master br0 state UP qlen 1000
link/ether 00:14:5e:18:0c:0e brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether 00:c0:26:74:07:fe brd ff:ff:ff:ff:ff:ff
inet 84.43.164.58/24 scope global eth1
valid_lft forever preferred_lft forever
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
link/ether 14:cc:20:02:74:27 brd ff:ff:ff:ff:ff:ff
inet 213.91.180.10/32 scope global eth2
valid_lft forever preferred_lft forever
# dmesg
[ 7.661592] bnx2 0000:03:00.0 eth0: Broadcom NetXtreme II BCM5708 1000Base-T (B1) PCI-X 64-bit 133MHz found at mem ce000000, IRQ 16, node addr 00:14:5e:18:0c:0e
[ 7.662761] bnx2 0000:06:00.0 eth1: Broadcom NetXtreme II BCM5708 1000Base-T (B1) PCI-X 64-bit 133MHz found at mem ca000000, IRQ 17, node addr 00:14:5e:18:0c:10
[ 7.762536] sundance.c:v1.2 11-Sep-2006 Written by Donald Becker
[ 7.762842] sundance 0000:08:03.0: PCI IRQ 24 -> rerouted to legacy IRQ 16
[ 7.763523] eth2: IC Plus Corporation IP100A FAST Ethernet Adapter at 0000000000016000, 14:cc:20:02:74:27, IRQ 16.
[ 7.764500] eth2: MII PHY found at address 0, status 0x786d advertising 01e1. В BIOS-а на машината мярнах, че IRQ-то е 11 и тръгнах да мисля в тази посока, но като видях # lspci -v
03:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet (rev 11)
Subsystem: IBM Device 0342
Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 27
Memory at ce000000 (64-bit, non-prefetchable) [size=32M]
Capabilities: [40] PCI-X non-bridge device
Capabilities: [48] Power Management version 2
Capabilities: [50] Vital Product Data
Capabilities: [58] MSI: Enable+ Count=1/1 Maskable- 64bit+
Kernel driver in use: bnx2
Kernel modules: bnx2
06:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet (rev 11)
Subsystem: IBM Device 0342
Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 28
Memory at ca000000 (64-bit, non-prefetchable) [size=32M]
Capabilities: [40] PCI-X non-bridge device
Capabilities: [48] Power Management version 2
Capabilities: [50] Vital Product Data
Capabilities: [58] MSI: Enable+ Count=1/1 Maskable- 64bit+
Kernel driver in use: bnx2
Kernel modules: bnx2
08:03.0 Ethernet controller: Sundance Technology Inc / IC Plus Corp IC Plus IP100A Integrated 10/100 Ethernet MAC + PHY (rev 31)
Subsystem: Sundance Technology Inc / IC Plus Corp Device 0201
Flags: bus master, medium devsel, latency 64, IRQ 16
I/O ports at 6000 [size=128]
Memory at c7effc00 (32-bit, non-prefetchable) [size=512]
[virtual] Expansion ROM at c6000000 [disabled] [size=64K]
Capabilities: [50] Power Management version 2
Kernel driver in use: sundance
Kernel modules: sundance
и кашата в главата ми започна да прелива. Какво може да причинява това "state UNKNOWN" ? # ifconfig eth2
eth2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 213.91.180.10 netmask 255.255.255.255 broadcast 0.0.0.0
ether 14:cc:20:02:74:27 txqueuelen 1000 (Ethernet)
RX packets 96 bytes 5760 (5.6 KiB)
RX errors 0 dropped 6024 overruns 0 frame 0
TX packets 60 bytes 3600 (3.5 KiB)
TX errors 2 dropped 60 overruns 0 carrier 0 collisions 0
# ping 213.91.180.9
PING 213.91.180.9 (213.91.180.9) 56(84) bytes of data.
From 213.91.180.10 icmp_seq=1 Destination Host Unreachable
From 213.91.180.10 icmp_seq=2 Destination Host Unreachable
From 213.91.180.10 icmp_seq=3 Destination Host Unreachable
А, защо е такава маската ?
Титла: Re: Неработеща мрежова платка - state UNKNOWN
Публикувано от: neter в Jan 25, 2016, 16:48
Като начало, с netmask 255.255.255.255 трудно ще ping-неш другия хост. Как се е получило това? С какво и как настройваш интерфейса? И при повече от един мрежови интерфейс е хубаво да добавяш "-I ethX" към ping командата, за да си сигурен, че минаваш през нужния при пробата.
Титла: Re: Неработеща мрежова платка - state UNKNOWN
Публикувано от: BRADATA в Jan 25, 2016, 17:14
laskov,
такива лайна съм виждал точно при броудкомски хардуер заради ACPI. Това, което правя на мойте сървъри с броудком мрежи е
echo "performance" >/sys/module/pcie_aspm/parameters/policy
Пробвай. Също така в драйвера можеш да кажеш да не се гаси мрежата при idle режими. Ама точните параметри трябва да си ги провериш с modinfo
Титла: Re: Неработеща мрежова платка - state UNKNOWN
Публикувано от: laskov в Jan 25, 2016, 17:42
...Как се е получило това? С какво и как настройваш интерфейса?... Понеже slackware настройва интерфейсите по старомоден начин и понеже аз съм много умен :) , в момента мрежата се настройва с два изпълними файла и с един конфигурационен :) И резултатът е този :) Първите експерименти с правилни (май :) ) настройки не са успешни...
Титла: Re: Неработеща мрежова платка - state UNKNOWN
Публикувано от: neter в Jan 26, 2016, 10:07
Понеже slackware...
Че що настройваш Slackware? Къде дяна Fedora-та? :) Съобщението "state UNKNOWN" не е задължително да е показател за проблем, но може да бъде предизвикано от друг проблем. Одеве видяхме грешно настроен интерфейс, поради което статусът на връзката на интерфейса може да не успее да се определи. Не разбрах, успя ли да постигнеш коректно изглеждаща конфигурация?
Титла: Re: Неработеща мрежова платка - state UNKNOWN
Публикувано от: laskov в Jan 26, 2016, 10:33
laskov,
такива лайна съм виждал точно при броудкомски хардуер заради ACPI. Това, което правя на мойте сървъри с броудком мрежи е
echo "performance" >/sys/module/pcie_aspm/parameters/policy
Пробвай. Също така в драйвера можеш да кажеш да не се гаси мрежата при idle режими. Ама точните параметри трябва да си ги провериш с modinfo
root@vn:~# cat /sys/module/pcie_aspm/parameters/policy
[default] performance powersave
root@vn:~# echo "performance" > /sys/module/pcie_aspm/parameters/policy
-bash: echo: грешка при запис: Действието не е позволено
Само да уточня, че броудкомските платки работят. Проблемът е с eth2, която е D-Link някакъв. Че що настройваш Slackware? Къде дяна Fedora-та? :)
Fedora имам само на лаптопа и не я използвам активно :) Съобщението "state UNKNOWN" не е задължително да е показател за проблем...
...Не разбрах, успя ли да постигнеш коректно изглеждаща конфигурация?
И аз вече си мисля това за "state UNKNOWN" , но повечето от примерите с такова състояние, които гледах в нета са с виртуални устройства. Коректно изглеждаща да, но работеща - не. root@vn:~# ip address show
...
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
link/ether 14:cc:20:02:74:27 brd ff:ff:ff:ff:ff:ff
inet 213.91.180.10/29 scope global eth2
valid_lft forever preferred_lft forever
...
root@vn:~# ping -I eth2 213.91.180.9
PING 213.91.180.9 (213.91.180.9) from 213.91.180.10 eth2: 56(84) bytes of data.
From 213.91.180.10 icmp_seq=1 Destination Host Unreachable
From 213.91.180.10 icmp_seq=2 Destination Host Unreachable
Титла: Re: Неработеща мрежова платка - state UNKNOWN
Публикувано от: Acho в Jan 26, 2016, 10:57
Малко железарското решение, ама пък като е такава кахърна карта, и спира цялата работа - не може ли да се смени тази LAN карта ?
Да се бодне една друга, най-обикновена и тривиална, да се инсталира модула за нея, и да се настрои интерфейса.
Титла: Re: Неработеща мрежова платка - state UNKNOWN
Публикувано от: laskov в Jan 26, 2016, 11:37
Да се бодне една друга, най-обикновена и тривиална, да се инсталира модула за нея, и да се настрои интерфейса. Тя е точно такава. Единственото особено нещо е, че е поставена в PCI слот, който е 3.3V и трябваше да търся да е такава. Питам се, дали трябва да повярвам на IBM, че само платките в техния списък на съвместими устройства може да тръгнат на това желязо (IBM System x3650 - [7979GSY] ) Още инфо: root@vn:~# ethtool eth2
Settings for eth2:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Link partner advertised pause frame use: No
Link partner advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pg
Wake-on: d
Current message level: 0x00000001 (1)
drv
Link detected: yes
Задаването на порт tp изглежда, че не е позволено.
Титла: Re: Неработеща мрежова платка - state UNKNOWN
Публикувано от: BRADATA в Jan 26, 2016, 13:51
Ама винаги тръгваме от зад напред... На това желязо няма да можеш да подкараш карта, дето не е одобрена. Т.е. отивай да четеш в интернетя и да си търсиш съвместима. След това (ако е толкова спешно) винаги можеш да го направиш с VLAN. Само нарисувай каква е идеята и ще го измислим :)
Титла: Re: Неработеща мрежова платка - state UNKNOWN
Публикувано от: laskov в Jan 26, 2016, 14:17
Ама винаги тръгваме от зад напред... :) Е, нали трябва да се пробва!? :) Междувременно, ето какво пробвах още :) : Вкарах му ръчно arp запис с MAC адреса на отсрещното устройство и ето какво казва ping сега: ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
няколко секунди след като съм го стартирал. На отсрещното устройство RX packets:0 , т.е., не праща пакети, въпреки, че така твърди ?
Титла: Re: Неработеща мрежова платка - state UNKNOWN
Публикувано от: laskov в Jan 27, 2016, 13:50
... винаги можеш да го направиш с VLAN. ... Направих го, но не ми харесва, понеже добавям ново активно устройство между мен и Интернета. На това желязо няма да можеш да подкараш карта, дето не е одобрена. IBM са поставили PCI riser и на него пише PCI, Затова реших да пробвам.
Титла: Re: Неработеща мрежова платка - state UNKNOWN
Публикувано от: BRADATA в Jan 27, 2016, 16:29
Те освен райзъра са поставили и една камара ограничения :) Ама ги пише в упътването...
Титла: Re: Неработеща мрежова платка - state UNKNOWN
Публикувано от: netgraph в 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-а. Ако не се е променил
вероятно ще означава, че е грешно (ако не е друг бъг в този стар драйвър).
Титла: Re: Неработеща мрежова платка - state UNKNOWN
Публикувано от: laskov в Feb 01, 2016, 12:02
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
Титла: Re: Неработеща мрежова платка - state UNKNOWN
Публикувано от: netgraph в 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
Реших да проверя съдържанието на 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 Гледай за всякакви съобщения свързани с картата и драйвъра.
Титла: Re: Неработеща мрежова платка - state UNKNOWN
Публикувано от: laskov в Feb 01, 2016, 16:32
Интересното при тази карта е, че си поисква IRQ-то при up операция, а не при инициализация, т.е. като направиш ip link set dev eth2 up и тогава се setup-ва IRQ-to.
Уникално! Вдигнат интерфейс и поставен кабел и 16: 0 0 0 0 IO-APIC 16-fasteoi eth2
Как ще върна после /proc/sys/kernel/printk ? С рестартиране ли? В момента cat /proc/sys/kernel/printk 3 4 1 7 Или преди това да му направя архив? :)
Титла: Re: Неработеща мрежова платка - state UNKNOWN
Публикувано от: netgraph в Feb 01, 2016, 18:21
Няма нужда, първата цифра ти е сегашния левел (3), след това направи
echo 3 > /proc/sys/kernel/printk
и ще върнеш старото ниво.
Титла: Re: Неработеща мрежова платка - state UNKNOWN
Публикувано от: laskov в Feb 02, 2016, 12:52
След зареждане на модула [516935.550891] sundance.c:v1.2 11-Sep-2006 Written by Donald Becker
[516935.551754] eth2: IC Plus Corporation IP100A FAST Ethernet Adapter at 0000000000016000, 14:cc:20:02:74:27, IRQ 16.
[516935.552808] eth2: MII PHY found at address 0, status 0x786d advertising 01e1.
След вдигане на интерфейса [517013.071026] eth2: Media selection timer tick, intr status 05c6, Tx 0 Rx 0.
[517013.071393] eth2: Setting full-duplex based on MII #0 negotiated capability
01e1.
[517023.103020] eth2: Media selection timer tick, intr status 05c6, Tx 0 Rx 0.
[517033.119069] eth2: Media selection timer tick, intr status 05c6, Tx 0 Rx 0.
... последния ред се повтаря през няколко сек. След няколко сек. става [517563.967023] eth2: Media selection timer tick, intr status 05c6, Tx 0 Rx 8000. След задаване на IP - нищо, но след ping eth2: Media selection timer tick, intr status 05c6, Tx c0 Rx 8000. След down на интерфейса [517566.383580] eth2: Shutting down ethercard, status was Tx c0 Rx 8000 Int 515.
[517566.383720] eth2: Queue pointers were Tx 0 / 0, Rx 0 / 0. Никакви други съобщения, дори при вадене и поставяне на кабела. Това може би също: поредица от
kernel: [518868.703184] 00 a7d30000 a7d30010 00018001(00) a5554402 8000002a
kernel: [518868.703314] 01 a7d30010 a7d30020 00018005(01) a5554c02 8000002a
... до
kernel: [518868.706722] 1a a7d301a0 a7d301b0 00018069(1a) bdaf4000 8000002a
kernel: [518868.706852] 1b a7d301b0 a7d301c0 0001806d(1b) bdaf4800 8000002a
kernel: [518868.706981] 1c a7d301c0 a7d301d0 00018071(1c) bdaf5000 8000002a
kernel: [518868.707124] 1d a7d301d0 00000000 00018075(1d) bdaf5800 8000002a
kernel: [518868.707264] 1e a7d301e0 00000000 00000000(00) 00000000 00000000
kernel: [518868.707403] 1f a7d301f0 00000000 00000000(00) 00000000 00000000
kernel: [518868.707541] TxListPtr=a7d301d0 netif_queue_stopped=1
kernel: [518868.707674] cur_tx=30(1e) dirty_tx=0(00)
kernel: [518868.707801] cur_rx=0 dirty_rx=0
kernel: [518868.709378] cur_task=30
|