On 12/17/06, Oren Held <[EMAIL PROTECTED]> wrote:
I tend to believe that on single user mode you'll see only the regular eth0 & eth1, and that later some evil script renames the interface name by running something like "ip link set eth1 name eth1.old"
Good idea, I tried to boot into single on 2.6.18-7, same effect. I also tried to boot into my backup 2.6.16-max debian kernel, single mode as well - in this case it show as <<< dynamic:/sys/class/net# ls eth0 eth1_rename lo
I went ahead and removed the Realtek PCI, rebooted - Pro/1000 gets eth0 Then I plugged the Realtek, took Pro/1000 out. Realtek gets eth0 Then I switched the PCI slots of the cards, inserted the Pro/1000 back in, rebooted - Realtek gets eth1_rename_ren - So I don't think it's a PCI / IRQ issue (I even tried to change the IRQ allocation in the BIOS, nada).
Try to analyze your startup scripts and see which one does that. I know that Xen's networking scripts do some not-too-nice stuff in order to configure bridging/nat, but your kernel seems to be Xen free..
Nope, no Xen in here, a bit of motorcycle maintenance but no further. The only variation I do have from the vanilla debian kernel are the asterisk zaptel modules which I have installed and loaded on boot for my tdm400p.
I hope it helped some way.
Thank you.
- Oren
Maxim.
Maxim Vexler wrote: > Hi List, > > I've have 2 NIC's in my home machine, a Intel(R) PRO/1000GT and a > RealTek RTL8139 > > When the system boots it creates the following (odd) kernel naming > schema, I haven't messed with any of my udev.d rules. > <<< > # ls /sys/class/net/ > eth0 eth1_rename_ren lo sit0 > > # udevtest /sys/class/net/eth0 > main: looking at device '/class/net/eth0' from subsystem 'net' > wait_for_sysfs: file '/sys/class/net/eth0/address' appeared after 0 loops > udev_rules_get_name: rule applied, 'eth0' becomes 'eth0' > main: run: 'socket:/org/kernel/udev/monitor' > main: run: 'net.agent' > main: run: 'socket:/org/freedesktop/hal/udev_event' > > # udevtest /sys/class/net/eth1_rename_ren > main: looking at device '/class/net/eth1_rename_ren' from subsystem 'net' > wait_for_sysfs: file '/sys/class/net/eth1_rename_ren/address' appeared > after 0 loops > udev_rules_get_name: rule applied, 'eth1_rename_ren' becomes 'eth0' > rename_netif: changing net interface name from 'eth1_rename_ren' to > 'eth0' > udev_device_event: renamed netif to 'eth0' > main: run: 'socket:/org/kernel/udev/monitor' > main: run: 'net.agent' > main: run: 'socket:/org/freedesktop/hal/udev_event' > > # ls /dev/eth* > ls: /dev/eth*: No such file or directory >>>> > > The (clipped) dmesg log looks like this: > <<< > Linux version 2.6.18-3-686 (Debian 2.6.18-7) ([EMAIL PROTECTED]) (gcc > version 4.1.2 20061115 (prerelease) (Debian 4.1.1-20)) #1 SMP Mon Dec > 4 16:41:14 UTC 2006 > NET: Registered protocol family 16 > NET: Registered protocol family 2 > audit: initializing netlink socket (disabled) > audit(1166373050.144:1): initialized > NET: Registered protocol family 1 > NET: Registered protocol family 17 > NET: Registered protocol family 8 > NET: Registered protocol family 20 > 8139cp: 10/100 PCI Ethernet driver v1.2 (Mar 22, 2004) > Intel(R) PRO/1000 Network Driver - version 7.1.9-k4-NAPI > Copyright (c) 1999-2006 Intel Corporation. > 8139cp 0000:00:0b.0: This (id 10ec:8139 rev 10) is not an 8139C+ > compatible chip > 8139cp 0000:00:0b.0: Try the "8139too" driver instead. > 8139too Fast Ethernet driver 0.9.27 > e1000: 0000:00:0d.0: e1000_probe: (PCI:33MHz:32-bit) 00:0e:0c:b2:de:29 > e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection > eth1: RealTek RTL8139 at 0xe000, 00:40:f4:92:86:73, IRQ 11 > eth1: Identified 8139 chip type 'RTL-8100B/8139D' > e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex >>>> > > Both cards work, I can ssh either one of them after I go manually IP > assign them >>>> > dynamic:~# ifconfig eth0 192.168.4.50 netmask 255.255.255.0 > dynamic:~# ifconfig eth1_rename_ren 192.168.4.44 netmask 255.255.255.0 > dynamic:~# ifconfig -a > eth0 Link encap:Ethernet HWaddr 00:0E:0C:B2:DE:29 > inet addr:192.168.4.50 Bcast:192.168.4.255 Mask:255.255.255.0 > inet6 addr: fe80::20e:cff:feb2:de29/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:2590 errors:0 dropped:0 overruns:0 frame:0 > TX packets:2422 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:100 > RX bytes:270181 (263.8 KiB) TX bytes:444726 (434.3 KiB) > Base address:0xe800 Memory:e7020000-e7040000 > > eth1_rena Link encap:Ethernet HWaddr 00:40:F4:92:86:73 > inet addr:192.168.4.44 Bcast:192.168.4.255 Mask:255.255.255.0 > inet6 addr: fe80::240:f4ff:fe92:8673/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:1110 errors:0 dropped:0 overruns:0 frame:0 > TX packets:711 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:101064 (98.6 KiB) TX bytes:96177 (93.9 KiB) > Interrupt:11 Base address:0xe000 > > lo Link encap:Local Loopback > inet addr:127.0.0.1 Mask:255.0.0.0 > inet6 addr: ::1/128 Scope:Host > UP LOOPBACK RUNNING MTU:16436 Metric:1 > RX packets:242 errors:0 dropped:0 overruns:0 frame:0 > TX packets:242 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:22642 (22.1 KiB) TX bytes:22642 (22.1 KiB) > > sit0 Link encap:IPv6-in-IPv4 > NOARP MTU:1480 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) > <<< > > > How can it be that I still communicate with the PC over the network > using those 2 devices if I don't have the proper block device under > /dev? > And WTF did eth1_rename_ren came from ? > > > Appreciate your input, output or regex, > Thank you, > Maxim. >
-- Cheers, Maxim Vexler "Free as in Freedom" - Do u GNU ? ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]