On 20/01/16 18:02, Andrew Donnellan wrote:
I'm hitting an issue on a ppc64le box running linux-next, which
according to git bisect is caused by this patch.
Whoops, that should be linuxppc*-dev*@lists.ozlabs.org in the Cc.
Andrew
--
Andrew Donnellan Software Engineer, OzLabs
andr
Currently, the OPAL msglog/console buffer is exposed as a sysfs file, with
the sysfs read handler responsible for retrieving the log from the OPAL
buffer. We'd like to be able to use it in xmon as well.
Refactor the OPAL msglog code to create a new function, opal_msglog_copy(),
that copies to an a
Add the 'do' command to dump the OPAL msglog in xmon.
Signed-off-by: Andrew Donnellan
---
arch/powerpc/xmon/xmon.c | 60
1 file changed, 60 insertions(+)
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index 07a8508..48b75ae 1006
On Wed, 2016-01-06 at 15:17 +0100, Petr Mladek wrote:
> On Fri 2015-12-04 15:45:29, Torsten Duwe wrote:
> > Changes since v4:
> > * change comment style in entry_64.S to C89
> > (nobody is using assembler syntax comments there).
> > * the bool function restore_r2 shouldn't return 2,
> >
On Tue, 2016-01-19 at 18:49 -0200, Breno Leitao wrote:
> During some debugging, we found that during a stack overflow, the SIGSEGV code
> returned is different on Power and Intel.
>
> We were able to narrow down the test case to the follow simple code:
>
> https://github.com/leitao/stack/blob/
On Wed, 2015-12-02 at 16:25 +1100, Gavin Shan wrote:
> In eeh_pe_loc_get(), the PE location code is retrieved from the
> "ibm,loc-code" property of the device node for the bridge of the
> PE's primary bus. It's not correct because the property indicates
> the parent PE's location code.
>
> This re
Looks good :)
Acked-by: Ian Munsie
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Tue, 2016-01-19 at 18:14 +0100, Frederic Barrat wrote:
> Introduce a new API to read the VPD of the adapter. In bare-metal, a
> kernel driver can find out the adapter pci_dev behind the AFU device
> and call pci_read_vpd() directly, but it won't work in a (powerVM)
> guest.
> Current implementat
On 20/01/16 04:14, Frederic Barrat wrote:
Introduce a new API to read the VPD of the adapter. In bare-metal, a
kernel driver can find out the adapter pci_dev behind the AFU device
and call pci_read_vpd() directly, but it won't work in a (powerVM)
guest.
Current implementation is a stub to allow e
Hello Gavin,
On Wed, Dec 2, 2015 at 3:55 PM, Gavin Shan wrote:
> In eeh_pe_loc_get(), the PE location code is retrieved from the
> "ibm,loc-code" property of the device node for the bridge of the
> PE's primary bus. It's not correct because the property indicates
> the parent PE's location code.
Breno,
Just to complement what you said, the si->si_code value you get on Power
with the code you provided (SEGV_ACCERR 2) comes
from .../arch/powerpc/mm/fault.c, line 375: https://goo.gl/6K40Bv
Hence, changing that line to 'code = SEGV_MAPERR;' makes your code die with
SIGSEGV Code ID 1, not 2:
During some debugging, we found that during a stack overflow, the SIGSEGV code
returned is different on Power and Intel.
We were able to narrow down the test case to the follow simple code:
https://github.com/leitao/stack/blob/master/overflow.c
On Power, the SIGSEV si->si_code is 2 (SEGV_ACCER
We have 2 patches here to deal with checks of EEH availability before its use.
The issue that triggered these patches was related to hotplug-add a PCI device
with no other PCI device present in machine. Since EEH wouldn't be enabled in
this case, we hit an oops.
We already sent a patch to ppc-dev
The Dynamic DMA Window (DDW) mechanism relies on EEH to obtain the
configuration address of devices. For example, the functions query_ddw()
and create_ddw() make use of eeh_dev struct. So, the dependency is
intrinsic - DDW mechanism will fail if EEH is not enabled.
Despite this dependency, no chec
The function eeh_add_device_early() is used to perform EEH initialization in
devices added later on the system, like in hotplug/DLPAR scenarios. Since the
commit 89a51df5ab1d ("powerpc/eeh: Fix crash in eeh_add_device_early() on Cell")
a new check was introduced in this function - Cell has no EEH c
On 01/14/2016 09:37 PM, Michael Ellerman wrote:
So, since my patch does not cover this case, I think would be more
interesting "unlink" the DDW mechanism from the EEH. It seems easy, I'll
try to send you a patch soon.
Do you think it is a good approach?
It sounds good, but I don't know off han
On 01/18/2016 09:52 PM, Alexey Kardashevskiy wrote:
On 01/13/2016 01:24 PM, Douglas Miller wrote:
On 01/12/2016 05:07 PM, Benjamin Herrenschmidt wrote:
On Tue, 2016-01-12 at 15:40 +1100, Alexey Kardashevskiy wrote:
Quite often drivers set only "write" permission assuming that this
includes
Introduce a new API to read the VPD of the adapter. In bare-metal, a
kernel driver can find out the adapter pci_dev behind the AFU device
and call pci_read_vpd() directly, but it won't work in a (powerVM)
guest.
Current implementation is a stub to allow existing drivers (cxlflash)
to start using it
Commit-ID: 9c03ee147193645be4c186d3688232fa438c57c7
Gitweb: http://git.kernel.org/tip/9c03ee147193645be4c186d3688232fa438c57c7
Author: Raghavendra K T
AuthorDate: Sat, 16 Jan 2016 00:31:23 +0530
Committer: Ingo Molnar
CommitDate: Tue, 19 Jan 2016 08:42:20 +0100
sched: Fix crash in sche
On Tue, Jan 19, 2016 at 3:11 PM, Lorenzo Pieralisi
wrote:
> On Tue, Jan 19, 2016 at 11:28:56AM +0530, Ganapatrao Kulkarni wrote:
>> On Mon, Jan 18, 2016 at 11:11 PM, David Daney wrote:
>> > On 01/18/2016 08:36 AM, Ganapatrao Kulkarni wrote:
>> >>
>> >> update numa_node of device associated with p
On 1/12/16, Michael Ellerman wrote:
> On Mon, 2015-12-14 at 23:18 +0300, Denis Kirjanov wrote:
>
>> ./drmgr -c cpu -a -r gives the following warning:
>>
>> [ 2327.035563]
>> RCU used illegally from offline CPU!
>> rcu_scheduler_active = 1, debug_locks = 1
>> [ 2327.035564] no locks held by swapper
On Tue, Jan 19, 2016 at 11:28:56AM +0530, Ganapatrao Kulkarni wrote:
> On Mon, Jan 18, 2016 at 11:11 PM, David Daney wrote:
> > On 01/18/2016 08:36 AM, Ganapatrao Kulkarni wrote:
> >>
> >> update numa_node of device associated with pci bus.
> >> moved down devm_kzalloc to allocate from node memory
22 matches
Mail list logo
