netdev - Re: e1000e on thinkpad x60: interrupt problem

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <1373390146.4286.1.camel@ppwaskie-mobl2>
Date:	Tue, 9 Jul 2013 17:15:48 +0000
From:	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>
To:	Pavel Machek <pavel@....cz>
CC:	"Ronciak, John" <john.ronciak@...el.com>,
	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
	"Brandeburg, Jesse" <jesse.brandeburg@...el.com>,
	"Allan, Bruce W" <bruce.w.allan@...el.com>,
	"Wyborny, Carolyn" <carolyn.wyborny@...el.com>,
	"Skidmore, Donald C" <donald.c.skidmore@...el.com>,
	"Rose, Gregory V" <gregory.v.rose@...el.com>,
	"Duyck, Alexander H" <alexander.h.duyck@...el.com>,
	"Dave, Tushar N" <tushar.n.dave@...el.com>,
	"e1000-devel@...ts.sourceforge.net" 
	<e1000-devel@...ts.sourceforge.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: e1000e on thinkpad x60: interrupt problem

On Tue, 2013-07-09 at 19:02 +0200, Pavel Machek wrote:
> Hi!
> 
> > Nothing appears to be wrong.  If the system is seeing ping packets
> >at all means that device is generating interrupts and that they are
> >being processed.  If you are looking at performance then sharing
> 
> No, that's not true. There is other interrupt load, and e1000e has big
> enough buffers; that means that packets eventually get processed. I
> strongly suspect e1000e generates little or no interrupts and packets
> only get processed when other devices on shared interrupt line
> generate interrupt. 

If the interrupt is shared, e1000e checks if it's the hardware that
generated it before processing packets.  Consuming an interrupt that
isn't meant for this device will throw major warnings in the kernel
about bad interrupt routing, etc.  Here's the code from the interrupt
handler (note the last part of the pasted code):

/**
 * e1000_intr - Interrupt Handler
 * @irq: interrupt number
 * @data: pointer to a network interface device structure
 **/
static irqreturn_t e1000_intr(int __always_unused irq, void *data)
{
        struct net_device *netdev = data;
        struct e1000_adapter *adapter = netdev_priv(netdev);
        struct e1000_hw *hw = &adapter->hw;
        u32 rctl, icr = er32(ICR);

        if (!icr || test_bit(__E1000_DOWN, &adapter->state))
                return IRQ_NONE;  /* Not our interrupt */

        /* IMS will not auto-mask if INT_ASSERTED is not set, and if it
is
         * not set, then the adapter didn't send an interrupt
         */
        if (!(icr & E1000_ICR_INT_ASSERTED))
                return IRQ_NONE;

Cheers,
-PJ