On Fri, 2010-04-16 at 23:27 +0200, Peter Zijlstra wrote:
> > If the owner is actually running, it may do so for a very long time. It
> > looks to me that everybody trying to take the mutex will thus spin and
> > never get out of the spin loop until the owner stops running.
>
> The inner-most spin
>
> I've queued the below patch
Thanks. Should it make -stable as well ?
Cheers,
Ben.
> ---
> Subject: mutex: Don't spin when the owner CPU is offline or other weird cases
> From: Benjamin Herrenschmidt
> Date: Fri Apr 16 23:20:00 CEST 2010
>
> Due to recent load-balancer changes that delay
On Wed, 2010-04-14 at 12:56 +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2010-04-14 at 12:35 +1000, Benjamin Herrenschmidt wrote:
> > Hi Peter !
> >
> > I -may- have found a bug with mutex adaptative spinning. We hit it when
> > torture testing CPU unplug.
>
> .../...
>
> In fact, I wonder if
On Wed, 2010-04-14 at 12:35 +1000, Benjamin Herrenschmidt wrote:
> [PATCH] mutex: Don't spin when the owner CPU is offline or other weird cases
>
> The current code might spin forever if the CPU owning the mutex has been
> offlined, and the last CPU in the system is trying to acquire it, since
>
Currently some MPC85xx and MPC86xx boards fail to build without
CONFIG_PCI:
arch/powerpc/platforms/fsl_uli1575.c: In function 'quirk_final_uli5249':
arch/powerpc/platforms/fsl_uli1575.c:234: error: implicit declaration of
function 'pci_bus_for_each_resource'
arch/powerpc/platforms/fsl_uli1575.c:2
On Fri, Apr 16, 2010 at 10:48:09AM -0500, Scott Wood wrote:
> Anton Vorontsov wrote:
> >On Thu, Apr 15, 2010 at 03:05:08PM -0500, Scott Wood wrote:
> >>Kumar Gala wrote:
> >>>On Apr 15, 2010, at 1:45 PM, Anton Vorontsov wrote:
> Kumar,
>
> According to patchwork, this is now delegated
This is started as swsusp_32.S modifications, but the amount of #ifdefs
made the whole file horribly unreadable, so let's put the support into
its own separate file.
The code should be relatively easy to modify to support 44x BookEs as
well, but since I don't have any 44x to test, let's confine th
Anton Vorontsov wrote:
+ /* Invalidate TLB0 & TLB1 */
+ li r6,0x04
+ tlbivax 0,r6
+ TLBSYNC
+ li r6,0x0c
+ tlbivax 0,r6
+ TLBSYNC
Is this needed? Shouldn't the boot process have already given us a sane
TLB?
-Scott
_
Anton Vorontsov wrote:
On Thu, Apr 15, 2010 at 03:05:08PM -0500, Scott Wood wrote:
Kumar Gala wrote:
On Apr 15, 2010, at 1:45 PM, Anton Vorontsov wrote:
Kumar,
According to patchwork, this is now delegated to you. Do you
have any objections to merge this?
Would like Scott's Ack.
I think we
Hi,
is there somebody working on the MPC5554 [1] serial port driver? I could
only find linux/drivers/serial/mpc52xx_uart.c but I'm not sure whether
this could work together with the eSCI on-chip hardware module which
can be found in MPC5554 [2].
References:
[1] Freescale MPC5554
http://www.fr
On Wed, 2010-04-14 at 14:28 +1000, Michael Neuling wrote:
> > Right, so I suspect this will indeed break some things.
> >
> > We initially allowed 0 capacity for when a cpu is consumed by an RT task
> > and there simply isn't much capacity left, in that case you really want
> > to try and move lo
On Fri, Apr 16, 2010 at 12:38:43PM +0200, Peter Zijlstra wrote:
> On Thu, 2010-04-15 at 19:15 +0200, Frederic Weisbecker wrote:
> > > that looks rather ugly. Why not do a raw:
> > >
> > > this_cpu_inc(lockdep_stats.redundant_hardirqs_on);
> > >
> > > which basically open-codes debug_atomic_
This is started as swsusp_32.S modifications, but the amount of #ifdefs
made the whole file horribly unreadable, so let's put the support into
its own separate file.
The code should be relatively easy to modify to support 44x BookEs as
well, but since I don't have any 44x to test, let's confine th
On Thu, 2010-04-15 at 19:15 +0200, Frederic Weisbecker wrote:
> > that looks rather ugly. Why not do a raw:
> >
> > this_cpu_inc(lockdep_stats.redundant_hardirqs_on);
> >
> > which basically open-codes debug_atomic_inc(), but without the warning?
>
>
> Because that would open a race again
On Thu, Apr 15, 2010 at 03:53:53PM +0200, Roman Fietze wrote:
> Hello Bill,
>
> On Thursday 15 April 2010 15:01:59 Bill Gatliff wrote:
>
> > Are you talking about this code here?
> >
> > void
> > shadowUpdatePacked (ScreenPtr pScreen,
> > shadowBufPtr pBuf)
> >
Hi Anton,
On 4/15/2010 9:36 PM, Anton Vorontsov wrote:
This patch adds support for eTSEC 2.0 as found in P1020.
The changes include introduction of the group nodes for
the etsec nodes.
Signed-off-by: Sandeep Gopalpet
Signed-off-by: Anton Vorontsov
---
This is based on
http://www.bitshrine.org/
On Fre, 2010-04-16 at 08:14 +0200, Roman Fietze wrote:
>
> On Thursday 15 April 2010 18:07:03 Bill Gatliff wrote:
>
> > I would love it if you posted your code! Thanks!!
>
> In this source file I just added my own routines:
>
> Index: programs/Xserver/hw/xfree86/drivers/fbdev/fbdev.c
> ===
Hello Bill,
On Friday 16 April 2010 04:51:38 Bill Gatliff wrote:
> Apparently, there are several similar modifications that need to be
> made, ...
I'm SW-Engineer, so I assume HW, that's always a good bet. ;)
Please take care, that I forgot to tell you that my X server runs well
on a Futjitsu 8
Enable the sharing of MSI interrupt through AMP OSes in the mpc8572ds
dtses.
Signed-off-by: Zhao Chenhui
Signed-off-by: Li Yang
---
arch/powerpc/boot/dts/mpc8572ds_camp_core0.dts | 15 +--
arch/powerpc/boot/dts/mpc8572ds_camp_core1.dts |7 ++-
2 files changed, 15 insertion
19 matches
Mail list logo
