public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: Greg KH <gregkh@suse.de>
Cc: Dave Olson <olson@unixfolk.com>,
	discuss@x86-64.org, Brice Goglin <brice@myri.com>,
	linux-kernel@vger.kernel.org,
	Greg Lindahl <greg.lindahl@qlogic.com>
Subject: Re: [discuss] Re: [RFC] Whitelist chipsets supporting MSI and check Hyper-transport capabilitiesKJ
Date: Wed, 21 Jun 2006 00:33:35 +0200	[thread overview]
Message-ID: <200606210033.35409.ak@suse.de> (raw)
In-Reply-To: <20060620212908.GA17012@suse.de>

On Tuesday 20 June 2006 23:29, Greg KH wrote:
> On Tue, Jun 20, 2006 at 09:25:30AM +0200, Andi Kleen wrote:
> > 
> > > Sure, that's true of almost everything new.   It remains broken until people
> > > start using it, complain, and get the bugs fixed.   Some of us have a vested
> > > interest in having MSI work, since it's the only way we can deliver interrupts.
> > > We've already worked with a few BIOS writers to get problems fixed, and we'll
> > > keep doing so as we find problems.   If enough hardware vendors and consumers
> > > do so, the broken stuff will get fixed, and stay fixed, because it will get
> > > tested.
> > 
> > Sometimes there are new things that work relatively well and only break occassionally
> > and then there are things where it seems to be the other way round.
> > 
> > My point was basically that every time we tried to turn on such a banana green feature
> > without white listing it was a sea of pain to get it to work everywhere
> > and tended to cause far too many non boots
> > 
> > (and any non boot is far worse than whatever performance advantage you get
> > from it) 
> > 
> > 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?
> 
> No, I don't want a whitelist, as it will be hard to always keep adding
> stuff to it (unless we can somehow figure out how to put a "cut-off"
> date check in there).  Yes, we do have a number of systems today that
> have MSI issues, but the newer ones all work properly, and we should
> continue on with the way we have today (blasklist problem boards, as the
> rest of the PCI subsystem works with the quirks).

On Intel chipsets just enabling it is fine - i haven't heard of a MSI problem
there so far. Detecting Intel chipsets can be tricky though - there are
AMD systems with Intel PCI bridges now. I suppose any blacklist will be 
per bridge.

Just on AMD there seems to be no PCI-X bridge that actually works with MSI without
hacks and PCI-E seems to be quite spotty too (e.g. BCM at least partly broken) 

Brice claims BCM can be fixed with a quirk and Petr claimed AMD 8132 can be fixed
with a quirk, but my personal feeling is that it is very risky to do so because
if these bits are not enabled by default they are likely unvalidated and might break
in subtle ways under high load (past experiences with forcing hardware features
on against BIOS wishes were usually negative) 

The good message is that AMD without quirk they don't do anything so it would just
not be enabled and at least not break anything.

BCM seems to need a blacklist to force MSI off (or at least tg3 is complaining
that MSI doesn't work). I guess we can try to contact someone at BCM
and ask them if they actually tested it. If they did then enabling it would
be fine.

NForce4 PCI Express is an unknown - we'll see how that works.

-Andi

  parent reply	other threads:[~2006-06-20 22:34 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <fa.5FgZbVFZIyOdjQ3utdNvbqTrUq0@ifi.uio.no>
     [not found] ` <fa.URgTUhhO9H/aLp98XyIN2gzSppk@ifi.uio.no>
2006-06-20  5:42   ` [discuss] Re: [RFC] Whitelist chipsets supporting MSI and check Hyper-transport capabilities Dave Olson
2006-06-20  7:25     ` Andi Kleen
2006-06-20  8:02       ` Jeff Garzik
2006-06-20  8:13         ` Andi Kleen
2006-06-20  8:27           ` Jeff Garzik
2006-06-20 22:44             ` Eric W. Biederman
2006-06-20 20:03       ` Greg Lindahl
2006-06-20 20:20         ` Randy.Dunlap
2006-06-20 20:26           ` Brice Goglin
2006-06-20 20:41           ` Greg Lindahl
2006-06-20 20:50             ` Brice Goglin
2006-06-20 20:53               ` Jeff Garzik
2006-06-20 20:57               ` Dave Olson
2006-06-20 20:23         ` Roland Dreier
2006-06-20 20:54           ` Jeff Garzik
2006-06-20 21:29       ` Greg KH
2006-06-20 22:27         ` Brice Goglin
2006-06-20 23:05           ` Greg KH
2006-06-20 23:16             ` Brice Goglin
2006-06-20 22:33         ` Andi Kleen [this message]
2006-06-20 22:46           ` [discuss] Re: [RFC] Whitelist chipsets supporting MSI and check Hyper-transport capabilitiesKJ Roland Dreier
2006-06-21  6:19             ` Dave Olson
2006-06-21  4:42 Allen Martin
2006-06-21 10:05 ` Andi Kleen
2006-06-21 16:21   ` Dave Olson
2006-06-21 16:37     ` Andi Kleen
     [not found]       ` <20060622012339.GD2614@greglaptop.internal.keyresearch.com>
2006-06-22  1:32         ` Greg Lindahl
  -- strict thread matches above, loose matches on Subject: below --
2006-06-23 15:43 Naren (Narendra) Sankar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200606210033.35409.ak@suse.de \
    --to=ak@suse.de \
    --cc=brice@myri.com \
    --cc=discuss@x86-64.org \
    --cc=greg.lindahl@qlogic.com \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=olson@unixfolk.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox