On 07/23/18 at 04:34pm, Michal Hocko wrote:
> On Thu 19-07-18 23:17:53, Baoquan He wrote:
> > Kexec has been a formal feature in our distro, and customers owning
> > those kind of very large machine can make use of this feature to speed
> > up the reboot process. On uefi machine, the kexec_file loa
From: Sam Bobroff
It is not currently possible to create the full number of possible
VCPUs (KVM_MAX_VCPUS) on Power9 with KVM-HV when the guest uses less
threads per core than it's core stride (or "VSMT mode"). This is
because the VCORE ID and XIVE offsets to grow beyond KVM_MAX_VCPUS
even though
On Mon, Jul 23, 2018 at 03:43:37PM +1000, Paul Mackerras wrote:
> On Thu, Jul 19, 2018 at 12:25:10PM +1000, Sam Bobroff wrote:
> > From: Sam Bobroff
> >
> > It is not currently possible to create the full number of possible
> > VCPUs (KVM_MAX_VCPUS) on Power9 with KVM-HV when the guest uses less
On 07/23/2018 07:46 AM, Anshuman Khandual wrote:
> On 07/20/2018 06:45 PM, Michael S. Tsirkin wrote:
>> On Fri, Jul 20, 2018 at 09:29:41AM +0530, Anshuman Khandual wrote:
>>> Subject: Re: [RFC 4/4] virtio: Add platform specific DMA API translation for
>>> virito devices
>>
>> s/virito/virtio/
>
>
Arnd Bergmann writes:
> Almost all files in the kernel are either plain text or UTF-8
> encoded. A couple however are ISO_8859-1, usually just a few
> characters in a C comments, for historic reasons.
>
> This converts them all to UTF-8 for consistency.
>
> Signed-off-by: Arnd Bergmann
> ---
...
On 07/23/2018 02:38 PM, Michael S. Tsirkin wrote:
> On Mon, Jul 23, 2018 at 11:58:23AM +0530, Anshuman Khandual wrote:
>> On 07/20/2018 06:46 PM, Michael S. Tsirkin wrote:
>>> On Fri, Jul 20, 2018 at 09:29:37AM +0530, Anshuman Khandual wrote:
This patch series is the follow up on the discussio
Hi Andrew,
On 07/19/18 at 12:44pm, Andrew Morton wrote:
> On Thu, 19 Jul 2018 23:17:53 +0800 Baoquan He wrote:
> > > As far as I can tell, the above is the whole reason for the patchset,
> > > yes? To avoid confusing users.
> >
> >
> > In fact, it's not just trying to avoid confusing users. Ke
On Tue, 24 Jul 2018 17:13:20 -0700 Joe Perches wrote:
> On Tue, 2018-07-24 at 14:00 -0700, Andrew Morton wrote:
> > On Tue, 24 Jul 2018 13:13:25 +0200 Arnd Bergmann wrote:
> > > Almost all files in the kernel are either plain text or UTF-8
> > > encoded. A couple however are ISO_8859-1, usually
Hi Alexandre,
On Thu, Jul 05, 2018 at 11:07:05AM +, Alexandre Ghiti wrote:
> In order to reduce copy/paste of functions across architectures and then
> make riscv hugetlb port (and future ports) simpler and smaller, this
> patchset intends to factorize the numerous hugetlb primitives that are
On Tue, 2018-07-24 at 14:00 -0700, Andrew Morton wrote:
> On Tue, 24 Jul 2018 13:13:25 +0200 Arnd Bergmann wrote:
> > Almost all files in the kernel are either plain text or UTF-8
> > encoded. A couple however are ISO_8859-1, usually just a few
> > characters in a C comments, for historic reasons.
On 2018/5/17 19:06, Laurent Dufour wrote:
> From: Peter Zijlstra
>
> Provide infrastructure to do a speculative fault (not holding
> mmap_sem).
>
> The not holding of mmap_sem means we can race against VMA
> change/removal and page-table destruction. We use the SRCU VMA freeing
> to keep the VMA a
On Tue, 24 Jul 2018 13:13:25 +0200
Arnd Bergmann wrote:
> Almost all files in the kernel are either plain text or UTF-8
> encoded. A couple however are ISO_8859-1, usually just a few
> characters in a C comments, for historic reasons.
>
> This converts them all to UTF-8 for consistency.
>
> Sig
On 07/24/2018 02:00 PM, Andrew Morton wrote:
> On Tue, 24 Jul 2018 13:13:25 +0200 Arnd Bergmann wrote:
>
>> Almost all files in the kernel are either plain text or UTF-8
>> encoded. A couple however are ISO_8859-1, usually just a few
>> characters in a C comments, for historic reasons.
>>
>> This
On Tue, 24 Jul 2018 13:13:25 +0200 Arnd Bergmann wrote:
> Almost all files in the kernel are either plain text or UTF-8
> encoded. A couple however are ISO_8859-1, usually just a few
> characters in a C comments, for historic reasons.
>
> This converts them all to UTF-8 for consistency.
Was "co
On 07/13/2018 03:18 PM, Michael Bringmann wrote:
pmt/numa: Disable arch_update_cpu_topology during post migration
CPU readd updates when evaluating device-tree changes after LPM
to avoid thread deadlocks trying to update node assignments.
System timing between all of the threads and timers restar
On Tue, Jul 24, 2018 at 01:13:25PM +0200, Arnd Bergmann wrote:
> Almost all files in the kernel are either plain text or UTF-8
> encoded. A couple however are ISO_8859-1, usually just a few
> characters in a C comments, for historic reasons.
>
> This converts them all to UTF-8 for consistency.
>
Move show_instructions() declaration to arch/powerpc/include/asm/stacktrace.h
and include asm/stracktrace.h in arch/powerpc/kernel/process.c, which contains
the implementation.
Modify show_instructions() not to call __kernel_text_address(), allowing
userspace instruction dump. probe_kernel_addres
This adds a human-readable name in the unhandled signal message.
Before this patch, a page fault looked like:
Jul 11 16:04:11 localhost kernel: pandafault[6303]: unhandled signal 11 at
17d0 nip 161c lr 7fff93c55100 code 2 in
pandafault[1000+1]
After this
This adds VMA address in the message printed for unhandled signals, similarly to
what other architectures, like x86, print.
Before this patch, a page fault looked like:
Jul 11 15:56:25 localhost kernel: pandafault[61470]: unhandled signal 11 at
17d0 nip 161c lr 7f
Simplify the message format by using REG_FMT as the register format. This
avoids having two different formats and avoids checking for MSR_64BIT.
Signed-off-by: Murilo Opsfelder Araujo
---
arch/powerpc/kernel/traps.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git
Make REG definition, in arch/powerpc/kernel/process.c, generic enough by
renaming it to REG_FMT and placing it in arch/powerpc/include/asm/reg.h to be
used elsewhere.
Replace occurrences of REG by REG_FMT in arch/powerpc/kernel/process.c.
Signed-off-by: Murilo Opsfelder Araujo
---
arch/powerpc/
Modify logic of show_signal_msg() to return early, if possible. Replace
printk_ratelimited() by printk() and a default rate limit burst to limit
displaying unhandled signals messages.
Signed-off-by: Murilo Opsfelder Araujo
---
arch/powerpc/kernel/traps.c | 21 +++--
1 file chang
Isolate the logic of printing unhandled signals out of _exception_pkey(). No
functional change, only code rearrangement.
Signed-off-by: Murilo Opsfelder Araujo
---
arch/powerpc/kernel/traps.c | 26 --
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/arch/p
Hi, everyone.
This series was inspired by the need to modernize and display more
informative messages about unhandled signals.
The "unhandled signal NN" is not very informative. We thought it would
be helpful adding a human-readable message describing what the signal
number means, printing the V
Hi Andy,
Sorry, I missed the arm64 question at the end of this...
On Thu, Jul 19, 2018 at 10:04:09AM -0700, Andy Lutomirski wrote:
> On Thu, Jul 19, 2018 at 9:45 AM, Andy Lutomirski wrote:
> > [I added PeterZ and Vitaly -- can you see any way in which this would
> > break something obscure? I d
On 24/07/2018 16:26, zhong jiang wrote:
> On 2018/5/17 19:06, Laurent Dufour wrote:
>> From: Peter Zijlstra
>>
>> Provide infrastructure to do a speculative fault (not holding
>> mmap_sem).
>>
>> The not holding of mmap_sem means we can race against VMA
>> change/removal and page-table destruct
From: Krzysztof Kozlowski
> Sent: 23 July 2018 17:20
> Use generic kernel CRC32 implementation because it:
> 1. Should be faster (uses lookup tables),
Are you sure?
The lookup tables are unlikely to be in the data cache and
the 6 cache misses kill performance.
(Not that it particularly matters whe
From: Krzysztof Kozlowski
> Sent: 24 July 2018 12:12
...
> >> Not tested on hardware.
> >
> > Have you verified that the old and new functions give the
> > same result for a few mac addresses?
> > It is very easy to use the wrong bits in crc calculations
> > or generate the output in the wrong bit
This makes it easy to run checkpatch with settings that we have agreed
on (bwhahahahah).
Usage is eg:
$ ./arch/powerpc/tools/checkpatch.sh -g origin/master..
To check all commits since origin/master.
Signed-off-by: Michael Ellerman
---
arch/powerpc/tools/checkpatch.sh | 21 +
On Tue, 2018-07-17 at 13:51:02 UTC, Ram Pai wrote:
> Currently in a multithreaded application, a key allocated by one
> thread is not usable by other threads. By "not usable" we mean that
> other threads are unable to change the access permissions for that
> key for themselves.
>
> When a new key
On Mon, 2018-07-09 at 14:24:25 UTC, Michael Ellerman wrote:
> Because the allmodconfig logic just sets every symbol to M or Y, it
> has the effect of always generating a 64-bit config, because
> CONFIG_PPC64 becomes Y.
>
> So to make it easier for folks to test 32-bit code, provide a phony
> defco
On Mon, 2018-07-09 at 06:25:21 UTC, Michael Ellerman wrote:
> When I added the spectre_v2 information in sysfs, I included the
> availability of the ori31 speculation barrier.
>
> Although the ori31 barrier can be used to mitigate v2, it's primarily
> intended as a spectre v1 mitigation. Spectre v
On Fri, 2018-06-29 at 08:39:04 UTC, "Aneesh Kumar K.V" wrote:
> This patch adds error reporting to H_ENTER and H_READ hcalls. A failure for
> both these hcalls are mostly fatal and it would be good to log the failure
> reason.
>
> We also switch printk to pr_*
>
> Signed-off-by: Aneesh Kumar K.V
On Fri, 2018-06-29 at 08:36:29 UTC, "Aneesh Kumar K.V" wrote:
> From: "Aneesh Kumar K.V"
>
> When computing the starting slot number for a hash page table group we used
> to do this
> hpte_group = ((hash & htab_hash_mask) * HPTES_PER_GROUP) & ~0x7UL;
>
> Multiplying with 8 (HPTES_PER_GROUP) impl
On Thu, 2018-06-21 at 08:31:57 UTC, "Aneesh Kumar K.V" wrote:
> With SPARSEMEM config enabled, we make sure that we don't add sections beyond
> MAX_PHYSMEM_BITS range. This results in not building vmemmap mapping for
> range beyond max range. But our memblock layer looks the device tree and
> crea
On Thu, 2018-06-07 at 01:57:51 UTC, wei.guo.si...@gmail.com wrote:
> From: Simon Guo
>
> Currently memcmp() 64bytes version in powerpc will fall back to .Lshort
> (compare per byte mode) if either src or dst address is not 8 bytes aligned.
> It can be opmitized in 2 situations:
>
> 1) if both ad
On Sun, 2018-06-03 at 12:24:32 UTC, Nicholas Piggin wrote:
> When the masked interrupt handler clears MSR[EE] for an interrupt in
> the PACA_IRQ_MUST_HARD_MASK set, it does not set PACA_IRQ_HARD_DIS.
> This makes them get out of synch.
>
> With that taken into account, it's only low level irq mani
On Mon, 2018-04-30 at 14:55:44 UTC, Nicholas Piggin wrote:
> The intention here is to consume and discard the remaining buffer
> upon error. This works if there has not been a previous partial write.
> If there has been, then total_len is no longer total number of bytes
> to copy. total_len is alwa
On Wed, 2018-04-25 at 05:17:59 UTC, Nicholas Piggin wrote:
> There is an asynchronous aspect to smp_send_nmi_ipi. The caller waits
> for all CPUs to call in to the handler, but it does not wait for
> completion of the handler. This is a needless complication, so remove
> it and always wait synchron
On Mon, 2018-02-05 at 05:17:16 UTC, Cyril Bur wrote:
> In commit eb5c3f1c8647 ("powerpc: Always save/restore checkpointed regs
> during treclaim/trecheckpoint") __tm_recheckpoint was modified to no
> longer take the second parameter 'unsigned long orig_msr' as part of a
> TM rewrite to simplify the
On Thu, 2018-02-01 at 01:07:46 UTC, Cyril Bur wrote:
> tm_reclaim_thread() doesn't use the parameter anymore, both callers have
> to bother getting it as they have no need for a struct thread_info
> either.
>
> Just remove it and adjust the callers.
>
> Signed-off-by: Cyril Bur
Applied to power
On Mon, 2017-02-20 at 13:22:10 UTC, Mukesh Ojha wrote:
> Moves the return value check of 'opal_dump_info' to a proper place which
> was previously unnecessarily filling all the dump info even on failure.
>
> Signed-off-by: Mukesh Ojha
> Acked-by: Stewart Smith
> Acked-by: Jeremy Kerr
Series ap
Almost all files in the kernel are either plain text or UTF-8
encoded. A couple however are ISO_8859-1, usually just a few
characters in a C comments, for historic reasons.
This converts them all to UTF-8 for consistency.
Signed-off-by: Arnd Bergmann
---
.../devicetree/bindings/net/nfc/pn544.tx
On 24 July 2018 at 13:05, David Laight wrote:
> From: Krzysztof Kozlowski
>> Sent: 23 July 2018 17:20
>> Use generic kernel CRC32 implementation because it:
>> 1. Should be faster (uses lookup tables),
>
> Are you sure?
> The lookup tables are unlikely to be in the data cache and
> the 6 cache mis
On 07/19/2018 04:25 AM, Sam Bobroff wrote:
> From: Sam Bobroff
>
> It is not currently possible to create the full number of possible
> VCPUs (KVM_MAX_VCPUS) on Power9 with KVM-HV when the guest uses less
> threads per core than it's core stride (or "VSMT mode"). This is
> because the VCORE ID an
OPAL firmware provides the facility for some groups of sensors to be
enabled/disabled at runtime to give the user the option of using the
system resources for collecting these sensors or not.
For example, on POWER9 systems, the On Chip Controller (OCC) gathers
various system and chip level sensors
Adds support to enable/disable a sensor group at runtime. This
can be used to select the sensor groups that needs to be copied to
main memory by OCC. Sensor groups like power, temperature, current,
voltage, frequency, utilization can be enabled/disabled at runtime.
Signed-off-by: Shilpasri G Bhat
This patch series adds new attribute to enable or disable a sensor at
runtime.
Changes from v7:
- Use of_for_each_phandle() and of_count_phandle_with_args() to parse
through the phandle array
v7 : https://lkml.org/lkml/2018/7/20/72
v6 : https://lkml.org/lkml/2018/7/18/806
v5 : https://lkml.org/
48 matches
Mail list logo
