Няма нужда, първата цифра ти е сегашния левел (3), след това направи
echo 3 > /proc/sys/kernel/printk
и ще върнеш старото ниво.

Код:

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
Гледай за всякакви съобщения свързани с картата и драйвъра.

Здравей,
Според мен има малък шанс да се подкара тази карта щом се вижда изобщо. Този 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-а. Ако не се е променил
вероятно ще означава, че е грешно (ако не е друг бъг в този стар драйвър).

http://www.neterra.tv/ предлагат OTT услуга (и бокс по желание), но не мога да коментирам за качеството.
Със сигурност работят активно по нея, добавят нови опции и има движение.
Още за бокса и услугата може да намериш тук: http://www.neterra.tv/page/mag

 

<snip>
Никога не съм реализирал нещо подобно и малко се притеснявам, дали ще има допълнителен товар върху машината от индивидуалното маршрутизиране за всяко IP.
Повече се притеснява, че за всеки vlan интерфейс трябва да се вдигне tc qdisc и tc filter за да се ограничи скороста за сваляне. Има ли допълнителен товар от това нещо и евентуално колко?

Здравей отново,
Радвам се, че си успял да си решиш проблема и си споделил подробно как за останалите. Относно въпросите ти - да, има допълнително натоварване разбира се.
Рутирането на индивидуални адреси няма да ти е проблем, а ограниченията и правилата ще ти натоварят най - много машината. Всичко е относително и зависи от
конфигурацията на филтрите, правилата, мрежовите настройки и естествено способностите на хардуера. Вероятно си стигнал до http://lartc.org/howto/ -
това е един от най - изчерпателните ресурси за Линукс по тези теми 
Наблюдавай си натоварването както и броячите за различни грешки, закъснения на пакети в час пик и т.н.

[1]

Ще се опитам да обесня идеята с два примера:

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 отговори първи), което пак е доста лесно да се провери.
Надявам се това да ти помогне 

Поздрави

Здравей, имам нексус и iPad 4 с ретина и това, което ще кажа си е лично мое мнение и се отнася и за мини-то, тъй като
впечатленията на един колега, който го ползва са същите.
Според мен избери iPad.
С Нексуса само проблеми както е написал предния юзър, а и батерията държи осезаемо по малко на активна работа
от мини-то, а за големия да не говорим.

Като offtopic ще напиша как използвам 4-ката, тъй като някои неща се отнасят и за мини:
Трябва ми лаптоп, който държи поне 10 часа на активна работа с пуснат wi-fi, на който мога да закачам
флашки и да имам vim + git (и да не тежи 100 кила). След jailbreak на 4-ката + клавиатурка, имам "лаптоп" с изключително висока
резолюция, който издържа 14 часа на активна работа с пуснато wi-fi, на който имам git, vim и цялото git дърво
на Линус (+ множество локални клонове) свалено, а и добро мултимедийно устройство 
След jailbreak с camera kit-a спокойно можеш да закачаш и флашки, до тук не съм имал проблем, въпреки че
някои хора се оплакват, че флашките им не палят. Явно е въпрос на късмет :-)

Та колкото и да не харесвам политиките на Apple, устройствата им определено ми допадат.

Поздрави 

Ем те дивайсите повече от свободните прекъсвания.

Това не е вярно, според http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html има 224 user-defined прекъсвания в IA-32.
Сега колко от тях може да се използват всъщност е друг въпрос, но при всички положения ще има достатъчно за този случай.
(А ако мине на PCIe вече може да станат още много повече)

The IA-32 Architecture defines 18 predefined interrupts and exceptions and 224 user defined interrupts, which are
associated with entries in the IDT.

GytOS според мен това е заради аватара ти 

хаха знаех си :-)

Ние пък в БГ си го отваряме супер бързо.

Докато имаше проблем засягаше и BG, както написах в "Update" пробвах и от машина в BG peering-а.

 

Даден interrupt може да бъде споределн м/у няколко устройства, не е задължително да имаш "конфликти"
Не е лошо да са на отделни прекъсвания, може да си го оправиш от BIOS-а, въпреки че не мисля че това е проблема.
А звуковата карта ако не я ползваш направо я спри от BIOS-a/махни от слота.

Това за 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 (то е повече за агрегиран вариант на тази информация), но също ще свърши работа за тази цел, освен ако нямаш някакви странни кратки пикове.
Инструмента си го избери, но е важно да видиш трафика, който минава докато се случва това и да се сметне дали тази шина (дори теоретично) може да издържи повече.

Добре, тези карти имат доста малко броячи (това е между другото)
Има един полезен пакет, който се казва sysstat (оригинално може да бъде намерен тук: http://pagesperso-orange.fr/sebastien.godard/)
Разгледай инструментите, които предлага и най - вече виж mpstat (най - елементарния пример е mpstat 1 - което го кара да се ъпдейтва на всяка секунда за всички налични процесори).
Не видях назад дали някой е питал за натоварване на машината докато се случва проблема, но чрез този инструмент (а и другите в пакета) може да провериш.
Също така е важно да споделиш какъв трафик на карта/какъв трафик общо - докато се случва проблема.
И все пак, за да проверим параметрите би ли споделил следното:
lspci -vv
Само частта за лан картите (няма нужда от целия изход).

Здравейте,
Имам проблем с пълното зареждане на 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: Добре вече работи, само се бави малко

Здравей, от много голяма полза ще бъде ако покажеш изхода от следните команди:
netstat -s
и
ethtool -S <interface>
тази команда за всяка лан карта, която ползваш.
и
ethtool -k <interface>
За всяка карта (това не е чак толкова важно, просто за информация).
Интересно ще е да наблюдаваш чрез ethtool -S картата, където имаш проблем докато се случва и да
се опиташ да забележиш дали някой от *_errors броячите се променя много/често по време на проблема
(e.g. watch ethtool -S <interface> за всяка карта докато се случва проблема)

Спецификация за проблема имах предвид, но сега видях, че от начало още искаш да е
kernel модул  На кратко drivers/input/input.c. А самата реализация вече може по много
начини да се направи, най - лесния според мен е да редактираш input модула, който се
използва за устройството и да се възползваш от input_inject_event() и другите експортнати
функции от input.

Успех