Re: [discuss] Re: [RFC] Whitelist chipsets supporting MSI and check Hyper-transport capabilities

[ebiederm@xmission.com (Eric W. Biederman)]

Jeff Garzik <jeff@garzik.org> writes:

> Andi Kleen wrote:
>> On Tuesday 20 June 2006 10:02, Jeff Garzik wrote:
>>> Andi Kleen wrote:
>>>> So if there are any more MSI problems comming up IMHO it should be white
>>>> list/disabled by default and only turn on after a long time when Windows
>>>> uses it by default or something. Greg, do you agree?
>>>
>>> We should be optimists, not pessimists.
>> Yes, booting on all systems is overrated anyways, isn't it?
>
> Don't be silly.  Whatever solution is arrived at will boot on all systems.
> That's an obvious operational requirement.
>
> This is how new technology always works in Linux.  We turn it on and see what
> works, and what doesn't.  And whether existing problems will disappear.  With
> MSI, I think we see them disappearing.
>
> Newer systems seem to be doing better with MSI, in part because PCI-Express and
> other technologies trend towards MSI-style operation.
>
> And the kernel's MSI code is finally getting cleaned up, and getting the
> attention it needs.
>
>
>>> MSI is useful enough that we should turn it on by default in newer systems.
>> That is what we've tried so far and it seems to not work.
>
> IMO that's an exaggeration.  On 50% of the x86-64 platforms (Intel), MSI has
> been working for quite some time.  On newer systems in the other half of the
> platforms, MSI seems be more usable than it has been in the past.

It would help if the msi code as more than a 3 year old proof of concept
that has intel assumptions all through it.  Things are getting better
but there are still issues there.

I suspect that on x86 hypertransport systems if we directed our writes
to 0xFDF8000000 instead of at 0xfee0000 we would have quite a bit more luck.
Hopefully I can test and confirm that soon.  It is still a trick to get
a card with a working MSI implementation.

My gut feel is what we want is not a while list or a black list but instead
a MSI window driver.  The location and the meaning of the window is on the
edge of being an architectural definition.  But it really isn't and we are
treating it like one.

So I think part of the reason we are having MSI is we are making unwarranted
assumptions.  Once we take a good look at our side and fix that then we
can tell if something was broken.

Eric