Hi All,
I've rebased and reworked the PS3 highmem patches that Hector and Andre have
submitted. They are now against Linux-3.3, and I plan for them to go upstream
for Linux-3.5. I'll rebase them again once a few 3.4-rc's are out.
This work needs to be tested more, especially needed is testing o
Hi,
I didn't actually try to compile the patch below; it didn't look like C
code so I wasn't sure what compiler to run it through. I guess maybe its
python? However, I'm very sure that the patches are completely correct,
because I read them, and I also know that Paul is a trustworthy programmer.
On Sat, Mar 31, 2012 at 11:32:00PM +0100, Russell King - ARM Linux wrote:
> On Sun, Apr 01, 2012 at 12:33:21AM +0800, Paul E. McKenney wrote:
> > Although there have been numerous complaints about the complexity of
> > parallel programming (especially over the past 5-10 years), the plain
> > truth
On Sun, Apr 01, 2012 at 12:19:25AM +0200, Lorenz Kolb wrote:
> With that patchset in mind, I am working on a really huge patch,
> which will greatly simplify the Linux kernel for the real problem
> of having that number of CPUs.
>
> That patch will have a lot of changes all over the architectures
On Sun, Apr 01, 2012 at 12:33:21AM +0800, Paul E. McKenney wrote:
> Although there have been numerous complaints about the complexity of
> parallel programming (especially over the past 5-10 years), the plain
> truth is that the incremental complexity of parallel programming over
> that of sequenti
With that patchset in mind, I am working on a really huge patch, which
will greatly simplify the Linux kernel for the real problem of having
that number of CPUs.
That patch will have a lot of changes all over the architectures, so
what will be the best way to post it? Should I split it archit
On Sat, Mar 31, 2012 at 11:00:08PM +0200, Eric Dumazet wrote:
> On Sun, 2012-04-01 at 00:33 +0800, Paul E. McKenney wrote:
> > Although there have been numerous complaints about the complexity of
> > parallel programming (especially over the past 5-10 years), the plain
> > truth is that the increme
On Sun, 2012-04-01 at 00:33 +0800, Paul E. McKenney wrote:
> Although there have been numerous complaints about the complexity of
> parallel programming (especially over the past 5-10 years), the plain
> truth is that the incremental complexity of parallel programming over
> that of sequential prog
On Sat, Mar 31, 2012 at 01:25:02PM -0700, Randy Dunlap wrote:
> On 03/31/2012 01:15 PM, Linas Vepstas wrote:
>
> >
> > Hi,
> >
> > I didn't actually try to compile the patch below; it didn't look like
> > C code so I wasn't sure what compiler to run it through. I guess maybe
> > its python? Ho
On 03/31/2012 01:15 PM, Linas Vepstas wrote:
>
> Hi,
>
> I didn't actually try to compile the patch below; it didn't look like
> C code so I wasn't sure what compiler to run it through. I guess maybe
> its python? However, I'm very sure that the patches are completely
> correct, because I read
On Sat, Mar 31, 2012 at 02:57:46PM -0500, Linas Vepstas wrote:
> Hi,
>
> I didn't actually try to compile the patch below; it didn't look like C
> code so I wasn't sure what compiler to run it through. I guess maybe its
> python? However, I'm very sure that the patches are completely correct,
>
Hi,
I didn't actually try to compile the patch below; it didn't look like
C code so I wasn't sure what compiler to run it through. I guess maybe
its python? However, I'm very sure that the patches are completely
correct, because I read them, and I also know Paul. And I've heard of
Thomas Gleix
On Sat, Mar 31, 2012 at 06:40:30PM +0200, Geert Uytterhoeven wrote:
> Hi Paul,
>
> On Sat, Mar 31, 2012 at 18:33, Paul E. McKenney
> wrote:
> > Although there have been numerous complaints about the complexity of
> > parallel programming (especially over the past 5-10 years), the plain
> > truth
Hi Paul,
On Sat, Mar 31, 2012 at 18:33, Paul E. McKenney
wrote:
> Although there have been numerous complaints about the complexity of
> parallel programming (especially over the past 5-10 years), the plain
> truth is that the incremental complexity of parallel programming over
> that of sequenti
Although there have been numerous complaints about the complexity of
parallel programming (especially over the past 5-10 years), the plain
truth is that the incremental complexity of parallel programming over
that of sequential programming is not as large as is commonly believed.
Despite that you m
On Mar 30, 2012, at 9:04 AM, Sebastian Andrzej Siewior wrote:
> On 03/29/2012 03:10 PM, Kumar Gala wrote:
>
>>> - include/configs/P1_P2_RDB.h
>>>
>>> #ifndef CONFIG_NAND_SPL
>>> #define CONFIG_SYS_NAND_BASE0xffa0
>>> #ifdef CONFIG_PHYS_64BIT
>>> #define CONFIG_SYS_NAND_BASE_PHYS
Ugh, sorry I forgot to attach the stress_32k.c test-case to this email.
Please find it attached to this one.
#include
#include
#include
#include
#include
#define ALLOC_BYTE 512*1024
#define COUNT 50
void *alloc_function_one( void *ptr );
void *alloc_function_two( void *ptr );
void *alloc_fu
Commit d065bd810b6deb67d4897a14bfe21f8eb526ba99
(mm: retry page fault when blocking on disk transfer) and
commit 37b23e0525d393d48a7d59f870b3bc061a30ccdb
(x86,mm: make pagefault killable)
The above commits introduced changes into the x86 pagefault handler
for making the page fault handler retryabl
On the project I'm working on, the hardware engineers put an I2C
device behind a unidirectional level translator. When I tried to
write to it, I was getting EIO due to the lack of receiver ack.
This is my hack to support this situation, based off 3.0.6 with a few
minor additions (none of which i
19 matches
Mail list logo
