All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: "Gavin Shan" <gwshan@linux.vnet.ibm.com>,
	"Yinghai Lu" <yinghai@kernel.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"Alexey Voronkov" <zermond@gmail.com>,
	"David Airlie" <airlied@linux.ie>,
	"Saifi Khan" <saifi.khan@datasynergy.org>,
	"Alex Deucher" <alexdeucher@gmail.com>,
	"Marek Kordík" <kordikmarek@gmail.com>,
	"Richard Yang" <weiyang@linux.vnet.ibm.com>
Subject: Re: Regression: bug 85491: radeon 0000:01:00.0: Fatal error during GPU init
Date: Tue, 09 Dec 2014 08:38:03 +1100	[thread overview]
Message-ID: <1418074683.13358.1.camel@kernel.crashing.org> (raw)
In-Reply-To: <CAErSpo69c6jXOp+nw2sTSU4vgqGufUQNUEGK4_2+6p-qpyE0vQ@mail.gmail.com>

On Mon, 2014-12-08 at 14:04 -0700, Bjorn Helgaas wrote:
> 
> However, I think 5b28541552ef is taking the wrong approach.  Consider
> a device that, like this Radeon, has a 32-bit prefetchable BAR.  If
> the upstream bridge has a 32-bit prefetchable window, things work as
> expected -- we put the prefetchable BAR in the prefetchable window.
> But if the bridge has a 64-bit prefetchable window, we put that same
> BAR in a 32-bit non-prefetchable window.

Well, that's expected, unless the 64-bit prefetchable window happens to
be fully enclosed in 32-bit space ... So maybe the approach is to check
that this is the case and "downgrade" such 64-bit prefetchable BARs to
32-bit ...

Cheers,
Ben.


> So we upgraded the system with a better bridge, i.e., it supports a
> full 64-bit window instead of just a 32-bit window, and the system
> performs WORSE.  That's what I think is fundamentally broken.
> 
> > Looking at bug#85491 and the logs from Marek, BIOS didn't configure
> windows
> > and BARs for PCI bridge and adapters properly, which forces the
> kernel to
> > reassign those BARs/windows failing to be claimed previously. If I'm
> correct,
> > we need a way to reassign the bridge's non-prefetchable window and
> with it,
> > find_free_bus_resource() needn't check on "!r->parent".
> 
> It's true that the BIOS didn't configure things correctly.  But we
> can't use that as an excuse; the kernel should be able to configure
> things correctly itself because there are plenty of machines where the
> BIOS never configures things.



  reply	other threads:[~2014-12-08 21:38 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-03 22:15 Regression: bug 85491: radeon 0000:01:00.0: Fatal error during GPU init Bjorn Helgaas
2014-12-04  0:51 ` Bjorn Helgaas
2014-12-04  1:44   ` Yinghai Lu
2014-12-04 17:34     ` Bjorn Helgaas
2014-12-04 22:06       ` Yinghai Lu
2014-12-05 10:59         ` Benjamin Herrenschmidt
2014-12-08  0:47           ` Gavin Shan
2014-12-08 21:04             ` Bjorn Helgaas
2014-12-08 21:38               ` Benjamin Herrenschmidt [this message]
2014-12-08 21:46                 ` Bjorn Helgaas
2014-12-08 23:38                   ` Gavin Shan
2014-12-09  0:21                     ` Yinghai Lu
2014-12-19 22:17                       ` Bjorn Helgaas
2014-12-20  0:23                       ` Bjorn Helgaas
2014-12-20  0:34                         ` Yinghai Lu
2014-12-20  0:56                           ` Bjorn Helgaas
2014-12-20  1:33                             ` Yinghai Lu
2014-12-23  1:53                               ` Yinghai Lu
2014-12-23 21:41                                 ` Bjorn Helgaas
2014-12-24  2:29                                   ` Yinghai Lu
2014-12-24 17:26                                     ` Bjorn Helgaas
2014-12-24 20:29                                       ` Yinghai Lu
2014-12-25 15:46                                     ` Marek Kordík
2014-12-25 21:12                                       ` Yinghai Lu
2015-01-09 18:45                                         ` Bjorn Helgaas
2015-01-09 20:38                                           ` Yinghai Lu
2014-12-22  8:17                           ` Wei Yang
2014-12-22 19:50                             ` Bjorn Helgaas
2014-12-04  1:38 ` Yinghai Lu
2014-12-04  1:41   ` Yinghai Lu
2014-12-04 16:15     ` Bjorn Helgaas
2014-12-04 22:15       ` Yinghai Lu
2014-12-04 22:25         ` Bjorn Helgaas
2014-12-04  2:01 ` Yinghai Lu
2014-12-04 16:37   ` Bjorn Helgaas
2014-12-04 22:24     ` Yinghai Lu
2014-12-05  0:24       ` Yinghai Lu

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=1418074683.13358.1.camel@kernel.crashing.org \
    --to=benh@kernel.crashing.org \
    --cc=airlied@linux.ie \
    --cc=alexdeucher@gmail.com \
    --cc=bhelgaas@google.com \
    --cc=gwshan@linux.vnet.ibm.com \
    --cc=kordikmarek@gmail.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=saifi.khan@datasynergy.org \
    --cc=weiyang@linux.vnet.ibm.com \
    --cc=yinghai@kernel.org \
    --cc=zermond@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.