On 06/12/2018 05:57 PM, Ricardo Neri wrote:
> diff --git a/Documentation/admin-guide/kernel-parameters.txt
> b/Documentation/admin-guide/kernel-parameters.txt
> index f2040d4..a8833c7 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++
Hi,
On 06/12/2018 05:57 PM, Ricardo Neri wrote:
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index c40c7b7..6e79833 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -828,6 +828,16 @@ config HARDLOCKUP_DETECTOR_PERF
> bool
> select SOFTLOCKUP_DETECTOR
>
>
Michael Ellerman writes:
> Pedro Franco de Carvalho writes:
>
>> Currently, the ebb_set function for writing to the EBB regset returns
>> ENODATA when ebb is active in the thread, and copies in the data when
>> it is inactive. This patch inverts the condition so that it matches
>> ebb_get and
On 06/13/2018 09:36 AM, Michael Ellerman wrote:
"Aneesh Kumar K.V" writes:
On 06/12/2018 07:17 PM, Michael Ellerman wrote:
Mahesh J Salgaonkar writes:
diff --git a/arch/powerpc/platforms/pseries/ras.c
b/arch/powerpc/platforms/pseries/ras.c
index 2edc673be137..e56759d92356 100644
---
"Aneesh Kumar K.V" writes:
> On 06/12/2018 07:17 PM, Michael Ellerman wrote:
>> Mahesh J Salgaonkar writes:
>>> diff --git a/arch/powerpc/platforms/pseries/ras.c
>>> b/arch/powerpc/platforms/pseries/ras.c
>>> index 2edc673be137..e56759d92356 100644
>>> --- a/arch/powerpc/platforms/pseries/ras.c
Christophe LEROY writes:
> Le 12/06/2018 à 16:53, Segher Boessenkool a écrit :
>> On Tue, Jun 12, 2018 at 09:14:53AM +, Christophe Leroy wrote:
>>> ---
>>> Not tested on PPC64.
>>
>> It won't be acceptable until that happens. It also is likely quite bad
>> performance on all 64-bit CPUs
Nicholas Piggin writes:
> POWER9 DD1 was never a product. It is no longer supported by upstream
> firmware, and it is not effectively supported in Linux due to lack of
> testing.
>
> Signed-off-by: Nicholas Piggin
Fine by me.
cheers
> ---
> arch/powerpc/include/asm/book3s/64/hugetlb.h | 15
On 06/12/2018 07:17 PM, Michael Ellerman wrote:
> Mahesh J Salgaonkar writes:
>> diff --git a/arch/powerpc/platforms/pseries/ras.c
>> b/arch/powerpc/platforms/pseries/ras.c
>> index 2edc673be137..e56759d92356 100644
>> --- a/arch/powerpc/platforms/pseries/ras.c
>> +++
On 06/12/2018 07:17 PM, Michael Ellerman wrote:
Mahesh J Salgaonkar writes:
diff --git a/arch/powerpc/platforms/pseries/ras.c
b/arch/powerpc/platforms/pseries/ras.c
index 2edc673be137..e56759d92356 100644
--- a/arch/powerpc/platforms/pseries/ras.c
+++ b/arch/powerpc/platforms/pseries/ras.c
@@
Pedro Franco de Carvalho writes:
> Currently ptrace doesn't flush the register state when the
> checkpointed GPRs of a 32-bit thread are accessed. This can cause core
> dumps to have stale data in the checkpointed GPR note.
> ---
> arch/powerpc/kernel/ptrace.c | 20
> 1
Pedro Franco de Carvalho writes:
> Currently, the ebb_set function for writing to the EBB regset returns
> ENODATA when ebb is active in the thread, and copies in the data when
> it is inactive. This patch inverts the condition so that it matches
> ebb_get and ebb_active.
> ---
>
Keep the HPET-based hardlockup detector disabled unless explicitly enabled
via a command line argument. If such parameter is not given, the hardlockup
detector will fallback to use the perf-based implementation.
The function hardlockup_panic_setup() is updated to return 0 in order to
to allow
Now that the implementation of the HPET-based hardlockup detector is
complete, enable it. It will be used only if it can be initialized
successfully. Otherwise, the perf-based detector will be used.
Cc: Ashok Raj
Cc: Andi Kleen
Cc: Tony Luck
Cc: Borislav Petkov
Cc: Jacob Pan
Cc: "Rafael J.
Each CPU should be monitored for hardlockups every watchdog_thresh seconds.
Since all the CPUs in the system are monitored by the same timer and the
timer interrupt is rotated among the monitored CPUs, the timer must expire
every watchdog_thresh/N seconds; where N is the number of monitored CPUs.
In order to detect hardlockups in all the monitored CPUs, move the
interrupt to the next monitored CPU when handling the NMI interrupt; wrap
around when reaching the highest CPU in the mask. This rotation is achieved
by setting the affinity mask to only contain the next CPU to monitor.
In order
In order to detect hardlockups, it is necessary to have the ability to
receive interrupts even when disabled: a non-maskable interrupt is
required. Add the flag IRQF_DELIVER_AS_NMI to the arguments of
request_irq() for this purpose.
Note that the timer, when programmed to deliver interrupts via
CPU architectures that have an NMI watchdog use arch_touch_nmi_watchdog()
to briefly ignore the hardlockup detector. If the architecture does not
have an NMI watchdog, one can be constructed using a source of non-
maskable interrupts. In this case, arch_touch_nmi_watchdog() is common
to any
Implement the start, stop and disable operations of the HPET-based NMI
watchdog. Given that a single timer is used to monitor all the CPUs in
the system, it is necessary to define a cpumask that keeps track of the
CPUs that can be monitored. This cpumask is protected with a spin lock.
As
This is the initial implementation of a hardlockup detector driven by an
HPET timer. This initial implementation includes functions to control
the timer via its registers. It also requests such timer, installs
a minimal interrupt handler and performs the initial configuration of
the timer.
The
Implementations of NMI watchdogs that use a single piece of hardware to
monitor all the CPUs in the system (as opposed to per-CPU implementations
such as perf) need to know which CPUs the watchdog is allowed to monitor.
In this manner, non-maskable interrupts are directed only to the monitored
Instead of exposing individual functions for the operations of the NMI
watchdog, define a common interface that can be used across multiple
implementations.
The struct nmi_watchdog_ops is defined for such operations. These initial
definitions include the enable, disable, start, stop, and cleanup
The current default implementation of the hardlockup detector assumes that
it is implemented using perf events. However, the hardlockup detector can
be driven by other sources of non-maskable interrupts (e.g., a properly
configured timer).
Put in a separate file all the code that is specific to
The procedure to detect hardlockups is independent of the underlying
mechanism that generated the non-maskable interrupt used to drive the
detector. Thus, it can be put in a separate, generic function. In this
manner, it can be invoked by various implementations of the NMI watchdog.
For this
Users of HPET timers (such as the hardlockup detector) need the definitions
of these flags to interpret the configuration of a timer as passed by
platform code.
Cc: Ashok Raj
Cc: Andi Kleen
Cc: Tony Luck
Cc: Borislav Petkov
Cc: Jacob Pan
Cc: Clemens Ladisch
Cc: Arnd Bergmann
Cc: Philippe
Implement the initial configuration of the timer to be used by the
hardlockup detector. The main focus of this configuration is to provide an
interrupt for the timer.
Two types of interrupt can be assigned to the timer. First, attempt to
assign a message-signaled interrupt. This implies creating
HPET timer 2 will be used to drive the HPET-based hardlockup detector.
Reserve such timer to ensure it cannot be used by user space programs or
clock events.
When looking for MSI-capable timers for clock events, skip timer 2 if
the HPET hardlockup detector is selected.
Also, do not assign an IO
It is easier to compute the expiration times of an HPET timer by using
its frequency (i.e., the number of times it ticks in a second) than its
period, as given in the capabilities register.
In addition to the HPET char driver, the HPET-based hardlockup detector
will also need to know the timer's
Some of the registers in the HPET hardware have a width of 64 bits. 64-bit
access functions are needed mostly to read the counter and write the
comparator in a single read or write. Also, 64-bit accesses can be used to
to read parameters located in the higher bits of some registers (such as
the
Even though there is a delivery mode field at the entries of an IO APIC's
redirection table, the documentation of the majority of the IO APICs
explicitly states that interrupt delivery as non-maskable is not supported.
Thus,
However, when using an IO APIC in combination with the Intel VT-d
Until now, the delivery mode of APIC interrupts is set to the default
mode set in the APIC driver. However, there are no restrictions in hardware
to configure each interrupt with a different delivery mode. Specifying the
delivery mode per interrupt is useful when one is interested in changing
the
The Intel IOMMU is capable of delivering remapped interrupts as non-
maskable. Add the IRQCHIP_CAN_DELIVER_AS_NMI flag to its irq_chip
structure to declare this capability. The delivery mode of each interrupt
can be set separately.
By default, the deliver mode is taken from the configuration
Certain interrupt controllers (such as APIC) are capable of delivering
interrupts as non-maskable. Likewise, drivers or subsystems (e.g., the
hardlockup detector) might be interested in requesting a non-maskable
interrupt. The new flag IRQF_DELIVER_AS_NMI serves this purpose.
When setting up an
Hi,
This patchset demonstrates the implementation of a hardlockup detector
driven by the High-Precision Event Timer.
== Introduction ==
In CPU architectures that do not have an NMI watchdog, one can be
constructed using a counter of the Performance Monitoring Unit (PMU).
Counters in the PMU
Certain interrupt controllers (e.g., APIC) are capable of delivering
interrupts to the CPU as non-maskable. Add the new IRQD_DELIVER_AS_NMI
interrupt state flag. The purpose of this flag is to communicate to the
underlying irqchip whether the interrupt must be delivered in this manner.
Cc: Ashok
Mathieu Malaterre writes:
> Hi there,
>
> I have a reproducible UBSAN appearing in dmesg after a while on my G4
> (*). Could anyone suggest a way to diagnose the actual root issue here
> (or is it just a false positive) ?
It looks like a real overflow, I guess the question is why are we seeing
On Tue, Jun 12, 2018 at 5:12 PM Nicholas Piggin wrote:
> >
> > And in _theory_, maybe you could have just used "invalpg" with a
> > targeted address instead. In fact, I think a single invlpg invalidates
> > _all_ caches for the associated MM, but don't quote me on that.
Confirmed. The SDK says
On Tue, 12 Jun 2018 16:39:55 -0700
Linus Torvalds wrote:
> On Tue, Jun 12, 2018 at 4:26 PM Linus Torvalds
> wrote:
> >
> > Right. Intel depends on the current thing, ie if a page table
> > *itself* is freed, we will will need to do a flush, but it's the exact
> > same flush as if there had
On Tue, 12 Jun 2018 16:26:33 -0700
Linus Torvalds wrote:
> On Tue, Jun 12, 2018 at 4:09 PM Nicholas Piggin wrote:
> >
> > Sorry I mean Intel needs the existing behaviour of range flush expanded
> > to cover page table pages right?
>
> Right. Intel depends on the current thing, ie if a
On Tue, Jun 12, 2018 at 4:26 PM Linus Torvalds
wrote:
>
> Right. Intel depends on the current thing, ie if a page table
> *itself* is freed, we will will need to do a flush, but it's the exact
> same flush as if there had been a regular page there.
>
> That's already handled by (for example)
On Tue, 12 Jun 2018 15:42:34 -0700
Linus Torvalds wrote:
> On Tue, Jun 12, 2018 at 3:31 PM Nicholas Piggin wrote:
> >
> > Okay sure, and this is the reason for the wide cc list. Intel does
> > need it of course, from 4.10.3.1 of the dev manual:
> >
> > — The processor may create a PML4-cache
On Tue, Jun 12, 2018 at 3:31 PM Nicholas Piggin wrote:
>
> Okay sure, and this is the reason for the wide cc list. Intel does
> need it of course, from 4.10.3.1 of the dev manual:
>
> — The processor may create a PML4-cache entry even if there are no
> translations for any linear address
On Tue, 12 Jun 2018 11:18:27 -0700
Linus Torvalds wrote:
> On Tue, Jun 12, 2018 at 12:16 AM Nicholas Piggin wrote:
> >
> > This brings the number of tlbiel instructions required by a kernel
> > compile from 33M to 25M, most avoided from exec->shift_arg_pages.
>
> And this shows that
Hi,
On Tue, Jun 12, 2018 at 6:53 PM, Laurent Vivier wrote:
> On 12/06/2018 01:47, Finn Thain wrote:
>> On Sun, 10 Jun 2018, Benjamin Herrenschmidt wrote:
> ...
>> I don't know what the bootloader situation is, but it looks messy...
>> http://nubus-pmac.sourceforge.net/#booters
>>
>> Laurent,
at 12:16 AM, Nicholas Piggin wrote:
> This reverts commit 4647706ebeee6e50f7b9f922b095f4ec94d581c3.
>
> Patch 99baac21e4585 ("mm: fix MADV_[FREE|DONTNEED] TLB flush miss
> problem") provides a superset of the TLB flush coverage of this
> commit, and even includes in the changelog "this patch
On Tue, Jun 12, 2018 at 12:16 AM Nicholas Piggin wrote:
>
> +static inline void __tlb_adjust_page_range(struct mmu_gather *tlb,
> + unsigned long address,
> + unsigned int range_size)
> +{
> + tlb->page_start =
Le 12/06/2018 à 16:53, Segher Boessenkool a écrit :
On Tue, Jun 12, 2018 at 09:14:53AM +, Christophe Leroy wrote:
---
Not tested on PPC64.
It won't be acceptable until that happens. It also is likely quite bad
performance on all 64-bit CPUs from the last fifteen years or so. Or you
This looks wrong. After a list iterator, the index variable points to a
dummy structure.
julia
url:
https://github.com/0day-ci/linux/commits/Baoquan-He/resource-Use-list_head-to-link-sibling-resource/20180612-113600
:: branch date: 7 hours ago
:: commit date: 7 hours ago
>>
On Tue, Jun 12, 2018 at 09:14:53AM +, Christophe Leroy wrote:
> ---
> Not tested on PPC64.
It won't be acceptable until that happens. It also is likely quite bad
performance on all 64-bit CPUs from the last fifteen years or so. Or you
did nothing to prove otherwise, at least.
> + *
> -Original Message-
> From: Yangbo Lu [mailto:yangbo...@nxp.com]
> Sent: Thursday, June 7, 2018 12:21 PM
> To: net...@vger.kernel.org; Madalin-cristian Bucur
> ; Richard Cochran ;
> Rob Herring ; Shawn Guo ;
> David S . Miller
> Cc: devicet...@vger.kernel.org;
On Tue, Jun 12, 2018 at 5:20 PM, Andy Shevchenko
wrote:
> On Tue, Jun 12, 2018 at 12:38 PM, Baoquan He wrote:
>> On 06/12/18 at 11:29am, Andy Shevchenko wrote:
>>> On Tue, Jun 12, 2018 at 6:28 AM, Baoquan He wrote:
>
>>> > +{
>>>
>>> > + for (pp = >child; (p = *pp) != NULL; pp = >sibling)
On Tue, Jun 12, 2018 at 12:38 PM, Baoquan He wrote:
> On 06/12/18 at 11:29am, Andy Shevchenko wrote:
>> On Tue, Jun 12, 2018 at 6:28 AM, Baoquan He wrote:
>> > +{
>>
>> > + for (pp = >child; (p = *pp) != NULL; pp = >sibling) {
>> > + if (p->end < res->start)
>> > +
On 06/12/2018 12:46 PM, Nicholas Piggin wrote:
This reverts commit 4647706ebeee6e50f7b9f922b095f4ec94d581c3.
Patch 99baac21e4585 ("mm: fix MADV_[FREE|DONTNEED] TLB flush miss
problem") provides a superset of the TLB flush coverage of this
commit, and even includes in the changelog "this patch
Mahesh J Salgaonkar writes:
> diff --git a/arch/powerpc/platforms/pseries/ras.c
> b/arch/powerpc/platforms/pseries/ras.c
> index 2edc673be137..e56759d92356 100644
> --- a/arch/powerpc/platforms/pseries/ras.c
> +++ b/arch/powerpc/platforms/pseries/ras.c
> @@ -422,6 +422,31 @@ int
On 06/05/2018 04:09 AM, Ram Pai wrote:
diff --git a/arch/powerpc/include/asm/pkeys.h b/arch/powerpc/include/asm/pkeys.h
index 0409c80..d349e22 100644
--- a/arch/powerpc/include/asm/pkeys.h
+++ b/arch/powerpc/include/asm/pkeys.h
@@ -13,7 +13,10 @@
DECLARE_STATIC_KEY_TRUE(pkey_disabled);
On 06/11/2018 10:08 PM, Ram Pai wrote:
Ok. try this patch. This patch is on top of the 5 patches that I had
sent last week i.e "[PATCH 0/5] powerpc/pkeys: fixes to pkeys"
The following is a draft patch though to check if it meets your
expectations.
commit
On 11/06/18 17:41, vrbagal1 wrote:
> On 2018-06-08 17:45, Oscar Salvador wrote:
>> On Fri, Jun 08, 2018 at 05:11:24PM +0530, vrbagal1 wrote:
>>> On 2018-06-08 16:58, Oscar Salvador wrote:
>>> >On Fri, Jun 08, 2018 at 04:44:24PM +0530, vrbagal1 wrote:
>>> >>Greetings!!!
>>> >>
>>> >>I am seeing
On Tue, 12 Jun 2018 02:59:11 +
Bharat Bhushan wrote:
> Hi Diana,
>
> > -Original Message-
> > From: Diana Craciun [mailto:diana.crac...@nxp.com]
> > Sent: Monday, June 11, 2018 6:23 PM
> > To: linuxppc-dev@lists.ozlabs.org
> > Cc: m...@ellerman.id.au; o...@buserror.net; Leo Li
> > ;
On 06/12/18 at 11:29am, Andy Shevchenko wrote:
> On Tue, Jun 12, 2018 at 6:28 AM, Baoquan He wrote:
> > reparent_resources() is duplicated in arch/microblaze/pci/pci-common.c
> > and arch/powerpc/kernel/pci-common.c, so move it to kernel/resource.c
> > so that it's shared. Later its code also
On 06/12/18 at 11:29am, Andy Shevchenko wrote:
> On Tue, Jun 12, 2018 at 6:28 AM, Baoquan He wrote:
> > reparent_resources() is duplicated in arch/microblaze/pci/pci-common.c
> > and arch/powerpc/kernel/pci-common.c, so move it to kernel/resource.c
> > so that it's shared. Later its code also
If possible CPUs are limited (e.g., by kexec), then the kvm prefetch
workaround function can access the paca pointer for a !possible CPU.
Fixes: d2e60075a3d44 ("powerpc/64: Use array of paca pointers and allocate
pacas individually")
Cc: sta...@kernel.org
Reported-by: Pridhiviraj Paidipeddi
This patch modifies the test for testing the new assembly strlen() instead
of the generic strlen()
Signed-off-by: Christophe Leroy
---
v6: added additional necessary defines in ppc_asm.h
v5: no change
v4: new
.../testing/selftests/powerpc/stringloops/Makefile | 3 +--
The generic implementation of strlen() reads strings byte per byte.
This patch implements strlen() in assembly based on a read of entire
words, in the same spirit as what some other arches and glibc do.
On a 8xx the time spent in strlen is reduced by 3/4 for long strings.
strlen() selftest on
This patch adds a test for strlen()
string.c contains a copy of strlen() from lib/string.c
The test first tests the correctness of strlen() by comparing
the result with libc strlen(). It tests all cases of alignment.
It them tests the duration of an aligned strlen() on a 4 bytes string,
on a 16
This patch renames memcmp test to memcmp_64 and adds
a memcmp_32 test for testing the 32 bits version of memcmp()
Signed-off-by: Christophe Leroy
---
v6: no change
v5: no change
v4: new
tools/testing/selftests/powerpc/stringloops/Makefile| 14 +++---
On Tue, Jun 12, 2018 at 6:28 AM, Baoquan He wrote:
> reparent_resources() is duplicated in arch/microblaze/pci/pci-common.c
> and arch/powerpc/kernel/pci-common.c, so move it to kernel/resource.c
> so that it's shared. Later its code also need be updated using list_head
> to replace singly linked
Hi Balbir,
On Tue, Jun 12, 2018 at 9:39 AM Balbir Singh wrote:
>
>
> On 12/06/18 06:20, Mathieu Malaterre wrote:
>
> > Hi Meelis,
> >
> > On Mon, Jun 11, 2018 at 1:21 PM Meelis Roos wrote:
> >> I am seeing this on PowerMac G4 with sungem ethernet driver. 4.17 was
> >> OK,
Hi Pingfan,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on v4.17]
[cannot apply to pci/next next-20180612]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Pingfan
On 12/06/18 06:20, Mathieu Malaterre wrote:
> Hi Meelis,
>
> On Mon, Jun 11, 2018 at 1:21 PM Meelis Roos wrote:
>> I am seeing this on PowerMac G4 with sungem ethernet driver. 4.17 was
>> OK, 4.17.0-10146-gf0dc7f9c6dd9 is problematic.
> Same here.
>
>> [ 140.518664] eth0: hw csum failure
>> [
On Tue, Jun 12, 2018 at 02:42:13PM +0800, Pingfan Liu wrote:
> The Linux Device Driver Model allows a physical device to be handled
> by only a single driver. But at present, both shpchp and portdrv_pci
> claim PCI_CLASS_BRIDGE_PCI, and touch devices_kset. This causes a
> few problems, one is the
On Tue, Jun 12, 2018 at 2:57 PM Christoph Hellwig wrote:
>
> On Tue, Jun 12, 2018 at 02:42:13PM +0800, Pingfan Liu wrote:
> > The Linux Device Driver Model allows a physical device to be handled
> > by only a single driver. But at present, both shpchp and portdrv_pci
> > claim
Use the page_start and page_end fields of mmu_gather to implement more
precise TLB flushing. (start, end) covers the entire TLB and page
table range that has been invalidated, for architectures that do not
have explicit page walk cache management. page_start and page_end are
just for ranges that
The mmu_gather APIs keep track of the invalidated address range
including the span covered by invalidated page table pages. Page table
pages with no ptes (and therefore could not have TLB entries) still
need to be involved in the invalidation if the processor caches
intermediate levels of the page
This reverts commit 4647706ebeee6e50f7b9f922b095f4ec94d581c3.
Patch 99baac21e4585 ("mm: fix MADV_[FREE|DONTNEED] TLB flush miss
problem") provides a superset of the TLB flush coverage of this
commit, and even includes in the changelog "this patch supersedes
'mm: Always flush VMA ranges affected
I'm just looking around TLB flushing and noticed a few issues with
the core code. The first one seems pretty straightforward, unless I
missed something, but the TLB flush pattern after the revert seems
okay.
The second one might be a bit more interesting for other architectures
and the big
On Tue, Jun 12, 2018 at 2:42 PM Pingfan Liu wrote:
>
> The Linux Device Driver Model allows a physical device to be handled
> by only a single driver. But at present, both shpchp and portdrv_pci
> claim PCI_CLASS_BRIDGE_PCI, and touch devices_kset. This causes a
> few problems, one is the wrong
Hi Pingfan,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on v4.17]
[cannot apply to pci/next next-20180612]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Pingfan
On 12/06/2018 01:47, Finn Thain wrote:
> On Sun, 10 Jun 2018, Benjamin Herrenschmidt wrote:
...
> I don't know what the bootloader situation is, but it looks messy...
> http://nubus-pmac.sourceforge.net/#booters
>
> Laurent, does Emile work on these machines?
>
No, Emile doesn't work on
The Linux Device Driver Model allows a physical device to be handled
by only a single driver. But at present, both shpchp and portdrv_pci
claim PCI_CLASS_BRIDGE_PCI, and touch devices_kset. This causes a
few problems, one is the wrong shutdown seq of devices, owing to the
broken devices_kset.
I
78 matches
Mail list logo
