On 2016-09-23 13:23:22 [+0000], Koehrer Mathias (ETAS/ESW5) wrote:

Hi Sebastian,

Hi Mathias,

The critical stuff seems to be
igb_has_link() calling hw->mac_ops.check_for_link (which is igb_check_for_link_82575() )
calling igb_check_for_copper_link() calling igb_phy_has_link.

Within igb_phy_has_link() the line with the code
   ret_val = hw->phy.ops.read_reg(hw, PHY_STATUS, &phy_status);
seems to be the candidate that causing the trouble.
And this function pointer points to igb_read_phy_reg_82580().

Does this give you any idea what goes wrong?

Nope. There is nothing that might prevents preemption (unless I missed
something). However if you there are a lot of posted writes writes to
the HW, the read might force them to occur *now* which will stall the
CPU until it happens.
Try to comment the function(s) out to see if that spikes vanishes. 
That igb_read_phy_reg_82580() function also invokes another one for the
acquire callback.

Thanks for any hints!

Regards

Mathias

Sebastian