* Stephen C. Tweedie <[EMAIL PROTECTED]> wrote:
> On Fri, 2005-08-26 at 12:20, Steven Rostedt wrote:
>
> > > could you try a), how clean does it get? Personally i'm much more in
> > > favor of cleanliness. On the vanilla kernel a spinlock is zero bytes on
> > > UP [the most RAM-sensitive
Hi,
On Fri, 2005-08-26 at 12:20, Steven Rostedt wrote:
> > could you try a), how clean does it get? Personally i'm much more in
> > favor of cleanliness. On the vanilla kernel a spinlock is zero bytes on
> > UP [the most RAM-sensitive platform], and it's a word on typical SMP.
It's a word,
Hi,
On Fri, 2005-08-26 at 05:24, Steven Rostedt wrote:
> Well, I just spent several hours trying to use the b_update_lock in
> implementing something to replace the bit spinlocks for RT. It's
> getting really ugly and I just hit a stone wall.
>
> The problem is that I have two locks to work
Hi,
On Fri, 2005-08-26 at 12:20, Steven Rostedt wrote:
could you try a), how clean does it get? Personally i'm much more in
favor of cleanliness. On the vanilla kernel a spinlock is zero bytes on
UP [the most RAM-sensitive platform], and it's a word on typical SMP.
It's a word, maybe;
Hi,
On Fri, 2005-08-26 at 05:24, Steven Rostedt wrote:
Well, I just spent several hours trying to use the b_update_lock in
implementing something to replace the bit spinlocks for RT. It's
getting really ugly and I just hit a stone wall.
The problem is that I have two locks to work with. A
* Stephen C. Tweedie [EMAIL PROTECTED] wrote:
On Fri, 2005-08-26 at 12:20, Steven Rostedt wrote:
could you try a), how clean does it get? Personally i'm much more in
favor of cleanliness. On the vanilla kernel a spinlock is zero bytes on
UP [the most RAM-sensitive platform], and
On Fri, 2005-08-26 at 08:08 +0200, Ingo Molnar wrote:
> * Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> > So, the only other solutions that I can think of is:
> >
> > a) add yet another (bloat) lock to the buffer head.
> >
> > b) Still use your b_update_lock for the jbd_lock_bh_journal_head and
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> So, the only other solutions that I can think of is:
>
> a) add yet another (bloat) lock to the buffer head.
>
> b) Still use your b_update_lock for the jbd_lock_bh_journal_head and
> change the jbd_lock_bh_state to what I discussed earlier, and
* Steven Rostedt [EMAIL PROTECTED] wrote:
So, the only other solutions that I can think of is:
a) add yet another (bloat) lock to the buffer head.
b) Still use your b_update_lock for the jbd_lock_bh_journal_head and
change the jbd_lock_bh_state to what I discussed earlier, and that
On Fri, 2005-08-26 at 08:08 +0200, Ingo Molnar wrote:
* Steven Rostedt [EMAIL PROTECTED] wrote:
So, the only other solutions that I can think of is:
a) add yet another (bloat) lock to the buffer head.
b) Still use your b_update_lock for the jbd_lock_bh_journal_head and
change the
On Fri, 2005-08-12 at 14:58 +0200, Ingo Molnar wrote:
> FYI, in -53-05 i've added a bh->b_update_lock, which enabled me to get
> rid of the bitlock ugliness in fs/buffer.c. Maybe it could be used to
> have a better fix for the jbd bitlock thing too?
Well, I just spent several hours trying to
On Fri, 2005-08-12 at 14:58 +0200, Ingo Molnar wrote:
FYI, in -53-05 i've added a bh-b_update_lock, which enabled me to get
rid of the bitlock ugliness in fs/buffer.c. Maybe it could be used to
have a better fix for the jbd bitlock thing too?
Well, I just spent several hours trying to use
On Sat, Aug 06, 2005 at 11:05:35PM -0400, Lee Revell wrote:
> zOn Fri, 2005-08-05 at 12:59 +0200, Ingo Molnar wrote:
> > ok, looks good - i've applied it and released the -52-14 PREEMPT_RT
> > patch.
> >
>
> Does not compile if RCU stats are enabled but torture test disabled.
My bad. Updated
On Sat, Aug 06, 2005 at 11:05:35PM -0400, Lee Revell wrote:
zOn Fri, 2005-08-05 at 12:59 +0200, Ingo Molnar wrote:
ok, looks good - i've applied it and released the -52-14 PREEMPT_RT
patch.
Does not compile if RCU stats are enabled but torture test disabled.
My bad. Updated RCU-only
zOn Fri, 2005-08-05 at 12:59 +0200, Ingo Molnar wrote:
> ok, looks good - i've applied it and released the -52-14 PREEMPT_RT
> patch.
>
Does not compile if RCU stats are enabled but torture test disabled.
Lee
--- linux-2.6.13-rc4/fs/proc/proc_misc.c.orig 2005-08-06 22:59:46.0
-0400
zOn Fri, 2005-08-05 at 12:59 +0200, Ingo Molnar wrote:
ok, looks good - i've applied it and released the -52-14 PREEMPT_RT
patch.
Does not compile if RCU stats are enabled but torture test disabled.
Lee
--- linux-2.6.13-rc4/fs/proc/proc_misc.c.orig 2005-08-06 22:59:46.0
-0400
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> Ingo,
>
> This was my final version of the softlockup patch. Do you have any
> comments on it? I wasn't sure if you were waiting for any more debate
> on this patch or not.
ok, looks good - i've applied it and released the -52-14 PREEMPT_RT
* Steven Rostedt [EMAIL PROTECTED] wrote:
Ingo,
This was my final version of the softlockup patch. Do you have any
comments on it? I wasn't sure if you were waiting for any more debate
on this patch or not.
ok, looks good - i've applied it and released the -52-14 PREEMPT_RT
patch.
AIL PROTECTED]>
To: Ingo Molnar <[EMAIL PROTECTED]>
Cc: linux-kernel@vger.kernel.org, Daniel Walker <[EMAIL PROTECTED]>
Subject: Re: [patch] Real-Time Preemption, -RT-2.6.13-rc4-V0.7.52-01
Date: Wed, 03 Aug 2005 12:44:07 -0400
Ingo,
Doing some more tests on the patch, I found
On 7/30/05, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> i have released the -V0.7.52-01 Real-Time Preemption patch, which can be
> downloaded from the usual place:
> ...
> reports, patches, suggestions welcome.
I can't get it to run on x86_64. The kernel won't build with
"voluntary preemption"
On 7/30/05, Ingo Molnar [EMAIL PROTECTED] wrote:
i have released the -V0.7.52-01 Real-Time Preemption patch, which can be
downloaded from the usual place:
...
reports, patches, suggestions welcome.
I can't get it to run on x86_64. The kernel won't build with
voluntary preemption enabled,
PROTECTED]
To: Ingo Molnar [EMAIL PROTECTED]
Cc: linux-kernel@vger.kernel.org, Daniel Walker [EMAIL PROTECTED]
Subject: Re: [patch] Real-Time Preemption, -RT-2.6.13-rc4-V0.7.52-01
Date: Wed, 03 Aug 2005 12:44:07 -0400
Ingo,
Doing some more tests on the patch, I found that I don't like the
placement
Ingo,
Doing some more tests on the patch, I found that I don't like the
placement in sched.c of the touch_light_softlockup_watchdog. I figure
that it may be better to put in into __schedule instead. This really
shows where a task is taken off the run queue.
-- Steve
New patch: I've only tested
On Wed, 2005-08-03 at 11:15 -0400, Steven Rostedt wrote:
> I tested this patch by switching the kjournald to FIFO prio 30 and doing
> a make of the kernel and "find / -name vmlinux", but this took 40
> minutes to cause the deadlock. Attached is a dumb module that creates a
> thread and spins. If
On Wed, 2005-08-03 at 10:50 -0400, Steven Rostedt wrote:
> Ingo,
>
> Here it is. The patch rewriten to use user_mode instead of arch
> dependent modifications. It seems to work just like my previous patch.
I tested this patch by switching the kjournald to FIFO prio 30 and doing
a make of the
On Wed, 2005-08-03 at 06:30 -0400, Steven Rostedt wrote:
> On Tue, 2005-08-02 at 19:58 -0700, Daniel Walker wrote:
> > The stack trace should show where the problem is . If it's in the kernel
> > we will see kernel functions before do_IRQ() , if it's just a whacked
> > out task then do_IRQ() would
Ingo,
Here it is. The patch rewriten to use user_mode instead of arch
dependent modifications. It seems to work just like my previous patch.
On Tue, 2005-08-02 at 19:58 -0700, Daniel Walker wrote:
>
> I can't speak for everyone else, but I would want to catch both. That
> way we'll know if
On Tue, 2005-08-02 at 19:58 -0700, Daniel Walker wrote:
> The stack trace should show where the problem is . If it's in the kernel
> we will see kernel functions before do_IRQ() , if it's just a whacked
> out task then do_IRQ() would be first in the stack trace .
The problem is not
On Tue, 2005-08-02 at 19:58 -0700, Daniel Walker wrote:
The stack trace should show where the problem is . If it's in the kernel
we will see kernel functions before do_IRQ() , if it's just a whacked
out task then do_IRQ() would be first in the stack trace .
The problem is not differentiating
Ingo,
Here it is. The patch rewriten to use user_mode instead of arch
dependent modifications. It seems to work just like my previous patch.
On Tue, 2005-08-02 at 19:58 -0700, Daniel Walker wrote:
I can't speak for everyone else, but I would want to catch both. That
way we'll know if it's
On Wed, 2005-08-03 at 06:30 -0400, Steven Rostedt wrote:
On Tue, 2005-08-02 at 19:58 -0700, Daniel Walker wrote:
The stack trace should show where the problem is . If it's in the kernel
we will see kernel functions before do_IRQ() , if it's just a whacked
out task then do_IRQ() would be
On Wed, 2005-08-03 at 10:50 -0400, Steven Rostedt wrote:
Ingo,
Here it is. The patch rewriten to use user_mode instead of arch
dependent modifications. It seems to work just like my previous patch.
I tested this patch by switching the kjournald to FIFO prio 30 and doing
a make of the kernel
On Wed, 2005-08-03 at 11:15 -0400, Steven Rostedt wrote:
I tested this patch by switching the kjournald to FIFO prio 30 and doing
a make of the kernel and find / -name vmlinux, but this took 40
minutes to cause the deadlock. Attached is a dumb module that creates a
thread and spins. If you
Ingo,
Doing some more tests on the patch, I found that I don't like the
placement in sched.c of the touch_light_softlockup_watchdog. I figure
that it may be better to put in into __schedule instead. This really
shows where a task is taken off the run queue.
-- Steve
New patch: I've only tested
On Tue, 2005-08-02 at 22:42 -0400, Steven Rostedt wrote:
> On Tue, 2005-08-02 at 19:25 -0700, Daniel Walker wrote:
> > On Tue, 2005-08-02 at 20:00 -0400, Steven Rostedt wrote:
> > > On Tue, 2005-08-02 at 16:38 -0700, Daniel Walker wrote:
> > > > Couldn't you just do some math off
On Tue, 2005-08-02 at 19:25 -0700, Daniel Walker wrote:
> On Tue, 2005-08-02 at 20:00 -0400, Steven Rostedt wrote:
> > On Tue, 2005-08-02 at 16:38 -0700, Daniel Walker wrote:
> > > Couldn't you just do some math off current->timestamp to see how long
> > > the task has been running? This per arch
On Tue, 2005-08-02 at 20:00 -0400, Steven Rostedt wrote:
> On Tue, 2005-08-02 at 16:38 -0700, Daniel Walker wrote:
> > Couldn't you just do some math off current->timestamp to see how long
> > the task has been running? This per arch stuff seems a bit invasive..
>
> The thing is, I'm tracking how
Keith Owens wrote:
On Tue, 02 Aug 2005 18:12:27 -0700,
George Anzinger wrote:
How about something like:
if (current + THREAD_SIZE/sizeof(long) - (regs + sizeof(pt_regs)) >
MAGIC)
current points to the current struct task, regs points to the kernel
stack. Those two data areas can
On Tue, 02 Aug 2005 18:12:27 -0700,
George Anzinger wrote:
>How about something like:
> if (current + THREAD_SIZE/sizeof(long) - (regs + sizeof(pt_regs)) >
> MAGIC)
current points to the current struct task, regs points to the kernel
stack. Those two data areas can be completely
Steven Rostedt wrote:
On Tue, 2005-08-02 at 16:38 -0700, Daniel Walker wrote:
Couldn't you just do some math off current->timestamp to see how long
the task has been running? This per arch stuff seems a bit invasive..
The thing is, I'm tracking how long the task is running in the kernel
On Tue, 2005-08-02 at 16:38 -0700, Daniel Walker wrote:
> Couldn't you just do some math off current->timestamp to see how long
> the task has been running? This per arch stuff seems a bit invasive..
The thing is, I'm tracking how long the task is running in the kernel
without doing a schedule.
Couldn't you just do some math off current->timestamp to see how long
the task has been running? This per arch stuff seems a bit invasive..
Daniel
On Tue, 2005-08-02 at 15:45 -0400, Steven Rostedt wrote:
> On Tue, 2005-08-02 at 12:19 +0200, Ingo Molnar wrote:
> > * Steven Rostedt <[EMAIL
On Tue, 2005-08-02 at 15:45 -0400, Steven Rostedt wrote:
> Here it is (Finally). I just had to be patient with the kjournal
> lockup. I had to wait some time before the lockup occurred, but when it
> did, I got my message out:
Oh yeah, this goes against 52-10.
-- Steve
-
To unsubscribe from
On Tue, 2005-08-02 at 12:19 +0200, Ingo Molnar wrote:
> * Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> > In my custom kernel, I have a wchan field of the task that records
> > where the task calls something that might schedule. This way I can see
> > where things locked up if I don't have a
On Tue, Aug 02, 2005 at 11:47:13AM -0400, Lee Revell wrote:
> On Tue, 2005-08-02 at 17:44 +0200, Vojtech Pavlik wrote:
> > Is your keyboard interrupt (irq #1) working correctly? If not, then the
> > keyboard controller is polled at 20Hz to compensate for lost interrupts,
> > which would make it
On 8/2/05, Lee Revell <[EMAIL PROTECTED]> wrote:
> On Tue, 2005-08-02 at 10:20 -0400, Steven Rostedt wrote:
> > On Tue, 2005-08-02 at 10:05 -0400, Lee Revell wrote:
> > > On Tue, 2005-08-02 at 09:56 -0400, Steven Rostedt wrote:
> > > > On Mon, 2005-08-01 at 00:45 -0400, Lee Revell wrote:
> > > > >
On Tue, Aug 02, 2005 at 11:37:41AM -0400, Lee Revell wrote:
> On Tue, 2005-08-02 at 10:20 -0400, Steven Rostedt wrote:
> > On Tue, 2005-08-02 at 10:05 -0400, Lee Revell wrote:
> > > On Tue, 2005-08-02 at 09:56 -0400, Steven Rostedt wrote:
> > > > On Mon, 2005-08-01 at 00:45 -0400, Lee Revell
On Tue, 2005-08-02 at 11:47 -0400, Lee Revell wrote:
> On Tue, 2005-08-02 at 17:44 +0200, Vojtech Pavlik wrote:
> > Is your keyboard interrupt (irq #1) working correctly? If not, then the
> > keyboard controller is polled at 20Hz to compensate for lost interrupts,
> > which would make it work, but
On Tue, 2005-08-02 at 17:44 +0200, Vojtech Pavlik wrote:
> Is your keyboard interrupt (irq #1) working correctly? If not, then the
> keyboard controller is polled at 20Hz to compensate for lost interrupts,
> which would make it work, but if no interrupts work, it would seem like
> typing over a
On Tue, 2005-08-02 at 17:44 +0200, Vojtech Pavlik wrote:
> Is your keyboard interrupt (irq #1) working correctly? If not, then the
> keyboard controller is polled at 20Hz to compensate for lost interrupts,
> which would make it work, but if no interrupts work, it would seem like
> typing over a
On Tue, 2005-08-02 at 10:20 -0400, Steven Rostedt wrote:
> > Are you in any position to do a binary search? It would be really
> bad
> > to release 2.6.13 with this problem...
>
> Unfortunately no. I'm trying to finish a milestone that was due last
> Friday, debug a problem that was found on my
On Tue, 2005-08-02 at 10:20 -0400, Steven Rostedt wrote:
> On Tue, 2005-08-02 at 10:05 -0400, Lee Revell wrote:
> > On Tue, 2005-08-02 at 09:56 -0400, Steven Rostedt wrote:
> > > On Mon, 2005-08-01 at 00:45 -0400, Lee Revell wrote:
> > > > On Sun, 2005-07-31 at 08:38 +0200, Ingo Molnar wrote:
> >
Trivial patch. Remove redundant unlikely.
Side note. Ingo, I've also completed the softdeadlock update patch, and
I'm right now trying to trigger the kjournald deadlock by upping it to
FIFO 30 and having non RT tasks running find and compiles. Since you
removed my inverted lock patch, this
On Tue, 2005-08-02 at 09:56 -0400, Steven Rostedt wrote:
> On Mon, 2005-08-01 at 00:45 -0400, Lee Revell wrote:
> > On Sun, 2005-07-31 at 08:38 +0200, Ingo Molnar wrote:
> > > ok - i've uploaded the -52-04 patch, does that fix it for you?
> >
> > Has anyone found their PS2 keyboard rather
On Tue, 2005-08-02 at 10:05 -0400, Lee Revell wrote:
> On Tue, 2005-08-02 at 09:56 -0400, Steven Rostedt wrote:
> > On Mon, 2005-08-01 at 00:45 -0400, Lee Revell wrote:
> > > On Sun, 2005-07-31 at 08:38 +0200, Ingo Molnar wrote:
> > > > ok - i've uploaded the -52-04 patch, does that fix it for
On Mon, 2005-08-01 at 00:45 -0400, Lee Revell wrote:
> On Sun, 2005-07-31 at 08:38 +0200, Ingo Molnar wrote:
> > ok - i've uploaded the -52-04 patch, does that fix it for you?
>
> Has anyone found their PS2 keyboard rather sluggish with this kernel?
> I'm not sure whether it's an -RT problem,
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> In my custom kernel, I have a wchan field of the task that records
> where the task calls something that might schedule. This way I can see
> where things locked up if I don't have a back trace of the task. This
> field is always zero when it
* Steven Rostedt [EMAIL PROTECTED] wrote:
In my custom kernel, I have a wchan field of the task that records
where the task calls something that might schedule. This way I can see
where things locked up if I don't have a back trace of the task. This
field is always zero when it switches
On Mon, 2005-08-01 at 00:45 -0400, Lee Revell wrote:
On Sun, 2005-07-31 at 08:38 +0200, Ingo Molnar wrote:
ok - i've uploaded the -52-04 patch, does that fix it for you?
Has anyone found their PS2 keyboard rather sluggish with this kernel?
I'm not sure whether it's an -RT problem, I'll have
On Tue, 2005-08-02 at 10:05 -0400, Lee Revell wrote:
On Tue, 2005-08-02 at 09:56 -0400, Steven Rostedt wrote:
On Mon, 2005-08-01 at 00:45 -0400, Lee Revell wrote:
On Sun, 2005-07-31 at 08:38 +0200, Ingo Molnar wrote:
ok - i've uploaded the -52-04 patch, does that fix it for you?
On Tue, 2005-08-02 at 09:56 -0400, Steven Rostedt wrote:
On Mon, 2005-08-01 at 00:45 -0400, Lee Revell wrote:
On Sun, 2005-07-31 at 08:38 +0200, Ingo Molnar wrote:
ok - i've uploaded the -52-04 patch, does that fix it for you?
Has anyone found their PS2 keyboard rather sluggish with
Trivial patch. Remove redundant unlikely.
Side note. Ingo, I've also completed the softdeadlock update patch, and
I'm right now trying to trigger the kjournald deadlock by upping it to
FIFO 30 and having non RT tasks running find and compiles. Since you
removed my inverted lock patch, this
On Tue, 2005-08-02 at 10:20 -0400, Steven Rostedt wrote:
On Tue, 2005-08-02 at 10:05 -0400, Lee Revell wrote:
On Tue, 2005-08-02 at 09:56 -0400, Steven Rostedt wrote:
On Mon, 2005-08-01 at 00:45 -0400, Lee Revell wrote:
On Sun, 2005-07-31 at 08:38 +0200, Ingo Molnar wrote:
ok - i've
On Tue, 2005-08-02 at 10:20 -0400, Steven Rostedt wrote:
Are you in any position to do a binary search? It would be really
bad
to release 2.6.13 with this problem...
Unfortunately no. I'm trying to finish a milestone that was due last
Friday, debug a problem that was found on my last
On Tue, 2005-08-02 at 17:44 +0200, Vojtech Pavlik wrote:
Is your keyboard interrupt (irq #1) working correctly? If not, then the
keyboard controller is polled at 20Hz to compensate for lost interrupts,
which would make it work, but if no interrupts work, it would seem like
typing over a slow
On Tue, 2005-08-02 at 17:44 +0200, Vojtech Pavlik wrote:
Is your keyboard interrupt (irq #1) working correctly? If not, then the
keyboard controller is polled at 20Hz to compensate for lost interrupts,
which would make it work, but if no interrupts work, it would seem like
typing over a slow
On 8/2/05, Lee Revell [EMAIL PROTECTED] wrote:
On Tue, 2005-08-02 at 10:20 -0400, Steven Rostedt wrote:
On Tue, 2005-08-02 at 10:05 -0400, Lee Revell wrote:
On Tue, 2005-08-02 at 09:56 -0400, Steven Rostedt wrote:
On Mon, 2005-08-01 at 00:45 -0400, Lee Revell wrote:
On Sun,
On Tue, Aug 02, 2005 at 11:47:13AM -0400, Lee Revell wrote:
On Tue, 2005-08-02 at 17:44 +0200, Vojtech Pavlik wrote:
Is your keyboard interrupt (irq #1) working correctly? If not, then the
keyboard controller is polled at 20Hz to compensate for lost interrupts,
which would make it work,
On Tue, 2005-08-02 at 12:19 +0200, Ingo Molnar wrote:
* Steven Rostedt [EMAIL PROTECTED] wrote:
In my custom kernel, I have a wchan field of the task that records
where the task calls something that might schedule. This way I can see
where things locked up if I don't have a back trace
On Tue, 2005-08-02 at 15:45 -0400, Steven Rostedt wrote:
Here it is (Finally). I just had to be patient with the kjournal
lockup. I had to wait some time before the lockup occurred, but when it
did, I got my message out:
Oh yeah, this goes against 52-10.
-- Steve
-
To unsubscribe from
Couldn't you just do some math off current-timestamp to see how long
the task has been running? This per arch stuff seems a bit invasive..
Daniel
On Tue, 2005-08-02 at 15:45 -0400, Steven Rostedt wrote:
On Tue, 2005-08-02 at 12:19 +0200, Ingo Molnar wrote:
* Steven Rostedt [EMAIL PROTECTED]
On Tue, 2005-08-02 at 16:38 -0700, Daniel Walker wrote:
Couldn't you just do some math off current-timestamp to see how long
the task has been running? This per arch stuff seems a bit invasive..
The thing is, I'm tracking how long the task is running in the kernel
without doing a schedule.
Steven Rostedt wrote:
On Tue, 2005-08-02 at 16:38 -0700, Daniel Walker wrote:
Couldn't you just do some math off current-timestamp to see how long
the task has been running? This per arch stuff seems a bit invasive..
The thing is, I'm tracking how long the task is running in the kernel
On Tue, 02 Aug 2005 18:12:27 -0700,
George Anzinger george@mvista.com wrote:
How about something like:
if (current + THREAD_SIZE/sizeof(long) - (regs + sizeof(pt_regs))
MAGIC)
current points to the current struct task, regs points to the kernel
stack. Those two data areas can be
Keith Owens wrote:
On Tue, 02 Aug 2005 18:12:27 -0700,
George Anzinger george@mvista.com wrote:
How about something like:
if (current + THREAD_SIZE/sizeof(long) - (regs + sizeof(pt_regs))
MAGIC)
current points to the current struct task, regs points to the kernel
stack. Those
On Tue, 2005-08-02 at 20:00 -0400, Steven Rostedt wrote:
On Tue, 2005-08-02 at 16:38 -0700, Daniel Walker wrote:
Couldn't you just do some math off current-timestamp to see how long
the task has been running? This per arch stuff seems a bit invasive..
The thing is, I'm tracking how long
On Tue, 2005-08-02 at 19:25 -0700, Daniel Walker wrote:
On Tue, 2005-08-02 at 20:00 -0400, Steven Rostedt wrote:
On Tue, 2005-08-02 at 16:38 -0700, Daniel Walker wrote:
Couldn't you just do some math off current-timestamp to see how long
the task has been running? This per arch stuff
On Tue, 2005-08-02 at 22:42 -0400, Steven Rostedt wrote:
On Tue, 2005-08-02 at 19:25 -0700, Daniel Walker wrote:
On Tue, 2005-08-02 at 20:00 -0400, Steven Rostedt wrote:
On Tue, 2005-08-02 at 16:38 -0700, Daniel Walker wrote:
Couldn't you just do some math off current-timestamp to see
On Mon, 2005-08-01 at 23:55 -0400, Steven Rostedt wrote:
> On Mon, 2005-08-01 at 14:20 -0700, Daniel Walker wrote:
> > It means that IRQ 14 is running for a long time as an RT task
>
> Oh yeah, I forgot to comment on this. Yes IRQ 14 is rather slow. It's
> the IDE drive interrupt and it gets
On Mon, 2005-08-01 at 14:20 -0700, Daniel Walker wrote:
> It means that IRQ 14 is running for a long time as an RT task
Oh yeah, I forgot to comment on this. Yes IRQ 14 is rather slow. It's
the IDE drive interrupt and it gets pretty busy. Actually the check
doesn't really see if it is running
On Mon, 2005-08-01 at 14:20 -0700, Daniel Walker wrote:
> On Mon, 2005-08-01 at 14:22 -0400, Steven Rostedt wrote:
> > Ingo,
> >
> > What's with the "BUG: possible soft lockup detected on CPU..."? I'm
> > getting a bunch of them from the IDE interrupt. It's not locking up,
> > but it does things
On Mon, 2005-08-01 at 14:09 -0700, Daniel Walker wrote:
>
> You guys want me to always CC in the future?
Yes, please CC the LKML. I try to for all updates since I might have
done a mistake in my code that my shallow tests don't catch, and others
might. Also to let others know what I'm
* Lee Revell <[EMAIL PROTECTED]> wrote:
> On Sun, 2005-07-31 at 08:38 +0200, Ingo Molnar wrote:
> > ok - i've uploaded the -52-04 patch, does that fix it for you?
>
> Has anyone found their PS2 keyboard rather sluggish with this kernel?
> I'm not sure whether it's an -RT problem, I'll have to
On Mon, 2005-08-01 at 22:52 +0200, Ingo Molnar wrote:
> * Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> > Ingo,
> >
> > What's with the "BUG: possible soft lockup detected on CPU..."? I'm
> > getting a bunch of them from the IDE interrupt. It's not locking up,
> > but it does things that
> * Lee Revell <[EMAIL PROTECTED]> wrote:
>
> > On Sun, 2005-07-31 at 08:38 +0200, Ingo Molnar wrote:
> > > ok - i've uploaded the -52-04 patch, does that fix it for you?
> >
> > Has anyone found their PS2 keyboard rather sluggish with this kernel?
> > I'm not sure whether it's an -RT problem,
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> > here's the patch below. Could you try to revert it?
>
> Thanks Ingo.
>
> If Daniel was trying to detect soft lock ups of lower priority tasks
> (tasks that block all tasks lower than itself), I've added a counter
> to Daniels patch to keep from
On Mon, 2005-08-01 at 14:22 -0400, Steven Rostedt wrote:
> Ingo,
>
> What's with the "BUG: possible soft lockup detected on CPU..."? I'm
> getting a bunch of them from the IDE interrupt. It's not locking up,
> but it does things that probably do take some time. Is this really
> necessary?
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> > here's the patch below. Could you try to revert it?
>
> You guys want me to always CC in the future?
well if it's somewhat larger than a trivial fix then it would definitely
be useful to always Cc: lkml. Trivial fixes can go to lkml too, just in
On Mon, 2005-08-01 at 22:52 +0200, Ingo Molnar wrote:
> * Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> > Ingo,
> >
> > What's with the "BUG: possible soft lockup detected on CPU..."? I'm
> > getting a bunch of them from the IDE interrupt. It's not locking up,
> > but it does things that
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> Ingo,
>
> What's with the "BUG: possible soft lockup detected on CPU..."? I'm
> getting a bunch of them from the IDE interrupt. It's not locking up,
> but it does things that probably do take some time. Is this really
> necessary? Here's an
Ingo,
Here's a conversion of the bit_spin_locks to wait_on_bit.
Unfortunately, this doesn't have PI but it is better than just a normal
bit_spin_lock.
This patch applies cleanly to 2.6.13-rc3 (that's what I tried it on). I
haven't done any benchmarking and I only booted this on a RT UP machine
Ingo,
What's with the "BUG: possible soft lockup detected on CPU..."? I'm
getting a bunch of them from the IDE interrupt. It's not locking up,
but it does things that probably do take some time. Is this really
necessary? Here's an example dump:
-- Steve
Note: I added the
Ingo,
What's with the BUG: possible soft lockup detected on CPU...? I'm
getting a bunch of them from the IDE interrupt. It's not locking up,
but it does things that probably do take some time. Is this really
necessary? Here's an example dump:
-- Steve
Note: I added the
Ingo,
Here's a conversion of the bit_spin_locks to wait_on_bit.
Unfortunately, this doesn't have PI but it is better than just a normal
bit_spin_lock.
This patch applies cleanly to 2.6.13-rc3 (that's what I tried it on). I
haven't done any benchmarking and I only booted this on a RT UP machine
* Steven Rostedt [EMAIL PROTECTED] wrote:
Ingo,
What's with the BUG: possible soft lockup detected on CPU...? I'm
getting a bunch of them from the IDE interrupt. It's not locking up,
but it does things that probably do take some time. Is this really
necessary? Here's an example dump:
On Mon, 2005-08-01 at 22:52 +0200, Ingo Molnar wrote:
* Steven Rostedt [EMAIL PROTECTED] wrote:
Ingo,
What's with the BUG: possible soft lockup detected on CPU...? I'm
getting a bunch of them from the IDE interrupt. It's not locking up,
but it does things that probably do take
* Daniel Walker [EMAIL PROTECTED] wrote:
here's the patch below. Could you try to revert it?
You guys want me to always CC in the future?
well if it's somewhat larger than a trivial fix then it would definitely
be useful to always Cc: lkml. Trivial fixes can go to lkml too, just in
case
On Mon, 2005-08-01 at 14:22 -0400, Steven Rostedt wrote:
Ingo,
What's with the BUG: possible soft lockup detected on CPU...? I'm
getting a bunch of them from the IDE interrupt. It's not locking up,
but it does things that probably do take some time. Is this really
necessary? Here's an
* Steven Rostedt [EMAIL PROTECTED] wrote:
here's the patch below. Could you try to revert it?
Thanks Ingo.
If Daniel was trying to detect soft lock ups of lower priority tasks
(tasks that block all tasks lower than itself), I've added a counter
to Daniels patch to keep from showing
* Lee Revell [EMAIL PROTECTED] wrote:
On Sun, 2005-07-31 at 08:38 +0200, Ingo Molnar wrote:
ok - i've uploaded the -52-04 patch, does that fix it for you?
Has anyone found their PS2 keyboard rather sluggish with this kernel?
I'm not sure whether it's an -RT problem, I'll have to
1 - 100 of 122 matches
Mail list logo
