On Fri, 2013-06-28 at 21:10 +0800, Gavin Shan wrote:
> The issue was introduced by commit 37f02195 ("powerpc/pci: fix
> PCI-e devices rescan issue on powerpc platform"). The field
That "fix" caused more problems than it solved. There's a better
approach floating around that I will merge eventually
On Fri, Jun 28, 2013 at 02:40:59PM +0530, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V"
>
> We want to use CMA for allocating hash page table and real mode area for
> PPC64. Hence move DMA contiguous related changes into a seperate config
> so that ppc64 can enable CMA without requiring DMA
On Fri, Jun 28, 2013 at 02:41:02PM +0530, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V"
>
> Both RMA and hash page table request will be a multiple of 256K. We can use
> a chunk size of 256K to track the free/used 256K chunk in the bitmap. This
> should help to reduce the bitmap size.
>
> S
On Fri, Jun 28, 2013 at 02:41:01PM +0530, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V"
>
> Use CMA for allocation of RMA region for guest. Also remove linear allocator
> now that it is not used
>
> Signed-off-by: Aneesh Kumar K.V
Acked-by: Paul Mackerras
... though it could use a more
On Fri, Jun 28, 2013 at 02:41:00PM +0530, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V"
>
> Use CMA for allocation of guest hash page.
"page table" not just "page". This patch description seems a bit
brief for a patch of this length. Please describe a little more of
the motivation and the
On Sat, Jun 29, 2013 at 1:43 AM, Santosh Shilimkar
wrote:
> Rob,
> Are you ok with phys_addr_t since your concern was about rest
> of the memory specific bits of the device-tree code use u64 ?
No. I still think it should be u64 for same reasons I said originally.
>>>
>>> +1
>
On Fri, 2013-06-28 at 21:10 +0800, Gavin Shan wrote:
> The issue was introduced by commit 37f02195 ("powerpc/pci: fix
> PCI-e devices rescan issue on powerpc platform"). The field
> (struct pci_dev::irq) is reused by PCI core to trace the base
> MSI interrupt number if the MSI stuff is enabled on t
Hi Linus !
We discovered some breakage in our "EEH" (PCI Error Handling) code while
doing error injection, due to a couple of regressions. One of them is
due to a patch (37f02195b) that, in hindsight, I shouldn't have merged
considering that it caused more problems than it solved.
Please pull tho
On Sun, Jun 30, 2013 at 09:09:20AM +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2013-06-28 at 21:10 +0800, Gavin Shan wrote:
> > The issue was introduced by commit 37f02195 ("powerpc/pci: fix
> > PCI-e devices rescan issue on powerpc platform"). The field
> > (struct pci_dev::irq) is reused by PC
On Sun, Jun 30, 2013 at 09:09:20AM +1000, Benjamin Herrenschmidt wrote:
>On Fri, 2013-06-28 at 21:10 +0800, Gavin Shan wrote:
.../...
>I'm running some tests, so far it looks good. However, Gavin, when you
>have a chance on vpl3, try injecting errors to other adapters, for
>example the VGA adapte
On Sun, 2013-06-30 at 09:51 +0800, Gavin Shan wrote:
> Ben, I think one patch was lost from mainline and that fixes the problem.
>
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=5fb621698e94e3af8b413d9439041fde48e2784d
>
> I had the patch applied to /home/benh/linu
Hi Linus !
Earlier today I mentioned that while we had fixed the kernel crashes,
EEH error recovery didn't always recover... It appears that I had
a fix for that already in powerpc-next (with a stable CC).
I cherry-picked it today and did a few tests and it seems that things
now work quite well.
On Thu, 2013-06-27 at 13:46 +0800, Gavin Shan wrote:
> During recovery for EEH errors, the device driver requires reset
> explicitly (most of cases). The EEH core doesn't do hotplug during
> reset. However, there might have some device drivers that can't
> support EEH. So the deivce can't be put in
13 matches
Mail list logo