On 09/01/2019 18:25, Benjamin Herrenschmidt wrote:
> On Wed, 2019-01-09 at 17:32 +1100, Alexey Kardashevskiy wrote:
>> I have just moved the "Mellanox Technologies MT27700 Family
>> [ConnectX-4]" from garrison to firestone machine and there it does not
>> produce an EEH, with the same kernel and
On 09/01/2019 18:24, Benjamin Herrenschmidt wrote:
> On Wed, 2019-01-09 at 15:53 +1100, Alexey Kardashevskiy wrote:
>> "A PCI completion timeout occurred for an outstanding PCI-E transaction"
>> it is.
>>
>> This is how I bind the device to vfio:
>>
>> echo vfio-pci > '/sys/bus/pci/devices/:
On Tue, 8 Jan 2019 16:30:24 -0600
Bjorn Helgaas wrote:
> Hi,
>
> I want to update the PCI Kconfig labels so they're more consistent and
> useful to users, something like the patch below. IIUC, the items
> below are all IBM-related; please correct me if not.
>
> I'd also like to expand (or remo
Andrea Arcangeli writes:
> Hello,
>
> On Tue, Jan 08, 2019 at 10:21:09AM +0530, Aneesh Kumar K.V wrote:
>> @@ -187,41 +149,25 @@ static long mm_iommu_do_alloc(struct mm_struct *mm,
>> unsigned long ua,
>> goto unlock_exit;
>> }
>>
>> +ret = get_user_pages_cma_migrate(ua,
Andrew Morton writes:
> On Tue, 8 Jan 2019 10:21:06 +0530 "Aneesh Kumar K.V"
> wrote:
>
>> ppc64 use CMA area for the allocation of guest page table (hash page table).
>> We won't
>> be able to start guest if we fail to allocate hash page table. We have
>> observed
>> hash table allocation f
Next step: a64e18ba191ba9102fb174f27d707485ffd9389c (powerpc/dma: remove
dma_nommu_get_required_mask)
git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
git checkout a64e18ba191ba9102fb174f27d707485ffd9389c
Link to the Git:
http://git.infradead.org/users/hch/misc.git/shor
There is a typo so we accidentally allocate enough memory for a pointer
when we wanted to allocate enough for a struct.
Fixes: 0bd971676e68 ("powerpc/powernv/npu: Add compound IOMMU groups")
Signed-off-by: Dan Carpenter
---
arch/powerpc/platforms/powernv/npu-dma.c | 2 +-
1 file changed, 1 inser
Matt Corallo writes:
> .config follows. I have not tested with 64K pages as, sadly, I have a
> large BTRFS volume that was formatted on x86, and am thus stuck with 4K
> pages. Note that this is roughly the Debian kernel, so it has whatever
> patches Debian defaults to applying, a list of which
Dan Carpenter writes:
> There is a typo so we accidentally allocate enough memory for a pointer
> when we wanted to allocate enough for a struct.
>
> Fixes: 0bd971676e68 ("powerpc/powernv/npu: Add compound IOMMU groups")
> Signed-off-by: Dan Carpenter
> ---
> arch/powerpc/platforms/powernv/npu-d
Use DEFINE_DEBUGFS_ATTRIBUTE rather than DEFINE_SIMPLE_ATTRIBUTE
for debugfs files.
Semantic patch information:
Rationale: DEFINE_SIMPLE_ATTRIBUTE + debugfs_create_file()
imposes some significant overhead as compared to
DEFINE_DEBUGFS_ATTRIBUTE + debugfs_create_file_unsafe().
Generated by: script
Hi Bjorn,
Bjorn Helgaas writes:
> Hi,
>
> I want to update the PCI Kconfig labels so they're more consistent and
> useful to users, something like the patch below. IIUC, the items
> below are all IBM-related; please correct me if not.
>
> I'd also like to expand (or remove) "RPA" because Google
This argument is required to extend the generic ptrace API with
PTRACE_GET_SYSCALL_INFO request: syscall_get_arch() is going
to be called from ptrace_request() along with syscall_get_nr(),
syscall_get_arguments(), syscall_get_error(), and
syscall_get_return_value() functions with a tracee as their
Cédric Le Goater writes:
> These flags are shared between Linux/KVM implementing the hypervisor
> calls for the XIVE native exploitation mode and the driver for the
> sPAPR guests.
>
> Signed-off-by: Cédric Le Goater
> ---
> arch/powerpc/include/asm/xive.h | 23 +++
> arch/
Commit e1c3743e1a20 ("powerpc/tm: Set MSR[TS] just prior to recheckpoint")
moved a code block around and this block uses a 'msr' variable outside of
the CONFIG_PPC_TRANSACTIONAL_MEM, however the 'msr' variable is declared
inside a CONFIG_PPC_TRANSACTIONAL_MEM block, causing a possible error when
CO
On 1/9/19 2:08 PM, Michael Ellerman wrote:
> Cédric Le Goater writes:
>
>> These flags are shared between Linux/KVM implementing the hypervisor
>> calls for the XIVE native exploitation mode and the driver for the
>> sPAPR guests.
>>
>> Signed-off-by: Cédric Le Goater
>> ---
>> arch/powerpc/inc
It's normal daily usage on a workstation (TALOS 2). I've seen it at least
twice, both times in rustc, though I've run rustc more times than I can count.
Note that the program that triggered it was running in lxc and it only happened
after upgrading to 4.19.
> On Jan 9, 2019, at 06:50, Aneesh Ku
With a recent change around IOMMU group, a system with an opencapi
adapter is no longer booting and we get a kernel oops:
BUG: Kernel NULL pointer dereference at 0x0028
Faulting instruction address: 0xc00aa38c
Oops: Kernel access of bad area, sig: 7 [#1]
LE SMP NR_CPUS=2048 NUMA PowerN
On Tue, Jan 8, 2019 at 10:31 PM Christophe Leroy
wrote:
>
>
>
> Le 09/01/2019 à 02:14, Kees Cook a écrit :
> > On Fri, Dec 14, 2018 at 7:26 AM Christophe Leroy
> > wrote:
> >>
> >> Introduce lkdtm tests for NULL pointer dereference: check
> >> access or exec at NULL address.
> >
> > Why is this n
On Wed, Jan 09, 2019 at 04:09:02PM +1100, Benjamin Herrenschmidt wrote:
> > POWER 8 firmware is good? If the link does eventually come back, is
> > the POWER8's D3 resumption timeout long enough?
> >
> > If this doesn't lead to an obvious conclusion you'll probably need to
> > connect to IBM's Me
On Tue, Dec 4, 2018 at 10:18 PM Rob Herring wrote:
>
> On Tue, Dec 4, 2018 at 7:01 PM Kevin Hilman wrote:
> >
> > Rob Herring writes:
> >
> > > It is best practice to have 1 binding per file, so board level bindings
> > > should be separate for various misc SoC bindings.
> > >
> > > Cc: Mark Rut
On Wed, 9 Jan 2019 16:13:42 +0100
Frederic Barrat wrote:
> With a recent change around IOMMU group, a system with an opencapi
> adapter is no longer booting and we get a kernel oops:
>
> BUG: Kernel NULL pointer dereference at 0x0028
> Faulting instruction address: 0xc00aa38c
> Oops
Le 09/01/2019 à 17:25, Greg Kurz a écrit :
On Wed, 9 Jan 2019 16:13:42 +0100
Frederic Barrat wrote:
With a recent change around IOMMU group, a system with an opencapi
adapter is no longer booting and we get a kernel oops:
BUG: Kernel NULL pointer dereference at 0x0028
Faulting instruc
On Wed, Jan 09, 2019 at 05:45:53PM +0100, Frederic Barrat wrote:
>
>
> Le 09/01/2019 à 17:25, Greg Kurz a écrit :
> > On Wed, 9 Jan 2019 16:13:42 +0100
> > Frederic Barrat wrote:
> >
> > > With a recent change around IOMMU group, a system with an opencapi
> > > adapter is no longer booting and
On Wed, 9 Jan 2019 17:45:53 +0100
Frederic Barrat wrote:
> Le 09/01/2019 à 17:25, Greg Kurz a écrit :
> > On Wed, 9 Jan 2019 16:13:42 +0100
> > Frederic Barrat wrote:
> >
> >> With a recent change around IOMMU group, a system with an opencapi
> >> adapter is no longer booting and we get a ke
On Wed, Jan 9, 2019 at 7:16 AM Kees Cook wrote:
>
> On Tue, Jan 8, 2019 at 10:31 PM Christophe Leroy
> wrote:
> >
> >
> >
> > Le 09/01/2019 à 02:14, Kees Cook a écrit :
> > > On Fri, Dec 14, 2018 at 7:26 AM Christophe Leroy
> > > wrote:
> > >>
> > >> Introduce lkdtm tests for NULL pointer derefe
Commit 8c8c10b90d88 ("powerpc/8xx: fix handling of early NULL pointer
dereference") moved the loading of r6 earlier in the code. As some
functions are called inbetween, r6 needs to be loaded again with the
address of swapper_pg_dir in order to set PTE pointers for
the Abatron BDI.
Fixes: 8c8c10b90
On 10/1/19 2:13 am, Frederic Barrat wrote:
With a recent change around IOMMU group, a system with an opencapi
adapter is no longer booting and we get a kernel oops:
BUG: Kernel NULL pointer dereference at 0x0028
Faulting instruction address: 0xc00aa38c
Oops: Kernel access of bad area
Christophe Leroy writes:
> Le 08/01/2019 à 13:21, Christophe Leroy a écrit :
>> Le 08/01/2019 à 13:05, Michael Ellerman a écrit :
>>> The page size the kernel is built with is useful info when debugging a
>>> crash, so add it to the output in __die().
>>>
>>> Result looks like eg:
>>>
>>> kerne
From: Daniel Axtens
All 64-bit objects need to specify the flag to be compiled correctly, we
just don't need it for 32-bit objects. GCC just ignored it, but clang
doesn't.
Link: https://github.com/ClangBuiltLinux/linux/issues/240
Signed-off-by: Daniel Axtens
Signed-off-by: Joel Stanley
---
ar
While mapping DMA for scatter list when a scsi command is queued the
existing call to dma_alloc_coherent() in our map_sg_data() function
passes zero for the gfp_flags parameter. We are most definitly in atomic
context at this point as queue_command() is called in softirq context
and further we have
During driver probe we allocate a dma region for our event pool.
Currently, zero is passed for the gfp_flags parameter. Driver probe
callbacks run in process context and we hold no locks so we can sleep
here if necessary.
Fix by passing GFP_KERNEL explicitly to dma_alloc_coherent().
Signed-off-by
c3ff2a519 "powerpc/32: add stack protector support" addes stack protector
support so now powerpc's "prepare" target depends on prepare0 (via
stack_protector_prepare target).
It works fine until we try build an external module where it fails with:
Run: 'make -j128 SYSSRC=/home/aik/p/kernel
SYSOUT=
On Sat, Dec 08, 2018 at 09:58:37AM +0800, Shawn Guo wrote:
> On Thu, Dec 06, 2018 at 05:33:13PM -0600, Rob Herring wrote:
> > On Wed, Dec 5, 2018 at 8:32 PM Shawn Guo wrote:
> > >
> > > On Mon, Dec 03, 2018 at 03:32:07PM -0600, Rob Herring wrote:
> > > > Convert Freescale SoC bindings to DT schema
Le 10/01/2019 à 02:42, Joel Stanley a écrit :
From: Daniel Axtens
All 64-bit objects need to specify the flag to be compiled correctly, we
just don't need it for 32-bit objects. GCC just ignored it, but clang
doesn't.
Link: https://github.com/ClangBuiltLinux/linux/issues/240
Signed-off-by:
34 matches
Mail list logo
