eth interface sorrend erdekesseg

[Andras HORVATH]

Ezt igy hogy? rhel5+2.6.29.1... A ket e1000e alaplapi, a ket ixgbe egy es
ugyanazon kartyanak a ket portja.

Ezen a heten mi alapjan osztjuk ki az ethX neveket?:)

raas

[***@lxfsrl4701 ~]# ethtool -i eth0
driver: ixgbe
version: 1.3.30-k2
firmware-version: N/A
bus-info: 0000:08:00.0
[***@lxfsrl4701 ~]# ethtool -i eth1
driver: e1000e
version: 0.3.3.3-k6
firmware-version: 2.1-12
bus-info: 0000:06:00.0
[***@lxfsrl4701 ~]# ethtool -i eth2
driver: ixgbe
version: 1.3.30-k2
firmware-version: N/A
bus-info: 0000:08:00.1
[***@lxfsrl4701 ~]# ethtool -i eth3
driver: e1000e
version: 0.3.3.3-k6
firmware-version: 2.1-12
bus-info: 0000:06:00.1

lspci:

[***@lxfsrl4701 ~]# lspci -vt
-[0000:00]-+-00.0 Intel Corporation 5000P Chipset Memory Controller Hub
+-02.0-[0000:01-07]--+-00.0-[0000:02-06]--+-00.0-[0000:03-05]--+-00.0-[0000:04]--
| | | \-00.2-[0000:05]--
| | \-02.0-[0000:06]--+-00.0 Intel Corporation 80003ES2LAN Gigabit Ethernet Controller (Copper)
| | \-00.1 Intel Corporation 80003ES2LAN Gigabit Ethernet Controller (Copper)
| \-00.3-[0000:07]--
+-04.0-[0000:08]--+-00.0 Intel Corporation 82598EB 10-Gigabit AT CX4 Network Connection
| \-00.1 Intel Corporation 82598EB 10-Gigabit AT CX4 Network Connection
+-06.0-[0000:09]----00.0 3ware Inc 9650SE SATA-II RAID
+-08.0 Intel Corporation 5000 Series Chipset DMA Engine
+-10.0 Intel Corporation 5000 Series Chipset FSB Registers
+-10.1 Intel Corporation 5000 Series Chipset FSB Registers
+-10.2 Intel Corporation 5000 Series Chipset FSB Registers
+-11.0 Intel Corporation 5000 Series Chipset Reserved Registers
+-13.0 Intel Corporation 5000 Series Chipset Reserved Registers
+-15.0 Intel Corporation 5000 Series Chipset FBD Registers
+-16.0 Intel Corporation 5000 Series Chipset FBD Registers
+-1c.0-[0000:0a]--
+-1d.0 Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #1
+-1d.1 Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #2
+-1d.2 Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #3
+-1d.7 Intel Corporation 631xESB/632xESB/3100 Chipset EHCI USB2 Controller
+-1e.0-[0000:0b]----01.0 ATI Technologies Inc ES1000
+-1f.0 Intel Corporation 631xESB/632xESB/3100 Chipset LPC Interface Controller
+-1f.1 Intel Corporation 631xESB/632xESB IDE Controller
\-1f.3 Intel Corporation 631xESB/632xESB/3100 Chipset SMBus Controller

[Vendel Cseh]

nekem ilyen témában debianon az udev szokott csinálni.

két dual protos tg3, gépen matrica szerint eth0 de install után eth(random) :)

udev->presistent-net-rules megberhelésével rendet lehet tenni ( ha
redhaton van ).

[Andras HORVATH]

Post by Vendel Cseh
udev->presistent-net-rules megberhelésével rendet lehet tenni ( ha
redhaton van ).

Nyilvan nincs :) persze attol meg csinalhatnek, de annyit nem er. A
teszt erejeig, amihez uj kernel kellett, elfelejtettuk a rhel-t, lett
helyette ubuntu, es mindjart szarazabb/biztonsagosabb az elet.

Szoval hatterben inicializalos, en is erre gyanakodtam :-/

raas

[Gabor Gombas]

Post by Andras HORVATH
Ezt igy hogy? rhel5+2.6.29.1... A ket e1000e alaplapi, a ket ixgbe egy es
ugyanazon kartyanak a ket portja.
Ezen a heten mi alapjan osztjuk ki az ethX neveket?:)
raas
driver: ixgbe
version: 1.3.30-k2
firmware-version: N/A
bus-info: 0000:08:00.0
driver: e1000e
version: 0.3.3.3-k6
firmware-version: 2.1-12
bus-info: 0000:06:00.0
driver: ixgbe
version: 1.3.30-k2
firmware-version: N/A
bus-info: 0000:08:00.1
driver: e1000e
version: 0.3.3.3-k6
firmware-version: 2.1-12
bus-info: 0000:06:00.1

dmesg | grep eth ? Mondjuk "ip link ... set name ..." es tarsai nem
logolodnak, de az udev igen.

Gabor

[Pallai Roland]

Post by Andras HORVATH
Ezt igy hogy? rhel5+2.6.29.1... A ket e1000e alaplapi, a ket ixgbe egy es
ugyanazon kartyanak a ket portja.
Ezen a heten mi alapjan osztjuk ki az ethX neveket?:)

Na igen :)

Az asszinkron modul inicializalas meg tudja rendesen kavarni a
sorrendet halokartyanal, winyonal, mindennel es minel tobb modult
alakitanak at ugy, hogy a hatterben inicializaljon, annal tobb ilyen
sorrend cserebere lesz. Szerencsere ittvan nekunk az udev..

[Daniel PATH]

Post by Pallai Roland

Post by Andras HORVATH
Ezt igy hogy? rhel5+2.6.29.1... A ket e1000e alaplapi, a ket ixgbe egy es
ugyanazon kartyanak a ket portja.
Ezen a heten mi alapjan osztjuk ki az ethX neveket?:)

Na igen :)
Az asszinkron modul inicializalas meg tudja rendesen kavarni a
sorrendet halokartyanal, winyonal, mindennel es minel tobb modult
alakitanak at ugy, hogy a hatterben inicializaljon, annal tobb ilyen
sorrend cserebere lesz. Szerencsere ittvan nekunk az udev..

man interfaces:

KNOWN BUGS/LIMITATIONS
The ifup and ifdown programs work with so-called "physical"
interface
names. These names are assigned to hardware by the kernel.
Unfortu-
nately it can happen that the kernel assigns different
physical inter-
face names to the same hardware at different times; for
example, what
was called "eth0" last time you booted is now called "eth1"
and vice
versa. This creates a problem if you want to configure the
interfaces
appropriately. A way to deal with this problem is to
use mapping
scripts that choose logical interface names according to the
properties
of the interface hardware. See the get-mac-address.sh
script in the
examples directory for an example of such a mapping script.
See also
Debian bug #101728.

udv,

[Daniel PATH]

Post by Pallai Roland

Post by Andras HORVATH
Ezt igy hogy? rhel5+2.6.29.1... A ket e1000e alaplapi, a ket ixgbe egy es
ugyanazon kartyanak a ket portja.
Ezen a heten mi alapjan osztjuk ki az ethX neveket?:)

Na igen :)
Az asszinkron modul inicializalas meg tudja rendesen kavarni a
sorrendet halokartyanal, winyonal, mindennel es minel tobb modult
alakitanak at ugy, hogy a hatterben inicializaljon, annal tobb ilyen
sorrend cserebere lesz. Szerencsere ittvan nekunk az udev..

talaltam meg egy ilyet:
http://www.cyberciti.biz/faq/setting-up-an-network-interfaces-file/

[blabla]
# Two ethernet interfaces, one connected to a trusted LAN, the other to
# the untrusted Internet. If their MAC addresses get swapped (because an
# updated kernel uses a different order when probing for network cards,
# say), then they don't get brought up at all.
#
# auto eth0 eth1
# iface eth0 inet static
# address 192.168.42.1
# netmask 255.255.255.0
# pre-up /path/to/check-mac-address.sh eth0 11:22:33:44:55:66
# pre-up /usr/local/sbin/enable-masq
[blabla]

udv,

[Gabor Gombas]

Post by Pallai Roland
Na igen :)
Az asszinkron modul inicializalas meg tudja rendesen kavarni a
sorrendet halokartyanal, winyonal, mindennel es minel tobb modult
alakitanak at ugy, hogy a hatterben inicializaljon, annal tobb ilyen
sorrend cserebere lesz. Szerencsere ittvan nekunk az udev..

2.6.29-ben az async infrastruktura meg defaultban ki van kapcsolva.
Ezenkivul IMHO a PCI felderites/inicializalas aszinkronna tetele nem
szerepel a napirenden.

Gabor

[Pallai Roland]

Post by Gabor Gombas

Post by Pallai Roland
Az asszinkron modul inicializalas meg tudja rendesen kavarni a
sorrendet halokartyanal, winyonal, mindennel es minel tobb modult
alakitanak at ugy, hogy a hatterben inicializaljon, annal tobb ilyen
sorrend cserebere lesz. Szerencsere ittvan nekunk az udev..

2.6.29-ben az async infrastruktura meg defaultban ki van kapcsolva.
Ezenkivul IMHO a PCI felderites/inicializalas aszinkronna tetele nem
szerepel a napirenden.

Hm, en mar etch'n'half kernelben is talaltam modult, ami hatterben
inicializalja az eszkozoket, pl a pendrive -ot vagy fibre channelt
(qla2xxx). Jartam mar ugy, hogy a pendrive betujele becsuszott az fc
storage -ek koze. No meg a rootdelay= is kell neha Lennybe.
Nem kell ehhez asszinkron PCI felderites, eleg ha a lan chip
inicializasa a hatterben folyik, amire lehet oka a fejlesztonek,
mondjuk ha a firmware lassan bootol (>100ms). A network hotplug
szerintem mar benne a kernelben, ami lehetove teszi, hogy ezt
megcsinalja, nem?

En nem tudom milyen async cucc jon a 2.6.29 utan, csak a
tapasztalataim utan irtam amit irtam.

[Gabor Gombas]

Post by Pallai Roland
Hm, en mar etch'n'half kernelben is talaltam modult, ami hatterben
inicializalja az eszkozoket, pl a pendrive -ot vagy fibre channelt
(qla2xxx). Jartam mar ugy, hogy a pendrive betujele becsuszott az fc
storage -ek koze. No meg a rootdelay= is kell neha Lennybe.
Nem kell ehhez asszinkron PCI felderites, eleg ha a lan chip
inicializasa a hatterben folyik, amire lehet oka a fejlesztonek,
mondjuk ha a firmware lassan bootol (>100ms). A network hotplug
szerintem mar benne a kernelben, ami lehetove teszi, hogy ezt
megcsinalja, nem?

Mindez jo, amit leirsz, csak eppen az eredeti levelben leirt jelenseget
egyik sem magyarazza.

Post by Pallai Roland
En nem tudom milyen async cucc jon a 2.6.29 utan, csak a
tapasztalataim utan irtam amit irtam.

http://lwn.net/Articles/326180/

De ez csak a nagy subsystem-eket parallelizalja egymassal, belul
tovabbra is marad a szekvencialis sorrend, pont azert, hogy stabil
legyen az elnevezes/szamozas.

Gabor

[Pallai Roland]

Post by Gabor Gombas

Post by Pallai Roland
Hm, en mar etch'n'half kernelben is talaltam modult, ami hatterben
inicializalja az eszkozoket, pl a pendrive -ot vagy fibre channelt
(qla2xxx). Jartam mar ugy, hogy a pendrive betujele becsuszott az fc
storage -ek koze. No meg a rootdelay= is kell neha Lennybe.
Nem kell ehhez asszinkron PCI felderites, eleg ha a lan chip
inicializasa a hatterben folyik, amire lehet oka a fejlesztonek,
mondjuk ha a firmware lassan bootol (>100ms). A network hotplug
szerintem mar benne a kernelben, ami lehetove teszi, hogy ezt
megcsinalja, nem?

Mindez jo, amit leirsz, csak eppen az eredeti levelben leirt jelenseget
egyik sem magyarazza.

Bar en valoban scsi eszkozokkel peldalozok, de szerinted lehetetlen,
hogy ugyanez menjen a network driver szintjen?

Post by Gabor Gombas

Post by Pallai Roland
En nem tudom milyen async cucc jon a 2.6.29 utan, csak a
tapasztalataim utan irtam amit irtam.

http://lwn.net/Articles/326180/
De ez csak a nagy subsystem-eket parallelizalja egymassal, belul
tovabbra is marad a szekvencialis sorrend, pont azert, hogy stabil
legyen az elnevezes/szamozas.

Az elnezeves/szamozas mar reg nem szekvencialis, ld. scsi. Pl.
sata_sil, sata_sil24, ahci keveresnel minden bootnal megvaltozhat a
sorrend, csak a /dev/disk/by-* tekintheto fixnek.

Amikor az udev kezeli a halozati eszkozoket is, mi ertelme annak, hogy
annak az elnevezese szekvencialis maradjon? En nem latom miert ne
mukodhetne, amit en jozan paraszti esszel kitalaltam az eredeti
problemara. ( Persze epp a jozan paraszti esz miatt lehet, hogy koze
sincs a valosaghoz, de mondj jobbat :)

[Gabor Gombas]

Post by Pallai Roland
Bar en valoban scsi eszkozokkel peldalozok, de szerinted lehetetlen,
hogy ugyanez menjen a network driver szintjen?

Az SCSI busz scannelese aszinkron mar regota (ill. ez a default, de ezt
felulbiralhatod). A PCI busz bejarasa nem az, es nem is akarjak azza
tenni. Mas kod van a hatterben.

Post by Pallai Roland
Az elnezeves/szamozas mar reg nem szekvencialis, ld. scsi. Pl.
sata_sil, sata_sil24, ahci keveresnel minden bootnal megvaltozhat a
sorrend, csak a /dev/disk/by-* tekintheto fixnek.

Nem egeszen. Ha fixen a kernelbe forditod a drivereket, es nem
valtoztatsz a HW konfiguracion, akkor fix a sorrend (meg SCSI-nel is, ha
kered; USB-nel nem, de ez HW "feature"). A "fastboot" patch csak ezt a
sorrend-tartast garantalja tovabbra is, mikozben lehetove teszi, hogy
pl. a sata_sil es az ahci driver parhuzamosan ellenorizze, hogy melyik
csatlakozo vegen log tenylegesen diszk.

Post by Pallai Roland
Amikor az udev kezeli a halozati eszkozoket is, mi ertelme annak, hogy
annak az elnevezese szekvencialis maradjon?

Nem az elnevezesrol van szo, hanem hogy milyen sorrendben hivodik meg a
driver ->probe() metodusa. Utana mar ugy nevezed at, ahogy jol esik.

Gabor