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 sh
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 comment
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 by
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
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 ma
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 PCI_CLASS_BRIDGE_PCI
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 w
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
>> [
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
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, 4.17.0-10146-gf0dc7f9c6
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
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 +++---
tools/testing/selftests/power
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
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 an
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 +--
.../selftests/powerpc/
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
Test
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 need
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 need
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 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 k
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 fe53b5fe2dcb3139ea27ade3ae7cbbe43c4af
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);
ex
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 pSeries_system_re
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 su
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 = &parent->child; (p = *pp) != NULL; pp = &p->sibling) {
>> > + if (p->end < res->start)
>> > +
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 = &parent->child; (p = *pp) != NULL; pp = &p
> -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; linuxppc-dev@lists.ozlabs.or
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.
> + * Algorigt
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
>>
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
di
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 = min(tlb->
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 "page_start/end" is purely for powerpc and used
nowhere else.
The previous patch
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 sup
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, does
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 "page_sta
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 tha
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 e
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 page table
*itself* is freed, we will will need to do a flush, but it's the
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) pud_
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 pa
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 been
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
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 i
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 R
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 have
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 in
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 field
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 d
As per the Intel 64 and IA-32 Architectures Software Developer's Manual
Volume 3 Section 10.11.2, the delivery mode field of the interrupt message
can be set to configure as non-maskable. Declare support to deliver non-
maskable interrupts by adding IRQCHIP_CAN_DELIVER_AS_NMI.
When composing the i
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 interru
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 tim
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 f
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 A
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 t
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 Om
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 purpo
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 pe
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
o
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
CPUs
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 det
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 individua
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 underly
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 th
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 to
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.
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. Wy
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 __se
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.
> ---
> arch/powerpc/ke
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 file
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
@@
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/pse
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
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 fro
"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
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
--- a/arch/
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 eb
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
>
> +con
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
> +++ b/Documentation/admin-guide/kernel-parameters
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 inva
Hi,
Observing kernel bug followed by kernel oops and system reboots, while
running kselftest on Power8 LPAR.
Machine Details: Power8 LPAR
Git Tree:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Commit ID: f5b7769eb0400ec5217a47e41148a9f816ca1f9f
Kernel version: 4.17.0-au
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:
implement
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 pc
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 th
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.
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-1
85 matches
Mail list logo