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 -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
