On Mon, 2011-07-18 at 14:48 +0800, Shan Hai wrote:
> It could not fix the problem, refer the following reply for
> the reasons.
.../...
> > diff --git a/kernel/futex.c b/kernel/futex.c
> > index fe28dc2..02adff7 100644
> > --- a/kernel/futex.c
> > +++ b/kernel/futex.c
> > @@ -355,8 +355,8 @@ st
On 07/18/2011 03:01 PM, Benjamin Herrenschmidt wrote:
On Mon, 2011-07-18 at 14:48 +0800, Shan Hai wrote:
It could not fix the problem, refer the following reply for
the reasons.
.../...
diff --git a/kernel/futex.c b/kernel/futex.c
index fe28dc2..02adff7 100644
--- a/kernel/futex.c
+++ b/ke
On Mon, 2011-07-18 at 15:26 +0800, Shan Hai wrote:
>
> I am sorry I hadn't tried your newer patch, I tried it but it still
> could not work in my test environment, I will dig into and tell you
> why that failed later.
Ok, please let me know what you find !
> Yep, I know holding lots of ifdef's
An implementation of a code generator for BPF programs to speed up packet
filtering on PPC64, inspired by Eric Dumazet's x86-64 version.
Filter code is generated as an ABI-compliant function in module_alloc()'d mem
with stackframe & prologue/epilogue generated if required (simple filters don't
nee
Le lundi 18 juillet 2011 à 17:50 +1000, Matt Evans a écrit :
> An implementation of a code generator for BPF programs to speed up packet
> filtering on PPC64, inspired by Eric Dumazet's x86-64 version.
>
> Filter code is generated as an ABI-compliant function in module_alloc()'d mem
> with stackfr
Hi all,
After merging the final tree, today's linux-next build (powerpc
allysconfig) failed like this:
arch/powerpc/kernel/exceptions-64s.S: Assembler messages:
arch/powerpc/kernel/exceptions-64s.S:1151: Error: attempt to move .org backwards
arch/powerpc/kernel/exceptions-64s.S:1160: Error: attem
UPDATE: Minor update in Copyright assignment in misc_32.S
Added requirement of upstream kexec-tools.
Changes from v1: Uses a tmp mapping in the other address space to setup
the 1:1 mapping (suggested by Sebastian Andrzej Siewior).
Note 1: Should we do the same for kernel
On Mon, Jul 18, 2011 at 02:01:15PM +1000, Tony Breeds wrote:
> On Fri, Jul 15, 2011 at 11:40:27AM -0500, Ayman Elkhashab wrote:
>
> > @@ -1582,8 +1628,8 @@ static int __init ppc4xx_setup_one_pciex_POM(struct
> > ppc4xx_pciex_port *port,
> > dcr_write(port->dcrs, DCRO_PEGPL_OMR2BAH, la
Signed-off-by: Stefan Roese
---
arch/powerpc/boot/dts/yosemite.dts | 36
1 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/yosemite.dts
b/arch/powerpc/boot/dts/yosemite.dts
index 6492324..30bb475 100644
--- a/arch/powerpc
Not sure if this is arch-dependant. If not, I'll register on the kernel
mailing list.
I'm working with some legacy driver code (an IOCTL) that busy waits
after requesting an operation from an FPGA. It reads a register in a
loop until the FPGA has finished the operation. The operation is
supposed t
On Sat, 16 Jul 2011 03:25:47 +
"Chen, Tiejun" wrote:
> > -Original Message-
> > From: Scott Wood [mailto:scottw...@freescale.com]
> > Sent: Saturday, July 16, 2011 2:43 AM
> > To: Chen, Tiejun
> > Cc: Kumar Gala; linuxppc-...@ozlabs.org
> > Subject: Re: [v3 PATCH 1/1] booke/kprobe: m
From: Eric Dumazet
Date: Mon, 18 Jul 2011 10:39:35 +0200
> So in PPC SEEN_XREG only is to be set of X is read, not if written.
>
> So you dont have to set SEEN_XREG bit in this part :
Matt, do you want to integrate changes based upon Eric's feedback
here or do you want me to apply your patch as
Le lundi 18 juillet 2011 à 12:42 -0700, David Miller a écrit :
> From: Eric Dumazet
> Date: Mon, 18 Jul 2011 10:39:35 +0200
>
> > So in PPC SEEN_XREG only is to be set of X is read, not if written.
> >
> > So you dont have to set SEEN_XREG bit in this part :
>
> Matt, do you want to integrate c
Anton, could you test the below two patches on that machine?
It should make things boot again, while I don't have a machine nearly
big enough to trigger any of this, I tested the new code paths by
setting FORCE_SD_OVERLAP in /debug/sched_features. Although any review
of the error paths would be mu
On 19/07/11 05:42, David Miller wrote:
> From: Eric Dumazet
> Date: Mon, 18 Jul 2011 10:39:35 +0200
>
>> So in PPC SEEN_XREG only is to be set of X is read, not if written.
>>
>> So you dont have to set SEEN_XREG bit in this part :
>
> Matt, do you want to integrate changes based upon Eric's fee
On Mon, Jul 18, 2011 at 08:31:01AM -0500, Ayman El-Khashab wrote:
> Yes, but I think that is correct for it to be "1". The data
> sheets for these parts that I checked had bit 1 marked as
> reserved. Only OMR1MSKL and OMR3MSKL had extra definitions
> such as the _IO and _UOT. The parts I checke
An implementation of a code generator for BPF programs to speed up packet
filtering on PPC64, inspired by Eric Dumazet's x86-64 version.
Filter code is generated as an ABI-compliant function in module_alloc()'d mem
with stackframe & prologue/epilogue generated if required (simple filters don't
nee
We already did it for hard IRQs but it looks like we forgot
to do it for softirqs. Without this, we would lose flags
such as TIF_NEED_RESCHED set using current_thread_info()
by something running of a softirq.
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/kernel/irq.c |7 +++
1 f
On 07/18/2011 03:36 PM, Benjamin Herrenschmidt wrote:
On Mon, 2011-07-18 at 15:26 +0800, Shan Hai wrote:
I am sorry I hadn't tried your newer patch, I tried it but it still
could not work in my test environment, I will dig into and tell you
why that failed later.
Ok, please let me know what you
On Tue, 2011-07-19 at 11:30 +0800, Shan Hai wrote:
> On 07/18/2011 03:36 PM, Benjamin Herrenschmidt wrote:
> > On Mon, 2011-07-18 at 15:26 +0800, Shan Hai wrote:
> >> I am sorry I hadn't tried your newer patch, I tried it but it still
> >> could not work in my test environment, I will dig into and
The futex code currently attempts to write to user memory within
a pagefault disabled section, and if that fails, tries to fix it
up using get_user_pages().
This doesn't work on archs where the dirty and young bits are
maintained by software, since they will gate access permission
in the TLB, and
Andrew, Anybody ? Can I have an -mm ack for this ?
Cheers,
Ben.
On Tue, 2011-06-28 at 14:54 -0500, Becky Bruce wrote:
> From: Becky Bruce
>
> This:
>
> vma->vm_pgoff & ~(huge_page_mask(h) >> PAGE_SHIFT)
>
> is incorrect on 32-bit. It causes us to & the pgoff with
> something that looks like
On Mon, 18 Jul 2011 23:35:56 +0200
Peter Zijlstra wrote:
> Anton, could you test the below two patches on that machine?
>
> It should make things boot again, while I don't have a machine nearly
> big enough to trigger any of this, I tested the new code paths by
> setting FORCE_SD_OVERLAP in /deb
On 07/19/2011 12:29 PM, Benjamin Herrenschmidt wrote:
The futex code currently attempts to write to user memory within
a pagefault disabled section, and if that fails, tries to fix it
up using get_user_pages().
This doesn't work on archs where the dirty and young bits are
maintained by software,
On 07/19/2011 12:29 PM, Benjamin Herrenschmidt wrote:
The futex code currently attempts to write to user memory within
a pagefault disabled section, and if that fails, tries to fix it
up using get_user_pages().
This doesn't work on archs where the dirty and young bits are
maintained by software,
On Tue, 2011-07-19 at 13:17 +0800, Shan Hai wrote:
> The patch works, but I have certain confusions,
> - Do we want to handle_mm_fault on each futex_lock_pi
> even though in most cases there is no write permission
> fixup's needed?
Don't we only ever call this when futex_atomic_op_inuse
On 07/19/2011 01:24 PM, Benjamin Herrenschmidt wrote:
On Tue, 2011-07-19 at 13:17 +0800, Shan Hai wrote:
The patch works, but I have certain confusions,
- Do we want to handle_mm_fault on each futex_lock_pi
even though in most cases there is no write permission
fixup's needed?
Don'
Our USB Device Controller (UDC) driver seems to get stuck in a loop waiting
for the CPM Command Register to indicate that the CPM has finished executing
a command. (It should do this by setting the cpmcr 'Command Done' bit).
This only happens if I disable the 'Early Debug' Kernel Hacking .config
Le mardi 19 juillet 2011 à 12:13 +1000, Matt Evans a écrit :
> An implementation of a code generator for BPF programs to speed up packet
> filtering on PPC64, inspired by Eric Dumazet's x86-64 version.
>
> Filter code is generated as an ABI-compliant function in module_alloc()'d mem
> with stackfr
On Jul 18, 2011, at 9:13 PM, Matt Evans wrote:
> An implementation of a code generator for BPF programs to speed up packet
> filtering on PPC64, inspired by Eric Dumazet's x86-64 version.
>
> Filter code is generated as an ABI-compliant function in module_alloc()'d mem
> with stackframe & prolog
30 matches
Mail list logo
