> -----Original Message----- > From: Rose, Gregory V [mailto:gregory.v.r...@intel.com] > Sent: Tuesday, September 20, 2011 11:55 AM > To: Venugopal Busireddy; e1000-devel@lists.sourceforge.net > Subject: RE: [ixgbevf]: patch to fix incorrect PF NACK assertion... > > > -----Original Message----- > > From: Venugopal Busireddy [mailto:v...@nextio.com] > > Sent: Tuesday, September 20, 2011 9:37 AM > > To: e1000-devel@lists.sourceforge.net > > Subject: [E1000-devel] [ixgbevf]: patch to fix incorrect PF NACK > > assertion... > > > > diff -r 194e296c8d2e ixgbevf_main.c > > --- a/ixgbevf_main.c Thu Sep 15 10:46:23 2011 -0500 > > +++ b/ixgbevf_main.c Thu Sep 15 10:47:08 2011 -0500 > > @@ -997,15 +997,18 @@ > > if (!hw->mbx.ops.check_for_ack(hw, 0)) > > got_ack = true; > > > > - hw->mbx.ops.read(hw, &msg, 1, 0); > > - > > - if ((msg & IXGBE_MBVFICR_VFREQ_MASK) == IXGBE_PF_CONTROL_MSG) > > - mod_timer(&adapter->watchdog_timer, > > - round_jiffies(jiffies + 1)); > > - > > - if (msg & IXGBE_VT_MSGTYPE_NACK) > > - DPRINTK(DRV, ERR, "Last Request of type %2.2x to PF > > Nacked\n", > > - msg & 0xFF); > > + if (!hw->mbx.ops.check_for_msg(hw, 0)) { > > + hw->mbx.ops.read(hw, &msg, 1, 0); > > + > > + if ((msg & IXGBE_MBVFICR_VFREQ_MASK) == > > IXGBE_PF_CONTROL_MSG) > > + mod_timer(&adapter->watchdog_timer, > > + round_jiffies(jiffies + 1)); > > + > > + if (msg & IXGBE_VT_MSGTYPE_NACK) > > + DPRINTK(DRV, ERR, > > + "Last Request of type %2.2x to PF > > Nacked\n", > > + msg & 0xFF); > > + } > > > > /* > > * checking for the ack clears the PFACK bit. Place > > Thanks for submitting the patch. I'm curious what steps you were taking to > cause > a problem with this code. In our own testing we haven't been seeing an issue > with this. If you could provide some information on the steps to reproduce > the > problem I'd appreciate it. > > Thanks, > > - Greg
We too have been using the VF/PF drivers for over a year, and I haven't seen it either until now. I have not done anything special to cause this problem to show up. It just appeared in a setup... This is very sensitive to timing. Even on the setup where I saw this problem, the problem would go away if I added any debug statements to either driver to track the exchanges! I have to use PCIe traces to do that!! The window where the problem occurs is that the VF driver sends a message to the PF driver, and the PF driver reads the message and sets the IXGBE_PFMAILBOX_ACK. This causes an interrupt on the VF, and in the ixgbevf_msix_mbx() function, we first read the ACK, and then proceed to read the mailbox for a message. Just prior to that, the PF driver acquires the lock on the mailbox to return the response message. The read operation in the VF driver fails because it cannot acquire the lock. Thanks, Venu ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
