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
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
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
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
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
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
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,
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 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,
>
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 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 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 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
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 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
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 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
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.
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
19 matches
Mail list logo
