On Wed, Dec 11, 2019 at 12:43:37PM +1100, Daniel Axtens wrote:
> If a process page-faults trying to write beyond the end of its
> stack, we attempt to grow the stack.
>
> However, if the kernel attempts to write beyond the end of a
> process's stack, it takes a bad fault. This can occur when the
On Wed, Nov 27, 2019 at 06:41:09AM +0100, Christophe Leroy wrote:
>
>
> Le 26/11/2019 à 21:13, Michal Suchanek a écrit :
> > Since commit ed1cd6deb013 ("powerpc: Activate CONFIG_THREAD_INFO_IN_TASK")
> > current_is_64bit() is quivalent to !is_32bit_task().
> > Remove the redundant function.
> >
On Sat, Nov 16, 2019 at 08:07:29PM +0530, Sourabh Jain wrote:
>
>
> On 11/9/19 6:29 PM, Michal Suchánek wrote:
> > On Sat, Nov 09, 2019 at 05:53:37PM +0530, Sourabh Jain wrote:
> >> As the number of FADump sysfs files increases it is hard to manage all of
> >>
On Fri, Nov 15, 2019 at 09:44:34AM +0100, Michal Suchánek wrote:
> On Fri, Nov 15, 2019 at 03:43:24PM +1100, Michael Ellerman wrote:
> > Michal Suchánek writes:
> > > On Thu, Nov 14, 2019 at 05:46:55PM +0100, Michal Suchánek wrote:
> > >> Hello,
> > >>
On Thu, Nov 14, 2019 at 05:46:55PM +0100, Michal Suchánek wrote:
> Hello,
>
> on powernv with 5.3.8 kernel I get flood of messages on boot.
>
> The messages match WARN_ONCE(1, "opal: OPAL_CONSOLE_FLUSH missing.\n");
Asking around it was pointed out that WARN_ONCE
Hello,
on powernv with 5.3.8 kernel I get flood of messages on boot.
The messages match WARN_ONCE(1, "opal: OPAL_CONSOLE_FLUSH missing.\n");
[ cut here ]
opal: OPAL_CONSOLE_FLUSH missing.
WARNING: CPU: 0 PID: 0 at ../arch/powerpc/platforms/powernv/opal.c:435
On Thu, Nov 14, 2019 at 08:07:35PM +1100, Michael Ellerman wrote:
> On Thu, 2019-05-02 at 21:09:07 UTC, Gustavo Walbon wrote:
> > From: "Gustavo L. F. Walbon"
> >
> > The issue was showing "Mitigation" message via sysfs whatever the state of
> > "RFI Flush", but it should show "Vulnerable" when
On Wed, Nov 13, 2019 at 01:02:34PM +1000, Nicholas Piggin wrote:
> Michal Suchanek's on November 13, 2019 2:52 am:
> > There are numerous references to 32bit functions in generic and 64bit
> > code so ifdef them out.
> >
> > Signed-off-by: Michal Suchanek
>
> For the most part these seem okay
On Sat, Nov 09, 2019 at 05:53:37PM +0530, Sourabh Jain wrote:
> As the number of FADump sysfs files increases it is hard to manage all of
> them inside /sys/kernel directory. It's better to have all the FADump
> related sysfs files in a dedicated directory /sys/kernel/fadump. But in
> order to
On Thu, Oct 24, 2019 at 01:16:51PM +0200, Michal Suchánek wrote:
> On Thu, Oct 24, 2019 at 04:08:08PM +0530, Hari Bathini wrote:
> >
> > Michal, thanks for looking into this.
> >
> > On 23/10/19 11:26 PM, Michal Suchanek wrote:
> > > There is duplicate messa
Hello,
On Wed, Oct 02, 2019 at 01:13:52PM +1000, Nicholas Piggin wrote:
> Michal Suchánek's on September 24, 2019 7:33 pm:
> > Hello,
> >
> > can you mark the individual patches with RFC rather than the wole
> > series?
>
> Hey, thanks for the reviews. I'll resend all but the last two patches
>
On Thu, Oct 24, 2019 at 04:08:08PM +0530, Hari Bathini wrote:
>
> Michal, thanks for looking into this.
>
> On 23/10/19 11:26 PM, Michal Suchanek wrote:
> > There is duplicate message about lack of support by firmware in
> > fadump_reserve_mem and setup_fadump. Due to different capitalization it
On Sun, Sep 15, 2019 at 11:28:09AM +1000, Nicholas Piggin wrote:
> System call entry and particularly exit code is beyond the limit of what
> is reasonable to implement in asm.
>
> This conversion moves all conditional branches out of the asm code,
> except for the case that all GPRs should be
On Sun, Sep 15, 2019 at 11:28:13AM +1000, Nicholas Piggin wrote:
> Add support for the scv instruction on POWER9 and later CPUs.
>
> For now this implements the zeroth scv vector 'scv 0', as identical
> to 'sc' system calls, with the exception that lr is not preserved, and
> it is 64-bit only.
On Sun, Sep 15, 2019 at 11:28:10AM +1000, Nicholas Piggin wrote:
> Implement the bulk of interrupt return logic in C. The asm return code
> must handle a few cases: restoring full GPRs, and emulating stack store.
>
> The asm return code is moved into 64e for now. The new logic has made
>
Hello,
can you mark the individual patches with RFC rather than the wole
series?
Thanks
Michal
On Sun, Sep 15, 2019 at 11:27:46AM +1000, Nicholas Piggin wrote:
> My interrupt entry patches have finally collided with syscall and
> interrupt exit patches, so I'll merge the series. Most patches
On Tue, 03 Sep 2019 10:00:57 +1000
Michael Ellerman wrote:
> Michal Suchánek writes:
> > On Mon, 02 Sep 2019 12:03:12 +1000
> > Michael Ellerman wrote:
> >
> >> Michal Suchanek writes:
> >> > On bigendian ppc64 it is common to have 32b
On Thu, 12 Sep 2019 21:36:11 +0200
Christophe Leroy wrote:
> Le 12/09/2019 à 20:26, Michal Suchánek a écrit :
> > On Thu, 12 Sep 2019 20:02:16 +0200
> > Christophe Leroy wrote:
> >
> >> Le 12/09/2019 à 19:26, Michal Suchanek a écrit :
> >>> There
On Thu, 12 Sep 2019 20:02:16 +0200
Christophe Leroy wrote:
> Le 12/09/2019 à 19:26, Michal Suchanek a écrit :
> > There are numerous references to 32bit functions in generic and 64bit
> > code so ifdef them out.
> >
> > Signed-off-by: Michal Suchanek
> > ---
> > v2:
> > - fix 32bit ifdef
On Thu, 5 Sep 2019 15:25:31 +
Christophe Leroy wrote:
> On 09/05/2019 12:35 PM, Nicholas Piggin wrote:
> > System call entry and particularly exit code is beyond the limit of what
> > is reasonable to implement in asm.
> >
> > This conversion moves all conditional branches out of the asm
On Thu, 29 Aug 2019 10:58:16 +0530
Hari Bathini wrote:
> On 28/08/19 10:57 PM, Michal Suchanek wrote:
> > Currently it is not possible to distinguish the case when fadump is
> > supported by firmware and disabled in kernel and completely unsupported
> > using the kernel sysfs interface. User can
On Mon, 02 Sep 2019 12:03:12 +1000
Michael Ellerman wrote:
> Michal Suchanek writes:
> > On bigendian ppc64 it is common to have 32bit legacy binaries but much
> > less so on littleendian.
>
> I think the toolchain people will tell you that there is no 32-bit
> little endian ABI defined at
On Mon, 02 Sep 2019 14:01:17 +1000
Michael Ellerman wrote:
> Michael Ellerman writes:
> > Michal Suchanek writes:
> ...
> >> @@ -295,6 +279,12 @@ static inline int current_is_64bit(void)
> >> }
> >>
> >> #else /* CONFIG_PPC64 */
> >> +static int read_user_stack_slow(void __user *ptr,
On Fri, 30 Aug 2019 23:03:43 +0200
Michal Suchanek wrote:
> Building callchain.c with !COMPAT proved quite ugly with all the
> defines. Splitting out the 32bit and 64bit parts looks better.
>
> No code change intended.
valid_user_sp is broken in compat. It needs to be ifdefed for the 32bit
On Sat, 31 Aug 2019 08:41:58 +0200
Christophe Leroy wrote:
> Le 30/08/2019 à 23:03, Michal Suchanek a écrit :
> > Less code means less bugs so add a knob to skip the compat stuff.
>
> I guess on PPC64 you have Gigabytes of memory and thousands of bogomips,
> hence you focus on bugs.
>
> My
On Fri, 30 Aug 2019 23:03:41 +0200
Michal Suchanek wrote:
> There are numerous references to 32bit functions in generic and 64bit
> code so ifdef them out.
>
> Signed-off-by: Michal Suchanek
> ---
> v2:
> - fix 32bit ifdef condition in signal.c
> - simplify the compat ifdef condition in vdso.c
On Fri, 30 Aug 2019 22:21:09 +0200
Christophe Leroy wrote:
> Le 30/08/2019 à 20:57, Michal Suchanek a écrit :
> > There are numerous references to 32bit functions in generic and 64bit
> > code so ifdef them out.
> >
> > Signed-off-by: Michal Suchanek
> > ---
> > v2:
> > - fix 32bit ifdef
On Fri, 30 Aug 2019 21:54:43 +0200
Arnd Bergmann wrote:
> On Fri, Aug 30, 2019 at 9:46 PM Michal Suchanek wrote:
> >
> > This reverts commit caf6f9c8a326cffd1d4b3ff3f1cfba75d159d70b.
> >
> > Maybe it was needed after all.
> >
> > When CONFIG_COMPAT is disabled on ppc64 the kernel does not
On Sat, 31 Aug 2019 02:48:26 +0800
kbuild test robot wrote:
> Hi Nicholas,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on linus/master]
> [cannot apply to v5.3-rc6 next-20190830]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help
On Fri, 30 Aug 2019 20:57:57 +0200
Michal Suchanek wrote:
> Building callchain.c with !COMPAT proved quite ugly with all the
> defines. Splitting out the 32bit and 64bit parts looks better.
>
BTW the powerpc callchain.c does not match any of the patterns of PERF
CORE in MAINTAINERS (unlike
On Fri, 30 Aug 2019 06:35:13 + (UTC)
Christophe Leroy wrote:
> On 08/29/2019 10:28 PM, Michal Suchanek wrote:
> > There are numerous references to 32bit functions in generic and 64bit
> > code so ifdef them out.
> >
> > Signed-off-by: Michal Suchanek
> > ---
> > v2:
> > - fix 32bit ifdef
On Fri, 30 Aug 2019 08:42:25 +0200
Michal Suchánek wrote:
> On Fri, 30 Aug 2019 06:35:11 + (UTC)
> Christophe Leroy wrote:
>
> > On 08/29/2019 10:28 PM, Michal Suchanek wrote:
> > obj-$(CONFIG_PPC_PERF_CTRS)+= core-book3s.o bhrb.o
> > diff --git a/arc
On Fri, 30 Aug 2019 06:35:11 + (UTC)
Christophe Leroy wrote:
> On 08/29/2019 10:28 PM, Michal Suchanek wrote:
> > Building callchain.c with !COMPAT proved quite ugly with all the
> > defines. Splitting out the 32bit and 64bit parts looks better.
> >
> > Also rewrite current_is_64bit as
On Thu, 29 Aug 2019 15:34:08 -0500
Uma Krishnan wrote:
> Below commit queued up for 5.4 includes these changes.
>
> commit 657bd277c162580674ddb86a90c4aeb62639bff5
> Author: Gustavo A. R. Silva
> Date: Sun Jul 28 19:21:19 2019 -0500
>
> Thanks,
> Uma Krishnan
Works for me as well.
Thanks
On Thu, 29 Aug 2019 16:32:50 +0200
Arnd Bergmann wrote:
> On Thu, Aug 29, 2019 at 4:19 PM Michal Suchánek wrote:
> > On Thu, 29 Aug 2019 14:57:39 +0200 Arnd Bergmann wrote:
> > > On Thu, Aug 29, 2019 at 2:37 PM Michal Suchánek
> > > wrote:
> > > >
On Thu, 29 Aug 2019 19:40:55 +0200
Christophe Leroy wrote:
> Le 29/08/2019 à 12:23, Michal Suchanek a écrit :
> > There are numerous references to 32bit functions in generic and 64bit
> > code so ifdef them out.
> >
> > Signed-off-by: Michal Suchanek
> > ---
> > v2:
> > - fix 32bit ifdef
On Thu, 29 Aug 2019 14:57:39 +0200
Arnd Bergmann wrote:
> On Thu, Aug 29, 2019 at 2:37 PM Michal Suchánek wrote:
> > On Thu, 29 Aug 2019 14:19:46 +0200 Arnd Bergmann wrote:
> > > On Thu, Aug 29, 2019 at 12:23 PM Michal Suchanek
> > > wrote:
> > > In pa
On Thu, 29 Aug 2019 14:19:46 +0200
Arnd Bergmann wrote:
> On Thu, Aug 29, 2019 at 12:23 PM Michal Suchanek wrote:
> >
> > Fixes: aff850393200 ("powerpc: add system call table generation support")
>
> This patch needs a proper explanation. The Fixes tag doesn't seem right
> here, since ppc64
On Thu, 29 Aug 2019 12:23:42 +0200
Michal Suchanek wrote:
> There are numerous references to 32bit functions in generic and 64bit
> code so ifdef them out.
>
> Signed-off-by: Michal Suchanek
> ---
> v2:
> - fix 32bit ifdef condition in signal.c
> - simplify the compat ifdef condition in vdso.c
On Wed, 28 Aug 2019 23:22:00 -0700
Christoph Hellwig wrote:
> On Wed, Aug 28, 2019 at 06:15:40PM +0200, Michal Suchánek wrote:
> > On Wed, 28 Aug 2019 08:15:52 -0700
> > Christoph Hellwig wrote:
> >
> > > On Tue, Aug 27, 2019 at 10:21:06PM +0200, Michal S
On Wed, 28 Aug 2019 23:46:24 -0700
Christoph Hellwig wrote:
> On Wed, Aug 28, 2019 at 06:43:50PM +0200, Michal Suchanek wrote:
> > +ifdef CONFIG_COMPAT
> > +obj-y += sys_ppc32.o ptrace32.o signal_32.o
> > +endif
>
> This should be:
>
> obj-$(CONFIG_COMPAT)
On Tue, 27 Aug 2019 17:57:31 +0530
Hari Bathini wrote:
> Hi Michal,
>
> Thanks for the patch.
>
> On 20/08/19 11:42 PM, Michal Suchanek wrote:
> > Currently it is not possible to distinguish the case when fadump is
> > supported by firmware and disabled in kernel and completely unsupported
>
On Wed, 28 Aug 2019 08:15:52 -0700
Christoph Hellwig wrote:
> On Tue, Aug 27, 2019 at 10:21:06PM +0200, Michal Suchanek wrote:
> > 64bit !COMPAT does not build because the llseek syscall is in the tables.
>
> Well, this will bloat thinkgs like 64-bit RISC-V for no good reason.
> Please
On Tue, 27 Aug 2019 23:55:48 +1000
Nicholas Piggin wrote:
> System call entry and particularly exit code is beyond the limit of what
> is reasonable to implement in asm.
>
> This conversion moves all conditional branches out of the asm code,
> except for the case that all GPRs should be
On Wed, 28 Aug 2019 20:57:48 +1000
Nicholas Piggin wrote:
> Michal Suchanek's on August 28, 2019 8:30 pm:
> > With endian switch disabled by default the ppc64le compat supports
> > ppc32le only which is something next to nobody has binaries for.
> >
> > Less code means less bugs so drop the
On Wed, 28 Aug 2019 13:08:48 +
Christophe Leroy wrote:
> On 08/28/2019 10:30 AM, Michal Suchanek wrote:
> > With endian switch disabled by default the ppc64le compat supports
> > ppc32le only which is something next to nobody has binaries for.
> >
> > Less code means less bugs so drop the
On Wed, 28 Aug 2019 14:49:16 +0200
Christophe Leroy wrote:
> Le 28/08/2019 à 12:30, Michal Suchanek a écrit :
> > There are numerous references to 32bit functions in generic and 64bit
> > code so ifdef them out.
>
> As far as possible, avoid opting things out with ifdefs. Ref
>
On Tue, 27 Aug 2019 22:21:08 +0200
Michal Suchanek wrote:
> There are numerous references to 32bit functions in generic and 64bit
> code so ifdef them out.
>
> Signed-off-by: Michal Suchanek
> ---
> arch/powerpc/include/asm/syscall.h | 2 ++
> arch/powerpc/kernel/Makefile | 15
On Wed, 6 Mar 2019 12:10:38 +1100
Suraj Jitindar Singh wrote:
> Commit ddf35cf3764b ("powerpc: Use barrier_nospec in copy_from_user()")
> Added barrier_nospec before loading from user-controller pointers.
> The intention was to order the load from the potentially user-controlled
> pointer vs a
On Wed, 24 Jul 2019 11:08:58 +0200
Laurent Dufour wrote:
> Le 23/07/2019 à 18:13, Vaibhav Jain a écrit :
> > This doc patch provides an initial description of the HCall op-codes
> > that are used by Linux kernel running as a guest operating
> > system (LPAR) on top of PowerVM or any other sPAPR
On Fri, 28 Jun 2019 00:51:19 +0530
Hari Bathini wrote:
> Currently, if memory_limit is specified and it overlaps with memory to
> be reserved for capture kernel, memory_limit is adjusted to accommodate
> capture kernel. With memory reservation for capture kernel moved later
> (after enforcing
t size of unknown algorithms with
> > > PCR read")
> > > Reported-by: Michal Suchanek
> > > Signed-off-by: Nayna Jain
> > > Reviewed-by: Mimi Zohar
> > > Tested-by: Sachin Sant
> > > Tested-by: Michal Suchánek
> >
> > Reviewed-by: Jarkko Sakkinen
>
> Thanks a lot! It is applied now.
Fixes the issue for me.
Thanks
Michal
On Fri, 05 Jul 2019 13:42:18 +0300
Jarkko Sakkinen wrote:
> On Wed, 2019-07-03 at 23:32 -0400, Nayna Jain wrote:
> > The nr_allocated_banks and allocated banks are initialized as part of
> > tpm_chip_register. Currently, this is done as part of auto startup
> > function. However, some drivers,
thms with
> >> PCR read")
> >> Signed-off-by: Nayna Jain
> > Reviewed-by: Mimi Zohar
>
> Thanks for the fix. Kernel boots fine with this fix.
>
> Tested-by: Sachin Sant
>
Tested-by: Michal Suchánek
Thanks
Michal
On Wed, 3 Jul 2019 13:17:16 +0200
Michal Suchánek wrote:
> On Wed, 3 Jul 2019 15:54:59 +0530
> Sachin Sant wrote:
>
> > Booting mainline kernel on PowerVM LPAR with vTPM enabled results
> > into a kernel crash.
> >
> > [0.365989] BUG: Kernel NULL
On Wed, 3 Jul 2019 15:54:59 +0530
Sachin Sant wrote:
> Booting mainline kernel on PowerVM LPAR with vTPM enabled results
> into a kernel crash.
>
> [0.365989] BUG: Kernel NULL pointer dereference at 0x0012
> [0.365995] Faulting instruction address: 0xc073dd80
> [
On Thu, 9 May 2019 07:06:32 -0700
Guenter Roeck wrote:
> On 5/9/19 6:26 AM, Michal Suchánek wrote:
> > On Thu, 9 May 2019 06:07:31 -0700
> > Guenter Roeck wrote:
> >
> >> On 5/9/19 2:49 AM, Michal Suchánek wrote:
> >>> On Thu, 9 May 2019 08:5
On Thu, 9 May 2019 14:19:23 +0200
Petr Mladek wrote:
> The commit 3e5903eb9cff70730 ("vsprintf: Prevent crash when dereferencing
> invalid pointers") broke boot on several architectures. The common
> pattern is that probe_kernel_read() is not working during early
> boot because userspace access
On Thu, 9 May 2019 06:07:31 -0700
Guenter Roeck wrote:
> On 5/9/19 2:49 AM, Michal Suchánek wrote:
> > On Thu, 9 May 2019 08:53:24 +0200
> > Greg Kroah-Hartman wrote:
> >
> >> On Wed, May 08, 2019 at 01:26:42PM -0700, Guenter Roeck wrote:
> >>> I s
On Thu, 9 May 2019 08:53:24 +0200
Greg Kroah-Hartman wrote:
> On Wed, May 08, 2019 at 01:26:42PM -0700, Guenter Roeck wrote:
> > I see multiple instances of:
> >
> > arch/powerpc/kernel/exceptions-64s.S:839: Error:
> > attempt to move .org backwards
> >
> > in v4.4.y.queue
On Thu, 18 Apr 2019 13:56:56 -0500
Nathan Lynch wrote:
Hello,
> Changing cpu <-> node relationships at runtime, as the pseries
> platform code attempts to do for LPM, PRRN, and VPHN is essentially
> unsupported by core subsystems. [1]
Wasn't there a patch that solves the discrepancy by
On Wed, 06 Mar 2019 14:47:33 +0530
"Aneesh Kumar K.V" wrote:
> Dan Williams writes:
>
> > On Thu, Feb 28, 2019 at 1:40 AM Oliver wrote:
> >>
> >> On Thu, Feb 28, 2019 at 7:35 PM Aneesh Kumar K.V
> >> wrote:
> Also even if the user decided to not use THP, by
> echo "never" >
On Mon, 18 Feb 2019 11:49:17 +0100
Michal Suchánek wrote:
Nevermind
Looks like some version of the patch is queued in powerpc/next already.
Thanks
Michal
On Thu, 14 Feb 2019 09:56:26 -0600
Michael Bringmann wrote:
Hello,
> To: linuxppc-dev@lists.ozlabs.org
> To: linux-ker...@vger.kernel.org
> Benjamin Herrenschmidt
> Paul Mackerras
> Michael Ellerman
> Nathan Lynch
> Corentin Labbe
> Tyrel Datwyler
> Srikar Dronamraju
> Guenter Roeck
>
On Thu, 14 Feb 2019 01:17:11 -0700 (MST)
sgosavi1 wrote:
> > Maybe look around
> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?
> > id=9a0e77f28b50128df0c9e26ae489e44e29a7270a
>
> >Also look at ide_platform.c. I imagine there must be some way to set it
> >up in
On Thu, 17 Jan 2019 23:13:28 +1100
Michael Ellerman wrote:
> On machines with 1TB segments and a 32-entry SLB it's quite hard to
> cause sufficient SLB pressure to trigger bugs caused due to badly
> timed SLB faults.
>
> We have seen this in the past and a few years ago added the
>
e as not
> transactional. When calling rfid, SRR1 will have MSR[TS] set, but the CPU
> state is non transactional, causing the TM Bad Thing with the following
> stack:
>
Works for me on Linux 4.4 and 4.12
Tested-by: Michal Suchánek
Thanks
On Mon, 26 Nov 2018 18:12:01 -0200
Breno Leitao wrote:
Hello
> +
> +int main(int argc, char **argv)
> +{
> + test_harness(tm_signal_sigreturn_nt, "tm_signal_sigreturn_nt");
Should be something like
return test_harness(tm_signal_sigreturn_nt, "tm_signal_sigreturn_nt");
> +}
> +
Thanks
On Fri, 30 Nov 2018 18:59:21 +0100
David Hildenbrand wrote:
> Let's introduce new types for different kinds of memory blocks and use
> them in existing code. As I don't see an easy way to split this up,
> do it in one hunk for now.
>
> acpi:
> Use DIMM or DIMM_UNREMOVABLE depending on
On Wed, 28 Nov 2018 16:55:30 +0100
Christian Zigotzky wrote:
> On 28 November 2018 at 12:05PM, Michael Ellerman wrote:
> > Nothing specific yet.
> >
> > I'm a bit worried it might break one of the many old obscure platforms
> > we have that aren't well tested.
> >
> Please don't apply the new
On Mon, 26 Nov 2018 16:59:14 +0100
David Hildenbrand wrote:
> On 26.11.18 15:20, Michal Suchánek wrote:
> > On Mon, 26 Nov 2018 14:33:29 +0100
> > David Hildenbrand wrote:
> >
> >> On 26.11.18 13:30, David Hildenbrand wrote:
> >>>
On Mon, 26 Nov 2018 14:33:29 +0100
David Hildenbrand wrote:
> On 26.11.18 13:30, David Hildenbrand wrote:
> > On 23.11.18 19:06, Michal Suchánek wrote:
> >>
> >> If we are going to fake the driver information we may as well add the
> >> type attribute an
On Wed, 10 Jan 2018 18:09:45 -0600
Li Yang wrote:
Hello,
> On Mon, Jan 8, 2018 at 2:17 AM, Christian Zigotzky
> wrote:
> > Hi All,
> >
> > Thanks a lot for your replies.
> >
> > @NXP developers: Could you please tell us some information?
>
> We have done some investigation but it is not
On Fri, 23 Nov 2018 12:13:58 +0100
David Hildenbrand wrote:
> On 28.09.18 17:03, David Hildenbrand wrote:
> > How to/when to online hotplugged memory is hard to manage for
> > distributions because different memory types are to be treated differently.
> > Right now, we need complicated udev
On Wed, 31 Oct 2018 19:04:14 -0300
Tulio Magno Quites Machado Filho wrote:
> Florian Weimer writes:
>
> > * Tulio Magno Quites Machado Filho:
> >
> >> I wonder if this is restricted to linker that Golang uses.
> >> Were you able to reproduce the same problem with Binutils'
> >> linker?
> >
On Wed, 31 Oct 2018 18:20:56 +0100
Florian Weimer wrote:
> We tried to use Go to build PIE binaries, and while the Go toolchain
> is definitely not ready (it produces text relocations and problematic
> relocations in general), it exposed what could be an accidental
> userspace ABI change.
>
>
On Sun, 29 Jul 2018 08:18:34 -0500
Michael Bringmann wrote:
> The migration of LPARs across Power systems affects many attributes
> including that of the associativity of CPUs. The patches in this
> set execute when a system is coming up fresh upon a migration target.
> They are intended to,
>
On Fri, 26 Oct 2018 15:57:15 -0700
Florian Fainelli wrote:
> On 10/23/18 11:22 PM, Michal Suchánek wrote:
> > On Tue, 23 Oct 2018 11:20:36 -0700
> > Florian Fainelli wrote:
> >
> >> On 10/23/18 11:02 AM, Joakim Tjernlund wrote:
> >>> On Tue, 2
On Tue, 23 Oct 2018 11:20:36 -0700
Florian Fainelli wrote:
> On 10/23/18 11:02 AM, Joakim Tjernlund wrote:
> > On Tue, 2018-10-23 at 10:03 -0700, Florian Fainelli wrote:
> >
> > I also noted that using status = "disabled" didn't work either to
> > create a fix name scheme. Even worse, all
On Thu, 4 Oct 2018 17:45:13 +0200
David Hildenbrand wrote:
> On 04/10/2018 17:28, Michal Suchánek wrote:
> >
> > The state of the art is to determine what to do with hotplugged
> > memory in userspace based on platform and virtualization type.
>
> Exactly.
>
On Thu, 4 Oct 2018 10:13:48 +0200
David Hildenbrand wrote:
ok, so what is the problem here?
Handling the hotplug in userspace through udev may be suboptimal and
kernel handling might be faster but that's orthogonal to the problem at
hand.
The state of the art is to determine what to do with
On Wed, 26 Sep 2018 19:46:08 +0800
zhong jiang wrote:
> It is safe to move dereference below a NULL test.
>
> Signed-off-by: zhong jiang
> ---
> arch/powerpc/kernel/cacheinfo.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/kernel/cacheinfo.c
>
On Tue, 18 Sep 2018 10:52:09 +0200
Christophe LEROY wrote:
>
>
> Le 14/09/2018 à 06:22, Nicholas Piggin a écrit :
> > On Fri, 14 Sep 2018 11:14:11 +1000
> > Michael Neuling wrote:
> >
> >> This stops us from doing code patching in init sections after
> >> they've been freed.
> >>
> >> In
On Mon, 10 Sep 2018 12:16:35 +0200
Christophe LEROY wrote:
> Le 10/09/2018 à 12:05, Michael Neuling a écrit :
> >
> >>> + /* Make sure we aren't patching a freed init section */
> >>> + if (in_init_section(patch_addr) && init_freed())
> >>> + return 0;
> >>> +
> >>
> >> Do we even
On Mon, 10 Sep 2018 15:44:05 +1000
Michael Neuling wrote:
> This stops us from doing code patching in init sections after they've
> been freed.
>
> In this chain:
> kvm_guest_init() ->
> kvm_use_magic_page() ->
> fault_in_pages_readable() ->
>__get_user() ->
>
On Mon, 10 Sep 2018 15:44:05 +1000
Michael Neuling wrote:
> This stops us from doing code patching in init sections after they've
> been freed.
>
> In this chain:
> kvm_guest_init() ->
> kvm_use_magic_page() ->
> fault_in_pages_readable() ->
>__get_user() ->
>
On Thu, 9 Aug 2018 18:33:33 +1000
Nicholas Piggin wrote:
> On Thu, 9 Aug 2018 13:39:45 +0530
> Ananth N Mavinakayanahalli wrote:
>
> > On Thu, Aug 09, 2018 at 06:02:53PM +1000, Nicholas Piggin wrote:
> > > On Thu, 09 Aug 2018 16:34:07 +1000
> > > Michael Ellerman wrote:
> > >
> > > >
On Fri, 3 Aug 2018 14:13:49 +1000
Nicholas Piggin wrote:
> The machine check code that flushes and restores bolted segments in
> real mode belongs in mm/slb.c. This will be used by pseries machine
> check and idle code.
>
> Signed-off-by: Nicholas Piggin
> ---
>
On Wed, 8 Aug 2018 21:07:11 +0530
"Aneesh Kumar K.V" wrote:
> On 08/08/2018 08:26 PM, Michael Ellerman wrote:
> > Mahesh J Salgaonkar writes:
> >> From: Mahesh Salgaonkar
> >>
> >> Introduce recovery action for recovered memory errors (MCEs).
> >> There are soft memory errors like SLB
Hello,
On Tue, 07 Aug 2018 19:47:14 +0530
"Mahesh J Salgaonkar" wrote:
> From: Mahesh Salgaonkar
>
> On pseries, as of today system crashes if we get a machine check
> exceptions due to SLB errors. These are soft errors and can be fixed
> by flushing the SLBs so the kernel can continue to
On Tue, 3 Jul 2018 08:08:14 +1000
"Nicholas Piggin" wrote:
> On Mon, 02 Jul 2018 11:17:06 +0530
> Mahesh J Salgaonkar wrote:
>
> > From: Mahesh Salgaonkar
> >
> > On pseries, as of today system crashes if we get a machine check
> > exceptions due to SLB errors. These are soft errors and can
Hello,
On Wed, 04 Jul 2018 23:28:21 +0530
"Mahesh J Salgaonkar" wrote:
> From: Mahesh Salgaonkar
>
> On pseries, as of today system crashes if we get a machine check
> exceptions due to SLB errors. These are soft errors and can be fixed
> by flushing the SLBs so the kernel can continue to
On Fri, 6 Jul 2018 19:40:24 +1000
Nicholas Piggin wrote:
> On Wed, 04 Jul 2018 23:30:12 +0530
> Mahesh J Salgaonkar wrote:
>
> > From: Mahesh Salgaonkar
> >
> > Now that other platforms also implements real mode mce handler,
> > lets consolidate the code by sharing existing powernv machine
On Tue, 3 Jul 2018 08:08:14 +1000
Nicholas Piggin wrote:
> On Mon, 02 Jul 2018 11:17:06 +0530
> Mahesh J Salgaonkar wrote:
>
> > From: Mahesh Salgaonkar
> >
> > On pseries, as of today system crashes if we get a machine check
> > exceptions due to SLB errors. These are soft errors and can be
On Fri, 8 Jun 2018 11:51:36 +1000
Nicholas Piggin wrote:
> On Thu, 07 Jun 2018 22:59:04 +0530
> Mahesh J Salgaonkar wrote:
>
> > From: Mahesh Salgaonkar
> >
> > Extract the MCE error details from RTAS extended log and display it
> > to console.
> >
> > With this patch you should now see mce
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 Sun, 10 Jun 2018 23:30:27 +1000
Nicholas Piggin wrote:
> 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.
>
> diff --git a/arch/powerpc/kvm/book3s_xive_template.c
>
On Fri, 8 Jun 2018 15:51:03 +0200
Florian Weimer wrote:
> On 06/08/2018 03:49 PM, Michal Suchánek wrote:
> > On Fri, 8 Jun 2018 14:57:06 +0200
> > Florian Weimer wrote:
> >
> >> On 06/08/2018 02:54 PM, Michal Suchánek wrote:
> >>> On Fri, 8 Ju
On Fri, 8 Jun 2018 14:57:06 +0200
Florian Weimer wrote:
> On 06/08/2018 02:54 PM, Michal Suchánek wrote:
> > On Fri, 8 Jun 2018 12:44:53 +0200
> > Florian Weimer wrote:
> >
> >> On 06/08/2018 12:15 PM, Michal Suchánek wrote:
> >>> On Fri, 8 Ju
On Fri, 8 Jun 2018 12:44:53 +0200
Florian Weimer wrote:
> On 06/08/2018 12:15 PM, Michal Suchánek wrote:
> > On Fri, 8 Jun 2018 07:53:51 +0200
> > Florian Weimer wrote:
> >
> >> On 06/08/2018 04:34 AM, Ram Pai wrote:
> >>>>
> >>
201 - 300 of 384 matches
Mail list logo
