[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m1ireizet0.fsf@ebiederm.dsl.xmission.com>
Date: Sat, 03 Feb 2007 22:12:43 -0700
From: ebiederm@...ssion.com (Eric W. Biederman)
To: "Adam Kropelin" <akropel1@...hester.rr.com>
Cc: "Auke Kok" <auke-jan.h.kok@...el.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)
"Adam Kropelin" <akropel1@...hester.rr.com> writes:
> Naive question... Can the pci layer (or e1000) detect that MSI is not enabled in
> the hardware and avoid using it in that case? With the number of MSI problems
> showing up it seems risky to assume it's usable on any given platform without
> some sort of sanity check.
>
Yes, that is what we should do. Start with the assumption MSI doesn't work
and enable it when we detect the hardware is setup properly.
Thing is that is going to take a little bit of work, and a little bit of
thinking on how to structure it properly. So in real time it is going
to be a couple of weeks before the code to do that is ready.
Right now the model is that piecemeal we put in the code to
conditionally turn off chipsets that are known to have problems.
Which for building a reliable system when MSI isn't mandatory for
operation seems backwards.
Probably in addition we should have a warning such as:
"Found devices supporting MSI and but chipset is unknown".
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/
Powered by blists - more mailing lists