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  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]
Date:	Tue, 9 Jul 2013 22:48:54 +0200
From:	Pavel Machek <>
To:	"Waskiewicz Jr, Peter P" <>
Cc:	"Ronciak, John" <>,
	"Kirsher, Jeffrey T" <>,
	"Brandeburg, Jesse" <>,
	"Allan, Bruce W" <>,
	"Wyborny, Carolyn" <>,
	"Skidmore, Donald C" <>,
	"Rose, Gregory V" <>,
	"Duyck, Alexander H" <>,
	"Dave, Tushar N" <>,
	"" <>
Subject: Re: e1000e on thinkpad x60: interrupt problem

On Tue 2013-07-09 17:15:48, Waskiewicz Jr, Peter P wrote:
> 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):

Yeah, of course you need to ask e1000e if it generated the
interrupt. That part works. The part that actually generates the
interrupt does not. Take a look at original mail...

packet comes
e1000e sets E1000_ICR_INT_ASSERTED bit
e1000e tries to generate an interrupt and fails
50msec passes
AHCI generates interrupt
all the handlers are called
    AHCI processes its interrupt, handles disk read
    e1000_intr notices E1000_ICR_INT_ASSERTED bit, delivers the packet.

Network still works, only slowly. Ping goes lower when I use the
disk. That matches what I see.

Do you have other explanation?

> /**
>  * 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

(cesky, pictures)
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists