Hi Nicholas,
I love your patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on next-20180613]
[cannot apply to v4.17]
[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
Hi Nicholas,
I love your patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on next-20180613]
[cannot apply to v4.17]
[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
On 06/13/2018 05:58 PM, Ricardo Neri wrote:
> On Tue, Jun 12, 2018 at 10:26:57PM -0700, Randy Dunlap wrote:
>> 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
The patch 99baac21e4 ("mm: fix MADV_[FREE|DONTNEED] TLB flush miss
problem") added a force flush mode to the mmu_gather flush, which
unconditionally flushes the entire address range being invalidated
(even if actual ptes only covered a smaller range), to solve a problem
with concurrent threads
On Tue, 12 Jun 2018 18:10:26 -0700
Linus Torvalds wrote:
> 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
On Wed, 13 Jun 2018 18:31:17 -0700
Ricardo Neri wrote:
> On Wed, Jun 13, 2018 at 09:52:25PM +1000, Nicholas Piggin wrote:
> > On Wed, 13 Jun 2018 11:26:49 +0200 (CEST)
> > Thomas Gleixner wrote:
> >
> > > On Wed, 13 Jun 2018, Peter Zijlstra wrote:
> > > > On Wed, Jun 13, 2018 at 05:41:41PM
On Wed, 13 Jun 2018 18:19:01 -0700
Ricardo Neri wrote:
> On Wed, Jun 13, 2018 at 10:43:24AM +0200, Peter Zijlstra wrote:
> > On Tue, Jun 12, 2018 at 05:57:34PM -0700, Ricardo Neri wrote:
> > > The current default implementation of the hardlockup detector assumes that
> > > it is implemented
On Wed, Jun 13, 2018 at 09:52:25PM +1000, Nicholas Piggin wrote:
> On Wed, 13 Jun 2018 11:26:49 +0200 (CEST)
> Thomas Gleixner wrote:
>
> > On Wed, 13 Jun 2018, Peter Zijlstra wrote:
> > > On Wed, Jun 13, 2018 at 05:41:41PM +1000, Nicholas Piggin wrote:
> > > > On Tue, 12 Jun 2018 17:57:32
On Wed, Jun 13, 2018 at 10:42:19AM +0200, Peter Zijlstra wrote:
> On Wed, Jun 13, 2018 at 05:41:41PM +1000, Nicholas Piggin wrote:
> > On Tue, 12 Jun 2018 17:57:32 -0700
> > Ricardo Neri wrote:
> >
> > > Instead of exposing individual functions for the operations of the NMI
> > > watchdog,
On Wed, Jun 13, 2018 at 10:43:24AM +0200, Peter Zijlstra wrote:
> On Tue, Jun 12, 2018 at 05:57:34PM -0700, Ricardo Neri wrote:
> > The current default implementation of the hardlockup detector assumes that
> > it is implemented using perf events.
>
> The sparc and powerpc things are very much
On Tue, Jun 12, 2018 at 10:23:47PM -0700, Randy Dunlap wrote:
> Hi,
Hi Randy,
>
> 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 @@
On Tue, Jun 12, 2018 at 10:26:57PM -0700, Randy Dunlap wrote:
> 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
> > ---
Ensure pkey-0 is allocated on start. Ensure pkey-0 can be attached
dynamically in various modes, without failures. Ensure pkey-0 can be
freed and allocated.
Signed-off-by: Ram Pai
---
tools/testing/selftests/vm/protection_keys.c | 66 +-
1 files changed, 64
introduce a new allocator that allocates 4k hardware-pages to back
64k linux-page. This allocator is only applicable on powerpc.
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
Signed-off-by: Thiago Jung Bauermann
---
tools/testing/selftests/vm/pkey-helpers.h|6 ++
Generally the signal handler restores the state of the pkey register
before returning. However there are times when the read/write operation
can legitamely fail without invoking the signal handler. Eg: A
sys_read() operaton to a write-protected page should be disallowed. In
such a case the state
detect write-violation on a page to which access-disabled
key is associated much after the page is mapped.
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
Acked-by: Dave Hansen
---
tools/testing/selftests/vm/protection_keys.c | 13 +
1 files changed, 13 insertions(+),
detect write-violation on a page to which write-disabled
key is associated much after the page is mapped.
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
Acked-by: Dave Hansen
---
tools/testing/selftests/vm/protection_keys.c | 12
1 files changed, 12 insertions(+), 0
detect access-violation on a page to which access-disabled
key is associated much after the page is mapped.
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
Acked-by: Dave Hansen
---
tools/testing/selftests/vm/protection_keys.c | 19 +++
1 files changed, 19
The maximum number of keys that can be allocated has to
take into consideration, that some keys are reserved by
the architecture for specific purpose. Hence cannot
be allocated.
Fix the assertion in test_pkey_alloc_exhaust()
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
---
pkey subsystem is supported if the hardware and kernel has support.
We determine that by checking if allocation of a key succeeds or not.
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
---
tools/testing/selftests/vm/pkey-helpers.h|2 ++
Introduce powerpc implementation for the various
abstractions.
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
Signed-off-by: Thiago Jung Bauermann
---
tools/testing/selftests/vm/pkey-helpers.h| 16 -
tools/testing/selftests/vm/pkey-powerpc.h| 91
When a key is freed, the key is no more effective.
Clear the bits corresponding to the pkey in the shadow
register. Otherwise it will carry some spurious bits
which can trigger false-positive asserts.
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
---
cleanup the code to satisfy coding styles.
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
---
tools/testing/selftests/vm/protection_keys.c | 64 +
1 files changed, 43 insertions(+), 21 deletions(-)
diff --git a/tools/testing/selftests/vm/protection_keys.c
expected_pkey_fault() is comparing the contents of pkey
register with 0. This may not be true all the time. There
could be bits set by default by the architecture
which can never be changed. Hence compare the value against
shadow pkey register, which is supposed to track the bits
accurately all
open_hugepage_file() <- opens the huge page file
get_start_key() <-- provides the first non-reserved key.
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
Signed-off-by: Thiago Jung Bauermann
Reviewed-by: Dave Hansen
---
tools/testing/selftests/vm/pkey-helpers.h| 10
alloc_random_pkey() was allocating the same pkey every time.
Not all pkeys were geting tested. fixed it.
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
---
tools/testing/selftests/vm/protection_keys.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git
When a key is freed, the key is no more effective.
Clear the bits corresponding to the pkey in the shadow
register. Otherwise it will carry some spurious bits
which can trigger false-positive asserts.
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
---
instead of clearing the bits, pkey_disable_clear() was setting
the bits. Fixed it.
Also fixed a wrong assertion in that function. When bits are
cleared, the resulting bit value will be less than the original.
This hasn't been a problem so far because this code isn't currently
used.
cc: Dave
If the flag is 0, no bits will be set. Hence we cant expect
the resulting bitmap to have a higher value than what it
was earlier.
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
---
tools/testing/selftests/vm/protection_keys.c |2 +-
1 files changed, 1 insertions(+), 1
helper functions to handler shadow pkey register
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
Signed-off-by: Thiago Jung Bauermann
---
tools/testing/selftests/vm/pkey-helpers.h| 29 ++
tools/testing/selftests/vm/pkey-x86.h|5
This is in preparation to accomadate a differing size register
across architectures.
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
Signed-off-by: Thiago Jung Bauermann
---
tools/testing/selftests/vm/pkey-helpers.h| 23 ---
tools/testing/selftests/vm/pkey-x86.h|
From: Thiago Jung Bauermann
This will help us ensure we print pkey_reg_t values correctly in different
architectures.
Signed-off-by: Thiago Jung Bauermann
---
tools/testing/selftests/vm/pkey-helpers.h |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git
From: Thiago Jung Bauermann
In preparation for multi-arch support, move definitions which have
arch-specific values to x86-specific header.
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
Signed-off-by: Thiago Jung Bauermann
---
tools/testing/selftests/vm/pkey-helpers.h| 111
Moved all the generic definition and helper functions to the header file.
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
Signed-off-by: Thiago Jung Bauermann
---
tools/testing/selftests/vm/pkey-helpers.h| 35 ++---
some pkru references are named to pkey_reg
and some prku references are renamed to pkey
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
Signed-off-by: Thiago Jung Bauermann
Reviewed-by: Dave Hansen
---
tools/testing/selftests/vm/pkey-helpers.h| 85 +-
cc: Dave Hansen
cc: Florian Weimer
Signed-off-by: Ram Pai
Signed-off-by: Thiago Jung Bauermann
Acked-by: Ingo Molnar
---
tools/testing/selftests/vm/.gitignore |1 +
tools/testing/selftests/vm/Makefile |1 +
tools/testing/selftests/vm/pkey-helpers.h | 219
Memory protection keys enables an application to protect its address space from
inadvertent access by its own code.
This feature is now enabled on powerpc architecture and integrated in
4.16-rc1. The patches move the selftests to arch neutral directory
and enhance their test coverage.
Test
Hi Nicholas,
I love your patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on next-20180613]
[cannot apply to v4.17]
[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
Deny all permissions on all keys, with some exceptions. pkey-0 must
allow all permissions, or else everything comes to a screaching halt.
Execute-only key must allow execute permission.
Signed-off-by: Ram Pai
---
arch/powerpc/mm/pkeys.c | 10 --
1 files changed, 4 insertions(+), 6
Applications need the ability to associate an address-range with some
key and latter revert to its initial default key. Pkey-0 comes close to
providing this function but falls short, because the current
implementation disallows applications to explicitly associate pkey-0 to
the address range.
execute-only key is allocated dynamically. This is a problem. When a
thread implicitly creates a execute-only key, and resets UAMOR for that
key, the UAMOR value does not percolate to all the other threads. Any
other thread may ignorantly change the permissions on the key. This can
cause the
Total number of pkeys calculation is off by 1. Fix it.
CC: Florian Weimer
CC: Michael Ellerman
CC: Thiago Jung Bauermann
Signed-off-by: Ram Pai
---
arch/powerpc/mm/pkeys.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/mm/pkeys.c
When a thread forks the contents of AMR, IAMR, UAMOR registers in the
newly forked thread are not inherited.
Save the registers before forking, for content of those
registers to be automatically copied into the new thread.
CC: Michael Ellerman
CC: Florian Weimer
CC: Andy Lutomirski
CC: Thiago
In a multithreaded application, a key allocated by one thread must
be activate and usable on all threads.
Currently this is not the case, because the UAMOR bits for all keys are
disabled by default. When a new key is allocated in one thread, though
the corresponding UAMOR bits for that thread get
Assortment of fixes to pkey.
Patch 1 makes pkey consumable in multithreaded applications.
Patch 2 fixes fork behavior to inherit the key attributes.
Patch 3 A off-by-one bug made one key unusable. Fixes it.
Patch 4 Execute-only key is preallocated.
Patch 5 Makes pkey-0 less special.
Hi Cyril,
On 02/19/2018 09:22 PM, Cyril Bur wrote:
> This is very much a proof of concept and if it isn't clear from the
> commit names, still a work in progress.
> I believe I have something that works - all the powerpc selftests
> pass. I would like to get some eyes on it to a) see if I've
Arnd,
In 5bfd643583b2e I can see that you changed:
$ git show 5bfd643583b2e -- arch/powerpc/platforms/powermac/time.c
[...]
#ifdef CONFIG_ADB_PMU
-static unsigned long pmu_get_time(void)
+static time64_t pmu_get_time(void)
{
struct adb_request req;
- unsigned int now;
+
On Wed, 13 Jun 2018 23:24:14 +1000
Michael Ellerman wrote:
> When we take an SLB multi-hit on bare metal, we see both the multi-hit
> and parity error bits set in DSISR. The user manuals indicates this is
> expected to always happen on Power8, whereas on Power9 it says a
> multi-hit will
On Wed, 13 Jun 2018 23:23:56 +1000
Michael Ellerman wrote:
> In the device tree CPU features quirk code we want to set
> CPU_FTR_POWER9_DD2_1 on all Power9s that aren't DD2.0 or earlier. But
> we got the logic wrong and instead set it on all CPUs that aren't
> Power9 DD2.0 or earlier, ie.
On Mon, Jun 11, 2018 at 01:34:50PM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2018-06-11 at 06:28 +0300, Michael S. Tsirkin wrote:
> >
> > > However if the administrator
> > > ignores/forgets/deliberatey-decides/is-constrained to NOT enable the
> > > flag, virtio will not be able to pass
On Mon, Jun 11, 2018 at 01:29:18PM +1000, Benjamin Herrenschmidt wrote:
> On Sun, 2018-06-10 at 19:39 -0700, Ram Pai wrote:
> >
> > However if the administrator
> > ignores/forgets/deliberatey-decides/is-constrained to NOT enable the
> > flag, virtio will not be able to pass control to the DMA
On Wed, Jun 13, 2018 at 12:41:41AM -0700, Christoph Hellwig wrote:
> On Mon, Jun 11, 2018 at 01:29:18PM +1000, Benjamin Herrenschmidt wrote:
> > At the risk of repeating myself, let's just do the first pass which is
> > to switch virtio over to always using the DMA API in the actual data
> > flow
On Thu, Jun 07, 2018 at 11:36:55PM -0700, Christoph Hellwig wrote:
> > This seems to be what was being asked for in this thread,
> > with comments claiming IOMMU flag adds too much overhead.
>
> Right now it means implementing a virtual iommu, which I agree is
> way too much overhead.
Well not
When we take an SLB multi-hit on bare metal, we see both the multi-hit
and parity error bits set in DSISR. The user manuals indicates this is
expected to always happen on Power8, whereas on Power9 it says a
multi-hit will "usually" also cause a parity error.
We decide what to do based on the
In the device tree CPU features quirk code we want to set
CPU_FTR_POWER9_DD2_1 on all Power9s that aren't DD2.0 or earlier. But
we got the logic wrong and instead set it on all CPUs that aren't
Power9 DD2.0 or earlier, ie. including Power8.
Fix it by making sure we're on a Power9. This isn't a
On Wed, 2018-06-13 at 22:25 +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2018-06-13 at 00:41 -0700, Christoph Hellwig wrote:
> > On Mon, Jun 11, 2018 at 01:29:18PM +1000, Benjamin Herrenschmidt wrote:
> > > At the risk of repeating myself, let's just do the first pass which is
> > > to switch
On Wed, Jun 13, 2018 at 02:29:57PM +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 when the drivers are
> loaded. This causes
On Wed, 2018-06-13 at 00:41 -0700, Christoph Hellwig wrote:
> On Mon, Jun 11, 2018 at 01:29:18PM +1000, Benjamin Herrenschmidt wrote:
> > At the risk of repeating myself, let's just do the first pass which is
> > to switch virtio over to always using the DMA API in the actual data
> > flow code,
On Wed, 13 Jun 2018 11:26:49 +0200 (CEST)
Thomas Gleixner wrote:
> On Wed, 13 Jun 2018, Peter Zijlstra wrote:
> > On Wed, Jun 13, 2018 at 05:41:41PM +1000, Nicholas Piggin wrote:
> > > On Tue, 12 Jun 2018 17:57:32 -0700
> > > Ricardo Neri wrote:
> > >
> > > > Instead of exposing individual
On Wed, Jun 13, 2018 at 10:43 AM Mathieu Malaterre wrote:
>
> On Wed, Jun 13, 2018 at 3:43 AM Michael Ellerman wrote:
> >
> > 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
Now that the PowerMac via-pmu driver supports m68k PowerBooks,
switch over to that driver and remove the via-pmu68k driver.
Cc: Geert Uytterhoeven
Tested-by: Stan Johnson
Signed-off-by: Finn Thain
---
arch/m68k/configs/mac_defconfig | 2 +-
arch/m68k/configs/multi_defconfig | 2 +-
On most PowerPC Macs, the PMU driver uses the shift register and
IO port B from a single VIA chip.
On 68k and early PowerPC PowerBooks, the driver uses the shift register
from one VIA chip together with IO port B from another.
Replace via with via1 and via2 to accommodate this. For the
At present, CONFIG_ADB_PMU depends on CONFIG_PPC_PMAC. When this gets
relaxed to CONFIG_PPC_PMAC || CONFIG_MAC, those Kconfig symbols with
implicit deps on PPC_PMAC will need explicit deps. Add them now.
No functional change.
Tested-by: Stan Johnson
Signed-off-by: Finn Thain
---
Put #ifdefs around the Open Firmware, xmon, interrupt dispatch,
battery and suspend code. Add the necessary interrupt handling to
support m68k PowerBooks.
The pmu_kind value is available to userspace using the
PMU_IOC_GET_MODEL ioctl. It is not clear yet what hardware classes
are be needed to
Now that the 68k Mac port has adopted the via-pmu driver, it must access
the PMU RTC using the appropriate command format. The same code can now
be used for both m68k and powerpc.
Replace the RTC code that's duplicated in arch/powerpc and arch/m68k
with common RTC accessors for Cuda and PMU
Some of the event counters are overloaded which makes it very
difficult to interpret their values.
Counter 0 is supposed to report CB1 interrupts but it can also count
PMU_INT_WAITING_CHARGER events.
Counter 1 is supposed to report GPIO interrupts but it can also count
other events (depending
Don't load the via-pmu68k driver on early PowerBooks. The M50753 PMU
device found in those models was never supported by this driver.
Attempting to load the driver usually causes a boot hang.
Cc: Geert Uytterhoeven
Signed-off-by: Finn Thain
Reviewed-by: Michael Schmitz
---
Replace an open-coded ffs() with the function call.
Simplify an if-else cascade using a switch statement.
Correct a typo and an indentation issue.
Tested-by: Stan Johnson
Signed-off-by: Finn Thain
Reviewed-by: Geert Uytterhoeven
---
drivers/macintosh/via-pmu.c | 39
On 68k Macs, the via/vias pointer can't be used to determine whether
the PMU driver has been initialized. For portability, add a new state
to indicate that via_find_pmu() succeeded.
After via_find_pmu() executes, testing vias == NULL is equivalent to
testing via == NULL. Replace these tests with
The pmu_init() function has the __init qualifier, but the ops struct
that holds a pointer to it does not. This causes a build warning.
The driver works fine because the pointer is only dereferenced early.
The function is so small that there's negligible benefit from using
the __init qualifier.
The shift register interrupt flag gets cleared in via_pmu_interrupt()
and once again in pmu_sr_intr(). Fix this theoretical race condition.
Tested-by: Stan Johnson
Signed-off-by: Finn Thain
Reviewed-by: Geert Uytterhoeven
---
drivers/macintosh/via-pmu.c | 1 -
1 file changed, 1 deletion(-)
This series of patches has the following aims.
1) Eliminate duplicated code. Linux presently has two drivers for
the 68HC05-based PMU devices found in Macs: via-pmu and via-pmu68k.
There's no value in having separate PMU drivers for each architecture.
2) Avoid further work on via-pmu68k
Add missing in_8() accessors to init_pmu() and pmu_sr_intr().
This fixes several sparse warnings:
drivers/macintosh/via-pmu.c:536:29: warning: dereference of noderef expression
drivers/macintosh/via-pmu.c:537:33: warning: dereference of noderef expression
drivers/macintosh/via-pmu.c:1455:17:
On 13/06/18 10:57, Thomas Gleixner wrote:
On Wed, 13 Jun 2018, Julien Thierry wrote:
On 13/06/18 10:20, Thomas Gleixner wrote:
Adding NMI delivery support at low level architecture irq chip level is
perfectly fine, but the exposure of that needs to be restricted very
much. Adding it to the
On 13/06/18 10:20, Thomas Gleixner wrote:
> On Wed, 13 Jun 2018, Julien Thierry wrote:
>> On 13/06/18 09:34, Peter Zijlstra wrote:
>>> On Tue, Jun 12, 2018 at 05:57:23PM -0700, Ricardo Neri wrote:
diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
index 5426627..dbc5e02
The patch 99baac21e4 ("mm: fix MADV_[FREE|DONTNEED] TLB flush miss
problem") added a force flush mode to the mmu_gather flush, which
unconditionally flushes the entire address range being invalidated
(even if actual ptes only covered a smaller range), to solve a problem
with concurrent threads
On Wed, 13 Jun 2018, Julien Thierry wrote:
> On 13/06/18 10:20, Thomas Gleixner wrote:
> > Adding NMI delivery support at low level architecture irq chip level is
> > perfectly fine, but the exposure of that needs to be restricted very
> > much. Adding it to the generic interrupt control
On 13/06/18 10:36, Julien Thierry wrote:
On 13/06/18 10:20, Thomas Gleixner wrote:
On Wed, 13 Jun 2018, Julien Thierry wrote:
On 13/06/18 09:34, Peter Zijlstra wrote:
On Tue, Jun 12, 2018 at 05:57:23PM -0700, Ricardo Neri wrote:
diff --git a/include/linux/interrupt.h
On Tue, 12 Jun 2018, Ricardo Neri wrote:
> + /* There are no CPUs to monitor. */
> + if (!cpumask_weight(>monitored_mask))
> + return NMI_HANDLED;
> +
> inspect_for_hardlockups(regs);
>
> + /*
> + * Target a new CPU. Keep trying until we find a monitored CPU.
On Tue, 12 Jun 2018, Ricardo Neri wrote:
> @@ -183,6 +184,8 @@ static irqreturn_t hardlockup_detector_irq_handler(int
> irq, void *data)
> if (!(hdata->flags & HPET_DEV_PERI_CAP))
> kick_timer(hdata);
>
> + pr_err("This interrupt should not have happened. Ensure delivery
On Wed, 13 Jun 2018, Julien Thierry wrote:
> On 13/06/18 09:34, Peter Zijlstra wrote:
> > On Tue, Jun 12, 2018 at 05:57:23PM -0700, Ricardo Neri wrote:
> > > diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
> > > index 5426627..dbc5e02 100644
> > > --- a/include/linux/interrupt.h
On Wed, 13 Jun 2018, Peter Zijlstra wrote:
> On Wed, Jun 13, 2018 at 05:41:41PM +1000, Nicholas Piggin wrote:
> > On Tue, 12 Jun 2018 17:57:32 -0700
> > Ricardo Neri wrote:
> >
> > > Instead of exposing individual functions for the operations of the NMI
> > > watchdog, define a common interface
On Tue, Jun 12, 2018 at 05:57:37PM -0700, Ricardo Neri wrote:
+static bool is_hpet_wdt_interrupt(struct hpet_hld_data *hdata)
+{
+ unsigned long this_isr;
+ unsigned int lvl_trig;
+
+ this_isr = hpet_readl(HPET_STATUS) & BIT(hdata->num);
+
+ lvl_trig =
Hi Peter, Ricardo,
On 13/06/18 09:34, Peter Zijlstra wrote:
On Tue, Jun 12, 2018 at 05:57:23PM -0700, Ricardo Neri wrote:
diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
index 5426627..dbc5e02 100644
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -61,6
On Tue, Jun 12, 2018 at 05:57:34PM -0700, Ricardo Neri wrote:
> The current default implementation of the hardlockup detector assumes that
> it is implemented using perf events.
The sparc and powerpc things are very much not using perf.
On Wed, Jun 13, 2018 at 3:43 AM Michael Ellerman wrote:
>
> 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) ?
>
On Wed, Jun 13, 2018 at 05:41:41PM +1000, Nicholas Piggin wrote:
> On Tue, 12 Jun 2018 17:57:32 -0700
> Ricardo Neri wrote:
>
> > Instead of exposing individual functions for the operations of the NMI
> > watchdog, define a common interface that can be used across multiple
> > implementations.
>
On Tue, Jun 12, 2018 at 05:57:23PM -0700, Ricardo Neri wrote:
> diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
> index 5426627..dbc5e02 100644
> --- a/include/linux/interrupt.h
> +++ b/include/linux/interrupt.h
> @@ -61,6 +61,8 @@
> *interrupt handler after
Hi Michael,
It looks like this commit generates the following error:
stacktrace.c:(.text+0x1b0): undefined reference to `.smp_send_safe_nmi_ipi'
make[1]: *** [vmlinux] Error 1
make: *** [sub-make] Error 2
See http://kisskb.ellerman.id.au/kisskb/buildresult/13395345/ for details
Seems like
On Mon, Jun 11, 2018 at 01:29:18PM +1000, Benjamin Herrenschmidt wrote:
> At the risk of repeating myself, let's just do the first pass which is
> to switch virtio over to always using the DMA API in the actual data
> flow code, with a hook at initialization time that replaces the DMA ops
> with
On Tue, 12 Jun 2018 17:57:32 -0700
Ricardo Neri wrote:
> 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
Hi all,
On Tue, Jun 12, 2018 at 10:15 AM Mathieu Malaterre wrote:
>
> 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
NX increments readOffset by FIFO size in receive FIFO control register
when CRB is read. But the index in RxFIFO has to match with the
corresponding entry in FIFO maintained by VAS in kernel. Otherwise NX
may be processing incorrect CRBs and can cause CRB timeout.
VAS FIFO offset is 0 when the
Export opal_check_token symbol for modules to check the availability
of OPAL calls before using them.
Signed-off-by: Haren Myneni
diff --git a/arch/powerpc/platforms/powernv/opal.c
b/arch/powerpc/platforms/powernv/opal.c
index 48fbb41..838b79b 100644
---
On Wed, Jun 13, 2018 at 2:37 PM Christoph Hellwig wrote:
>
> If we successfull call ->probe twice on a device we have a much
> deeper problem than we can fix in the PCI layer or shpchp.
>
OK, see your point.
> Please explain the actual race or other condition that can lead to
> this and report
On 06/12/18 at 05:10pm, Julia Lawall wrote:
> 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
If we successfull call ->probe twice on a device we have a much
deeper problem than we can fix in the PCI layer or shpchp.
Please explain the actual race or other condition that can lead to
this and report it to the driver core maintainer.
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 when the drivers are
loaded. This causes a few problems, one is the wrong shutdown seq of
devices, owing to
In __driver_attach(), if a driver matches a device, the device will
be appended to the tail of devices_kset, no matter what the probing
result of the device. Hence in order to prevent a driver to append
a probed device to devices_kset, it requires a correct matching.
As for pci, pci driver uses
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. This cause problems, such as the wrong
shutdown seq. This series keeps shpchp driver away from pcie port device.
V1 -> V2:
1 - 100 of 102 matches
Mail list logo
