linux-kernel - Re: 24 lost ticks with 2.6.20.10 kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4638B748.40007@intel.com>
Date:	Wed, 02 May 2007 09:07:36 -0700
From:	"Kok, Auke" <auke-jan.h.kok@...el.com>
To:	Michel Lespinasse <walken@....org>
CC:	Chuck Ebbert <cebbert@...hat.com>, linux-kernel@...r.kernel.org,
	Dave Jones <davej@...hat.com>, Jeb Cramer <cramerj@...el.com>,
	John Ronciak <john.ronciak@...el.com>,
	Jesse Brandeburg <jesse.brandeburg@...el.com>,
	Jeff Kirsher <jeffrey.t.kirsher@...el.com>
Subject: Re: 24 lost ticks with 2.6.20.10 kernel

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/