Re: 24 lost ticks with 2.6.20.10 kernel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux