linux-kernel - Re: 2.6.20-rc7: known regressions (v2) (part 1)

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: <m1wt2yzxq4.fsf@ebiederm.dsl.xmission.com>
Date:	Sat, 03 Feb 2007 15:24:03 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Auke Kok <auke-jan.h.kok@...el.com>
Cc:	Adam Kropelin <akropel1@...hester.rr.com>,
	Adrian Bunk <bunk@...sta.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	jgarzik@...ox.com, alan@...rguk.ukuu.org.uk,
	Allen Parker <parker@...hunt.com>, jesse.brandeburg@...el.com,
	gregkh@...e.de, linux-pci@...ey.karlin.mff.cuni.cz,
	netdev@...r.kernel.org
Subject: Re: 2.6.20-rc7: known regressions (v2) (part 1)

Auke Kok <auke-jan.h.kok@...el.com> writes:

> that's explained by a driver change that did that. Since at initialization we're
> basically waiting for a link change to tell the stack that we're up, we decided
> to change the order to have the hardware fire an LSI interrupt to trigger a
> watchdog run. So no interrupts would immediately explain why the watchdog never
> runs. That's nothing to worry about for this problem, as soon as interrupts are
> seen in /proc/interrupts this all starts working for e1000.

While I think we need to fix this issue, and in general the issue of MSI
interrupts on PCI-Express busses downstream of hypertransport chains.
This e1000 issue is not a regression, so not fixing it for 2.6.20 is
not a big deal.

I have yet to see all of the pieces I'm trying to look at confirmed,
but I believe by at least looking at the hypertransport MSI mapping
capability's enable bit in general we should be able to do a much
better job of detecting if MSI works in a system or not.

I though someone several months ago had made our MSI supported detect logic
a lot smarter, with defaults that were generally correct, but looking
at the kernel that code apparently never made it anywhere.  Instead
all I see are a handful of common chipsets special cased by the quirk logic.

We should be able to do a lot better but not in the 2.6.20 time frame.

As for the original problem report with duplicate MSI interrupts in
/proc/interrupts.  That sounds like a regression and is probably
simple to fix if we can get some more details.

Eric
-
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/