On 08/05/16 12:01, Sreekanth Rupavatharam wrote: > We have this code snippet in em_irq_fast > > ifp = > adapter->ifp; > > > > > reg_icr = E1000_READ_REG(&adapter->hw, > E1000_ICR); > > > > > /* Hot eject? > */ > > if (reg_icr == > 0xffffffff) > > return > FILTER_STRAY; > > > > > /* Definitely not our interrupt. > */ > > if (reg_icr == 0x0) > > return FILTER_STRAY; > > I don’t understand why the function returns if the read value is 0. From > the programmer’s manual of Intel NIC, I see the following definition. > > > > > > > > > > > > > > > > > > TXDW > > > > 0 > > > > 0b > > > > Transmit Descriptor Written Back Set when hardware processes a transmit > descriptor with the RS bit set (and possibly IDE set). If using delayed > interrupts (IDE set), the interrupt occurs after the timer expires. > > TXQE > > > > 1 > > > > 0b > > > > Transmit Queue Empty > > Set when the last descriptor block for a transmit queue has been used. > > LSC > > > > 2 > > > > 0b > > > > Link Status Change This bit is set each time the link status changes > (either from up to > > down, or from down to up). This bit is affected by the internal link > indication when configured for internal PHY mode. > > RXSEQ > > > > 3 > > > > 0b > > > > Receive Sequence Error In TBI mode/internal SerDes1, incoming packets > with a bad delimiter sequence set this bit. In other 802.3 > implementations, this would be classified as a framing error. A valid > sequence consists of: idle SOF data pad (opt) EOF fill (opt) > idle. This is a reserved bit for the *82541xx*, *82547GI/EI*, and > *82540EP/ EM*. Set to 0b. > > RXDMT0 > > > > 4 > > > > 0b > > > > Receive Descriptor Minimum Threshold Reached > > Indicates that the minimum number of receive descriptors are available > and software should load more receive descriptors. > > Reserved > > > > 5 > > > > 0b > > > > Reserved Reads as 0b. > > RXO > > > > 6 > > > > 0b > > > > Receiver Overrun Set on receive data FIFO overrun. Could be caused either > > because there are no available receive buffers or because PCI receive > bandwidth is inadequate. > > > > If an interrupt happens due to a normal receive, shouldn’t the value of > this register be 0 and still be valid? I am seeing this issue on a VM > guest(QEMU hypervisor) where during a flood test, the driver starts > rejecting packets because the register value is 0. Can anyone tell me > if it’s ok or not to remove the check for 0 value ? > > > > Thanks, > > > > -Sreekanth > > >
Is this with the "lem" driver or the "em" driver under QEMU? Look for "legacy" in the boot output of your VM. sean
signature.asc
Description: OpenPGP digital signature
