From: Wei Yang <weiyang@linux.vnet.ibm.com>
To: Yinghai Lu <yinghai@kernel.org>
Cc: "Wei Yang" <weiyang@linux.vnet.ibm.com>,
"Marek Kordík" <kordikmarek@gmail.com>,
"Alexey Voronkov" <zermond@gmail.com>,
"Gavin Shan" <gwshan@linux.vnet.ibm.com>,
"Benjamin Herrenschmidt" <benh@kernel.crashing.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] PCI: Clear bridge MEM_64 flag if one child does not support it
Date: Tue, 9 Dec 2014 15:56:19 +0800 [thread overview]
Message-ID: <20141209075619.GA23327@richard> (raw)
In-Reply-To: <CAE9FiQWz=vdR=QSkoEs5XjUxg_y4vJgnChQAc1-U_9xzfQpknQ@mail.gmail.com>
On Mon, Dec 08, 2014 at 11:20:59PM -0800, Yinghai Lu wrote:
>On Mon, Dec 8, 2014 at 6:26 PM, Wei Yang <weiyang@linux.vnet.ibm.com> wrote:
>> On Tue, Dec 09, 2014 at 11:11:19AM +1100, Gavin Shan wrote:
>>>
>>>I'm going to give it a spin and Richard, could you please apply Yinghai's
>>>patch to see if your SRIOV code can work properly?
>>>
>>
>> I did a quick test on my machine. This patch doesn't affect the MMIO
>> allocation on out platform, so SRIOV works fine.
>>
>> I will spend more time to read the patch to get more understanding about the
>> problem.
>
>Hi Marek,
>
>Can you boot following branch with "debug ignore_loglevel pci=realloc"
>on your setup?
>
>git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git
>for-pci-allocate-fit-3.18
>
>it has
>8f74af9: PCI, x86: Allocate mmio near end of free range
>1ff91c1: PCI: Don't allocate small resource in big free space.
>108b43b: resources: Add allocate_resource_fit()
>b6a22f0: resources: Make find_resource could return just fit resource
>cf50e16: resources: Split out __allocate_resource()
>
>on top the v3.18, and it will allocate resource in fit way.
Hi, Yinghai
Just spent some time to understand the problem and your patch.
Two comments to this patch:
1. realloc_head is not necessary here
2. In case we have two MEM BAR under a bus, one is MEM64|PREF and one is PREF,
after this patch, the MEM64 flag will be cleared, right? If so, this may fall
back to the same situation in bug 74151.
I am looking at the bugzilla and try to understand the root cause for this
allocation failure. Currently I don't get the reason. In my mind, the resource
will be sized in the non-pref bridge window. But seems not. I have asked more
info in the bugzilla, so that I could understand the problem. (Yeah, maybe I
am not that smart, if one of you would help me understand the problem, I am
happy to offer you a cup of coffee :-) )
Bjorin,
As you mentioned in another thread, "5b28541552ef is taking the wrong
approach". (http://www.spinics.net/lists/linux-pci/msg37374.html) Maybe I
don't catch it clearly. Put a 32bit prefetchable resource in a 32bit
non-prefetchable bridge window is a bad idea? But in my mind, if the bridge
prefetchable window is 64bit, we can't put a 32bit prefetchable resource in
it.
I am trying to catch up with the updates of the bug, if I missed something
just let me know.
>
>Thanks
>
>Yinghai
--
Richard Yang
Help you, Help me
next prev parent reply other threads:[~2014-12-09 7:56 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-08 21:52 [PATCH] PCI: Clear bridge MEM_64 flag if one child does not support it Yinghai Lu
2014-12-08 22:56 ` Benjamin Herrenschmidt
2014-12-08 23:00 ` Benjamin Herrenschmidt
2014-12-09 0:09 ` Yinghai Lu
2014-12-09 21:39 ` Yinghai Lu
2014-12-08 23:59 ` Yinghai Lu
2014-12-09 0:11 ` Gavin Shan
2014-12-09 2:26 ` Wei Yang
2014-12-09 7:20 ` Yinghai Lu
2014-12-09 7:56 ` Wei Yang [this message]
2014-12-09 18:21 ` Bjorn Helgaas
2014-12-10 9:42 ` Wei Yang
2014-12-09 19:49 ` Yinghai Lu
2014-12-09 18:07 ` Marek Kordík
2014-12-09 18:22 ` Bjorn Helgaas
2014-12-09 19:42 ` Yinghai Lu
2014-12-09 22:15 ` Marek Kordík
2014-12-09 23:16 ` Yinghai Lu
2014-12-09 1:08 ` Gavin Shan
2014-12-09 1:38 ` 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=20141209075619.GA23327@richard \
--to=weiyang@linux.vnet.ibm.com \
--cc=benh@kernel.crashing.org \
--cc=bhelgaas@google.com \
--cc=gwshan@linux.vnet.ibm.com \
--cc=kordikmarek@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--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.