Hi,
On Fri, 2009-07-31 at 16:10 +1000, David Gibson wrote:
> On Mon, Jul 27, 2009 at 05:41:52AM +0530, K.Prasad wrote:
> > Hi David,
> > I'm back with a new version of patches after a brief hiatus!
> >
> > After much deliberation about modifying the code to change the timing of
> > signal
>
Hi Tobias,
On 2/28/24 16:10, Tobias Huschle wrote:
> The previously used CFS scheduler gave tasks that were woken up an
> enhanced chance to see runtime immediately by deducting a certain value
> from its vruntime on runqueue placement during wakeup.
>
> This property was used by some, at least v
On 3/14/24 13:45, Tobias Huschle wrote:
> On Fri, Mar 08, 2024 at 03:11:38PM +0000, Luis Machado wrote:
>> On 2/28/24 16:10, Tobias Huschle wrote:
>>>
>>> Questions:
>>> 1. The kworker getting its negative lag occurs in the following scenario
>>>-
On 3/20/24 07:04, Tobias Huschle wrote:
> On Tue, Mar 19, 2024 at 02:41:14PM +0100, Vincent Guittot wrote:
>> On Tue, 19 Mar 2024 at 10:08, Tobias Huschle wrote:
>>>
>>> On 2024-03-18 15:45, Luis Machado wrote:
>>>> On 3/14/24 13:45, Tobias Huschle wrote:
&
Hi,
This is a patch that has been sitting idle for quite some time. I
decided to move it further because it is something useful. It was
originally written by Michel Darneille, based off of 2.6.16.
The original patch, though, was not compatible with the current DABR
logic. DABR's are used to imple
Thanks for the inlining tip. It should be now. :-)
So, basically we are looking at a cleaner and much better interface to
set such hardware features? That's something that would greatly improve
the communication from, say, GDB to the kernel regarding these
facilities.
Regards,
Luis
On Wed, 2008-
On Thu, 2008-05-22 at 13:51 +1000, Paul Mackerras wrote:
> Luis Machado writes:
>
> > This is a patch that has been sitting idle for quite some time. I
> > decided to move it further because it is something useful. It was
> > originally written by Michel Darnei
On Wed, 2008-05-21 at 23:46 -0700, Roland McGrath wrote:
> > I would think there would be a different REQUEST value to mean "set a
> > hardware breakpoint". Roland McGrath (cc'd) might be able to tell us
> > what other architectures do.
>
> Other architectures don't give a good model to follow.
e masks on the
> @@ -312,8 +316,8 @@ enum {
>
> EMAC_FTRS_POSSIBLE =
> #ifdef CONFIG_IBM_NEW_EMAC_EMAC4
> - EMAC_FTR_EMAC4 | EMAC_FTR_HAS_NEW_STACR|
> - EMAC_FTR_STACR_OC_INVERT|
> + EMAC_FTR_EMAC4 | EMAC_FTR_HAS_NEW_STACR |
> + EMAC_FTR
On Thu, 2008-05-22 at 13:51 +1000, Paul Mackerras wrote:
> Luis Machado writes:
>
> > This is a patch that has been sitting idle for quite some time. I
> > decided to move it further because it is something useful. It was
> > originally written by Michel Darnei
Hi guys,
Did anyone have a chance to go over this patch? Looking forward to
receive feedbacks on it.
Thanks!
Regards,
Luis
On Fri, 2008-06-20 at 17:14 -0300, Luis Machado wrote:
> On Thu, 2008-05-22 at 13:51 +1000, Paul Mackerras wrote:
> > Luis Machado writes:
> >
> > &
y.
Sometimes the watchpoint won't trigger, even though the monitored
variable's value was modified.
Appreciate your feedback.
Best regards,
--
Luis Machado
LoP Toolchain
Software Engineer
IBM Linux Technology Center
___
Linuxppc-dev mailing li
ns.
Regards,
--
Luis Machado
Software Engineer
IBM Linux Technology Center
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
, which i don't think have DABRX registers. I guess it's the
almost the same CPU as G5's.
Regards,
--
Luis Machado
Software Engineer
IBM Linux Technology Center
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
, i tested the binary against the 2.6.25-rc4 kernel. It
still fails. So this is really an open bug for PPC.
--
Luis Machado
Software Engineer
IBM Linux Technology Center
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
On Wed, 2008-03-12 at 23:30 +0100, Jens Osterkamp wrote:
> > Just to make sure, i tested the binary against the 2.6.25-rc4 kernel. It
> > still fails. So this is really an open bug for PPC.
>
> On a Cell- or 970-based machine ?
>
> Gruß,
> Jens
On a 970-based m
> This doesn't look right for how it's coded. This would be the
> CONFIG_4xx || CONFIG_BOOKE case, but CONFIG_4xx includes PowerPC 405.
> That has a different bit layout among the DBCR registers. Namely, on
> 405 you would be clearing the TDE and IAC1 events because the DAC
> events are in DBCR1
ed on a 440 Taishan board and
on a PPC970. Both worked as they should. Ok?
Signed-off-by: Luis Machado <[EMAIL PROTECTED]>
Index: linux-2.6.26/arch/powerpc/kernel/process.c
===
--- linux-2.6.26.orig/arch/powerpc/kernel/process.
> Some comment, first the above negate conditional
> looks rather ugly, I'd rather do a
>
> #if defined(CONFIG_4xx) || defined(CONFIG_BOOKE)
> dbcr0 case
> #else
> dabr case
> #endif
Yes, it makes sense. I'll switch it around.
> second I wonder why we have the notify_die only for one
t; josh
Yes, sorry. I wasn't aware of this specific define value. It makes
things easier to support 405's later.
Like so?
This addresses Christoph's comments as well.
Signed-off-by: Luis Machado <[EMAIL PROTECTED]>
Works for me.
I presume you had positive results on the Book-E as well.
By the way, thanks for cleaning it up.
Luis
On Fri, 2008-07-25 at 14:27 -0500, Kumar Gala wrote:
> * CONFIG_BOOKE is selected by CONFIG_44x so we dont need both
> * Fixed a few comments
> * Go back to only using DBCR0_IDM t
21 matches
Mail list logo
