Re: RE : Re: Kernel issues due to identical network cards
On Sat, Jan 05, 2008 at 01:11:41PM +0100, David MAGNY wrote: > --- "Douglas A. Tutty" <[EMAIL PROTECTED]> a ?crit > > On Fri, Jan 04, 2008 at 11:06:31PM +0100, David > > MAGNY wrote: > > > Hello, > > > > > > I am upgrading a firewall from Sarge to Etch. > > > > > > On this machine, I have 3 network cards. > > > > > > 2 networks cards are identical. It is PCI network > > > cards and it is SMC1233A-TX. > > > > > > On Sarge, everything worked well. > > > > > > The issue is that only one card of both is > > available. > > > > What exactly does this line mean? Do you mean that > > of the two identical > > cards, only one is available? > > Yes, only one is available > > so at least you know that the kernel is finding the > > card. > > [snip dmesg that shows all three cards] > > This suggests that eth0 is the intel card, while > > eth1 and eth2 are the > > two ADMtek comets. > > Yes you are right. But, I use ifrename (/etc/iftab) in > order to be sure that a network interface has always > the same name when I restart the server. > > if my /etc/iftab I mention that, > ethO is one of ADMtek comet > eth1 is the intel card > eth2 is the other ADMtek card > > and in fact eth2 is not available. > > What if you don't use iftab? If, as a test, you just go ahead and set up all three cards? Does /sbin/ifconfig then show three cards configured? If so, then dmesg and the kernel are just fine, the problem is in ifrename. I've never needed ifrename so I don't know about it. > > > What does your /etc/network/interfaces look like? > #eth0 is connected to Internet > auto eth0 > iface eth0 inet static > address X.X.X.X > netmask X.X.X.X > network X.X.X.X > broadcast X.X.X.X > gateway X.X.X.X > > #eth1 is connected to the private network > auto eth1 > iface eth1 inet static > address 192.168.0.254 > netmask 255.255.255.0 > network 192.168.0.0 > broadcast 192.168.0.255 > > #eth2 is connected to the DMZ > auto eth2 > iface eth2 inet static > address 192.168.2.254 > netmask 255.255.255.0 > network 192.168.2.0 > broadcast 192.168.2.255 > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE : Re: Kernel issues due to identical network cards
--- "Douglas A. Tutty" <[EMAIL PROTECTED]> a écrit : > On Fri, Jan 04, 2008 at 11:06:31PM +0100, David > MAGNY wrote: > > Hello, > > > > I am upgrading a firewall from Sarge to Etch. > > > > On this machine, I have 3 network cards. > > > > 2 networks cards are identical. It is PCI network > > cards and it is SMC1233A-TX. > > > > On Sarge, everything worked well. > > > > The issue is that only one card of both is > available. > > What exactly does this line mean? Do you mean that > of the two identical > cards, only one is available? Yes, only one is available > > > The used kernel is 2.6.18. > > > > Within the dmesg log file, I have the following > > information : > > > > > I noticed that the two identical network cards are > > detected : > > > > eth1: ADMtek Comet rev 17 at 0001c800, > > 00:50:BF:B0:CB:4B, IRQ 217. > > ACPI: PCI Interrupt :03:0d.0[A] -> GSI 49 > (level, > > low) -> IRQ 225 > > tulip1: MII transceiver #1 config 1000 status > 786d > > advertising 05e1. > > eth2: ADMtek Comet rev 17 at 0001cc00, > > 00:50:BF:B7:F2:79, IRQ 225. > > > > I added the following parameters to the kernel > > pci=irprouting, and I always have the same issue. > > You also have this (culled from your dmesg) > > > e1000: eth0: e1000_probe: Intel(R) PRO/1000 > Network > > Connection > > usb 1-1: device not accepting address 2, error -71 > > Vendor: ATA Model: WDC WD800AAJS-18 Rev: > 01.0 > > Type: Direct-Access ANSI > SCSI > > revision: 05 > > ACPI: PCI Interrupt :03:0c.0[A] -> GSI 53 > (level, > > low) -> IRQ 217 > > tulip0: MII transceiver #1 config 1000 status > 786d > > advertising 05e1. > > so at least you know that the kernel is finding the > card. > > I don't like the 2.6 dmesg with messages from > different modules being > intermixed. Since I don't know the kernel > internals, its hard for me to > tell what line belongs to which device if it doesn't > start with a device > node. So, in this case, I don't know if the third > line (usb 1-1...) > relates to the problem or not. > > This suggests that eth0 is the intel card, while > eth1 and eth2 are the > two ADMtek comets. Yes you are right. But, I use ifrename (/etc/iftab) in order to be sure that a network interface has always the same name when I restart the server. if my /etc/iftab I mention that, ethO is one of ADMtek comet eth1 is the intel card eth2 is the other ADMtek card and in fact eth2 is not available. > What does your /etc/network/interfaces look like? #eth0 is connected to Internet auto eth0 iface eth0 inet static address X.X.X.X netmask X.X.X.X network X.X.X.X broadcast X.X.X.X gateway X.X.X.X #eth1 is connected to the private network auto eth1 iface eth1 inet static address 192.168.0.254 netmask 255.255.255.0 network 192.168.0.0 broadcast 192.168.0.255 #eth2 is connected to the DMZ auto eth2 iface eth2 inet static address 192.168.2.254 netmask 255.255.255.0 network 192.168.2.0 broadcast 192.168.2.255 > > Doug. > David > > -- > To UNSUBSCRIBE, email to > [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > > _ Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail http://mail.yahoo.fr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Kernel issues due to identical network cards
On Fri, Jan 04, 2008 at 11:06:31PM +0100, David MAGNY wrote: > Hello, > > I am upgrading a firewall from Sarge to Etch. > > On this machine, I have 3 network cards. > > 2 networks cards are identical. It is PCI network > cards and it is SMC1233A-TX. > > On Sarge, everything worked well. > > The issue is that only one card of both is available. > The used kernel is 2.6.18. > > Within the dmesg log file, I have the following > information : ... > e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network > Connection found 1 card, though it's not very helpful info. ... > eth1: ADMtek Comet rev 17 at 0001c800, > 00:50:BF:B0:CB:4B, IRQ 217. ... found another card, with MAC and irq. > eth2: ADMtek Comet rev 17 at 0001cc00, > 00:50:BF:B7:F2:79, IRQ 225. ditto. ... > ADDRCONF(NETDEV_UP): eth2: link is not ready > e1000: eth2: e1000_watchdog: NIC Link is Up 100 Mbps > Full Duplex > ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready hmmm... do the ADMtek cards use e1000 driver or did eth0 get moved to eth2, thus bumping eth2 elsewhere? > > > > I noticed that the two identical network cards are > detected : > > eth1: ADMtek Comet rev 17 at 0001c800, > 00:50:BF:B0:CB:4B, IRQ 217. > ACPI: PCI Interrupt :03:0d.0[A] -> GSI 49 (level, > low) -> IRQ 225 > tulip1: MII transceiver #1 config 1000 status 786d > advertising 05e1. > eth2: ADMtek Comet rev 17 at 0001cc00, > 00:50:BF:B7:F2:79, IRQ 225. > > I added the following parameters to the kernel > pci=irprouting, and I always have the same issue. why did you do this? is that a typo? irqrouting maybe? what output from lspci -v what output from ls /sys/bus/pci/drivers/ and ls /sys/bus/pci/drivers/e1000 A signature.asc Description: Digital signature
Re: Kernel issues due to identical network cards
On Fri, Jan 04, 2008 at 11:06:31PM +0100, David MAGNY wrote: > Hello, > > I am upgrading a firewall from Sarge to Etch. > > On this machine, I have 3 network cards. > > 2 networks cards are identical. It is PCI network > cards and it is SMC1233A-TX. > > On Sarge, everything worked well. > > The issue is that only one card of both is available. What exactly does this line mean? Do you mean that of the two identical cards, only one is available? > The used kernel is 2.6.18. > > Within the dmesg log file, I have the following > information : > > I noticed that the two identical network cards are > detected : > > eth1: ADMtek Comet rev 17 at 0001c800, > 00:50:BF:B0:CB:4B, IRQ 217. > ACPI: PCI Interrupt :03:0d.0[A] -> GSI 49 (level, > low) -> IRQ 225 > tulip1: MII transceiver #1 config 1000 status 786d > advertising 05e1. > eth2: ADMtek Comet rev 17 at 0001cc00, > 00:50:BF:B7:F2:79, IRQ 225. > > I added the following parameters to the kernel > pci=irprouting, and I always have the same issue. You also have this (culled from your dmesg) > e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network > Connection > usb 1-1: device not accepting address 2, error -71 > Vendor: ATA Model: WDC WD800AAJS-18 Rev: 01.0 > Type: Direct-Access ANSI SCSI > revision: 05 > ACPI: PCI Interrupt :03:0c.0[A] -> GSI 53 (level, > low) -> IRQ 217 > tulip0: MII transceiver #1 config 1000 status 786d > advertising 05e1. so at least you know that the kernel is finding the card. I don't like the 2.6 dmesg with messages from different modules being intermixed. Since I don't know the kernel internals, its hard for me to tell what line belongs to which device if it doesn't start with a device node. So, in this case, I don't know if the third line (usb 1-1...) relates to the problem or not. This suggests that eth0 is the intel card, while eth1 and eth2 are the two ADMtek comets. What does your /etc/network/interfaces look like? Doug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Kernel issues due to identical network cards
Hello, I am upgrading a firewall from Sarge to Etch. On this machine, I have 3 network cards. 2 networks cards are identical. It is PCI network cards and it is SMC1233A-TX. On Sarge, everything worked well. The issue is that only one card of both is available. The used kernel is 2.6.18. Within the dmesg log file, I have the following information : Linux version 2.6.18-5-686 (Debian 2.6.18.dfsg.1-17) ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Mon Dec 24 16:41:07 UTC 2007 BIOS-provided physical RAM map: BIOS-e820: - 000a (usable) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 1fe8cc00 (usable) BIOS-e820: 1fe8cc00 - 1fe8ec00 (ACPI NVS) BIOS-e820: 1fe8ec00 - 1fe90c00 (ACPI data) BIOS-e820: 1fe90c00 - 2000 (reserved) BIOS-e820: e000 - f000 (reserved) BIOS-e820: fec0 - fed00400 (reserved) BIOS-e820: fed2 - feda (reserved) BIOS-e820: fee0 - fef0 (reserved) BIOS-e820: ffb0 - 0001 (reserved) 0MB HIGHMEM available. 510MB LOWMEM available. found SMP MP-table at 000fe710 On node 0 totalpages: 130700 DMA zone: 4096 pages, LIFO batch:0 Normal zone: 126604 pages, LIFO batch:31 DMI 2.3 present. ACPI: RSDP (v000 DELL ) @ 0x000fec10 ACPI: RSDT (v001 DELLPE1420 0x0007 ASL 0x0061) @ 0x000fcb6c ACPI: FADT (v001 DELLPE1420 0x0007 ASL 0x0061) @ 0x000fcbac ACPI: SSDT (v001 DELLst_ex 0x1000 MSFT 0x010d) @ 0xfffc4a0c ACPI: MADT (v001 DELLPE1420 0x0007 ASL 0x0061) @ 0x000fcc20 ACPI: BOOT (v001 DELLPE1420 0x0007 ASL 0x0061) @ 0x000fccaa ACPI: ASF! (v016 DELLPE1420 0x0007 ASL 0x0061) @ 0x000fccd2 ACPI: MCFG (v001 DELLPE1420 0x0007 ASL 0x0061) @ 0x000fcd39 ACPI: HPET (v001 DELLPE1420 0x0007 ASL 0x0061) @ 0x000fcd77 ACPI: DSDT (v001 DELLdt_ex 0x1000 MSFT 0x010d) @ 0x ACPI: PM-Timer IO Port: 0x808 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 15:4 APIC version 20 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 15:4 APIC version 20 ACPI: LAPIC (acpi_id[0x03] lapic_id[0x01] disabled) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x07] disabled) ACPI: LAPIC_NMI (acpi_id[0xff] high level lint[0x1]) ACPI: IOAPIC (id[0x08] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 8, version 32, address 0xfec0, GSI 0-23 ACPI: IOAPIC (id[0x09] address[0xfec8] gsi_base[24]) IOAPIC[1]: apic_id 9, version 32, address 0xfec8, GSI 24-47 ACPI: IOAPIC (id[0x0a] address[0xfec80800] gsi_base[48]) IOAPIC[2]: apic_id 10, version 32, address 0xfec80800, GSI 48-71 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Enabling APIC mode: Flat. Using 3 I/O APICs ACPI: HPET id: 0x8086a201 base: 0xfed0 Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 3000 (gap: 2000:c000) Detected 2793.335 MHz processor. Built 1 zonelists. Total pages: 130700 Kernel command line: root=/dev/sda1 ro pci=routeirq mapped APIC to d000 (fee0) mapped IOAPIC to c000 (fec0) mapped IOAPIC to b000 (fec8) mapped IOAPIC to a000 (fec80800) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 PID hash table entries: 2048 (order: 11, 8192 bytes) Console: colour VGA+ 80x25 Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 510652k/522800k available (1541k kernel code, 11580k reserved, 576k data, 196k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. hpet0: at MMIO 0xfed0 (virtual 0xe080), IRQs 2, 8, 0 hpet0: 3 64-bit timers, 14318180 Hz Using HPET for base-timer Calibrating delay using timer specific routine.. 5590.14 BogoMIPS (lpj=11180287) Security Framework v1.0.0 initialized SELinux: Disabled at boot. Capability LSM initialized Mount-cache hash table entries: 512 CPU: After generic identify, caps: bfebfbff 2000 641d CPU: After vendor identify, caps: bfebfbff 2000 641d monitor/mwait feature present. using mwait in idle threads. CPU: Trace cache: 12K uops, L1 D cache: 16K CPU: L2 cache: 1024K CPU: Physical Processor ID: 0 CPU: After all inits, caps: bfebfbff 2000 0180 641d Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU0: Intel P4/Xeon Extended MCE MSRs
