Hi Randy,
On Tue, Nov 6, 2018 at 2:06 AM Randy Dunlap wrote:
> On 11/5/18 2:12 PM, Geert Uytterhoeven wrote:
> > On Mon, Nov 5, 2018 at 11:07 PM Geert Uytterhoeven
> > wrote:
> >> Below is the list of build error/warning regressions/improvements in
> >> v4.20-rc1[1] compared to v4.19[2].
> >>
>
The code for assert_slb_exists() and assert_slb_notexists() is almost
identical, except for the polarity of the WARN_ON(). In a future patch
we'll need to modify this code, so consolidate it now into a single
function.
Signed-off-by: Michael Ellerman
---
arch/powerpc/mm/slb.c | 29 +-
Old toolchains don't know about slbfee and break the build, eg:
{standard input}:37: Error: Unrecognized opcode: `slbfee.'
Fix it by using the macro version. We need to add an underscore
version that takes raw register numbers from the inline asm, rather
than our Rx macros.
Fixes: e15a4fea4dee
The slbfee instruction was only added in ISA 2.05 (Power6), it's not
supported on older CPUs. We don't have a CPU feature for that ISA
version though, so just use the ISA 2.06 feature flag.
Fixes: e15a4fea4dee ("powerpc/64s/hash: Add some SLB debugging tests")
Signed-off-by: Michael Ellerman
---
This patchset for the hardware transactional memory (TM) subsystem
aims to avoid spending a lot of time on TM suspended mode in kernel
space. It basically changes where the reclaim/recheckpoint will be
executed.
The hardware is designed so once a CPU enters in transactional state it
uses a footp
This patch creates a macro that will be invoked on all entrance to the
kernel, so, in kernel space the transaction will be completely reclaimed
and not suspended anymore.
This patchset checks if we are coming from PR, if not, skip. This is useful
when there is a irq_replay() being called after rec
If there is a FP/VEC/Altivec touch inside a transaction and the facility is
disabled, then a facility unavailable exception is raised and ends up
calling {fp,vec,vsx}_unavailable_tm, which was reclaiming and
recheckpointing.
This is not required anymore, since the checkpointed state was reclaimed
This is the only place we are going to recheckpoint now. Now the task
needs to have TIF_RESTORE_TM flag set, which will get into
restore_tm_state() at exception exit path, and execute the recheckpoint
depending on the MSR.
Every time a task is required to recheckpoint, or just have the TM SPRs
res
If the task data was reclaimed (through TM_KERNEL_ENTRY), then it needs to
be recheckpointed later, once exiting to userspace. The recheckpoint is
done by restore_tm_state() function, which is called on our way to
userspace if the task has the TIF_RESTORE_TM flag set.
This patch makes sure the tas
Do not recheckpoint at signal code return. Just make sure TIF_RESTORE_TM is
set, which will restore on the exit to userspace by restore_tm_state.
All the FP and VEC lazy restore was already done by tm_reclaim_current(),
where it checked if FP/VEC was set, and filled out the ckfp and ckvr
registers
__switch_to_tm is the function that switches between two tasks which might
have TM enabled. This function is clearly split in two parts, the task that
is leaving the CPU, known as 'prev' and the task that is being scheduled,
known as 'new'.
It starts checking if the previous task had TM enable, if
Make sure that we are not suspended on ptrace and that the registers were
already reclaimed.
Since the data was already reclaimed, there is nothing to be done here
except to restore the SPRs.
Signed-off-by: Breno Leitao
---
arch/powerpc/kernel/ptrace.c | 16 +---
1 file changed, 13
In the past, TIF_RESTORE_TM was being handled with the rest of the TIF workers,
but, that was too early, and can cause some IRQ to be replayed in suspended
state (after recheckpoint).
This patch moves TIF_RESTORE_TM handler to as late as possible, it also
forces the IRQ to be disabled, and it will
Since every kernel entrance is calling TM_KERNEL_ENTRY, it is not
expected to arrive at this point with a suspended transaction.
If that is the case, cause a warning and reclaim the current thread in
order to avoid a TM Bad Thing.
Signed-off-by: Breno Leitao
---
arch/powerpc/kernel/process.c |
Add some debug information into the TM subsystem. When enable, now it
prints when there is a reclaim, recheckpoint or lazy TM disabling.
Signed-off-by: Breno Leitao
---
arch/powerpc/kernel/process.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel
As other exit points, move SRR1 (MSR) into paca->tm_scratch, so, if
there is a TM Bad Thing in RFID, it is easy to understand what was the
SRR1 value being used.
Signed-off-by: Breno Leitao
---
arch/powerpc/kernel/entry_64.S | 4
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/ke
In the previous TM code, trecheckpoint was being executed in the middle of
an exception, thus, SPRs were being restored to default kernel SPRs (as
DSCR) value after trecheckpoint was done.
With this current patchset, trecheckpoint is executed just before getting
to userspace, at ret_from_except_li
Currently the signal context restore code enables the bit on the MSR
register without restoring the TM SPRs, which can cause undesired side
effects.
This is not correct because if TM is enabled in MSR, it means the TM SPR
registers are valid and updated, which is not correct here. In fact, the
liv
The Documentation/powerpc/transactional_memory.txt says:
"Syscalls made from within a suspended transaction are performed as normal
and the transaction is not explicitly doomed by the kernel. However,
what the kernel does to perform the syscall may result in the transaction
being doomed by
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
Signed-off-by: Yangtao Li
---
arch/powerpc/platforms/powernv/vas-debug.c | 28 --
1 file changed, 4 insertions(+), 24 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/vas-debug.c
b/arch/powerpc/platforms/powernv/
When compiled for 64-bit, the PD_HUGE constant is a 64-bit integer.
Mark it as an unsigned long.
This squashes over a thousand sparse warnings on my minimal T4240RDB
(e6500, ppc64be) config, of the following 2 forms:
arch/powerpc/include/asm/hugetlb.h:52:49: warning: constant 0x8000
Hi Pierre,
On Tue, Nov 6, 2018 at 3:56 PM Pierre-Louis Bossart
wrote:
>
> *** ERRORS ***
>
> + /kisskb/src/sound/pci/hda/patch_ca0132.c: error: implicit
> declaration of function 'pci_iomap'
> [-Werror=implicit-function-declaration]: => 8799:3
> >>> sh4-all{mod
On Tue, 06 Nov 2018 02:04:47 +0100,
Randy Dunlap wrote:
>
> On 11/5/18 2:12 PM, Geert Uytterhoeven wrote:
> > On Mon, Nov 5, 2018 at 11:07 PM Geert Uytterhoeven
> > wrote:
> >> Below is the list of build error/warning regressions/improvements in
> >> v4.20-rc1[1] compared to v4.19[2].
> >>
> >>
On Tue, Nov 06, 2018 at 08:56:39AM -0600, Pierre-Louis Bossart wrote:
> > However, looking at what else can enable SND_HDA, I think it should be
> > select SND_SOC_HDAC_HDA if SND_PCI || ARCH_TEGRA
> This codec can only be used by the Skylake driver (and the upcoming SOF
> one). For Tegra t
* Breno Leitao:
> This patchset for the hardware transactional memory (TM) subsystem
> aims to avoid spending a lot of time on TM suspended mode in kernel
> space. It basically changes where the reclaim/recheckpoint will be
> executed.
I assumed that we want to abort on every system call these
hi Florian,
On 11/06/2018 04:32 PM, Florian Weimer wrote:
> * Breno Leitao:
>
>> This patchset for the hardware transactional memory (TM) subsystem
>> aims to avoid spending a lot of time on TM suspended mode in kernel
>> space. It basically changes where the reclaim/recheckpoint will be
>> exe
On 11/5/2018 11:52 PM, Laurent Dufour wrote:
> Le 05/11/2018 à 08:04, vinayak menon a écrit :
>> Hi Laurent,
>>
>> On Thu, May 17, 2018 at 4:37 PM Laurent Dufour
>> wrote:
>>>
>>> The VMA sequence count has been introduced to allow fast detection of
>>> VMA modification when running a page fault h
*** ERRORS ***
+ /kisskb/src/sound/pci/hda/patch_ca0132.c: error: implicit declaration of
function 'pci_iomap' [-Werror=implicit-function-declaration]: => 8799:3
sh4-all{mod,yes}config
Looks like d9b84a15892c0233 ("ALSA: hda: Fix implicit definition of
pci_iomap() on SH")
is not suffic
On Tue, 6 Nov 2018 23:37:09 +1100
Michael Ellerman wrote:
> The slbfee instruction was only added in ISA 2.05 (Power6), it's not
> supported on older CPUs. We don't have a CPU feature for that ISA
> version though, so just use the ISA 2.06 feature flag.
>
> Fixes: e15a4fea4dee ("powerpc/64s/has
> In fact, I was the one that identified this performance degradation issue,
> and reported to Adhemerval who kindly fixed it with
> f0458cf4f9ff3d870c43b624e6dccaaf657d5e83.
>
> Anyway, I think we are safe here.
FWIW Agreed. PPC_FEATURE2_HTM_NOSC should be persevered by this series.
Mikey
Mike Snitzer writes:
> On Mon, Nov 05 2018 at 5:25am -0500,
> Michael Ellerman wrote:
>
>> Linus Torvalds writes:
>> ...
>> > Mike Snitzer (1):
>> > device mapper updates
>>
>> Hi Mike,
>>
>> Replying here because I can't find the device-mapper pull or the patch
>> in question on LKML. I
This series was originally part of the series ("serial: Finish kgdb on
qcom_geni; fix many lockdep splats w/ kgdb") but it made sense to
split it up.
It's believed that dropping into kgdb should be more robust once these
patches are applied.
Changes in v3:
- No separate init call.
- Don't round u
The function kgdb_roundup_cpus() was passed a parameter that was
documented as:
> the flags that will be used when restoring the interrupts. There is
> local_irq_save() call before kgdb_roundup_cpus().
Nobody used those flags. Anyone who wanted to temporarily turn on
interrupts just did local_ir
When I had lockdep turned on and dropped into kgdb I got a nice splat
on my system. Specifically it hit:
DEBUG_LOCKS_WARN_ON(current->hardirq_context)
Specifically it looked like this:
sysrq: SysRq : DEBUG
[ cut here ]
DEBUG_LOCKS_WARN_ON(current->hardirq_context)
Hi,
On Sat, Nov 3, 2018 at 3:45 AM Daniel Thompson
wrote:
>
> On Wed, Oct 31, 2018 at 02:41:14PM -0700, Doug Anderson wrote:
> > > As mentioned in another part of the thread we can also add robustness
> > > by skipping a cpu where csd->flags != 0 (and adding an appropriately
> > > large comment r
TRACE_INCLUDE_PATH and TRACE_INCLUDE_FILE are used by
, so like that #include, they should
be outside #ifdef protection.
They also need to be #undefed before defining, in case multiple trace
headers are included by the same C file. This became the case on
book3e after commit cf4a6085151a ("powerp
On Sun, 2018-10-28 at 17:35 +0100, Christian Zigotzky wrote:
> Hello,
>
> SMP doesn't work anymore with the latest Git kernel (28/10/18 11:12AM
> GMT) on my P5020 board and on virtual e5500 QEMU machines.
>
> Board with P5020 dual core CPU:
>
> [0.00] ---
On Mon, Oct 15, 2018 at 08:32:57PM +1100, Alexey Kardashevskiy wrote:
> This step is to help removing the npu struct from pnv_phb so it
> can be used by pseries as well.
>
> Signed-off-by: Alexey Kardashevskiy
Reviewed-by: David Gibson
> ---
> arch/powerpc/platforms/powernv/npu-dma.c | 20 +++
On Mon, Oct 15, 2018 at 08:32:58PM +1100, Alexey Kardashevskiy wrote:
> We are going to add a global list of NPUs in the system which is going
> to be yet another static symbol. Let's reorganise the code and put all
> static symbols into one struct for better tracking what is really needed
> for NP
On Mon, Oct 15, 2018 at 08:32:59PM +1100, Alexey Kardashevskiy wrote:
> The powernv PCI code stores NPU data in the pnv_phb struct. The latter
> is referenced by pci_controller::private_data. We are going to have NPU2
> support in the pseries platform as well but it does not store any
> private_dat
Back in 2006 Ben added some workarounds for a misbehaviour in the
Spider IO bridge used on early Cell machines, see commit
014da7ff47b5 ("[POWERPC] Cell "Spider" MMIO workarounds"). Later these
were made to be generic, ie. not tied specifically to Spider.
The code stashes a token in the high bits
On 07 November 2018 at 03:11AM, Scott Wood wrote:
On Sun, 2018-10-28 at 17:35 +0100, Christian Zigotzky wrote:
Hello,
SMP doesn't work anymore with the latest Git kernel (28/10/18 11:12AM
GMT) on my P5020 board and on virtual e5500 QEMU machines.
Board with P5020 dual core CPU:
[0.00]
42 matches
Mail list logo
