Question about em_irq_fast

[Sean Bruno]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-net/attachments/20160808/5eba93dc/attachment.sig>