On Thu, Jun 11, 2020 at 09:23:52PM -0700, Matt Turner wrote:
> Since I noticed earlier that using maxcpus=1 on a 2-CPU system
> prevented the system from hanging, I tried disabling CONFIG_SMP on my
> 1-CPU system as well. In doing so, I discovered that the RCU torture
> module (RCU_TORTURE_TEST)
On Thu, Jan 10, 2019 at 11:42:32PM +0100, Arnd Bergmann wrote:
> On Thu, Jan 10, 2019 at 7:10 PM Joseph Myers wrote:
> >
> > On Thu, 10 Jan 2019, Arnd Bergmann wrote:
> >
> > > - Add system calls that have not yet been integrated into all
> > > architectures but that we definitely want there.
>
On Thu, Dec 13, 2018 at 08:07:24AM -0800, Tejun Heo wrote:
> Hello, Michael.
>
> On Thu, Dec 13, 2018 at 09:26:12PM +1300, Michael Cree wrote:
> > A kernel built for generic UP Alpha had been noted to fail to boot
> > for quite some time (since the release of 3.18). The ke
A kernel built for generic UP Alpha had been noted to fail to boot
for quite some time (since the release of 3.18). The kernel either
locks up before printing any messages to the console or just falls
back into the SRM with a HALT instruction again before any messages
are printed to the console.
On Fri, Nov 02, 2018 at 08:56:37PM +0530, Brajeswar Ghosh wrote:
> Remove asm/xchg.h which is included more than once
>
> Signed-off-by: Brajeswar Ghosh
> ---
> arch/alpha/include/asm/cmpxchg.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/alpha/include/asm/cmpxchg.h
>
On Fri, Nov 02, 2018 at 08:56:37PM +0530, Brajeswar Ghosh wrote:
> Remove asm/xchg.h which is included more than once
>
> Signed-off-by: Brajeswar Ghosh
> ---
> arch/alpha/include/asm/cmpxchg.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/alpha/include/asm/cmpxchg.h
>
.
Signed-off-by: Michael Cree <mc...@orcon.net.nz>
---
arch/alpha/Kconfig | 1 +
arch/alpha/kernel/Makefile | 2 +-
arch/alpha/kernel/bugs.c | 45 +
3 files changed, 47 insertions(+), 1 deletion(-)
create mode 100644 arch/alpha/kernel/
.
Signed-off-by: Michael Cree
---
arch/alpha/Kconfig | 1 +
arch/alpha/kernel/Makefile | 2 +-
arch/alpha/kernel/bugs.c | 45 +
3 files changed, 47 insertions(+), 1 deletion(-)
create mode 100644 arch/alpha/kernel/bugs.c
diff --git a/arch/alpha
On Tue, Jan 02, 2018 at 02:01:34PM -0500, Mikulas Patocka wrote:
> On alpha, a process will crash if it attempts to start a thread and a
> signal is delivered at the same time. The crash can be reproduced with
> this program: https://cygwin.com/ml/cygwin/2014-11/msg00473.html
>
> The reason for
On Tue, Jan 02, 2018 at 02:01:34PM -0500, Mikulas Patocka wrote:
> On alpha, a process will crash if it attempts to start a thread and a
> signal is delivered at the same time. The crash can be reproduced with
> this program: https://cygwin.com/ml/cygwin/2014-11/msg00473.html
>
> The reason for
On Thu, Sep 28, 2017 at 08:43:54AM -0700, Paul E. McKenney wrote:
> On Thu, Sep 28, 2017 at 09:45:35AM +0100, Will Deacon wrote:
> > On Thu, Sep 28, 2017 at 10:38:01AM +0200, Peter Zijlstra wrote:
> > > On Wed, Sep 27, 2017 at 04:49:28PM +0100, Will Deacon wrote:
> > > > In many cases, page tables
On Thu, Sep 28, 2017 at 08:43:54AM -0700, Paul E. McKenney wrote:
> On Thu, Sep 28, 2017 at 09:45:35AM +0100, Will Deacon wrote:
> > On Thu, Sep 28, 2017 at 10:38:01AM +0200, Peter Zijlstra wrote:
> > > On Wed, Sep 27, 2017 at 04:49:28PM +0100, Will Deacon wrote:
> > > > In many cases, page tables
On Fri, Jul 14, 2017 at 05:59:06AM -0500, Eric W. Biederman wrote:
> in which cases the oddities will happen let alone test them. Plus at
> least for ia64 and alpha those architectures don't appear to be
> receiving updates for new syscalls, and no new hardware is being built
> so I don't know
On Fri, Jul 14, 2017 at 05:59:06AM -0500, Eric W. Biederman wrote:
> in which cases the oddities will happen let alone test them. Plus at
> least for ia64 and alpha those architectures don't appear to be
> receiving updates for new syscalls, and no new hardware is being built
> so I don't know
Since commit 71810db27c1c853b33 (modversions: treat symbol CRCs
as 32 bit quantities) R_ALPHA_REFLONG relocations can be required
to load modules. This implements it.
Tested-by: Bob Tracy <r...@gherkin.frus.com>
Signed-off-by: Michael Cree <mc...@orcon.net.nz>
---
arch/alpha/kernel/
Since commit 71810db27c1c853b33 (modversions: treat symbol CRCs
as 32 bit quantities) R_ALPHA_REFLONG relocations can be required
to load modules. This implements it.
Tested-by: Bob Tracy
Signed-off-by: Michael Cree
---
arch/alpha/kernel/module.c | 3 +++
1 file changed, 3 insertions(+)
diff
On Wed, Apr 12, 2017 at 07:57:52AM +0200, Helge Deller wrote:
> On 12.04.2017 04:59, Bob Tracy wrote:
> > Bottom line is, no kernel I've built since 4.9 can load a module. All
> > attempts to load a module result in the error message emitted by
> > "arch/alpha/kernel/module.c" as follows:
> >
>
On Wed, Apr 12, 2017 at 07:57:52AM +0200, Helge Deller wrote:
> On 12.04.2017 04:59, Bob Tracy wrote:
> > Bottom line is, no kernel I've built since 4.9 can load a module. All
> > attempts to load a module result in the error message emitted by
> > "arch/alpha/kernel/module.c" as follows:
> >
>
On Tue, Feb 14, 2017 at 12:35:58PM +0100, Andrea Parri wrote:
> On Mon, Feb 13, 2017 at 01:24:36PM -0800, Paul E. McKenney wrote:
> >
> >
> > C auto/C-LB-LRW+OB-Ov
> > (*
> > * Result: Maybe
> > * P0-P1 rf OB-Ov:
On Tue, Feb 14, 2017 at 12:35:58PM +0100, Andrea Parri wrote:
> On Mon, Feb 13, 2017 at 01:24:36PM -0800, Paul E. McKenney wrote:
> >
> >
> > C auto/C-LB-LRW+OB-Ov
> > (*
> > * Result: Maybe
> > * P0-P1 rf OB-Ov:
Hi Paul,
On Mon, Feb 13, 2017 at 11:09:31AM -0800, Paul E. McKenney wrote:
> On Mon, Feb 13, 2017 at 01:53:27PM -0500, bob smith wrote:
> > On 2/13/17 1:39 PM, Paul E. McKenney wrote:
> > > can real DEC Alpha hardware end up with both instances of "r1"
> > > having the value 1?
> >
> > I thought
Hi Paul,
On Mon, Feb 13, 2017 at 11:09:31AM -0800, Paul E. McKenney wrote:
> On Mon, Feb 13, 2017 at 01:53:27PM -0500, bob smith wrote:
> > On 2/13/17 1:39 PM, Paul E. McKenney wrote:
> > > can real DEC Alpha hardware end up with both instances of "r1"
> > > having the value 1?
> >
> > I thought
On Tue, Oct 25, 2016 at 09:26:38PM +1300, Michael Cree wrote:
> And while I mention libc I am seeing (rather rare) random segfaults
> in programs such as cp, tar, install and dpkg ever since the upgrade
> to glibc 2.23 (or maybe it was 2.24). I am struggling to get a
> backtrace bec
On Tue, Oct 25, 2016 at 09:26:38PM +1300, Michael Cree wrote:
> And while I mention libc I am seeing (rather rare) random segfaults
> in programs such as cp, tar, install and dpkg ever since the upgrade
> to glibc 2.23 (or maybe it was 2.24). I am struggling to get a
> backtrace bec
On Sun, May 10, 2015 at 02:33:36AM +0800, Chen Gang wrote:
> The related warnings:
>
> CALLscripts/checksyscalls.sh
> :1238:2: warning: #warning syscall seccomp not implemented [-Wcpp]
> :1241:2: warning: #warning syscall getrandom not implemented [-Wcpp]
> :1244:2: warning:
On Sun, May 10, 2015 at 02:33:36AM +0800, Chen Gang wrote:
The related warnings:
CALLscripts/checksyscalls.sh
stdin:1238:2: warning: #warning syscall seccomp not implemented [-Wcpp]
stdin:1241:2: warning: #warning syscall getrandom not implemented [-Wcpp]
stdin:1244:2:
On Sun, Feb 08, 2015 at 04:25:46AM +, Mathieu Desnoyers wrote:
> > From: "Michael Cree"
> > The Alpha kernel is behaving pretty well provided one builds a machine
> > specific kernel and UP. When running an SMP kernel some packages
> > (most notably the
On Sun, Feb 08, 2015 at 04:25:46AM +, Mathieu Desnoyers wrote:
From: Michael Cree mc...@orcon.net.nz
The Alpha kernel is behaving pretty well provided one builds a machine
specific kernel and UP. When running an SMP kernel some packages
(most notably the java runtime
On Sun, Feb 08, 2015 at 08:59:41AM +0800, Greg KH wrote:
> On Sun, Feb 08, 2015 at 01:47:29PM +1300, Michael Cree wrote:
> > On Sat, Feb 07, 2015 at 10:30:44PM +, Mathieu Desnoyers wrote:
> > > > On Fri, Feb 06, 2015 at 09:08:21PM -0500, Ma
On Sat, Feb 07, 2015 at 10:30:44PM +, Mathieu Desnoyers wrote:
> > On Fri, Feb 06, 2015 at 09:08:21PM -0500, Mathieu Desnoyers wrote:
> > > A lockless_dereference() appears to be missing in llist_del_first().
> > > It should only matter for Alpha in practice.
What could one anticipate to be
On Sat, Feb 07, 2015 at 10:30:44PM +, Mathieu Desnoyers wrote:
On Fri, Feb 06, 2015 at 09:08:21PM -0500, Mathieu Desnoyers wrote:
A lockless_dereference() appears to be missing in llist_del_first().
It should only matter for Alpha in practice.
What could one anticipate to be the
On Sun, Feb 08, 2015 at 08:59:41AM +0800, Greg KH wrote:
On Sun, Feb 08, 2015 at 01:47:29PM +1300, Michael Cree wrote:
On Sat, Feb 07, 2015 at 10:30:44PM +, Mathieu Desnoyers wrote:
On Fri, Feb 06, 2015 at 09:08:21PM -0500, Mathieu Desnoyers wrote:
A lockless_dereference() appears
On Fri, Sep 05, 2014 at 05:12:28PM -0400, Peter Hurley wrote:
> On 09/05/2014 04:39 PM, Michael Cree wrote:
> > On Fri, Sep 05, 2014 at 04:14:48PM -0400, Peter Hurley wrote:
> >> Second, in the body of the document:
> >>
> >> "The Linux kernel no lon
On Fri, Sep 05, 2014 at 01:34:52PM -0700, H. Peter Anvin wrote:
> On 09/05/2014 01:14 PM, Peter Hurley wrote:
> >
> > Here's how I read the two statements.
> >
> > First, the commit message:
> >
> > "It [this commit] documents that CPUs [supported by the Linux kernel]
> > _must provide_ atomic
On Fri, Sep 05, 2014 at 04:14:48PM -0400, Peter Hurley wrote:
> Second, in the body of the document:
>
> "The Linux kernel no longer supports pre-EV56 Alpha CPUs, because these
> older CPUs _do not provide_ atomic one-byte and two-byte loads and stores."
Let's be clear here, the pre-EV56 Alpha
On Thu, Sep 04, 2014 at 07:08:48PM -0700, H. Peter Anvin wrote:
> On 09/04/2014 05:59 PM, Peter Hurley wrote:
> > I have no idea how prevalent the ev56 is compared to the ev5.
> > Still we're talking about a chip that came out in 1996.
>
> Ah yes, I stand corrected. According to Wikipedia, the
On Thu, Sep 04, 2014 at 07:08:48PM -0700, H. Peter Anvin wrote:
On 09/04/2014 05:59 PM, Peter Hurley wrote:
I have no idea how prevalent the ev56 is compared to the ev5.
Still we're talking about a chip that came out in 1996.
Ah yes, I stand corrected. According to Wikipedia, the affected
On Fri, Sep 05, 2014 at 04:14:48PM -0400, Peter Hurley wrote:
Second, in the body of the document:
The Linux kernel no longer supports pre-EV56 Alpha CPUs, because these
older CPUs _do not provide_ atomic one-byte and two-byte loads and stores.
Let's be clear here, the pre-EV56 Alpha CPUs do
On Fri, Sep 05, 2014 at 01:34:52PM -0700, H. Peter Anvin wrote:
On 09/05/2014 01:14 PM, Peter Hurley wrote:
Here's how I read the two statements.
First, the commit message:
It [this commit] documents that CPUs [supported by the Linux kernel]
_must provide_ atomic one-byte and
On Fri, Sep 05, 2014 at 05:12:28PM -0400, Peter Hurley wrote:
On 09/05/2014 04:39 PM, Michael Cree wrote:
On Fri, Sep 05, 2014 at 04:14:48PM -0400, Peter Hurley wrote:
Second, in the body of the document:
The Linux kernel no longer supports pre-EV56 Alpha CPUs, because these
older CPUs
true fork, but OSF/1
> compatibility is no longer important. Note that glibc has never
> used the r20 result value, instead always testing r0 vs 0 to
> determine the child/parent status.
>
> This failure can be seen in the glibc nptl/tst-eintr* tests.
>
> Reported-by:
compatibility is no longer important. Note that glibc has never
used the r20 result value, instead always testing r0 vs 0 to
determine the child/parent status.
This failure can be seen in the glibc nptl/tst-eintr* tests.
Reported-by: Michael Cree mc...@orcon.net.nz
Signed-off-by: Richard
On Wed, Jul 30, 2014 at 11:42:32AM -1000, Richard Henderson wrote:
> Signed-off-by: Richard Henderson
> ---
> arch/alpha/include/asm/unistd.h | 2 +-
> arch/alpha/include/uapi/asm/unistd.h | 3 +++
> arch/alpha/kernel/systbls.S | 3 +++
> 3 files changed, 7 insertions(+), 1
On Wed, Jul 30, 2014 at 11:42:32AM -1000, Richard Henderson wrote:
Signed-off-by: Richard Henderson r...@twiddle.net
---
arch/alpha/include/asm/unistd.h | 2 +-
arch/alpha/include/uapi/asm/unistd.h | 3 +++
arch/alpha/kernel/systbls.S | 3 +++
3 files changed, 7 insertions(+),
On Thu, Jul 24, 2014 at 08:19:52AM -1000, Richard Henderson wrote:
> On 07/22/2014 10:52 PM, Michael Cree wrote:
> > Running strace on nptl/tst-eintr3 reveals that the clone() syscall
> > is retried by the kernel if an ERESTARTNOINTR error occurs. At
> > $syscall_error
On Thu, Jul 24, 2014 at 08:19:52AM -1000, Richard Henderson wrote:
On 07/22/2014 10:52 PM, Michael Cree wrote:
Running strace on nptl/tst-eintr3 reveals that the clone() syscall
is retried by the kernel if an ERESTARTNOINTR error occurs. At
$syscall_error in arch/alpha/kernel/entry.S
I am seeing a bug in clone() on the Alpha architecture. Reported to
Debian as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755397
The test suite of glibc sometimes fails in the nptl/tst-eintr3 test
with a segmentation fault. I have tracked it down to the thread
pointer returned by the
I am seeing a bug in clone() on the Alpha architecture. Reported to
Debian as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755397
The test suite of glibc sometimes fails in the nptl/tst-eintr3 test
with a segmentation fault. I have tracked it down to the thread
pointer returned by the
On Tue, Feb 04, 2014 at 01:08:38PM -0800, Greg Kroah-Hartman wrote:
> 3.12-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Mikulas Patocka
>
> commit 0ef38d70d4118b2ce1a538d14357be5ff9dc2bbd upstream.
>
> The patch
On Tue, Feb 04, 2014 at 01:08:38PM -0800, Greg Kroah-Hartman wrote:
3.12-stable review patch. If anyone has any objections, please let me know.
--
From: Mikulas Patocka mpato...@redhat.com
commit 0ef38d70d4118b2ce1a538d14357be5ff9dc2bbd upstream.
The patch
> counter relationships mean that raw events actually
> correspond to the Linux-specific Alpha events, rather than anything
> defined by the architecture.
>
> This patch adds a new callback to alpha_pmu_t for validating the raw
> event encoding with the Linux event types for the P
event encoding with the Linux event types for the PMU, preventing the
out-of-bounds array access.
Cc: Peter Zijlstra a.p.zijls...@chello.nl
Cc: Michael Cree mc...@orcon.net.nz
Cc: Matt Turner matts...@gmail.com
Signed-off-by: Will Deacon will.dea...@arm.com
Acked-by: Michael Cree mc
On Tue, Jul 23, 2013 at 07:20:22AM -0800, Richard Henderson wrote:
> On 07/22/2013 07:25 PM, Michael Cree wrote:
> > I wondered if your proposal will break glibc as glibc checks for
> > __NR_oldumount and does different things based on that. But maybe your
> > fix will not a
On Tue, Jul 23, 2013 at 07:20:22AM -0800, Richard Henderson wrote:
On 07/22/2013 07:25 PM, Michael Cree wrote:
I wondered if your proposal will break glibc as glibc checks for
__NR_oldumount and does different things based on that. But maybe your
fix will not adversely affect glibc (I did
On Mon, Jul 22, 2013 at 09:31:41PM -0500, Rob Landley wrote:
> On 07/16/2013 07:03:47 PM, Michael Cree wrote:
> >On Tue, Jul 16, 2013 at 06:35:07PM -0500, Rob Landley wrote:
> >> On 07/16/2013 12:04:33 PM, Richard Henderson wrote:
> >> >Here's a set of minor upda
On Mon, Jul 22, 2013 at 09:31:41PM -0500, Rob Landley wrote:
On 07/16/2013 07:03:47 PM, Michael Cree wrote:
On Tue, Jul 16, 2013 at 06:35:07PM -0500, Rob Landley wrote:
On 07/16/2013 12:04:33 PM, Richard Henderson wrote:
Here's a set of minor updates for arch/alpha that should
On Thu, Jul 18, 2013 at 03:04:25PM -0700, Richard Henderson wrote:
> On 07/18/2013 02:28 PM, Michael Cree wrote:
> > On the kernel without the patch set the dummy-RTC timer interrupt received
> > 30876 interrupts in a 30s period which is within measurement uncertainty of
> >
On Thu, Jul 18, 2013 at 03:04:25PM -0700, Richard Henderson wrote:
On 07/18/2013 02:28 PM, Michael Cree wrote:
On the kernel without the patch set the dummy-RTC timer interrupt received
30876 interrupts in a 30s period which is within measurement uncertainty of
the expected 30*1024 = 30720
On Thu, Jul 18, 2013 at 06:38:14AM -0700, Richard Henderson wrote:
> On 07/17/2013 06:14 PM, Michael Cree wrote:
> > Tested the patch series applied against 3.10.1 on a 3-CPU ES45. System came
> > up fine but I noticed date was wrong and had been reset back to the start
> >
On Thu, Jul 18, 2013 at 06:38:14AM -0700, Richard Henderson wrote:
On 07/17/2013 06:14 PM, Michael Cree wrote:
Tested the patch series applied against 3.10.1 on a 3-CPU ES45. System came
up fine but I noticed date was wrong and had been reset back to the start
of the epoch (Jan 1 1970
On Tue, Jul 16, 2013 at 10:34:08AM -0700, Richard Henderson wrote:
> The series seems pretty stable under QEMU, but I have no real hardware
> on which to test -- the whole reason I'm interested in QEMU of course.
> So I'm hoping that someone will notice this and help me out with testing.
Tested
On Tue, Jul 16, 2013 at 10:34:08AM -0700, Richard Henderson wrote:
The series seems pretty stable under QEMU, but I have no real hardware
on which to test -- the whole reason I'm interested in QEMU of course.
So I'm hoping that someone will notice this and help me out with testing.
Tested the
On Tue, Jul 16, 2013 at 06:35:07PM -0500, Rob Landley wrote:
> On 07/16/2013 12:04:33 PM, Richard Henderson wrote:
> >Here's a set of minor updates for arch/alpha that should not
> >be controversial.
>
> I also note that I had to do this to get busybox to build against
> uClibc:
> -#define
On Tue, Jul 16, 2013 at 06:35:07PM -0500, Rob Landley wrote:
On 07/16/2013 12:04:33 PM, Richard Henderson wrote:
Here's a set of minor updates for arch/alpha that should not
be controversial.
I also note that I had to do this to get busybox to build against
uClibc:
-#define __NR_umount
On Sun, Apr 21, 2013 at 07:35:31PM +1000, Stephen Rothwell wrote:
> On Sun, 21 Apr 2013 05:29:28 +0100 (BST) "Maciej W. Rozycki"
> wrote:
> >
> > Hmm, nobody has replied, so just FYI such widening multiplication is
> > available in all 64-bit MIPS hardware and GCC has supported it since 4.4
>
On Sun, Apr 21, 2013 at 07:35:31PM +1000, Stephen Rothwell wrote:
On Sun, 21 Apr 2013 05:29:28 +0100 (BST) Maciej W. Rozycki
ma...@linux-mips.org wrote:
Hmm, nobody has replied, so just FYI such widening multiplication is
available in all 64-bit MIPS hardware and GCC has supported it
On Thu, Nov 15, 2012 at 10:49:28AM -0700, Shuah Khan wrote:
> On Fri, 2012-10-26 at 10:32 -0600, Shuah Khan wrote:
> > Add support for debug_dma_mapping_error() call to avoid warning from
> > debug_dma_unmap() interface when it checks for mapping error checked
> > status. Without this patch,
On Thu, Nov 15, 2012 at 10:49:28AM -0700, Shuah Khan wrote:
On Fri, 2012-10-26 at 10:32 -0600, Shuah Khan wrote:
Add support for debug_dma_mapping_error() call to avoid warning from
debug_dma_unmap() interface when it checks for mapping error checked
status. Without this patch, device
On Mon, Mar 25, 2013 at 07:13:35AM -0500, Bob Tracy wrote:
> Getting lots of these since attempting to upgrade past 3.8.0-rc7. I
> *don't* think it's a kernel issue at this point, because while older
> kernels (found an old 3.5.0-rc4 setup from about a year ago in my archives)
> seem to take
On Mon, Mar 25, 2013 at 07:13:35AM -0500, Bob Tracy wrote:
Getting lots of these since attempting to upgrade past 3.8.0-rc7. I
*don't* think it's a kernel issue at this point, because while older
kernels (found an old 3.5.0-rc4 setup from about a year ago in my archives)
seem to take longer
On 26/03/2013, at 4:09 AM, Tobias Klausmann wrote:
On Mon, 25 Mar 2013, Will Deacon wrote:
Any news on these? I've included an updated version of the first
patch, with
the Tested-by-tag and a tweaked commit message below.
As a data point, I tried vanilla 3.8.4 on the weekend. With my
usual
On 26/03/2013, at 4:09 AM, Tobias Klausmann wrote:
On Mon, 25 Mar 2013, Will Deacon wrote:
Any news on these? I've included an updated version of the first
patch, with
the Tested-by-tag and a tweaked commit message below.
As a data point, I tried vanilla 3.8.4 on the weekend. With my
usual
On 18/03/2013, at 10:48 AM, Will Deacon wrote:
Due to all of the goodness being packed into today's kernels, the
resulting image isn't as slim as it once was.
In light of this, don't pass -msmall-data to the tools, which
results in
link failures due to impossible relocations when compiling
On 18/03/2013, at 10:48 AM, Will Deacon wrote:
Due to all of the goodness being packed into today's kernels, the
resulting image isn't as slim as it once was.
In light of this, don't pass -msmall-data to the tools, which
results in
link failures due to impossible relocations when compiling
On 9/01/2013, at 2:28 PM, Michel Lespinasse wrote:
Update the alpha arch_get_unmapped_area function to make use of
vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse
'Tis running fine on my alpha.
Tested-by: Michael Cree
Cheers
Michael
On 9/01/2013, at 2:28 PM, Michel Lespinasse wrote:
Update the alpha arch_get_unmapped_area function to make use of
vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse wal...@google.com
'Tis running fine on my alpha.
Tested-by: Michael Cree mc
On Tue, Oct 09, 2012 at 10:15:08AM +0100, David Howells wrote:
> Can you merge the following branch into the alpha tree please.
>
> This is to complete part of the UAPI disintegration for which the preparatory
> patches were pulled recently.
I think the alpha-next tree is currently inactive so
On Tue, Oct 09, 2012 at 10:15:08AM +0100, David Howells wrote:
Can you merge the following branch into the alpha tree please.
This is to complete part of the UAPI disintegration for which the preparatory
patches were pulled recently.
I think the alpha-next tree is currently inactive so
On Sat 13 October 2012 14:09:36 Linus Torvalds wrote:
> On Sat, Oct 13, 2012 at 1:03 AM, Oleg Nesterov wrote:
> > arch/alpha and probably some other architectures call
> > do_notify_resume()->task_work_run() with irqs disabled.
>
> I'm going to ignore this patch because I *hope* it is
On Sat 13 October 2012 14:09:36 Linus Torvalds wrote:
On Sat, Oct 13, 2012 at 1:03 AM, Oleg Nesterov o...@redhat.com wrote:
arch/alpha and probably some other architectures call
do_notify_resume()-task_work_run() with irqs disabled.
I'm going to ignore this patch because I *hope* it is
On 26/08/12 04:18, Paul E. McKenney wrote:
> On Sat, Aug 25, 2012 at 03:16:49PM +0200, Frederic Weisbecker wrote:
>> On Fri, Aug 24, 2012 at 08:50:47PM -0700, Paul E. McKenney wrote:
>>> On Sat, Aug 25, 2012 at 02:19:14AM +0100, Ben Hutchings wrote:
On Fri, 2012-08-24 at 14:26 -0700, Paul E.
On 26/08/12 04:18, Paul E. McKenney wrote:
On Sat, Aug 25, 2012 at 03:16:49PM +0200, Frederic Weisbecker wrote:
On Fri, Aug 24, 2012 at 08:50:47PM -0700, Paul E. McKenney wrote:
On Sat, Aug 25, 2012 at 02:19:14AM +0100, Ben Hutchings wrote:
On Fri, 2012-08-24 at 14:26 -0700, Paul E. McKenney
On 25/08/12 13:19, Ben Hutchings wrote:
> On Fri, 2012-08-24 at 14:26 -0700, Paul E. McKenney wrote:
>> On Thu, Aug 23, 2012 at 04:58:24PM +0200, Frederic Weisbecker wrote:
>>> Hi,
>>>
>>> Changes since v1:
>>>
>>> - Fixed preempt handling in alpha idle loop
>>> - added ack from Geert
>>> - fixed
On 25/08/12 13:19, Ben Hutchings wrote:
On Fri, 2012-08-24 at 14:26 -0700, Paul E. McKenney wrote:
On Thu, Aug 23, 2012 at 04:58:24PM +0200, Frederic Weisbecker wrote:
Hi,
Changes since v1:
- Fixed preempt handling in alpha idle loop
- added ack from Geert
- fixed stable email address,
to add:
Tested-by: Michael Cree
Cheers
Michael.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
with no RCU CPU stalls with this
patch against a 3.5.2 kernel! Nice. Very nice.
I see the stable queue is CCed but I note the patch does not apply
cleanly to the 3.2.y kernel. It would be nice to have a backport of the
patches for the 3.2 stable kernel.
So feel free to add:
Tested-by: Michael
On 23/08/2012, at 12:14 AM, Bob Tracy wrote:
Kernel version 3.6.0-rc2, and probably -rc1 as well. I get the
following compile-time error on alpha architecture:
(...)
CC net/core/sock.o
net/core/sock.c:274:36: error: initializer element is not constant
Try v3.6-rc3. It should be fixed
On 23/08/2012, at 12:14 AM, Bob Tracy wrote:
Kernel version 3.6.0-rc2, and probably -rc1 as well. I get the
following compile-time error on alpha architecture:
(...)
CC net/core/sock.o
net/core/sock.c:274:36: error: initializer element is not constant
Try v3.6-rc3. It should be fixed
On 12/08/12 14:10, Fengguang Wu wrote:
> On Sun, Aug 12, 2012 at 01:33:09PM +1200, Michael Cree wrote:
>> On 03/08/12 03:02, Fengguang Wu wrote:
>>> On Thu, Jul 26, 2012 at 10:06:41AM -0700, Tony Luck wrote:
>>>> On Tue, Jul 24, 2012 at 10:10 PM, James Bott
On 03/08/12 03:02, Fengguang Wu wrote:
> On Thu, Jul 26, 2012 at 10:06:41AM -0700, Tony Luck wrote:
>> On Tue, Jul 24, 2012 at 10:10 PM, James Bottomley
>> wrote:
Here is the line in sock.i:
struct static_key memalloc_socks = ((struct static_key) { .enabled =
((atomic_t) { (0)
On 03/08/12 03:02, Fengguang Wu wrote:
On Thu, Jul 26, 2012 at 10:06:41AM -0700, Tony Luck wrote:
On Tue, Jul 24, 2012 at 10:10 PM, James Bottomley
james.bottom...@hansenpartnership.com wrote:
Here is the line in sock.i:
struct static_key memalloc_socks = ((struct static_key) { .enabled =
On 12/08/12 14:10, Fengguang Wu wrote:
On Sun, Aug 12, 2012 at 01:33:09PM +1200, Michael Cree wrote:
On 03/08/12 03:02, Fengguang Wu wrote:
On Thu, Jul 26, 2012 at 10:06:41AM -0700, Tony Luck wrote:
On Tue, Jul 24, 2012 at 10:10 PM, James Bottomley
james.bottom...@hansenpartnership.com wrote
Kay Sievers wrote:
On Fri, 2007-12-07 at 23:05 -0600, Bob Tracy wrote:
Kay Sievers wrote:
Is the udev daemon (still) running while it fails?
Yes, and there's something else I forgot to mention that may be
significant... For the bad case, in addition to udevd, "ps -ef"
shows a "sh -e
Kay Sievers wrote:
On Fri, 2007-12-07 at 23:05 -0600, Bob Tracy wrote:
Kay Sievers wrote:
Is the udev daemon (still) running while it fails?
Yes, and there's something else I forgot to mention that may be
significant... For the bad case, in addition to udevd, ps -ef
shows a sh -e
Bob Tracy wrote:
That was quick :-). Backing out the sysctl_check.c diff gives me a
working kernel. Beats the [EMAIL PROTECTED] out of me how/why, though.
Michael Cree: could you try backing out the diff below from your
2.6.24-rc3 tree and see if things are now working for you?
Yes
Bob Tracy wrote:
That was quick :-). Backing out the sysctl_check.c diff gives me a
working kernel. Beats the [EMAIL PROTECTED] out of me how/why, though.
Michael Cree: could you try backing out the diff below from your
2.6.24-rc3 tree and see if things are now working for you?
Yes
On 1/12/2007, at 11:42 AM, Andrew Morton wrote:
On Sat, 01 Dec 2007 11:30:01 +1300
Michael Cree <[EMAIL PROTECTED]> wrote:
Bob Tracy wrote:
Andrew Morton wrote:
Could be something change in sysfs. Please double-check the config
options, make sure that something important didn't get di
On 1/12/2007, at 11:42 AM, Andrew Morton wrote:
On Sat, 01 Dec 2007 11:30:01 +1300
Michael Cree [EMAIL PROTECTED] wrote:
Bob Tracy wrote:
Andrew Morton wrote:
Could be something change in sysfs. Please double-check the config
options, make sure that something important didn't get disabled
Bob Tracy wrote:
Andrew Morton wrote:
Could be something change in sysfs. Please double-check the config
options, make sure that something important didn't get disabled.
Here's
hoping someone else is seeing this or can replicate it in the meantime.
Snap.
2.6.24-rc2 works fine.
Bob Tracy wrote:
Andrew Morton wrote:
Could be something change in sysfs. Please double-check the config
options, make sure that something important didn't get disabled.
Here's
hoping someone else is seeing this or can replicate it in the meantime.
Snap.
2.6.24-rc2 works fine.
100 matches
Mail list logo
