On 11/03/2020 17:09, Aneesh Kumar K.V wrote:
> Vaibhav Jain writes:
>
>> Recently we discovered an issue on pseries guests that prevents pci
>> devices from accessing pmem memory via DMA. Performing such an
>> operation will cause PHB to freeze the corresponding partition
>> endpoint and in so
ld instruction should have 14 bit immediate field (DS) concatenated with
0b00 on the right, encode it accordingly.
Fixes: 4ceae137bdab ("powerpc: emulate_step() tests for load/store
instructions")
Reviewed-by: Sandipan Das
Signed-off-by: Balamuruhan S
---
arch/powerpc/lib/test_emulate_step.c |
introduce macro `IMM_DS()` to encode DS form instructions with
14 bit immediate field.
Signed-off-by: Balamuruhan S
---
arch/powerpc/lib/test_emulate_step.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/lib/test_emulate_step.c
b/arch/powerpc/lib/test_emul
Vaibhav Jain writes:
> Recently we discovered an issue on pseries guests that prevents pci
> devices from accessing pmem memory via DMA. Performing such an
> operation will cause PHB to freeze the corresponding partition
> endpoint and in some scenarios will shutdown the disk that hosts the
> roo
Russell Currey writes:
> From: Christophe Leroy
>
> In addition to the set_memory_xx() functions which allows to change
> the memory attributes of not (yet) used memory regions, implement a
> set_memory_attr() function to:
> - set the final memory protection after init on currently used
> kernel
Russell Currey writes:
> The set_memory_{ro/rw/nx/x}() functions are required for STRICT_MODULE_RWX,
> and are generally useful primitives to have. This implementation is
> designed to be completely generic across powerpc's many MMUs.
>
> It's possible that this could be optimised to be faster f
Recently we discovered an issue on pseries guests that prevents pci
devices from accessing pmem memory via DMA. Performing such an
operation will cause PHB to freeze the corresponding partition
endpoint and in some scenarios will shutdown the disk that hosts the
rootfs.
A fix for this is in works
es matched by all F: patterns in in each section.
Done via the perl script below and the previously posted
cvt_fallthrough.pl script.
Link:
https://lore.kernel.org/lkml/b56602fcf79f849e733e7b521bb0e17895d390fa.1582230379.git.joe.com/
These patches are based on next-20200310 and are available in
gi
Convert the various uses of fallthrough comments to fallthrough;
Done via script
Link:
https://lore.kernel.org/lkml/b56602fcf79f849e733e7b521bb0e17895d390fa.1582230379.git.joe.com/
Signed-off-by: Joe Perches
---
arch/powerpc/platforms/cell/spufs/switch.c | 2 +-
1 file changed, 1 insertion(+),
Convert the various uses of fallthrough comments to fallthrough;
Done via script
Link:
https://lore.kernel.org/lkml/b56602fcf79f849e733e7b521bb0e17895d390fa.1582230379.git.joe.com/
Signed-off-by: Joe Perches
---
arch/powerpc/kvm/book3s_32_mmu.c | 2 +-
arch/powerpc/kvm/book3s_64_mmu.c | 2 +-
On Wed, 2020-03-04 at 12:06 +0100, Frederic Barrat wrote:
>
> Le 28/02/2020 à 07:12, Andrew Donnellan a écrit :
> > On 21/2/20 2:27 pm, Alastair D'Silva wrote:
> > > From: Alastair D'Silva
> > >
> > > When health & performance data is requested from the controller,
> > > it responds with an erro
On Wed, 2020-03-04 at 12:00 +0100, Frederic Barrat wrote:
>
> Le 21/02/2020 à 04:27, Alastair D'Silva a écrit :
> > From: Alastair D'Silva
> >
> > Some of the interrupts that the card generates are better handled
> > by the userspace daemon, in particular:
> > Controller Hardware/Firmware Fatal
On Tue, Mar 10, 2020 at 04:11:28PM -0500, Michael Roth wrote:
> The h_cede_tm kvm-unit-test currently fails when run inside an L1 guest
> via the guest/nested hypervisor.
>
> ./run-tests.sh -v
> ...
> TESTNAME=h_cede_tm TIMEOUT=90s ACCEL= ./powerpc/run powerpc/tm.elf -smp
> 2,threads=2 -mac
>>> So:
>>> - change the test when setting up a PACA to consider the actual value of
>>>the MSR rather than the CPU feature.
>>>
>>> - move the PACA setup to before the cpu feature parsing.
>>
>> Hmm. Problem is that equally we want PACA to be sane before we call too
>> far into the rest of
From: Juliet Kim
Date: Tue, 10 Mar 2020 09:23:58 -0500
> The ibmvnic driver does not check the device state when the device
> is removed. If the device is removed while a device reset is being
> processed, the remove may free structures needed by the reset,
> causing an oops.
>
> Fix this by che
The h_cede_tm kvm-unit-test currently fails when run inside an L1 guest
via the guest/nested hypervisor.
./run-tests.sh -v
...
TESTNAME=h_cede_tm TIMEOUT=90s ACCEL= ./powerpc/run powerpc/tm.elf -smp
2,threads=2 -machine cap-htm=on -append "h_cede_tm"
FAIL h_cede_tm (2 tests, 1 unexpected
Commit 0962e8004e97 ("powerpc/prom: Scan reserved-ranges node for
memory reservations") enabled support to parse reserved-ranges DT
node and reserve kernel memory falling in these ranges for F/W
purposes. Memory reserved for FADump should not overlap with these
ranges as it could corrupt memory mea
At times, memory ranges have to be looked up during early boot, when
kernel couldn't be initialized for dynamic memory allocation. In fact,
reserved-ranges look up is needed during FADump memory reservation.
Without accounting for reserved-ranges in reserving memory for FADump,
MPIPL boot fails wit
Em Mon, Mar 09, 2020 at 11:55:50AM +0530, Kajol Jain escreveu:
> Patch enhances current metric infrastructure to handle "?" in the metric
> expression. The "?" can be use for parameters whose value not known while
> creating metric events and which can be replace later at runtime to
> the proper va
On Tue, Mar 10, 2020 at 03:18:36PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Mon, Mar 09, 2020 at 10:35:06AM +0100, Jiri Olsa escreveu:
> > On Mon, Mar 09, 2020 at 11:55:44AM +0530, Kajol Jain wrote:
> > > First patch of the patchset fix inconsistent results we are getting when
> > > we run multi
On 3/10/20 10:25 AM, Nathan Lynch wrote:
> Tyrel Datwyler writes:
>> The expectation is that when calling of_read_drc_info_cell()
>> repeatedly to parse multiple drc-info records that the in/out curval
>> parameter points at the start of the next record on return. However,
>> the current behavior
Em Mon, Mar 09, 2020 at 10:35:06AM +0100, Jiri Olsa escreveu:
> On Mon, Mar 09, 2020 at 11:55:44AM +0530, Kajol Jain wrote:
> > First patch of the patchset fix inconsistent results we are getting when
> > we run multiple 24x7 events.
> >
> > Patchset adds json file metric support for the hv_24x7 s
On 3/10/20 4:09 PM, Greg Kurz wrote:
> On Fri, 6 Mar 2020 16:01:40 +0100
> Cédric Le Goater wrote:
>
>> When a CPU is brought up, an IPI number is allocated and recorded
>> under the XIVE CPU structure. Invalid IPI numbers are tracked with
>> interrupt number 0x0.
>>
>> On the PowerNV platform,
Reorder Linux PTE bits to (almost) match Hash PTE bits.
RW Kernel : PP = 00
RO Kernel : PP = 00
RW User : PP = 01
RO User : PP = 11
So naturally, we should have
_PAGE_USER = 0x001
_PAGE_RW = 0x002
Today 0x001 and 0x002 and _PAGE_PRESENT and _PAGE_HASHPTE which
both are software only bits.
Tyrel Datwyler writes:
> The expectation is that when calling of_read_drc_info_cell()
> repeatedly to parse multiple drc-info records that the in/out curval
> parameter points at the start of the next record on return. However,
> the current behavior has curval still pointing at the final value of
On Fri, 6 Mar 2020 16:01:41 +0100
Cédric Le Goater wrote:
> The PowerNV platform has multiple IRQ chips and the xmon command
> dumping the state of the XIVE interrupt should only operate on the
> XIVE IRQ chip.
>
> Fixes: 5896163f7f91 ("powerpc/xmon: Improve output of XIVE interrupts")
> Cc: st
On Fri, 6 Mar 2020 16:01:42 +0100
Cédric Le Goater wrote:
> Some firmwares or hypervisors can advertise different source
> characteristics. Track their value under XMON. What we are mostly
> interested in is the StoreEOI flag.
>
> Signed-off-by: Cédric Le Goater
> ---
Reviewed-by: Greg Kurz
On Fri, 6 Mar 2020 16:01:40 +0100
Cédric Le Goater wrote:
> When a CPU is brought up, an IPI number is allocated and recorded
> under the XIVE CPU structure. Invalid IPI numbers are tracked with
> interrupt number 0x0.
>
> On the PowerNV platform, the interrupt number space starts at 0x10 and
>
On Thu 27-02-20 19:26:54, Michal Hocko wrote:
> [Cc ppc maintainers]
[...]
> Please have a look at
> http://lkml.kernel.org/r/52ef4673-7292-4c4c-b459-af583951b...@linux.vnet.ibm.com
> for the boot log with the debugging patch which tracks set_numa_mem.
> This seems to lead to a crash in the slab a
The ibmvnic driver does not check the device state when the device
is removed. If the device is removed while a device reset is being
processed, the remove may free structures needed by the reset,
causing an oops.
Fix this by checking the device state before processing device remove.
Signed-off-b
https://bugzilla.kernel.org/show_bug.cgi?id=206669
--- Comment #10 from John Paul Adrian Glaubitz (glaub...@physik.fu-berlin.de)
---
(In reply to Aneesh Kumar KV from comment #9)
> Also, can you try disabling THP. echo "never" >
> /sys/kernel/mm/transparent_hugepage/enabled
Yes. Just disabled.
https://bugzilla.kernel.org/show_bug.cgi?id=206669
Aneesh Kumar KV (aneesh.ku...@linux.ibm.com) changed:
What|Removed |Added
CC||aneesh.ku..
Masahiro Yamada writes:
> On Fri, Mar 6, 2020 at 9:27 AM Michael Ellerman
> wrote:
>>
>> On Wed, 2020-02-19 at 00:04:34 UTC, Michael Ellerman wrote:
>> > Some of our phony targets are not marked as such. This can lead to
>> > confusing errors, eg:
>> >
>> > $ make clean
>> > $ touch install
>
Nicholas Piggin writes:
> Daniel Axtens's on March 6, 2020 5:30 pm:
>> kcov instrumentation is collected the __sanitizer_cov_trace_pc hook in
>> kernel/kcov.c. The compiler inserts these hooks into every basic block
>> unless kcov is disabled for that file.
>>
>> We then have a deep call-chain:
>
On Tue, Mar 03, 2020 at 01:50:46PM +0100, Wolfram Sang wrote:
> Commit af503716ac14 made sure OF devices get an OF style modalias with
> I2C events. It assumed all in-tree users were converted, yet it missed
> some Macintosh drivers.
>
> Add an OF module device table for all windfarm drivers to ma
Hello,
On 10.03.2020 06:44, Michael Ellerman wrote:
Christophe Leroy writes:
Le 07/03/2020 à 09:42, Christophe Leroy a écrit :
Le 06/03/2020 à 20:05, Nick Desaulniers a écrit :
As a heads up, our CI went red last night, seems like a panic from
free_initmem? Is this a known issue?
Thanks f
Wolfram Sang writes:
> On Tue, Mar 03, 2020 at 01:50:46PM +0100, Wolfram Sang wrote:
>> Commit af503716ac14 made sure OF devices get an OF style modalias with
>> I2C events. It assumed all in-tree users were converted, yet it missed
>> some Macintosh drivers.
>>
>> Add an OF module device table f
Wolfram Sang writes:
> Commit af503716ac14 made sure OF devices get an OF style modalias with
> I2C events. It assumed all in-tree users were converted, yet it missed
> some Macintosh drivers.
>
> Add an OF module device table for all windfarm drivers to make them
> automatically load again.
>
>
We have an embedded T1042 NXP CDC ethernet gadget which seems to completely
freeze when an
usb0 I/F is established and one do 1 of two things:
1) reboot the connected Linux laptop -> CDC gadget appears to enter complete
system freeze.
2) on laptop, ifconfig usb0 down; rmmod cdc_ether -> CDC gag
On Tue, Feb 25, 2020 at 03:26:13PM +0100, Wolfram Sang wrote:
> The comment had some flaws which are now fixed:
> - the prefix is 'MAC' not 'AAPL'
> - no kernel coding style and too short length
> - 'we do' instead of 'we to'
>
> Signed-off-by: Wolfram Sang
Applied to for-next, thanks!
signat
On Tue, Mar 03, 2020 at 01:50:46PM +0100, Wolfram Sang wrote:
> Commit af503716ac14 made sure OF devices get an OF style modalias with
> I2C events. It assumed all in-tree users were converted, yet it missed
> some Macintosh drivers.
>
> Add an OF module device table for all windfarm drivers to ma
41 matches
Mail list logo
