Oliver O'Halloran writes:
> On Wed, Sep 28, 2016 at 12:43 PM, Aneesh Kumar K.V
> wrote:
>> Balbir Singh writes:
>>
>>> The top 3 bits of the lower order byte should contain the
>>> AP encoding, we assume the top 3 bits of the MSB.
>
> Balbir, could you reword this so it says "Currently we wrong
Jan Stancek writes:
> Hi Denis / all,
>
> Do you know if there is a patch or lead for this problem? I seem
> to be hitting same Oops with P730 lpar when running 4.8 (see below),
> but 4.7.7 looks OK.
Does this fix it?
cheers
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_
On Fri, Sep 30, 2016 at 09:47:49AM +1000, Gavin Shan wrote:
>In current implementation, pcibios_sriov_enable() is used by PPC
>PowerNV platform only. In PowerNV specific pcibios_sriov_enable(),
>PF's IOV BARs might be updated (shifted) by pci_update_resource().
>It means the IOV BARs aren't ready f
On 11/10/16 02:09, Frederic Barrat wrote:
diff --git a/drivers/misc/cxl/cxl.h b/drivers/misc/cxl/cxl.h
index 01d372a..ed89c57 100644
--- a/drivers/misc/cxl/cxl.h
+++ b/drivers/misc/cxl/cxl.h
@@ -618,6 +618,14 @@ struct cxl {
bool perst_select_user;
bool perst_same_image;
bool psl_t
Am 10.10.2016 um 08:10 schrieb Heiner Kallweit:
> Am 10.10.2016 um 06:41 schrieb Michael Ellerman:
>> Heiner Kallweit writes:
>>
>>> Am 07.10.2016 um 21:26 schrieb Heiner Kallweit:
Am 07.10.2016 um 07:51 schrieb Oliver O'Halloran:
> Hi, Heiner
>
> Could you send me a copy of the k
On Mon, 10 Oct 2016 19:16:16 +0530
Ravi Bangoria wrote:
> On Wednesday 05 October 2016 05:04 PM, Arnaldo Carvalho de Melo wrote:
> > Em Wed, Sep 21, 2016 at 09:17:56PM +0530, Ravi Bangoria escreveu:
> >> From: Kim Phillips
> >>
> >> For ARM we remove the list that contains non-arm insns, and
> >
s with the same error.
Build logs of next-20161010 are at:
arm at https://travis-ci.org/sudipm-mukherjee/parport/jobs/166321467
powerpc at https://travis-ci.org/sudipm-mukherjee/parport/jobs/166321473
Regards
Sudip
Signed-off-by: Sudip Mukherjee
---
build log is at:
https://travis-ci.org/sudipm
Hi Vaibhav,
A few comments below...
Le 10/10/2016 à 16:09, Vaibhav Jain a écrit :
This patch prevents resetting the cxl adapter via sysfs in presence of
one or more active cxl_context on it. This protects against an
unrecoverable error caused by PSL owning a dirty cache line even after
reset
On 10/09/2016 10:49 PM, Nicholas Piggin wrote:
On Sun, 9 Oct 2016 08:21:21 -0700
Guenter Roeck wrote:
Nicholas,
some of my qemu tests for ppc64 started failing on mainline (and -next).
You can find a test log at
http://kerneltests.org/builders/qemu-ppc64-master/builds/580/steps/qemubuildcomma
This patch prevents resetting the cxl adapter via sysfs in presence of
one or more active cxl_context on it. This protects against an
unrecoverable error caused by PSL owning a dirty cache line even after
reset and host tries to touch the same cache line. In case a force reset
of the card is requir
On Wednesday 05 October 2016 05:04 PM, Arnaldo Carvalho de Melo wrote:
> Em Wed, Sep 21, 2016 at 09:17:56PM +0530, Ravi Bangoria escreveu:
>> From: Kim Phillips
>>
>> For ARM we remove the list that contains non-arm insns, and
>> instead add more maintainable branch instruction regex logic.
> Th
On Wednesday 05 October 2016 05:01 PM, Arnaldo Carvalho de Melo wrote:
> Em Wed, Sep 21, 2016 at 09:17:55PM +0530, Ravi Bangoria escreveu:
>> If jump target is outside of function range, perf is not handling it
>> correctly. Especially when target address is lesser than function start
>> address,
On Wednesday 05 October 2016 04:58 PM, Arnaldo Carvalho de Melo wrote:
> Em Wed, Sep 21, 2016 at 09:17:54PM +0530, Ravi Bangoria escreveu:
>> Current perf is not able to parse jump instruction when second operand
>> contains target address. Arch like powerpc has such instructions. For
>> example,
On Wednesday 05 October 2016 04:57 PM, Arnaldo Carvalho de Melo wrote:
> Em Wed, Sep 21, 2016 at 09:17:53PM +0530, Ravi Bangoria escreveu:
>> For jump instructions that does not include target address as direct
>> operand, use raw value for that. This is needed for certain powerpc
> "use raw va
Hi Arnaldo,
Sorry for little late replies, I was off last week.
Please find my comments.
On Wednesday 05 October 2016 04:49 PM, Arnaldo Carvalho de Melo wrote:
> Em Wed, Sep 21, 2016 at 09:17:51PM +0530, Ravi Bangoria escreveu:
>> Change current data structures and function to enable cross arch
On 10/10/16 23:53, Tejun Heo wrote:
> On Mon, Oct 10, 2016 at 10:17:16PM +1100, Balbir Singh wrote:
>> rest_init()
>> {
>> ...
>> kernel_thread(kernel_init, NULL, CLONE_FS);
>> numa_default_policy();
>> pid = kernel_thread(kthreadd, NULL, CLONE_FS | CLONE_FILES);
>> rcu_r
On Mon, Oct 10, 2016 at 09:02:53AM -0400, Tejun Heo wrote:
> Hello, Michael.
>
> On Mon, Oct 10, 2016 at 09:22:55PM +1100, Michael Ellerman wrote:
> > This patch seems to be causing one of my Power8 boxes not to boot.
> >
> > Specifically commit 3347fa092821 ("workqueue: make workqueue available
Hello, Michael.
On Mon, Oct 10, 2016 at 09:22:55PM +1100, Michael Ellerman wrote:
> This patch seems to be causing one of my Power8 boxes not to boot.
>
> Specifically commit 3347fa092821 ("workqueue: make workqueue available
> early during boot") in linux-next.
>
> If I revert this on top of ne
On Mon, Oct 10, 2016 at 10:17:16PM +1100, Balbir Singh wrote:
> rest_init()
> {
> ...
> kernel_thread(kernel_init, NULL, CLONE_FS);
> numa_default_policy();
> pid = kernel_thread(kthreadd, NULL, CLONE_FS | CLONE_FILES);
> rcu_read_lock();
> kthreadd_task = find_t
Hi Michael,
On 10/09/2016 11:00 PM, Michael Ellerman wrote:
Guenter Roeck writes:
Nicholas,
some of my qemu tests for ppc64 started failing on mainline (and -next).
You can find a test log at
http://kerneltests.org/builders/qemu-ppc64-master/builds/580/steps/qemubuildcommand/logs/stdio
The
Hi Denis / all,
Do you know if there is a patch or lead for this problem? I seem
to be hitting same Oops with P730 lpar when running 4.8 (see below),
but 4.7.7 looks OK.
Regards,
Jan
[8.698424] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[8.713373] IPv6: ADDRCONF(NETDEV_UP): eth1
On 10/10/16 21:22, Michael Ellerman wrote:
> Hi Tejun,
>
> Tejun Heo writes:
>> From f85002f627f7fdc7b3cda526863f5c9a8d36b997 Mon Sep 17 00:00:00 2001
>> From: Tejun Heo
>> Date: Fri, 16 Sep 2016 15:49:32 -0400
>> Subject: [PATCH] workqueue: make workqueue available early during boot
>>
>> Wor
Mahesh J Salgaonkar writes:
> From: Mahesh Salgaonkar
>
> There are chances that multiple CPUs can call crash_fadump() simultaneously
> and would start duplicating same info to vmcoreinfo ELF note section. This
> causes makedumpfile to fail during kdump capture. One example is,
> triggering dump
Anton Blanchard writes:
>> > 14c00-14c00 g exc_virt_0x4c00_system_call
>>^
>>What's this? The address? If so it's wrong?
>
> Offset into the binary I think, there's one 64kB page of ELF gunk at
> the start.
Ah OK makes sense.
>> So more digging required.
>
> Thanks for checking, it's
Hi Tejun,
Tejun Heo writes:
> From f85002f627f7fdc7b3cda526863f5c9a8d36b997 Mon Sep 17 00:00:00 2001
> From: Tejun Heo
> Date: Fri, 16 Sep 2016 15:49:32 -0400
> Subject: [PATCH] workqueue: make workqueue available early during boot
>
> Workqueue is currently initialized in an early init call; ho
Hi Michael,
> > 14c00-14c00 g exc_virt_0x4c00_system_call
>^
>What's this? The address? If so it's wrong?
Offset into the binary I think, there's one 64kB page of ELF gunk at
the start.
> Seems likely. But I can't see why.
>
> AFAICS we have never emitted a size for those symbols:
>
On Mon, 2016-10-10 at 16:35 +1100, Michael Ellerman wrote:
> > are you going to take this patch? The issue appears to me for a
> long time
>
> I guess. Ben's response was a bit equivocal. But I guess he meant
> "seems
> OK". So yeah I'll pick it up for 4.10.
Yeah... seems ok. I haven't touched th
27 matches
Mail list logo
