Hi I have a number of ibm x336 servers that have the following 2 onboard nics (eth0/1 are 2 other bcm57xx nics on a PCIX card). kernel version is 2.6.15.4, though I have tried 2.4.32/2.6.14-rc4 and they both have the issue below.
ACPI: PCI Interrupt 0000:06:00.0[A] -> GSI 16 (level, low) -> IRQ 169 PCI: Enabling bus mastering for device 0000:06:00.0 PCI: Setting latency timer of device 0000:06:00.0 to 64 eth2: Tigon3 [partno(BCM95721) rev 4101 PHY(5750)] (PCI Express) 10/100/1000BaseT Ethernet 00:0d:60:9a:81:be eth2: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] Split[0] WireSpeed[1] TSOcap[1] eth2: dma_rwctrl[76180000] ACPI: PCI Interrupt 0000:07:00.0[A] -> GSI 16 (level, low) -> IRQ 169 PCI: Setting latency timer of device 0000:07:00.0 to 64 eth3: Tigon3 [partno(BCM95721) rev 4101 PHY(5750)] (PCI Express) 10/100/1000BaseT Ethernet 00:0d:60:9a:81:bf eth3: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] Split[0] WireSpeed[1] TSOcap[1] eth3: dma_rwctrl[76180000] I am seeing the following issue on only the first onboard nic on each of the servers. If the nic is put into promisc mode too soon after the nic is brought up, the promisc bit in the rx_mode register is somehow getting reset to 0; Test cases are non-sleep case (promisc bit gets lost) ifconfig eth2 up;tcpdump -n -i eth2 and sleep case (promisc is set) ifconfig eth2 up;sleep 1;tcpdump -n -i eth2 I added some addition debug statements to the driver to printk when its updates to the rx_mode register. It dumps what the change is, who changed it (via stack dump) and re-reads the register and print the value out. This is the output of the parts that set the device into promisc mode, which is the same for both test cases. ADDRCONF(NETDEV_UP): eth2: link is not ready eth2: setting rx_mode register to 00000102 [<f888e26c>] _tw32_flush+0x30/0xac [tg3] [<f88973a0>] __tg3_set_rx_mode+0x194/0x1ac [tg3] [<c012d668>] wakeme_after_rcu+0x0/0x10 [<f88973dd>] tg3_set_rx_mode+0x25/0x3c [tg3] [<c04bbfb1>] __dev_mc_upload+0x21/0x28 [<c04bbfd1>] dev_mc_upload+0x19/0x28 [<c04b987b>] dev_set_promiscuity+0x37/0x5c [<c0580bc7>] packet_dev_mc+0x67/0x7c [<c0580d36>] packet_mc_add+0x126/0x13c [<c0580f25>] packet_setsockopt+0xa5/0xd4 [<c04b0c51>] sys_setsockopt+0x69/0x84 [<c04b1296>] sys_socketcall+0x1b6/0x208 [<c0102af9>] syscall_call+0x7/0xb eth2: read 00000102 from rx_mode register device eth2 entered promiscuous mode tg3: eth2: Link is up at 100 Mbps, full duplex. tg3: eth2: Flow control is off for TX and off for RX. ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready both indicate they are setting the promisc bit 0x000000100, and reading it back as being set, but ethtool and tcpdump show otherwise in the non-sleep case. non-sleep case # ethtool -d eth2 | egrep -A4 1128 | egrep -A4 1128 | head -4 1128 0x02 1129 0x00 1130 0x00 1131 0x00 sleep case # ethtool -d eth2 | egrep -A4 1128 | egrep -A4 1128 | head -4 1128 0x02 1129 0x01 1130 0x00 1131 0x00 I recent got burned by this because we use eth2/3 in a bridge, eth2 wasnt seeing any stp related broadcasts, which triggered a loop. thanks jim - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
