From mboxrd@z Thu Jan 1 00:00:00 1970 From: Auke Kok Subject: Re: e100: inappropriate handling of shared interrupt ? Date: Mon, 27 Nov 2006 11:18:13 -0800 Message-ID: <456B39F5.6070608@intel.com> References: <1197.38.114.160.126.1164653578.squirrel@webmail.vranix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netdev@vger.kernel.org Return-path: Received: from mga09.intel.com ([134.134.136.24]:25524 "EHLO mga09.intel.com") by vger.kernel.org with ESMTP id S933283AbWK0TSP (ORCPT ); Mon, 27 Nov 2006 14:18:15 -0500 To: Shaw Vrana In-Reply-To: <1197.38.114.160.126.1164653578.squirrel@webmail.vranix.com> Sender: netdev-owner@vger.kernel.org List-Id: netdev.vger.kernel.org Shaw Vrana wrote: > Hello All, > > I'm seeing some odd behavior using the e100 driver for an intel ethernet > controller 82557/8/9 (revv 10). It appears as if the e100 driver is > handling interrupts generated by another device, though I am not certain > of this.. > > Using some printks, I see some odd packets received that are eventually > dropped somewhere up the stack. The packets usually look something like > this: > > SrcAddr: 8.0.69.0 (bogus source ip) > DstAddr: 0.40.226.169 (bogus dest ip) > Protocol: 6 > InputInt: 2 > SrcPort: 20 > DstPort: 8793 > > The src address and dest. address are entirely bogus, the protocol is not > always TCP, but I've seen it be icmp or udp. In addition, I see _nothing_ > using tcpdump, which I also do not understand as I didn't think packets > were dropped before tcpdump. I've seen this behavior on multiple machines > using the same hardware, but haven't been able to make much sense of it. > These packets do not seem to affect the normal operation of the device, > i.e. it services correct ips/ports just as one would expect. > > B/c I haven't been able to see the packets using tcpdump, I have been > thinking that the packets were generated by the box itself. The packets > appear to be constantly arriving, though it does not appear as if a packet > with the same src ip/dst ip arrives more than once, though I could be > wrong about this. > > From dmesg I see that the e100 is sharing irq 12. > > e100: Intel(R) PRO/100 Network Driver, 3.4.8-k2-NAPI > e100: Copyright(c) 1999-2005 Intel Corporation > PCI: Found IRQ 12 for device 0000:01:04.0 > PCI: Sharing IRQ 12 with 0000:00:02.0 > PCI: Sharing IRQ 12 with 0000:00:1d.0 > divert: allocating divert_blk for eth0 > e100: eth0: e100_probe: addr 0xe8083000, irq 12, MAC addr 00:0E:B6:26:95:05 > (This is the only other message I see mentioning irq 12) what does /proc/interrupts say after the box is fully booted? > serio: i8042 AUX port at 0x60,0x64 irq 12 so, proc/interrupts should show 2 devices using the same interrupt. > (output of ethtool -e) > Offset Values > ------ ------ > 0x0000 00 0e b6 26 95 05 1b 0d ff ff 01 02 01 47 ff ff > 0x0010 ff ff ff ff 00 5f 70 00 86 80 7f 00 ff ff ff ff > 0x0020 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > 0x0030 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > 0x0040 ff ff ff ff ff ff 29 12 ff ff ff ff ff ff ff ff > 0x0050 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > 0x0060 2c 01 00 40 06 41 ff ff ff ff ff ff ff ff ff ff > 0x0070 ff ff ff ff ff ff ff ff ff ff ff ff ff ff b3 b5 > > eth1 Link encap:Ethernet HWaddr 00:0E:B6:26:95:05 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:3959305 errors:0 dropped:0 overruns:0 frame:0 > TX packets:5337629 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:100 > RX bytes:801040171 (763.9 MiB) TX bytes:797939498 (760.9 MiB) > Interrupt:12 Base address:0xd000 Memory:e8083000-e8084000 > > > Notice that 0 errors are reported.. How could this be? use ethtool -S eth1 to get more information on errors etc. It's unlikely that an irq problem shows up in the ifconfig error stats. Those are completely different counters that don't interact. > ethtool eth1 > Supported ports: [ TP MII ] > Supported link modes: 10baseT/Half 10baseT/Full > 100baseT/Half 100baseT/Full > Supports auto-negotiation: Yes > Advertised link modes: 10baseT/Half 10baseT/Full > 100baseT/Half 100baseT/Full > Advertised auto-negotiation: No > Speed: 100Mb/s > Duplex: Full > Port: MII > PHYAD: 1 > Transceiver: internal > Auto-negotiation: off > Supports Wake-on: g > Wake-on: d > Current message level: 0x00000007 (7) > Link detected: yes > > > Any ideas? can you try with the latest e100 driver from e1000.sf.net ? I don't think it solves it but it might help to try (doesn't hurt). Cheers, Auke