Ping?
On 02/10/2018 13:20, Alexey Kardashevskiy wrote:
> The skiboot firmware has a hot reset handler which fences the NVIDIA V100
> GPU RAM on Witherspoons and makes accesses no-op instead of throwing HMIs:
> https://github.com/open-power/skiboot/commit/fca2b2b839a67
>
> Now we are going to pas
When printing the machine check cause, the cause appears on the
following line due to bad use of printk without \n:
[ 33.663993] Machine check in kernel mode.
[ 33.664011] Caused by (from SRR1=9032):
[ 33.664036] Data access error at address c90c8000
This patch fixes it by using pr_cont() f
Ping?
On 17/09/2018 17:05, Alexey Kardashevskiy wrote:
> Ping?
>
> The problem is still there...
>
>
> On 24/08/2018 13:04, Alexey Kardashevskiy wrote:
>>
>>
>> On 09/08/2018 14:41, Alexey Kardashevskiy wrote:
>>>
>>>
>>> On 25/07/2018 19:50, Alexey Kardashevskiy wrote:
I am trying to pas
do_exit() already includes a test to panic() is in_interrupt()
This patch removes powerpc one which is redundant.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/traps.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index
Cc: sta...@vger.kernel.org
Le 13/10/2018 à 11:16, Christophe Leroy a écrit :
commit b96672dd840f ("powerpc: Machine check interrupt is a non-
maskable interrupt") added a call to nmi_enter() at the beginning of
machine check restart exception handler. Due to that, in_interrupt()
always returns
On 10/12/2018 03:37 AM, Joel Fernandes (Google) wrote:
> Android needs to mremap large regions of memory during memory management
> related operations. The mremap system call can be really slow if THP is
> not enabled. The bottleneck is move_page_tables, which is copying each
> pte at a time, an
Hi all,
Today's linux-next tree does not boot in qemu (with kvm or without).
Here is the (non-kvm) boot log (the kvm one is basically the same):
--
SLOF[0m[?25l
**
[1mQEMU S
Hi all,
On Mon, 15 Oct 2018 19:18:59 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next tree does not boot in qemu (with kvm or without).
> Here is the (non-kvm) boot log (the kvm one is basically the same):
I should have said that the kernel build is pseries_le_defconfig.
--
Cheers,
Stephe
On Mon, Oct 15, 2018 at 03:35:41PM +0900, Masahiro Yamada wrote:
> 'git grep' did not get any other hit.
>
> masahiro@pug:~/ref/linux$ git grep PCI_QSPAN
> arch/powerpc/Kconfig: default PCI_QSPAN if PPC_8xx
> arch/powerpc/Kconfig:config PCI_QSPAN
>
> With your patch, PCI_QSPAN will become
> a d
On Mon, Oct 15, 2018 at 03:37:05PM +0900, Masahiro Yamada wrote:
> I think HAVE_ is a preferred prefix in this case according to this doc:
> https://github.com/masahir0y/linux/blob/v4.19-rc4/Documentation/kbuild/kconfig-language.txt#L448
Ok, I'll switch everything to HAVE_*
> If you do this for e
> Thanks for great work again.
>
> However, I suspect some breakages
> (not testing yet, just quick review by my eyes.)
>
> I left some comments in individual patches.
Thanks. I've updated the git tree based on your comments.
On Mon, Oct 15, 2018 at 5:57 PM Christoph Hellwig wrote:
>
> On Mon, Oct 15, 2018 at 03:37:05PM +0900, Masahiro Yamada wrote:
> > I think HAVE_ is a preferred prefix in this case according to this doc:
> > https://github.com/masahir0y/linux/blob/v4.19-rc4/Documentation/kbuild/kconfig-language.txt#
Normally mm_iommu_get() is supposed to add a reference and
mm_iommu_put() to remove it. However historically mm_iommu_find() does
the referencing and mm_iommu_get() is doing allocation and referencing.
This is step 1 towards simpler mm_iommu_get().
This renames:
- mm_iommu_get to mm_iommu_new;
-
Since we are going to have 2 different preregistering helpers, let's
make it clear that mm_iommu_new() is only for the normal (i.e. not device)
memory and for existing areas mm_iommu_get() should be used instead.
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/mm/mmu_context_iommu.c | 3 +--
This new memory does not have page structs as it is not plugged to
the host so gup() will fail anyway.
This adds 2 helpers:
- mm_iommu_newdev() to preregister the "memory device" memory so
the rest of API can still be used;
- mm_iommu_is_devmem() to know if the physical address is one of thise
new
This is a first set of patches required for passing through NVIDIA V100
with coherent memory. The full patchset is here:
https://github.com/aik/linux/tree/nv2
The matching QEMU is here:
https://github.com/aik/qemu/tree/nv2
This particular patchset prepares for having device memory which is not
bac
We are going to add another helper to preregister device memory so
instead of having mm_iommu_new() which pre-registers the normal memory
and references the region, we need separate helpers for pre-registerign
and referencing.
To make the mm_iommu_get name reflect what it is supposed to do, this
c
LEROY Christophe writes:
> Michael Ellerman a écrit :
>> Michael Ellerman writes:
>>> Christophe Leroy writes:
>>>
Set PAGE_KERNEL directly in the caller and do not rely on a
hack adding PAGE_KERNEL flags when _PAGE_PRESENT is not set.
As already done for PPC64, use pgprot_c
This step is to help removing the npu struct from pnv_phb so it
can be used by pseries as well.
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/platforms/powernv/npu-dma.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/platforms/powern
In order to make ATS work and translate addresses for arbitrary
LPID and PID, we need to program an NPU with these.
This implements a helper to assign a GPU to LPAR and program the NPU
with a wildcard for PID. The helper also takes MSR (only DR/HV/PR/SF bits
are allowed) to program them into NPU2
On Sat, 2018-10-13 at 09:45 +, Christophe Leroy wrote:
> commit 06ec27aea9fc ("powerpc/64: add stack protector support")
> doesn't initialise the stack canary on SMP secondary CPU's paca,
> leading to the following false positive report from the
> stack protector.
>
> smp: Bringing up secondar
This is a second set of patches required for passing through NVIDIA V100
with coherent memory. The full patchset is here:
https://github.com/aik/linux/tree/nv2
The matching QEMU is here:
https://github.com/aik/qemu/tree/nv2
This patchset reworks NPU DMA code to be used with VFIO. The exported s
We are going to add a global list of NPUs in the system which is going
to be yet another static symbol. Let's reorganise the code and put all
static symbols into one struct for better tracking what is really needed
for NPU (this might become a driver data some day).
Signed-off-by: Alexey Kardashev
The powernv PCI code stores NPU data in the pnv_phb struct. The latter
is referenced by pci_controller::private_data. We are going to have NPU2
support in the pseries platform as well but it does not store any
private_data in in the pci_controller struct; and even if it did,
it would be a different
At the moment the NPU context init/destroy code calls OPAL. The init
handler in OPAL configures the NPU to pass ATS requests to nested MMU,
the destroy handler does nothing besides sanity checks.
Since the init handler programs the NPU with a wildcard for LPID/PID,
this can be done at the point wh
Strangely Reza is missed by the get_maintainers.pl, adding in cc: :-/
On 15/10/2018 20:32, Alexey Kardashevskiy wrote:
> This is a second set of patches required for passing through NVIDIA V100
> with coherent memory. The full patchset is here:
> https://github.com/aik/linux/tree/nv2
> The matchi
Segher Boessenkool writes:
> On Sat, Oct 13, 2018 at 10:55:01PM +1100, Michael Ellerman wrote:
>> So it's only my cross compilers that don't work.
>>
>> The kernel.org ones are:
>> Configured with: /home/arnd/git/gcc/configure --target=powerpc64-linux
>> --enable-targets=all
>> --prefix=/ho
This is a third set of patches required for passing through NVIDIA V100
with coherent memory. The full patchset is here:
https://github.com/aik/linux/tree/nv2
The matching QEMU is here:
https://github.com/aik/qemu/tree/nv2
This implements a subdriver for NVIDIA V100 GPU with coherent memory and
VFIO regions already support region capabilities with a limited set of
fields. However the subdriver might have to report to the userspace
additional bits.
This adds an add_capability() hook to vfio_pci_regops.
This is aiming Witherspoon POWER9 machines which have multiple
interconnected NVIDIA V
So far we only allowed mapping of MMIO BARs to the userspace. However
there there are GPUs with on-board coherent RAM accessible via side
channels which we also want to map to the userspace. The first client
for this is NVIDIA V100 GPU with NVLink2 direct links to a POWER9
NPU-enabled CPU; such GPU
POWER9 Witherspoon machines come with 4 or 6 V100 GPUs which are not
pluggable PCIe devices but implement PCIe links for config space and MMIO.
In addition to that the GPUs are interconnected to each other and also
have direct links to the P9 CPU. The links are NVLink2 and provide direct
access to
The powernv platform maintains 2 TCE tables for VFIO - a hardware TCE
table and a table with userspace addresses. These tables are radix trees,
we allocate indirect levels when they are written to. Since
the memory allocation is problematic in real mode, we have 2 accessors
to the entries:
- for vi
On Mon, 15 Oct 2018 09:10:53 +0200
Christian Borntraeger wrote:
> On 10/12/2018 03:37 AM, Joel Fernandes (Google) wrote:
> > Android needs to mremap large regions of memory during memory management
> > related operations. The mremap system call can be really slow if THP is
> > not enabled. The bo
On Fri, Oct 12, 2018 at 06:31:58PM -0700, Joel Fernandes (Google) wrote:
> Android needs to mremap large regions of memory during memory management
> related operations.
Just curious: why?
> + if ((old_addr & ~PMD_MASK) || (new_addr & ~PMD_MASK)
> + || old_end - old_addr < PMD_SIZE)
Meelis Roos writes:
> I tried to test the fix to 32-bit poweroc boot hang but found that current
> git does not compile on 32bit poweroc at all for me:
That's GCC 8 I think?
I have seen that but couldn't work out what the hell GCC is thinking.
I don't think there's an actual bug, the size of t
Madhavan Srinivasan writes:
> On Saturday 13 October 2018 04:26 PM, Michael Ellerman wrote:
>> We use a shared definition for struct pt_regs in uapi/asm/ptrace.h.
>> That means the layout of the structure is ABI, ie. we can't change it.
>>
>> That would be fine if it was only used to describe the
My recent patch to split pt_regs between user and kernel missed
the usage in struct sigcontext.
Because this is a user visible struct it should be using the user
visible definition, which when we're building for the kernel is called
struct user_pt_regs.
As far as I can see this hasn't actually ca
I'm pretty sure this is dead code, it's only used by the a.out core
dump code, and we don't support a.out. We should remove it.
But while it's in the tree it should be using the ABI version of
pt_regs which is called user_pt_regs in the kernel, because the whole
struct is written to the core dump
Nicholas Piggin writes:
> On Sat, 13 Oct 2018 21:56:44 +1100
> Michael Ellerman wrote:
>
>> We use a shared definition for struct pt_regs in uapi/asm/ptrace.h.
>> That means the layout of the structure is ABI, ie. we can't change it.
>>
>> That would be fine if it was only used to describe the u
On 14/10/2018 10:16, Thomas Gleixner wrote:
>>> +static inline bool kvm_available_flush_tlb_with_range(void)
>>> +{
>>> + return kvm_x86_ops->tlb_remote_flush_with_range;
>>> +}
>> Seems that kvm_available_flush_tlb_with_range() is not used in this patch…
> What's wrong with that?
>
> It provid
On 13/10/2018 16:53, lantianyu1...@gmail.com wrote:
> From: Lan Tianyu
>
> For nested memory virtualization, Hyper-v doesn't set write-protect
> L1 hypervisor EPT page directory and page table node to track changes
> while it relies on guest to tell it changes via HvFlushGuestAddressLlist
> hype
I tried to test the fix to 32-bit poweroc boot hang but found that current git
does not compile on 32bit poweroc at all for me:
That's GCC 8 I think?
Yes, gcc version 8.2.0 (Debian 8.2.0-7).
I have seen that but couldn't work out what the hell GCC is thinking.
I don't think there's an actu
On Monday 15 October 2018 04:38 PM, Michael Ellerman wrote:
Madhavan Srinivasan writes:
On Saturday 13 October 2018 04:26 PM, Michael Ellerman wrote:
We use a shared definition for struct pt_regs in uapi/asm/ptrace.h.
That means the layout of the structure is ABI, ie. we can't change it.
Stephen Rothwell writes:
> Hi all,
>
> Today's linux-next tree does not boot in qemu (with kvm or without).
> Here is the (non-kvm) boot log (the kvm one is basically the same):
>
> --
...
> Welcome to Open Firmware
>
> Copyright (c) 2004, 20
On 10/15/18 12:07 PM, Christophe Leroy wrote:
Since commit bd0dbb73e013 ("powerpc/mm/books3s: Add new pte bit to
mark pte temporarily invalid."), _PAGE_PRESENT doesn't mean exactly
that a page is present. A page is also considered preset when
_PAGE_INVALID is set.
This patch changes the meaning
Hi all,
Spotted this today, haven't had time to debug it further, just FYI in
case anyone else sees it.
Running tests in cpufreq
selftests: cpufreq: main.sh
pid 9727's current affinity mask:
pid 9727's
Looks like a lack of initialisation of the canary for the non-boot CPUs
on SMP, you applied this morning the patch I sent you for that.
Is the patch in ?
Christophe
Le 15/10/2018 à 15:26, Michael Ellerman a écrit :
Hi all,
Spotted this today, haven't had time to debug it further, just FYI in
Quoting Vabhav Sharma (2018-10-14 19:58:15)
> > > +
> > > + pmu {
> > > + compatible = "arm,cortex-a72-pmu";
> > > + interrupts = ;
> > > + };
> > > +
> > > + psci {
> > > + compatible = "arm,psci-0.2";
> > > + method = "smc";
> > > + };
> > > +
> > >
On 11-10-18, 17:46, Peng Ma wrote:
> From: Wen He
>
> This patch implement a standard macro call functions is
> used to NXP dma drivers.
>
> Signed-off-by: Wen He
Please read Documentation/process/submitting-patches.rst, we expect each
patch you send to have your signed off and signed off from
Currently, we expect to be able to reach ftrace_caller() from all
ftrace-enabled functions through a single relative branch. With large
kernel configs, we see functions farther than 32MB of ftrace_caller()
causing ftrace_init() to bail.
One way to solve this is by adding additional trampolines aro
On Sun, Oct 14, 2018 at 7:26 PM wrote:
>
> From: Frank Rowand
>
> If overlay properties #address-cells or #size-cells are already in
> the live devicetree for any given node, then the values in the
> overlay must match the values in the live tree.
>
> If the properties are already in the live tre
On Sun, Oct 14, 2018 at 7:26 PM wrote:
>
> From: Frank Rowand
>
> Add checks to (1) overlay apply process and (2) memory freeing
> triggered by overlay release. The checks are intended to detect
> possible memory leaks and invalid overlays.
>
> The checks revealed bugs in existing code. Fixed t
On 10/14/18 20:21, Frank Rowand wrote:
> On 10/14/18 18:55, Joe Perches wrote:
>> On Sun, 2018-10-14 at 18:52 -0700, Frank Rowand wrote:
>>> On 10/14/18 18:06, Joe Perches wrote:
On Sun, 2018-10-14 at 17:24 -0700, frowand.l...@gmail.com wrote:
> From: Frank Rowand
>
> Add test cas
The migration of LPARs across Power systems affects many attributes
including that of the associativity of memory blocks. The patches
in this set execute when a system is coming up fresh upon a migration
target. They are intended to,
* Recognize changes to the associativity of memory recorded in
powerpc/drmem: Export many of the functions of DRMEM to parse
"ibm,dynamic-memory" and "ibm,dynamic-memory-v2" during hotplug
operations and for Post Migration events.
Also modify the DRMEM initialization code to allow it to,
* Be called after system initialization
* Provide a separate user copy
powerpc/drmem: Add internal_flags field to each LMB to allow
marking of kernel software-specific operations that need not
be exported to other users. For instance, if information about
selected LMBs needs to be maintained for subsequent passes
through the system, it can be encoded into the LMB arr
migration/memory: This patch adds a new pseries hotplug action
for CPU and memory operations, PSERIES_HP_ELOG_ACTION_READD_MULTIPLE.
This is a variant of the READD operation which performs the action
upon multiple instances of the resource at one time. The operation
is to be triggered by device-tr
migration/memory: This patch adds code that recognizes changes to
the associativity of memory blocks described by the device-tree
properties in order to drive equivalent 'hotplug' operations to
update local and general kernel data structures to reflect those
changes. These differences may include:
migration/memory: This patch adds recognition for changes to the
associativity of memory blocks described by 'ibm,dynamic-memory-v2'.
If the associativity of an LMB has changed, it should be readded to
the system in order to update local and general kernel data structures.
This patch builds upon pr
powerpc/drmem: Add internal_flags field to each LMB to allow
marking of kernel software-specific operations that need not
be exported to other users. For instance, if information about
selected LMBs needs to be maintained for subsequent passes
through the system, it can be encoded into the LMB arr
e_nid+0x20/0x68
> Modules linked in:
> CPU: 0 PID: 0 Comm: swapper Not tainted 4.19.0-rc7-next-20181015 #1
> NIP: c0f99198 LR: c0f99490 CTR: c0bb8364
> REGS: c00001217a78 TRAP: 0700 Not tainted (4.19.0-rc7-next-20181015)
> MSR: 80021000
On 10/15/18 12:01, Alan Tull wrote:
> On Sun, Oct 14, 2018 at 7:26 PM wrote:
>>
>> From: Frank Rowand
>>
>> If overlay properties #address-cells or #size-cells are already in
>> the live devicetree for any given node, then the values in the
>> overlay must match the values in the live tree.
>>
>>
On 10/15/18 12:21, Alan Tull wrote:
> On Sun, Oct 14, 2018 at 7:26 PM wrote:
>>
>> From: Frank Rowand
>>
>> Add checks to (1) overlay apply process and (2) memory freeing
>> triggered by overlay release. The checks are intended to detect
>> possible memory leaks and invalid overlays.
>>
>> The c
enum memblock_flags flags)
{
if (WARN_ON_ONCE(!align))
align = SMP_CACHE_BYTES;
Looks like patch
"memblock: stop using implicit alignment to SMP_CACHE_BYTES"
missed some places ...
> > Modules linked in:
> > CPU: 0 PID: 0 Com
Hi Guenter,
[Again, just cc'ing the PPC folks]
On Mon, 15 Oct 2018 12:39:14 -0700 Guenter Roeck wrote:
>
> On Mon, Oct 15, 2018 at 07:25:46PM +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > Changes since 20181012:
> >
> > My qemu boots of a powerpc pseries_le_defconfig kernel failed today.
luding big endian pseries) also generate a warning.
> >
> > WARNING: CPU: 0 PID: 0 at mm/memblock.c:1301
> > .memblock_alloc_range_nid+0x20/0x68
> > Modules linked in:
> > CPU: 0 PID: 0 Comm: swapper Not tainted 4.19.0-rc7-next-20181015 #1
> > NIP: c0f991
On Mon, Oct 15, 2018 at 3:24 PM Frank Rowand wrote:
>
> On 10/15/18 12:21, Alan Tull wrote:
> > On Sun, Oct 14, 2018 at 7:26 PM wrote:
> >>
> >> From: Frank Rowand
> >>
> >> Add checks to (1) overlay apply process and (2) memory freeing
> >> triggered by overlay release. The checks are intended
On Sat, Oct 13, 2018 at 05:10:09PM +0200, Christoph Hellwig wrote:
> We plan to enable building the pcmcia core and drivers, and the
> non-prefixed PCMCIA name clashes with some arch headers.
In the followup PCMCIA patch, you capitalized "PCMCIA core".
s/^pci: /PCI: / in subject
On Sat, Oct 13, 2018 at 05:10:12PM +0200, Christoph Hellwig wrote:
> There is no good reason to duplicate the PCI menu in every architecture.
> Instead provide a selectable HAS_PCI symbol that indicates availability
> of PCI support and the handle the rest in drivers/pci
endian pseries
> > > boots; big endian works fine. I'll try to bisect later.
> > >
> > > ALl ppc qemu tests (including big endian pseries) also generate a warning.
> > >
> > > WARNING: CPU: 0 PID: 0 at mm/memblock.c:1301
> > > .memblock_alloc_ra
aef241f1c1a09a4d1f1f06fd565b6
> > # first bad commit: [cde1c7f7e92aef241f1c1a09a4d1f1f06fd565b6] mm: remove
> > include/linux/bootmem.h
> >
> > Reverting this patch together with its fix-up "powerpc: fix up for removal
> > of
> > linux/bootmem.h" fixes the problem. This also fixes the traceback seen with
> > all
> > other ppc64 images.
> >
> > Guenter
>
> Thanks for this ... though a strange result as those patches were in
> next-20181012 as well, so I wonder what else changed.
>
Quite simple - the bisect is wrong. For some reason I started with
next-20181012 (which was fine), not 20181015 (which is broken).
Repeating it now. Sorry for the confusion.
Guenter
mu tests (including big endian pseries) also generate a
> > > > warning.
> > > >
> > > > WARNING: CPU: 0 PID: 0 at mm/memblock.c:1301
> > > > .memblock_alloc_range_nid+0x20/0x68
> > > > Modules linked in:
> > > > CPU: 0 PID: 0 Comm
an pseries
> > > > > boots; big endian works fine. I'll try to bisect later.
> > > > >
> > > > > ALl ppc qemu tests (including big endian pseries) also generate a
> > > > > warning.
> > > > >
> > > > >
gt; > > > >
> > > > > > ALl ppc qemu tests (including big endian pseries) also generate a
> > > > > > warning.
> > > > > >
> > > > > > WARNING: CPU: 0 PID: 0 at mm/memblock.c:1301
> > > > > > .
On Tue, 16 Oct 2018 07:24:39 +1100 Stephen Rothwell
wrote:
> On Tue, 16 Oct 2018 07:12:40 +1100 Stephen Rothwell
> wrote:
> >
> > On Mon, 15 Oct 2018 11:26:37 -0700 Guenter Roeck wrote:
> > >
> > > ALl ppc qemu tests (including big endian pseries) also generate a warning.
> > >
> > > WARNING
h compile errors.
The problem does seem to be related to the bootmem changes, though.
I might try again tonight if I find the time.
Guenter
# bad: [ca0591d03a2d373e0019ad357fbbee69c8272381] Add linux-next specific files
for 20181015
# good: [0238df646e6224016a45505d2c111a24669ebe21] Linux 4.19-rc7
git
gt;
> > > > > > > Same here. Interestingly, this only affects little endian pseries
> > > > > > > boots; big endian works fine. I'll try to bisect later.
> > > > > > >
> > > > > > > ALl ppc qemu tests (including big endian pseries) al
gt;
> > > > > > > Same here. Interestingly, this only affects little endian pseries
> > > > > > > boots; big endian works fine. I'll try to bisect later.
> > > > > > >
> > > > > > > ALl ppc qemu tests (including big endian pseries) al
> > > > > > > > pseries
> > > > > > > > boots; big endian works fine. I'll try to bisect later.
> > > > > > > >
> > > > > > > > ALl ppc qemu tests (including big endian pseries) also gener
On Mon, Oct 15, 2018 at 02:42:09AM -0700, Christoph Hellwig wrote:
> On Fri, Oct 12, 2018 at 06:31:58PM -0700, Joel Fernandes (Google) wrote:
> > Android needs to mremap large regions of memory during memory management
> > related operations.
>
> Just curious: why?
In Android we have a requiremen
Hi Michael,
On Mon, 15 Oct 2018 23:45:10 +1100 Michael Ellerman wrote:
>
> > Preparing to boot Linux version 4.19.0-rc7 (sfr@ash) (gcc version 8.2.0
> > (Debian 8.2.0-4)) #2 SMP Mon Oct 15 18:53:28 AEDT 2018
> ^^
> I a
Hi Alexey,
Looking at the skiboot side I think we only fence the NVLink bricks as part of a
PCIe function level reset (FLR) rather than a PCI Hot or Fundamental reset which
I believe is what the code here does. So to fence the bricks you would need to
do either a FLR on the given link or alter Ski
Michael Bringmann writes:
> diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c
> b/arch/powerpc/platforms/pseries/hotplug-memory.c
> index 2b796da..9c76345 100644
> --- a/arch/powerpc/platforms/pseries/hotplug-memory.c
> +++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
> @@ -541,6
le endian pseries
> > > boots; big endian works fine. I'll try to bisect later.
> > >
> > > ALl ppc qemu tests (including big endian pseries) also generate a warning.
> > >
> > > WARNING: CPU: 0 PID: 0 at mm/memblock.c:1301
> > > .memblock_alloc
On Mon, 15 Oct 2018 09:40:50 +0200
Christophe LEROY wrote:
> Cc: sta...@vger.kernel.org
>
> Le 13/10/2018 à 11:16, Christophe Leroy a écrit :
> > commit b96672dd840f ("powerpc: Machine check interrupt is a non-
> > maskable interrupt") added a call to nmi_enter() at the beginning of
> > machine
From: Rob Herring
Date: Mon, 15 Oct 2018 20:00:24 -0500
> David, Can you revert commit 0b9871a3a8cc. I'll have to find another approach.
Ok.
On 16/10/2018 11:38, Alistair Popple wrote:
> Hi Alexey,
>
> Looking at the skiboot side I think we only fence the NVLink bricks as part
> of a
> PCIe function level reset (FLR) rather than a PCI Hot or Fundamental reset
> which
> I believe is what the code here does. So to fence the bricks y
Hi Alexey,
On Tuesday, 16 October 2018 12:37:49 PM AEDT Alexey Kardashevskiy wrote:
>
> On 16/10/2018 11:38, Alistair Popple wrote:
> > Hi Alexey,
> >
> > Looking at the skiboot side I think we only fence the NVLink bricks as part
> > of a
> > PCIe function level reset (FLR) rather than a PCI H
67f38bd8c4a80e0ac84ecc981e95b98703393 M kernel
:04 04 30c64583e66fc20181d7ce2b6ced9d7e060e1042
4e57b31864cef4e921bbd73150f63637a819e3c4 M lib
:04 04 1b341ab0dd034f0fef37c234a771419924e0ecc9
9c489ba60978950733bf678191833fdb9689bdab M mm
# bad: [ca0591d03a2d37
On 16/10/2018 12:44, Alistair Popple wrote:
> Hi Alexey,
>
> On Tuesday, 16 October 2018 12:37:49 PM AEDT Alexey Kardashevskiy wrote:
>>
>> On 16/10/2018 11:38, Alistair Popple wrote:
>>> Hi Alexey,
>>>
>>> Looking at the skiboot side I think we only fence the NVLink bricks as part
>>> of a
>>
> reset_ntl() does what npu2_dev_procedure_reset() does plus more stuff,
> there nothing really in npu2_dev_procedure_reset() which reset_ntl()
> does not do already from the hardware standpoint. And it did stop HMIs
> for me though.
>
> but ok, what will be sufficient then if not reset_ntl()?
Ar
Hi all,
On Tue, 16 Oct 2018 13:02:16 +1100 Stephen Rothwell
wrote:
>
> Reverting fe3d2a45e8079fdd7d4da1ff07f4b40bc3cb499f (and the following 2
> commits) produces a kernel that boots.
Instead of that, I applied this patch on top of linux-next and it boots
and produces a stack trace ...
From: S
On 16/10/2018 13:19, Alistair Popple wrote:
>> reset_ntl() does what npu2_dev_procedure_reset() does plus more stuff,
>> there nothing really in npu2_dev_procedure_reset() which reset_ntl()
>> does not do already from the hardware standpoint. And it did stop HMIs
>> for me though.
>>
>> but ok,
At the moment PNV_IODA_PE_DEV is only used for NPU PEs which are not
present on IODA1 machines (i.e. POWER7) so let's remove a piece of
dead code.
Signed-off-by: Alexey Kardashevskiy
---
We might actually want to get rid of the entire IODA1 there.
---
arch/powerpc/platforms/powernv/pci-ioda.c |
fixup_phb() is never used, this removes it.
pick_m64_pe() and reserve_m64_pe() are always defined for all powernv
PHBs: they are initialized by pnv_ioda_parse_m64_window() which is
called unconditionally from pnv_pci_init_ioda_phb() which initializes
all known PHB types on powernv so we can open c
From: Frank Rowand
Add checks to (1) overlay apply process and (2) memory freeing
triggered by overlay release. The checks are intended to detect
possible memory leaks and invalid overlays.
The checks revealed bugs in existing code. Fixed the bugs.
While fixing bugs, noted other issues, which
From: Frank Rowand
Add checks:
- attempted kfree due to refcount reaching zero before overlay
is removed
- properties linked to an overlay node when the node is removed
- node refcount > one during node removal in a changeset destroy,
if the node was created by the changeset
After
From: Frank Rowand
The refcount of a newly added overlay node decrements to one
(instead of zero) when the overlay changeset is destroyed. This
change will cause the final decrement be to zero.
After applying this patch, new validation warnings will be
reported from the devicetree unittest duri
From: Frank Rowand
There is a matching of_node_put() in __of_detach_node_sysfs()
Remove misleading comment from function header comment for
of_detach_node().
This patch may result in memory leaks from code that directly calls
the dynamic node add and delete functions directly instead of
using c
From: Frank Rowand
"of: overlay: add missing of_node_get() in __of_attach_node_sysfs"
added a missing of_node_get() to __of_attach_node_sysfs(). This
results in a refcount imbalance for nodes attached with
dlpar_attach_node(). The calling sequence from dlpar_attach_node()
to __of_attach_node_sy
1 - 100 of 130 matches
Mail list logo
