netdev - Re: e100: inappropriate handling of shared interrupt ?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20061201193257.GA19425@gmail.com>
Date:	Fri, 1 Dec 2006 11:32:57 -0800
From:	Shaw Vrana <shaw@...nix.com>
To:	Auke Kok <auke-jan.h.kok@...el.com>
Cc:	netdev@...r.kernel.org
Subject: Re: e100: inappropriate handling of shared interrupt ?

Hi Auke,

On Mon, Nov 27, 2006 at 11:18:13AM -0800, Auke Kok wrote:
> >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?

       CPU0       
  0: 1236112960          XT-PIC  timer
  2:          0          XT-PIC  cascade
  4:     144338          XT-PIC  serial
  5:    2109514          XT-PIC  primary
  8:          0          XT-PIC  rtc
  9:          0          XT-PIC  ehci_hcd
 10:   55010907          XT-PIC  lan0_0
 12:   57079668          XT-PIC  wan0_0
 14:   28456949          XT-PIC  ide0
NMI:          0 
ERR:          0


> >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.

NIC statistics:
     rx_packets: 25896640
     tx_packets: 33721440
     rx_bytes: 391691733
     tx_bytes: 2804738076
     rx_errors: 0
     tx_errors: 0
     rx_dropped: 0
     tx_dropped: 0
     multicast: 0
     collisions: 0
     rx_length_errors: 0
     rx_over_errors: 0
     rx_crc_errors: 0
     rx_frame_errors: 0
     rx_fifo_errors: 0
     rx_missed_errors: 0
     tx_aborted_errors: 0
     tx_carrier_errors: 0
     tx_fifo_errors: 0
     tx_heartbeat_errors: 0
     tx_window_errors: 0
     tx_deferred: 0
     tx_single_collisions: 0
     tx_multi_collisions: 0
     tx_flow_control_pause: 40967
     rx_flow_control_pause: 0
     rx_flow_control_unsupported: 0
     tx_tco_packets: 0
     rx_tco_packets: 0


Unfortunately I do not currently have a machine in the lab on which I can
reproduce this problem, so this data toook a little while to get.  I did
find a box with the same version of the NIC, but the weird packets did not
appear on there at all.  I have seen this problem personally, but that box
seems to have disappeared.

Is there any reason these packets would not be reported in the above
statistics?  And if an interrupt sharing error is out, where could these
packets be coming from?

> 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).

I'll fly the NIC home and test the new driver if worse comes to worse.. :(


Thanks for your input,
Shaw
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html