We are building some redhat Linux AS 3 servers. They have HP NC364T GBit cards in their PCI slots. The problem we are having is that we can assign IP to the cards and ping themselves, but they can't ping out, even we connect a cross connect cable between 2 servers in same subnet. We always get "Destination unreachable" errors.

This is the list of NICs available on our systems. The broadcom NICs are onborad and they are working fine. The Intel 82571EB are the HP quarcard which using e1000 driver. We have trying different versions of e1000 driver, but all give same error. At this point, we start to think that the Redhat AS 3 with 2.4.x kernel doesn't support the 82571EB chip set NICs. Have anyone had similar problems or know the problems/fixes between e1000 driver and 2.4.x kernel linux?

03:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet (rev 12)
05:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet (rev 12)
19:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (Copper) (rev 06)
19:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (Copper) (rev 06)
1a:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (Copper) (rev 06)
1a:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (Copper) (rev 06)

The tcpdump on the destination IP can see the broadcast ARP requests, but no responses are sent back.

Thanks

I experienced a similiar problem this week on an HP M350G5 w/ RHEL3U9 ES and e1000-7.6.12. I also noticed that ethtool reported the link down (when I *knew* the cabling was OK). Disabling APIC fixed the problem for me.

You can disable APIC by adding "noapic" your boot params in the configuration of your boot loader of choice.

e.g. - I use GRUB, so...

[root@host ~]# grep noapic /boot/grub/grub.conf
kernel /vmlinuz-2.4.21-50.ELsmp ro root=LABEL=/ noapic
kernel /vmlinuz-2.4.21-50.EL ro root=LABEL=/ noapic


Hope that helps.

~decnartne~

While this command seems to work it also forces all the interrupts to one CPU socket. the second one sees nothing..

Would the NOLAPIC be better? What is the difference?

that's correct. unfortunately, i posted my suggestion w/out fully understanding and quantifying the ramifications. ug...

Any way around this? is there a way to force APIC back on after the system is booted all the way? What about starting the NIC up either earlier or later?

Seems that we need to find a way to make the NIC work while APIC is enabled...