On Fri, May 22, 2020 at 02:35:23AM +0100, Al Viro wrote:
> On Fri, May 22, 2020 at 02:29:50AM +0100, Al Viro wrote:
> > On Thu, May 21, 2020 at 06:11:08PM -0700, Guenter Roeck wrote:
> >
> > > Mainline, with:
> > >
> > > qemu-system-sparc -M SS-4 -kernel arch/sparc/boot/zImage -no-reboot \
> > >
On Thu, May 21, 2020 at 11:39:38AM +0200, Peter Zijlstra wrote:
> On Thu, May 21, 2020 at 02:40:36AM +0200, Frederic Weisbecker wrote:
> > On Wed, May 20, 2020 at 02:50:56PM +0200, Peter Zijlstra wrote:
> > > On Tue, May 19, 2020 at 11:58:17PM -0400, Qian Cai wrote:
> > > > Just a head up.
On Fri, May 22, 2020 at 02:29:50AM +0100, Al Viro wrote:
> On Thu, May 21, 2020 at 06:11:08PM -0700, Guenter Roeck wrote:
>
> > Mainline, with:
> >
> > qemu-system-sparc -M SS-4 -kernel arch/sparc/boot/zImage -no-reboot \
> > -snapshot -drive file=rootfs.ext2,format=raw,if=scsi \
> >
On Thu, May 21, 2020 at 06:11:08PM -0700, Guenter Roeck wrote:
> Mainline, with:
>
> qemu-system-sparc -M SS-4 -kernel arch/sparc/boot/zImage -no-reboot \
> -snapshot -drive file=rootfs.ext2,format=raw,if=scsi \
> -append "panic=-1 slub_debug=FZPUA root=/dev/sda console=ttyS0"
>
On 5/21/20 5:46 PM, Al Viro wrote:
> On Thu, May 21, 2020 at 11:46:12PM +0100, Al Viro wrote:
>> On Thu, May 21, 2020 at 03:20:46PM -0700, Guenter Roeck wrote:
>>> On 5/21/20 10:27 AM, Al Viro wrote:
On Tue, May 19, 2020 at 09:54:22AM -0700, Guenter Roeck wrote:
> On Mon, May 18, 2020 at
On Thu, May 21, 2020 at 11:46:12PM +0100, Al Viro wrote:
> On Thu, May 21, 2020 at 03:20:46PM -0700, Guenter Roeck wrote:
> > On 5/21/20 10:27 AM, Al Viro wrote:
> > > On Tue, May 19, 2020 at 09:54:22AM -0700, Guenter Roeck wrote:
> > >> On Mon, May 18, 2020 at 11:48:43AM -0700,
On Wed, May 20, 2020 at 02:26:38PM -0400, Daniel Jordan wrote:
> Please review and test, and thanks to Alex, Andrew, Josh, and Pavel for
> their feedback in the last version.
I re-tested v2:
Tested-by: Josh Triplett
[0.231435] node 1 initialised, 24189223 pages in 32ms
[0.236718] node
On Wed, May 20, 2020 at 10:45:58PM +0530, Vaibhav Jain wrote:
...
> > On Wed, May 20, 2020 at 12:30:56AM +0530, Vaibhav Jain wrote:
...
> >> @@ -39,6 +78,15 @@ struct papr_scm_priv {
> >>struct resource res;
> >>struct nd_region *region;
> >>struct nd_interleave_set nd_set;
> >> +
>
On Thu, May 21, 2020 at 03:23:11PM -0700, Nick Desaulniers wrote:
> On Thu, May 21, 2020 at 6:00 AM Michael Ellerman wrote:
> >
> > Nathan Chancellor writes:
> > > On Tue, May 19, 2020 at 05:56:32PM -0700, 'Nick Desaulniers' via Clang
> > > Built Linux wrote:
> > >> Looks like our CI is still
On Thu, May 21, 2020 at 03:20:46PM -0700, Guenter Roeck wrote:
> On 5/21/20 10:27 AM, Al Viro wrote:
> > On Tue, May 19, 2020 at 09:54:22AM -0700, Guenter Roeck wrote:
> >> On Mon, May 18, 2020 at 11:48:43AM -0700, ira.we...@intel.com wrote:
> >>> From: Ira Weiny
> >>>
> >>> The kunmap_atomic
> On 5/21/20 10:42 AM, Ira Weiny wrote:
> > On Thu, May 21, 2020 at 09:05:41AM -0700, Guenter Roeck wrote:
> >> On 5/19/20 10:13 PM, Ira Weiny wrote:
> >>> On Tue, May 19, 2020 at 12:42:15PM -0700, Guenter Roeck wrote:
> On Tue, May 19, 2020 at 11:40:32AM -0700, Ira Weiny wrote:
> > On
On 5/21/20 10:42 AM, Ira Weiny wrote:
> On Thu, May 21, 2020 at 09:05:41AM -0700, Guenter Roeck wrote:
>> On 5/19/20 10:13 PM, Ira Weiny wrote:
>>> On Tue, May 19, 2020 at 12:42:15PM -0700, Guenter Roeck wrote:
On Tue, May 19, 2020 at 11:40:32AM -0700, Ira Weiny wrote:
> On Tue, May 19,
On 5/21/20 10:27 AM, Al Viro wrote:
> On Tue, May 19, 2020 at 09:54:22AM -0700, Guenter Roeck wrote:
>> On Mon, May 18, 2020 at 11:48:43AM -0700, ira.we...@intel.com wrote:
>>> From: Ira Weiny
>>>
>>> The kunmap_atomic clean up failed to remove one set of pagefault/preempt
>>> enables when vaddr
On Thu, May 21, 2020 at 09:46:35AM -0700, Alexander Duyck wrote:
> It is more about not bothering with the extra tracking. We don't
> really need it and having it doesn't really add much in the way of
> value.
Yeah, it can probably go.
> > > > @@ -1863,11 +1892,32 @@ static int __init
"Paul E. McKenney" writes:
> On Thu, May 21, 2020 at 02:51:24PM +1000, Stephen Rothwell wrote:
>> Hi all,
>>
>> On Tue, 19 May 2020 17:23:16 +1000 Stephen Rothwell
>> wrote:
>> >
>> > Today's linux-next merge of the rcu tree got a conflict in:
>> >
>> > arch/powerpc/kernel/traps.c
>> >
>>
On Thu, 21 May 2020, Dan Williams wrote:
> On Thu, May 21, 2020 at 10:03 AM Aneesh Kumar K.V
> wrote:
> >
> > > Moving on to the patch itself--Aneesh, have you audited other persistent
> > > memory users in the kernel? For example, drivers/md/dm-writecache.c does
> > > this:
> > >
> > >
On Thu, May 21, 2020 at 7:39 AM Jeff Moyer wrote:
>
> Dan Williams writes:
>
> >> But I agree with your concern that if we have older kernel/applications
> >> that continue to use `dcbf` on future hardware we will end up
> >> having issues w.r.t powerfail consistency. The plan is what you
On Thu, May 21, 2020 at 10:03 AM Aneesh Kumar K.V
wrote:
>
> On 5/21/20 8:08 PM, Jeff Moyer wrote:
> > Dan Williams writes:
> >
> >>> But I agree with your concern that if we have older kernel/applications
> >>> that continue to use `dcbf` on future hardware we will end up
> >>> having issues
On Thu, May 21, 2020 at 09:05:41AM -0700, Guenter Roeck wrote:
> On 5/19/20 10:13 PM, Ira Weiny wrote:
> > On Tue, May 19, 2020 at 12:42:15PM -0700, Guenter Roeck wrote:
> >> On Tue, May 19, 2020 at 11:40:32AM -0700, Ira Weiny wrote:
> >>> On Tue, May 19, 2020 at 09:54:22AM -0700, Guenter Roeck
On Tue, May 19, 2020 at 09:54:22AM -0700, Guenter Roeck wrote:
> On Mon, May 18, 2020 at 11:48:43AM -0700, ira.we...@intel.com wrote:
> > From: Ira Weiny
> >
> > The kunmap_atomic clean up failed to remove one set of pagefault/preempt
> > enables when vaddr is not in the fixmap.
> >
> > Fixes:
On Thu, May 21, 2020 at 11:43:40AM +1000, Alistair Popple wrote:
> Matrix multiple assist (MMA) is a new feature added to ISAv3.1 and
s/Matrix multiple assist/Matrix-Multiply Assist/
> POWER10. Support on powernv can be selected via a firmware CPU device
> tree feature which enables it via a PCR
On 5/21/20 8:08 PM, Jeff Moyer wrote:
Dan Williams writes:
But I agree with your concern that if we have older kernel/applications
that continue to use `dcbf` on future hardware we will end up
having issues w.r.t powerfail consistency. The plan is what you outlined
above as tighter ecosystem
Michael Ellerman writes:
> Vaibhav Jain writes:
>> Thanks for reviewing this this patch Ira. My responses below:
>> Ira Weiny writes:
>>> On Wed, May 20, 2020 at 12:30:56AM +0530, Vaibhav Jain wrote:
Implement support for fetching nvdimm health information via
H_SCM_HEALTH hcall as
From: Christophe Leroy
Let's reduce the number of registers used in TLB miss handlers.
We have both r9 and r12 available for any temporary use.
r9 is enough, avoid using r12.
Signed-off-by: Christophe Leroy
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/head_40x.S | 70
From: Christophe Leroy
This erratum is dedicated to IBM 405GP and STB03xxx
which are now gone.
Remove this erratum.
Signed-off-by: Christophe Leroy
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/asm-405.h | 19 ---
arch/powerpc/include/asm/atomic.h
From: Christophe Leroy
We have r12 available, use it to keep CR around and don't
save it in SPRN_SPRG_SCRATCH6.
Signed-off-by: Christophe Leroy
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/head_40x.S | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff
From: Christophe Leroy
EP405 is an old type of board based on a 405GP which is obsolete.
Remove it.
Signed-off-by: Christophe Leroy
---
v4: A few things from previous patch are now here as there are not related to
walnut
Signed-off-by: Christophe Leroy
---
arch/powerpc/boot/Makefile
From: Christophe Leroy
CONFIG_WALNUT is not selected by any config and is based
on 405GP which is obsolete.
Remove it.
Signed-off-by: Christophe Leroy
---
v4: Moved a few things related to EP405 to next patch
Signed-off-by: Christophe Leroy
Signed-off-by: Christophe Leroy
---
From: Christophe Leroy
CONFIG_STB03xxx is not user selectable and is not selected
by any config.
Remove it.
Signed-off-by: Christophe Leroy
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/cputable.c | 13 -
arch/powerpc/platforms/40x/Kconfig | 5 -
2 files
From: Christophe Leroy
This erratum was for IBM 403GCX, 405EP and STB03xxx which are
now gone.
Remove this erratum.
Signed-off-by: Christophe Leroy
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/head_40x.S | 6 --
arch/powerpc/platforms/40x/Kconfig | 4
2 files
From: Christophe Leroy
ISS4xx has support for 405GP which is obsolete.
Remote it.
Signed-off-by: Christophe Leroy
Signed-off-by: Christophe Leroy
---
arch/powerpc/platforms/44x/Kconfig | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/44x/Kconfig
From: Christophe Leroy
All platforms selecting the obsolete processor are gone now.
Remove support for it.
Signed-off-by: Christophe Leroy
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/cputable.c | 13 -
arch/powerpc/platforms/40x/Kconfig | 6 --
2 files
From: Michal Simek
The latest Xilinx design tools called ISE and EDK has been released in
October 2013. New tool doesn't support any PPC405/PPC440 new designs.
These platforms are no longer supported and tested.
PowerPC 405/440 port is orphan from 2013 by
commit cdeb89943bfc ("MAINTAINERS: Fix
From: Christophe Leroy
CONFIG_403GCX is not user selectable and is not
selected by any platform.
Remove it.
Signed-off-by: Christophe Leroy
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/cache.h | 2 +-
arch/powerpc/include/asm/reg_booke.h | 54
From: Christophe Leroy
Commit 1bc54c03117b ("powerpc: rework 4xx PTE access and TLB miss")
reworked 44x PTE access to avoid atomic pte updates, and
left 8xx, 40x and fsl booke with atomic pte updates.
Commit 6cfd8990e27d ("powerpc: rework FSL Book-E PTE access and TLB
miss") removed atomic pte
v1 and v2 of this series were aiming at removing 40x entirely,
but it led to protests.
v3 is trying to start modernising powerpc 40x:
- Rework TLB miss handlers to not use PTE_ATOMIC_UPDATES and _PAGE_HWWRITE
- Remove old versions of 40x processors, namely 403 and 405GP and associated
errata.
-
From: Christophe Leroy
40x was the last user of PTE_ATOMIC_UPDATES.
Drop everything related to PTE_ATOMIC_UPDATES.
Signed-off-by: Christophe Leroy
---
v5: Rebased on top of the 8xx hugepage series
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/nohash/32/pgtable.h | 15
On Thu, May 21, 2020 at 8:37 AM Daniel Jordan
wrote:
>
> On Wed, May 20, 2020 at 06:29:32PM -0700, Alexander Duyck wrote:
> > On Wed, May 20, 2020 at 11:27 AM Daniel Jordan
> > > @@ -1814,16 +1815,44 @@ deferred_init_maxorder(u64 *i, struct zone *zone,
> > > unsigned long *start_pfn,
> > >
On 5/19/20 10:13 PM, Ira Weiny wrote:
> On Tue, May 19, 2020 at 12:42:15PM -0700, Guenter Roeck wrote:
>> On Tue, May 19, 2020 at 11:40:32AM -0700, Ira Weiny wrote:
>>> On Tue, May 19, 2020 at 09:54:22AM -0700, Guenter Roeck wrote:
On Mon, May 18, 2020 at 11:48:43AM -0700, ira.we...@intel.com
On Thu, May 21, 2020 at 08:00:31AM -0700, Alexander Duyck wrote:
> So I was thinking about my suggestion further and the loop at the end
> isn't quite correct as I believe it could lead to gaps. The loop on
> the end should probably be:
> for_each_free_mem_pfn_range_in_zone_from(i,
On Wed, May 20, 2020 at 06:29:32PM -0700, Alexander Duyck wrote:
> On Wed, May 20, 2020 at 11:27 AM Daniel Jordan
> > @@ -1814,16 +1815,44 @@ deferred_init_maxorder(u64 *i, struct zone *zone,
> > unsigned long *start_pfn,
> > return nr_pages;
> > }
> >
> > +struct definit_args {
> > +
On Tue, May 19, 2020 at 12:42:15PM -0700, Guenter Roeck wrote:
> > On Tue, May 19, 2020 at 09:54:22AM -0700, Guenter Roeck wrote:
> > > as do the nosmp sparc32 boot tests,
> > > but sparc32 boot tests with SMP enabled still fail with lots of messages
> > > such as:
> > >
> > > BUG: Bad page state
On Wed, May 20, 2020 at 6:29 PM Alexander Duyck
wrote:
>
> On Wed, May 20, 2020 at 11:27 AM Daniel Jordan
> wrote:
> >
> > Deferred struct page init is a significant bottleneck in kernel boot.
> > Optimizing it maximizes availability for large-memory systems and allows
> > spinning up
On 21. 05. 20 15:53, Michael Ellerman wrote:
> Christophe Leroy writes:
>> Le 21/05/2020 à 09:02, Michael Ellerman a écrit :
>>> Arnd Bergmann writes:
+On Wed, Apr 8, 2020 at 2:04 PM Michael Ellerman
wrote:
> Benjamin Herrenschmidt writes:
>> On Fri, 2020-04-03 at 15:59
Dan Williams writes:
>> But I agree with your concern that if we have older kernel/applications
>> that continue to use `dcbf` on future hardware we will end up
>> having issues w.r.t powerfail consistency. The plan is what you outlined
>> above as tighter ecosystem control. Considering we don't
Vaibhav Jain writes:
> Thanks for reviewing this this patch Ira. My responses below:
> Ira Weiny writes:
>> On Wed, May 20, 2020 at 12:30:56AM +0530, Vaibhav Jain wrote:
>>> Implement support for fetching nvdimm health information via
>>> H_SCM_HEALTH hcall as documented in Ref[1]. The hcall
Christophe Leroy writes:
> Le 21/05/2020 à 09:02, Michael Ellerman a écrit :
>> Arnd Bergmann writes:
>>> +On Wed, Apr 8, 2020 at 2:04 PM Michael Ellerman
>>> wrote:
Benjamin Herrenschmidt writes:
> On Fri, 2020-04-03 at 15:59 +1100, Michael Ellerman wrote:
>> Benjamin
On Thu, May 21, 2020 at 02:51:24PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> On Tue, 19 May 2020 17:23:16 +1000 Stephen Rothwell
> wrote:
> >
> > Today's linux-next merge of the rcu tree got a conflict in:
> >
> > arch/powerpc/kernel/traps.c
> >
> > between commit:
> >
> >
Nathan Chancellor writes:
> On Tue, May 19, 2020 at 05:56:32PM -0700, 'Nick Desaulniers' via Clang Built
> Linux wrote:
>> Looks like our CI is still red from this:
>>
>> https://travis-ci.com/github/ClangBuiltLinux/continuous-integration/builds/166854584
>>
>> Filing a bug to follow up on:
>>
On Thu, May 21, 2020 at 01:00:27PM +0200, Peter Zijlstra wrote:
> On Thu, May 21, 2020 at 12:49:37PM +0200, Peter Zijlstra wrote:
> > On Thu, May 21, 2020 at 11:39:39AM +0200, Peter Zijlstra wrote:
> > > On Thu, May 21, 2020 at 02:40:36AM +0200, Frederic Weisbecker wrote:
> >
> > > This:
> > >
>
On Wed, May 20, 2020 at 8:38 PM Mark Brown wrote:
>
> On Wed, May 20, 2020 at 07:22:19PM +0800, Shengjiu Wang wrote:
>
> > I see some driver also request dma channel in open() or hw_params().
> > how can they avoid the defer probe issue?
> > for example：
> > sound/arm/pxa2xx-pcm-lib.c
> >
On Thu, May 21, 2020 at 12:49:37PM +0200, Peter Zijlstra wrote:
> On Thu, May 21, 2020 at 11:39:39AM +0200, Peter Zijlstra wrote:
> > On Thu, May 21, 2020 at 02:40:36AM +0200, Frederic Weisbecker wrote:
>
> > This:
> >
> > > smp_call_function_single_async() {
> > >
On Thu, May 21, 2020 at 11:39:39AM +0200, Peter Zijlstra wrote:
> On Thu, May 21, 2020 at 02:40:36AM +0200, Frederic Weisbecker wrote:
> This:
>
> > smp_call_function_single_async() {
> > smp_call_function_single_async() {
> > // verified csd->flags != CSD_LOCK
Le 21/05/2020 à 09:02, Michael Ellerman a écrit :
Arnd Bergmann writes:
+On Wed, Apr 8, 2020 at 2:04 PM Michael Ellerman wrote:
Benjamin Herrenschmidt writes:
On Fri, 2020-04-03 at 15:59 +1100, Michael Ellerman wrote:
Benjamin Herrenschmidt writes:
IBM still put 40x cores inside
On Thu, May 21, 2020 at 02:40:36AM +0200, Frederic Weisbecker wrote:
>atomic_fetch_or(,
> nohz_flags(0))
> softirq() {#VMEXIT or anything
> that could stop a CPU for a while
>
On Thu, May 21, 2020 at 02:40:36AM +0200, Frederic Weisbecker wrote:
> On Wed, May 20, 2020 at 02:50:56PM +0200, Peter Zijlstra wrote:
> > On Tue, May 19, 2020 at 11:58:17PM -0400, Qian Cai wrote:
> > > Just a head up. Repeatedly compiling kernels for a while would trigger
> > > endless
Dmitry Torokhov writes:
> Hi Michael,
>
> On Wed, May 20, 2020 at 04:07:00PM +1000, Michael Ellerman wrote:
>> [ + Dmitry & linux-input ]
>>
>> Nathan Chancellor writes:
>> > This causes a build error with CONFIG_WALNUT because kb_cs and kb_data
>> > were removed in commit 917f0af9e5a9
From: huhai
Signed-off-by: huhai
---
arch/powerpc/platforms/4xx/pci.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/4xx/pci.c b/arch/powerpc/platforms/4xx/pci.c
index e6e2adcc7b64..c13d64c3b019 100644
--- a/arch/powerpc/platforms/4xx/pci.c
+++
On 4/29/20 9:51 AM, Cédric Le Goater wrote:
> When a passthrough IO adapter is removed from a pseries machine using
> hash MMU and the XIVE interrupt mode, the POWER hypervisor, pHyp,
> expects the guest OS to have cleared all page table entries related to
> the adapter. If some are still present,
Arnd Bergmann writes:
> +On Wed, Apr 8, 2020 at 2:04 PM Michael Ellerman wrote:
>> Benjamin Herrenschmidt writes:
>> > On Fri, 2020-04-03 at 15:59 +1100, Michael Ellerman wrote:
>> >> Benjamin Herrenschmidt writes:
>> > IBM still put 40x cores inside POWER chips no ?
>>
>> Oh yeah that's true.
Ira Weiny writes:
> On Wed, May 20, 2020 at 12:30:57AM +0530, Vaibhav Jain wrote:
>> Introduce support for Papr nvDimm Specific Methods (PDSM) in papr_scm
>> modules and add the command family to the white list of NVDIMM command
>> sets. Also advertise support for ND_CMD_CALL for the dimm
>>
On Wed, May 20, 2020 at 07:43:08PM +0200, Laurent Dufour wrote:
> The commit 8c47b6ff29e3 ("KVM: PPC: Book3S HV: Check caller of H_SVM_*
> Hcalls") added checks of secure bit of SRR1 to filter out the Hcall
> reserved to the Ultravisor.
>
> However, the Hcall H_SVM_INIT_ABORT is made by the
62 matches
Mail list logo
