Hi Sebastian, > > 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. I tried hard to identify a single function that is causing the spikes. However I had no success. I could not identify a single function. What I did now instead was to use the kernel tracer to identify the issue. I run now cyclictest with only one thread by using the following command: # cyclictest -a -i 100 -m -n -p 80 -t 1 -b 25 -f -O latency-format Please see the attached fragment of the trace output. It contains the last couple of cycles from the cyclictest before it stopped because of the latency being larger than 25us. I repeated that test a multiple times. And I noticed always igb relevant functions just before the final cycle in the cycletest. And for me it looks as if the calls that are in the trace from line 3621 to 3641 occur always before the latency exceeds the threshold. Can you please have a look inside the attached trace file. Do you have any idea what might cause the issue here? Thanks Mathias
Attachment:
trace-extract.gz
Description: trace-extract.gz
