Haliho!
mar par hete szenvedek ezzel a doggel :)
Egy AMD64-es gep, Debian lenny-vel. Kabelnetes kapcsolat, pump huzza fel eth0-ra.
Eredetileg 2.6.16.27 a kernel (eredetileg, mert anno azt raktam fel)
Ket tokugyanolyan halokartya van benne:
02:08.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
Subsystem: Realtek Semiconductor Co., Ltd. RT8139
Flags: bus master, medium devsel, latency 64, IRQ 7
I/O ports at d800 [=256]
Memory at feaffc00 (32-bit, non-prefetchable) [=256]
Expansion ROM at feae0000 [disabled] [=64K]
Capabilities: [50] Power Management version 2
Kernel driver in use: 8139too
Kernel modules: 8139cp
--
02:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
Subsystem: Realtek Semiconductor Co., Ltd. RT8139
Flags: bus master, medium devsel, latency 64, IRQ 4
I/O ports at d400 [=256]
Memory at feaff800 (32-bit, non-prefetchable) [=256]
Capabilities: [50] Power Management version 2
Kernel driver in use: 8139too
Kernel modules: 8139cp
Anno gond volt vele, kellett egy append=routeirq (asszem, ilyesmi) a kernel boot-hoz, mert mindketto egy IRQ-t kapott...
Aztan (erdekes modon)
CONFIG_NE2K_PCI=y
CONFIG_8139CP=m
CONFIG_8139TOO=y
megoldotta a problemat, ket kulon IRQ-n van jo ideje, mint latszik, a regi 8139-es nem modul, a kernel resze, az ujabb modul. Nem tudom, miert, de iggy mukodik...
Namost, apt-get update/upgrade es kozli, hogy lehet, hogy nem indul uj kernel nelkul (2.6.18 feletti). Oke, 2.6.27.2 letolt, fordit (volt 2.6.26 is, de ott is ugyanaz, amit mindjart irok).
JAIGEN: meg a 2.6.26-tal jatszotta, hogy minden rendben, de NAT nincs. Oke, modulkent hozzaforgattam, aztan (vszinuleg gcc verzio miatt) nem stimmelt. Utan tokeletesen el is szallt a gep, meg "unable root fs is volt", LiveCD-vel hoztuk helyre ugy-ahogy.
Kellemes tavolrol instrualni valakit, akinek a parancsokat is betuzni kell :)
Szoval, most egy ideje a 2.6.27.2 az aldozat, cronbol tizpercenkent csereli a lilo.conf-ot, hogy melyik kernel legyen default es restart.
TEHAT: ha 2.6.16.26 van, akkor van net, van NAT, van anyamtyukja, csak idonkent ilyenek jonnek:
kernel: NETDEV WATCHDOG: eth0: transmit timed out
kernel: eth0: Transmit timeout, status 0c 0005 c07f media 10.
kernel: eth0: Tx queue start entry 556 dirty entry 552.
kernel: eth0: Tx descriptor 0 is 0008a362. (queue head)
kernel: eth0: Tx descriptor 1 is 0008a362.
kernel: eth0: Tx descriptor 2 is 0008a362.
kernel: eth0: Tx descriptor 3 is 0008a362.
kernel: eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
kernel: eth0: Promiscuous mode enabled.
es idonkent x idore megszakad a kapcsolat (ssh-n is latszik, de nincs ujratarcsazas, magatol helyreall). Ez gondolom, a modul es fix kerneldriver osszeakadasa vagy barmi mas. Ezert is kellene kernelt cserelnem.
HA 2.6.27.2, akkor
lspci -v megint latja mindket halokartyat, de ha pump vagy ifconfig up fel akarja huzni eth0-t, akkor:
eth0: ERROR while getting interface flags: No such device
Probaltam az uj kernelben csak a 8139too, majd csak a 8139cp drivert, modulkent, majd mindkettot, valtozas nincs. Legfeljebb az, hogy lspci kozli, hogy ezt es ezt a modult talalta es hasznalja a kartyakhoz (mindkettohoz!). Holott ifconfig csak az eth1-t talalja kernelnel...
Otlet? Gep tavol van, azert van a cron-bol ujrainditas is es amikor nincs net, nem is tudok ranezni, hogy megis mi van.
- 2066 megtekintés
Hozzászólások
/etc/udev/rules.d/70-persistent-net.rules
?
- A hozzászóláshoz be kell jelentkezni
Idezzem be?
SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:50:fc:f0:cc:90", NAME="eth0"
SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:0e:2e:80:1d:88", NAME="eth1"
# PCI device 0x10ec:0x8139 (8139too)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:50:fc:1e:81:f9", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
Nekem sokat nem mond...Arra emlekszem, hogy regebben nyugom volt, hogy masik halokartyat berakva pl. eth0 helyere, miert lesz eth2, annak is az udev-hez volt koze.
Ennyit tudok az udev-rol :)
- A hozzászóláshoz be kell jelentkezni
Ellenőrizned kellene, hogy rendben van e, de ha csak egyszerűen csinálsz egy backupot belőle a home-odba majd töröld innen, és reboot (ez gyorsabb mint ellenőrizni).
- A hozzászóláshoz be kell jelentkezni
Foleg, hogy nem tudom, hogyan kellene ellenorizni es mit latnek, ha rendben lenne :) (Mint irtam, nem ertek az udevhez)
Ugyhogy az lesz: egyik esetben a script torli, masik esetben bemasolja. Koszi az otletet!
- A hozzászóláshoz be kell jelentkezni
Ez létrejön magától, és valószínűleg a mostani struktúra nem ez, és az interfész átnevezés miatt szívsz. Csak próbáld ki, hogy töröld, a backup csak ellenőrzésre, illetve visszaállításra kell.
- A hozzászóláshoz be kell jelentkezni
Mit is mondhatnek...Szmamomra Isten vagy matol :) Mar jopar honapja szivtam ezzel a szarral (igaz, csak hetvegen, ha nem dolgozott a cegnel senki) es nem haladtam elore.
Ezzel meg rogton mukodott :) Koszi!
Igen, lattam, hogy letrehozta es mas a tartalma, mint az eredeti. Sajnos, ha scriptbol nem allitom vissza a backupot restart elott, akkkor eseleyem sem lett volna, leven a gep vagy 160 km-re tolem. (Naja, amig nem tudtam, hogy automatan generalodik)
Szoval mukszik, koszi!
- A hozzászóláshoz be kell jelentkezni
Szívesen,
Kedvenc Baker street-i nyomozóm szerint nem jó ha a dedukció lépéseit felfedjük, de azért én csak megjegyzésként leírnám, te hogy jössz rá (hátha máskor jól jön, neked vagy másnak)
A linux pci eszköz felismerése esetenként, akár passzióból (kernel felismerési sorrend, bios frissítés) stb változhat, ez elég sok gondot jelentett régen, főleg olyan környezetben ahol snmp stb felhasználás is volt.
Udev gyönyörű, képes fixen tartani az interfészeket, amit adatbázissal, azonosítással, és interfészátnevezéssel old meg.
Ez a logokban olvasható információ. Innen kellett volna látnod (dmesg, grep eth stb). Ha tudod, hogy lehet ilyet mást is meg tudsz vele oldani.
Még egy vicc(bár ez jól láthatóan jelzi a debian) a régi debian-os installoknak, egy ideje szól a debian, hogy deprecated a network/options file. Nos lenny-től már nem is dolgozik vele (ip_forward, stb)
- A hozzászóláshoz be kell jelentkezni
Az egyetlen bibi ott volt (bar megoldhato lett volna), hogy amikor az uj kernel bootolt, nem tudtam ranezni a gepre (nem volt net), amikor a regi , akkor viszont a dmesg-t felulirta. A syslog oke volt, boot utan logolta az ifconfig kimenetet, az lsmod kimenetet, lspci kimenetet meg egy-ket dolgot, de az nem jutott eszembe, hogy a dmesg-t is "archivaljam". Ebbol lattam, hogy lspci szerint ket halokartya van, de az ifconfig csak egyet huz fel (es az "ifconfig eth0 up" is nemletezo eszkoz uzenetet ad). Mondjuk, ha egy "ls /dev"-et nyomok logba, akkor sem ertettem volna, hova a nyavalyaba tunt el az eth0, amikor ott volt. Tehat sejtettem, hogy az udev kornyeken van a bibi, de megoldani nem tudtam.
Mint amikor a falban eleg a vezetek es ez miatt nincs villany a konyhaban: erezni az egett szagot, sejti az ember, hogy valahol elegett a vezetek, de nem villanyszerelo, hogy pontosan felderitse, hol is egett el es nem villanyszerelo, hogy nekialljon furni-faragni es atvezetekelni a lakast.
- A hozzászóláshoz be kell jelentkezni
Szia !
Leirom az en tapasztalataimat, sokat segiteni nem fog, de a problemadhoz kapcsolodhat.
Nekem 3 db
Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 20)
-as van egy gepben es a 2.6.26 -os sorozattal(2.6.26.5-el probaltam) jelentkezett egy olyan problema, hogy ha pl barmelyik kartyabol kihuztad a kabelt (vagy lekapcsoltad a masik vegen a szamitogepet), akkor kifagyott az egesz gep. ( De ha 2 masodpercen belul visszadugtad, akkor mar a tovabbi kihuzasra nem jott elo a hiba) A hiba jelentkezett 8139too es 8139cp -vel is. 2.6.27.1-el jo, igy nekem szerencsere tovabb nem kellett veszodnom.
Link:
http://groups.google.com/group/linux.kernel/browse_thread/thread/f3f9ff…
Udv:
Istvan
- A hozzászóláshoz be kell jelentkezni
Szia!
Hat, sajnos nem errol van szo. Tobb kernel verioval is jelentkezett es nem lefagyas volt.
- A hozzászóláshoz be kell jelentkezni
Ize. Valami gebasz meg mindig van.
Leggyakrabban az eth1-en (belso halos cim), de neha az eth0-n is (kabelnetes)
Mindketto 8139-es kartya. Debian Lenny, 2.6.27.2 kernel. Kerestem, de csak regebbi
kernelekkel bukkantam a hibara, ott sem tudtak a megoldast.
02:08.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
Subsystem: Realtek Semiconductor Co., Ltd. RT8139
Flags: bus master, medium devsel, latency 64, IRQ 7
I/O ports at d800 [=256]
Memory at feaffc00 (32-bit, non-prefetchable) [=256]
Expansion ROM at feae0000 [disabled] [=64K]
Capabilities: [50] Power Management version 2
Kernel driver in use: 8139too
Kernel modules: 8139too, 8139cp
02:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
Subsystem: Realtek Semiconductor Co., Ltd. RT8139
Flags: bus master, medium devsel, latency 64, IRQ 4
I/O ports at d400 [=256]
Memory at feaff800 (32-bit, non-prefetchable) [=256]
Capabilities: [50] Power Management version 2
Kernel driver in use: 8139too
Kernel modules: 8139too, 8139cp
Nov 18 06:57:47 ceg kernel: eth1: Transmit timeout, status 0c 0005 c07f media 10.
Nov 18 06:57:47 ceg kernel: eth1: Tx queue start entry 290 dirty entry 286.
Nov 18 06:57:47 ceg kernel: eth1: Tx descriptor 0 is 0008a5ea.
Nov 18 06:57:47 ceg kernel: eth1: Tx descriptor 1 is 0008a5ea.
Nov 18 06:57:47 ceg kernel: eth1: Tx descriptor 2 is 0008a5ea. (queue head)
Nov 18 06:57:47 ceg kernel: eth1: Tx descriptor 3 is 0008a5ea.
Nov 18 06:57:47 ceg kernel: eth1: link up, 100Mbps, full-duplex, lpa 0x45E1
Nov 18 06:57:59 ceg kernel: eth1: Transmit timeout, status 0c 0005 c07f media 10.
Nov 18 06:57:59 ceg kernel: eth1: Tx queue start entry 249 dirty entry 245.
Nov 18 06:57:59 ceg kernel: eth1: Tx descriptor 0 is 0008a5ea.
Nov 18 06:57:59 ceg kernel: eth1: Tx descriptor 1 is 0008a5ea. (queue head)
Nov 18 06:57:59 ceg kernel: eth1: Tx descriptor 2 is 0008a5ea.
Nov 18 06:57:59 ceg kernel: eth1: Tx descriptor 3 is 0008a5ea.
Nov 18 06:57:59 ceg kernel: eth1: link up, 100Mbps, full-duplex, lpa 0x45E1
Nov 18 06:58:11 ceg kernel: eth1: Transmit timeout, status 0c 0005 c07f media 10.
Nov 18 06:58:11 ceg kernel: eth1: Tx queue start entry 668 dirty entry 664.
Nov 18 06:58:11 ceg kernel: eth1: Tx descriptor 0 is 0008a5ea. (queue head)
Nov 18 06:58:11 ceg kernel: eth1: Tx descriptor 1 is 0008a5ea.
Nov 18 06:58:11 ceg kernel: eth1: Tx descriptor 2 is 0008a5ea.
Nov 18 06:58:11 ceg kernel: eth1: Tx descriptor 3 is 0008a5ea.
Nov 18 06:58:11 ceg kernel: eth1: link up, 100Mbps, full-duplex, lpa 0x45E1
- A hozzászóláshoz be kell jelentkezni
Nos, ugy tunik, megvan. Az nvidia driver telepitesnel bukott ki (hiaba router/mailserver, a fonok latni akarja, milyen a Linux grafikus felulete), volt regen a lilo.conf-ban egy
pci=routeirq (mert a ket halokartya csak egy IRQ-n volt hajlando osztozni :)
Probaltam az
irqpoll -> semmi
noapic -> es vegre ugy tunik, megvan :)
Majd hetfon kiderul, ha a munkatarsak elkezdik hasznalni a gepet.
Alaplap (hwinfo alapjan):
ASUS K8N Ami BIOS-szal. Lehet, hoyg egy BIOS update is megoldana a gondokat.
- A hozzászóláshoz be kell jelentkezni