your prompt
response to this matter as the urgency
demands.
Yours faithfully,
John Cooper(QC)
25 Bedford ROW,
London,United Kingdom.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo inf
your prompt
response to this matter as the urgency
demands.
Yours faithfully,
John Cooper(QC)
25 Bedford ROW,
London,United Kingdom.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
Steven Rostedt wrote:
IIRC, only CALLER_ADDR0 is actually used (I've found that the others are
mostly unreliable).
I seem to recall more use was made of __builtin_return_address(n)
for 0 < n in the past compared to the current code. Likely for
shallow frames the 0 < n calls were potentially
Steven Rostedt wrote:
IIRC, only CALLER_ADDR0 is actually used (I've found that the others are
mostly unreliable).
I seem to recall more use was made of __builtin_return_address(n)
for 0 n in the past compared to the current code. Likely for
shallow frames the 0 n calls were potentially
Steven Rostedt wrote:
On Thu, 15 Nov 2007, Tim Bird wrote:
john cooper wrote:
The more daunting problem stems from limitations in the MIPS
ABI which makes the latency trace support problematic.
Rather than rehash the issue:
http://lists.linuxcoding.com/kernel/2005-q4/msg10163.html
Until
Steven Rostedt wrote:
On Thu, 15 Nov 2007, Tim Bird wrote:
john cooper wrote:
The more daunting problem stems from limitations in the MIPS
ABI which makes the latency trace support problematic.
Rather than rehash the issue:
http://lists.linuxcoding.com/kernel/2005-q4/msg10163.html
Until
Thomas Gleixner wrote:
I fear you are the one who is in charge to get mips working again :)
But as always, there are bad news and good news: As far as I heard
last week John Cooper is looking into this as well.
I'm not actively working on it but AFAIK I may have been
the last one to touch
Thomas Gleixner wrote:
I fear you are the one who is in charge to get mips working again :)
But as always, there are bad news and good news: As far as I heard
last week John Cooper is looking into this as well.
I'm not actively working on it but AFAIK I may have been
the last one to touch
Daniel Walker wrote:
I'm not sure I'd get into "bisecting" one big patch. Especially if you
new to the patches inner workings..
You can bisect by kernel version using the older patches but it's
clearly limited,
http://people.redhat.com/mingo/realtime-preempt/older/
Actually working on
Daniel Walker wrote:
I'm not sure I'd get into bisecting one big patch. Especially if you
new to the patches inner workings..
You can bisect by kernel version using the older patches but it's
clearly limited,
http://people.redhat.com/mingo/realtime-preempt/older/
Actually working on this
Gene Heskett wrote:
Humm, I wondering out loud if this is the video dma failure in tvtime?
Anyway, it applied cleanly over -33, and is building now, set for
mode=4.
On i386 the hw_irq_controller.end() handler
conditionally calls the function registered
for the hw_irq_controller.enable()
Gene Heskett wrote:
Humm, I wondering out loud if this is the video dma failure in tvtime?
Anyway, it applied cleanly over -33, and is building now, set for
mode=4.
On i386 the hw_irq_controller.end() handler
conditionally calls the function registered
for the hw_irq_controller.enable()
Ingo,
Attached is a patch for 51-28 which brings PPC
up to date for 2.6.12 PREEMPT_RT. My goal was to
get a more recent vintage of this work building and
minimally booting for PPC. Yet this has been stable
even under our internal stress tests. We now have
this running on 8560 and 8260 PPC
Ingo,
Attached is a patch for 51-28 which brings PPC
up to date for 2.6.12 PREEMPT_RT. My goal was to
get a more recent vintage of this work building and
minimally booting for PPC. Yet this has been stable
even under our internal stress tests. We now have
this running on 8560 and 8260 PPC
Steven Rostedt wrote:
On Sat, 2005-04-16 at 09:05 -0400, john cooper wrote:
Sven Dietrich wrote:
[...]
This one probably should be a raw_spinlock.
This lock is only held to protect access to the queues.
Since the queues are already priority ordered, there is
little benefit to ordering -the order
Sven Dietrich wrote:
/** A fuqueue, a prioritized wait queue usable from
kernel space. */
struct fuqueue {
spinlock_t lock;
struct plist wlist;
struct fuqueue_ops *ops;
};
Would the above spinlock_t be a raw_spinlock_t? This goes
back to my first question.
Sven Dietrich wrote:
/** A fuqueue, a prioritized wait queue usable from
kernel space. */
struct fuqueue {
spinlock_t lock;
struct plist wlist;
struct fuqueue_ops *ops;
};
Would the above spinlock_t be a raw_spinlock_t? This goes
back to my first question.
Steven Rostedt wrote:
On Sat, 2005-04-16 at 09:05 -0400, john cooper wrote:
Sven Dietrich wrote:
[...]
This one probably should be a raw_spinlock.
This lock is only held to protect access to the queues.
Since the queues are already priority ordered, there is
little benefit to ordering -the order
Daniel Walker wrote:
I'm not sure if this has changed at all in recent RT patches, but I've
noticed several issues popping up that are related to the timer
interrupt sending signals...
I've also seen BUG asserts kicking in on PPC (40-04-ish) in
signal delivery [actual receipt] paths.
Daniel Walker wrote:
I'm not sure if this has changed at all in recent RT patches, but I've
noticed several issues popping up that are related to the timer
interrupt sending signals...
I've also seen BUG asserts kicking in on PPC (40-04-ish) in
signal delivery [actual receipt] paths.
Frank Rowand wrote:
john cooper wrote:
... There is also a bug fix
contained for tlb_gather_mmu() which was causing debug
assertions to be generated in a path which attempted to
sleep with a non-zero preempt count.
Manish Lachwani mentioned to me that he faced the same issue
with the MIPS RT
Frank Rowand wrote:
john cooper wrote:
... There is also a bug fix
contained for tlb_gather_mmu() which was causing debug
assertions to be generated in a path which attempted to
sleep with a non-zero preempt count.
Manish Lachwani mentioned to me that he faced the same issue
with the MIPS RT
Ingo,
We've had a PPC port of your RT work underway with
a focus on trace instrumentation. This is based upon
realtime-preempt-2.6.11-rc2-V0.7.37-02. A diff is
attached.
To the extent possible the tracing facilities are the
same as your x86 work. In the process a few PPC/gcc
issues needed
Ingo,
We've had a PPC port of your RT work underway with
a focus on trace instrumentation. This is based upon
realtime-preempt-2.6.11-rc2-V0.7.37-02. A diff is
attached.
To the extent possible the tracing facilities are the
same as your x86 work. In the process a few PPC/gcc
issues needed
24 matches
Mail list logo
