Re: 24 lost ticks with 2.6.20.10 kernel

["Kok, Auke" <auke-jan.h.kok@intel.com>]

Michel Lespinasse wrote:
> On my system, every e1000_watchdog() invocation calls e1000_read_phy_reg()
> twice: first near the top of e1000_check_for_link() within the
> e1000_media_type_copper && hw->get_link_status condition, then within
> e1000_update_stats() to read and update the idle_errors statistic.
> Each call results in a 100ms delay. The second call is enclosed within
> an spin_lock_irqsave()..spin_unlock_irqrestore() section, so it results
> in 100ms of lost ticks too.

Unfortunately we need the spinlock here. I'm not 100% sure the irqsave is no 
longer needed since we recently modified the watchdog to run as a task (out of 
interrupt context), but this code hasn't made it upstream yet (it's sitting in 
mm if you're interested).

> Now I have no idea how to fix that, but it does seem like it must be an
> initialisation issue. Possibly it might be a matter of telling the firmware
> "management engine" to keep its paws off of the adapter, I dont know.
> If you want me to add logging within the init functions, let me know.

please don't, see below

> The other operations - like all the E1000_READ_REG() calls within
> e1000_update_stats() - seem to take negligible time compared to the
> two failing e1000_read_phy_reg() calls.
> 
>> I've had good results with 2.6.21.1 (even running tickless :)) on these 
>> NICs. Have you tried that yet?
> 
> Not yet. Coming up... I'd prefer not to rely on new kernels at this
> point though - but I can certainly try it just to report on current status.

I currently suspect that (on this NIC) you're being bitten by a initialization 
bug that was fixed in later patches that made it into 2.6.21. The best thing to 
try for you is attempt to run 2.6.21 in the same configuration and see if that 
fixes it for you. It has to do with a patch I sent to fix the firmware takeover 
bits at startup, something that was definately broken in 2.6.19 and probably 2.6.20.

Auke