> -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: make program
> exception to use one dedicated exception stack
>
> On F
On Tue, Jun 28, 2011 at 09:47:11AM -0400, Josh Boyer wrote:
> The *p variable is declared and used to save inb->ptr, however p is
> later never used. This has been the case since commit 6c0f3676 and can
> lead to build failures with -Werror=unused-but-set-variable:
>
> flattree.c: In functi
On Tue, Jun 28, 2011 at 08:47:09AM -0400, Josh Boyer wrote:
> Commit 376ab6f2 removed the old style check functionality from DTC,
> however the check option and variable were not removed. This leads to
> build failures when -Werror=unused-but-set-variable is specified:
>
> dtc.c: In functio
On Fri, 2011-07-15 at 11:32 -0400, Shan Hai wrote:
>
> I agree with you, the problem could be triggered by accessing
> any user space page which has kernel read only permission
> in the page fault disabled context, the problem also affects
> architectures which depend on SW dirty/young tracking as
On Fri, 2011-07-15 at 11:32 +0100, David Laight wrote:
> > The fault causing futex_atomic_cmpxchg_inatomic() is
> > protected by pagefault_disable(), so the page fault handler has
> > no chance to toggle the SW dirty/young tracking.
>
> Perhaps that is the bug!
> Whatever pagefault_disable() does,
Hi,
Anyone know what it means when a dual core dual cpu (total 4 cores)
beeps three times on startup? The white power led also blinks 3 times
every few seconds.
The machine in question is a recent acquisition. I have got it to boot once.
Thanks!
kevin
___
On Sat, Jul 09, 2011 at 12:14:09PM +0200, Anatolij Gustschin wrote:
> On Wed, 6 Jul 2011 11:52:45 -0600
> Grant Likely wrote:
>
> > On Mon, May 23, 2011 at 11:25:30AM +0200, Anatolij Gustschin wrote:
> > > The mpc52xx_gpio driver currently supports 8 wakeup GPIOs and 32
> > > simple GPIOs. Extend
On Fri, 15 Jul 2011 13:28:15 +0800
tiejun.chen wrote:
> Kumar Gala wrote:
> > I'm still very confused why we need a unique stack frame for kprobe/program
> > exceptions on book-e devices.
>
> Its a bug at least for Book-E.
But why only booke? There's nothing booke-specific about the stwu
inst
On Fri, 2011-07-15 at 11:32 +0100, David Laight wrote:
> > The fault causing futex_atomic_cmpxchg_inatomic() is
> > protected by pagefault_disable(), so the page fault handler has
> > no chance to toggle the SW dirty/young tracking.
>
> Perhaps that is the bug!
> Whatever pagefault_disable() does,
On Fri, 2011-07-15 at 11:18 -0400, Shan Hai wrote:
> >> + vma = find_vma(mm, address);
> > Uhm, find_vma() needs mmap_sem, and futex_atomic_cmpxchg_inatomic() is
> > most certainly not called with that lock held.
> >
>
> My fault, that will be fixed in the V2 patch.
But you cannot, the function
From: Ayman El-Khashab
Adds a register to the config space for the 460sx. Changes the vc0
detect to a pll detect. maps configuration space to test the link
status. changes the setup to enable gen2 devices to operate at gen2
speeds. fixes mapping that was not correct for the 460sx. added
bit
On 07/15/2011 06:32 AM, David Laight wrote:
The fault causing futex_atomic_cmpxchg_inatomic() is
protected by pagefault_disable(), so the page fault handler has
no chance to toggle the SW dirty/young tracking.
Perhaps that is the bug!
Whatever pagefault_disable() does, it shouldn't disable the
On 07/15/2011 06:23 AM, Peter Zijlstra wrote:
On Fri, 2011-07-15 at 16:07 +0800, Shan Hai wrote:
The kernel has no write permission on COW pages by default on e500 core, this
will cause endless loop in futex_lock_pi, because futex code assumes the kernel
has write permission on COW pages. Grant
> The fault causing futex_atomic_cmpxchg_inatomic() is
> protected by pagefault_disable(), so the page fault handler has
> no chance to toggle the SW dirty/young tracking.
Perhaps that is the bug!
Whatever pagefault_disable() does, it shouldn't disable the
SW dirty/young tracking - which should
On Fri, 2011-07-15 at 16:07 +0800, Shan Hai wrote:
> The kernel has no write permission on COW pages by default on e500 core, this
> will cause endless loop in futex_lock_pi, because futex code assumes the
> kernel
> has write permission on COW pages. Grant write permission to the kernel on COW
>
On 07/15/2011 05:50 PM, Peter Zijlstra wrote:
On Fri, 2011-07-15 at 17:08 +0800, Shan Hai wrote:
The whole scenario should be,
- the child process triggers a page fault at the first time access to
the lock, and it got its own writable page, but its *clean* for
the reason just for che
On Fri, 2011-07-15 at 17:08 +0800, Shan Hai wrote:
> The whole scenario should be,
> - the child process triggers a page fault at the first time access to
> the lock, and it got its own writable page, but its *clean* for
> the reason just for checking the status of the lock.
> I am s
On Fri, 2011-07-15 at 17:08 +0800, Shan Hai wrote:
> The whole scenario should be,
> - the child process triggers a page fault at the first time access to
> the lock, and it got its own writable page, but its *clean* for
> the reason just for checking the status of the lock.
> I am s
On Fri, 2011-07-15 at 16:38 +0800, MailingLists wrote:
> A page could be set to read only by the kernel (supervisor in the
> powerpc
> literature) on the e500, and that's what the kernel do. Set
> SW(supervisor
> write) bit in the TLB entry to grant write permission to the kernel on
> a
> page.
>
On 07/15/2011 04:44 PM, Peter Zijlstra wrote:
On Fri, 2011-07-15 at 16:38 +0800, MailingLists wrote:
On 07/15/2011 04:20 PM, Peter Zijlstra wrote:
On Fri, 2011-07-15 at 16:07 +0800, Shan Hai wrote:
The following test case could reveal a bug in the futex_lock_pi()
BUG: On FUTEX_LOCK_PI, there
On Fri, 2011-07-15 at 10:20 +0200, Peter Zijlstra wrote:
> But but but but, that get_user_pages(.write=1, .force=0) should result
> in a COW break, getting our own writable page.
>
> What is this e500 thing smoking that this doesn't work?
Right. That should have triggered the cow & flushed the T
On Fri, 2011-07-15 at 16:38 +0800, MailingLists wrote:
> On 07/15/2011 04:20 PM, Peter Zijlstra wrote:
> > On Fri, 2011-07-15 at 16:07 +0800, Shan Hai wrote:
> >> The following test case could reveal a bug in the futex_lock_pi()
> >>
> >> BUG: On FUTEX_LOCK_PI, there is a infinite loop in the futex
On Fri, 2011-07-15 at 10:45 +1000, Anton Blanchard wrote:
> Hi,
>
> > Urgh.. so those spans are generated by sched_domain_node_span(), and
> > it looks like that simply picks the 15 nearest nodes to the one we've
> > got without consideration for overlap with previously generated spans.
>
> I do
On 07/15/2011 04:20 PM, Peter Zijlstra wrote:
On Fri, 2011-07-15 at 16:07 +0800, Shan Hai wrote:
The following test case could reveal a bug in the futex_lock_pi()
BUG: On FUTEX_LOCK_PI, there is a infinite loop in the futex_lock_pi()
on Powerpc e500 core.
Cause: The linux kernel on the
On Fri, 2011-07-15 at 16:07 +0800, Shan Hai wrote:
>
> The following test case could reveal a bug in the futex_lock_pi()
>
> BUG: On FUTEX_LOCK_PI, there is a infinite loop in the futex_lock_pi()
> on Powerpc e500 core.
> Cause: The linux kernel on the e500 core has no write permission o
The kernel has no write permission on COW pages by default on e500 core, this
will cause endless loop in futex_lock_pi, because futex code assumes the kernel
has write permission on COW pages. Grant write permission to the kernel on COW
pages when access violation page fault occurs.
Signed-off-by:
The following test case could reveal a bug in the futex_lock_pi()
BUG: On FUTEX_LOCK_PI, there is a infinite loop in the futex_lock_pi()
on Powerpc e500 core.
Cause: The linux kernel on the e500 core has no write permission on
the COW page, refer the head comment of the following
27 matches
Mail list logo
