On Thu, 10 Jan 2008, Parag Warudkar wrote:
> On Jan 9, 2008 6:56 AM, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
>
> > Can you apply the patch below + the debug patch which prints the timer
> > stats on softlockup and provide the output of this.
>
> Applied to today's git and running for 21
On Thu, 10 Jan 2008, Parag Warudkar wrote:
On Jan 9, 2008 6:56 AM, Thomas Gleixner [EMAIL PROTECTED] wrote:
Can you apply the patch below + the debug patch which prints the timer
stats on softlockup and provide the output of this.
Applied to today's git and running for 21 hours - no
On Jan 9, 2008 6:56 AM, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> Can you apply the patch below + the debug patch which prints the timer
> stats on softlockup and provide the output of this.
Applied to today's git and running for 21 hours - no recurrence yet
even with 1.2 wakeups per second.
On Jan 9, 2008 6:56 AM, Thomas Gleixner [EMAIL PROTECTED] wrote:
Can you apply the patch below + the debug patch which prints the timer
stats on softlockup and provide the output of this.
Applied to today's git and running for 21 hours - no recurrence yet
even with 1.2 wakeups per second.
I
On Mon, 17 Dec 2007, Thomas Gleixner wrote:
> I try to come up with some more debug patches tomorrow.
Sorry took a bit longer than a day :(
Can you apply the patch below + the debug patch which prints the timer
stats on softlockup and provide the output of this.
Thanks,
tglx
diff
On Mon, 17 Dec 2007, Thomas Gleixner wrote:
I try to come up with some more debug patches tomorrow.
Sorry took a bit longer than a day :(
Can you apply the patch below + the debug patch which prints the timer
stats on softlockup and provide the output of this.
Thanks,
tglx
diff --git
On Mon, 17 Dec 2007, Parag Warudkar wrote:
> On Dec 17, 2007 3:05 AM, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> > Sigh. You did not have the debug patch applied anymore, which printks
> > the timer_list data ? Can you apply it again and provide the output
> > please ?
> >
>
> This keeps
On Dec 17, 2007 3:05 AM, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
>
> On Sun, 16 Dec 2007, Parag Warudkar wrote:
>
> > On Dec 16, 2007 12:15 AM, Parag Warudkar <[EMAIL PROTECTED]> wrote:
> > > On Sat, 15 Dec 2007, Parag Warudkar wrote:
> > >
> > > >> I will run it for a little longer just to be
On Sun, 16 Dec 2007, Parag Warudkar wrote:
> On Dec 16, 2007 12:15 AM, Parag Warudkar <[EMAIL PROTECTED]> wrote:
> > On Sat, 15 Dec 2007, Parag Warudkar wrote:
> >
> > >> I will run it for a little longer just to be sure - but I don't think it
> > >> will be a problem.
> >
> > No problems for
On Sun, 16 Dec 2007, Parag Warudkar wrote:
On Dec 16, 2007 12:15 AM, Parag Warudkar [EMAIL PROTECTED] wrote:
On Sat, 15 Dec 2007, Parag Warudkar wrote:
I will run it for a little longer just to be sure - but I don't think it
will be a problem.
No problems for last 10 hours - I
On Dec 17, 2007 3:05 AM, Thomas Gleixner [EMAIL PROTECTED] wrote:
On Sun, 16 Dec 2007, Parag Warudkar wrote:
On Dec 16, 2007 12:15 AM, Parag Warudkar [EMAIL PROTECTED] wrote:
On Sat, 15 Dec 2007, Parag Warudkar wrote:
I will run it for a little longer just to be sure - but I don't
On Mon, 17 Dec 2007, Parag Warudkar wrote:
On Dec 17, 2007 3:05 AM, Thomas Gleixner [EMAIL PROTECTED] wrote:
Sigh. You did not have the debug patch applied anymore, which printks
the timer_list data ? Can you apply it again and provide the output
please ?
This keeps getting more and
On Dec 16, 2007 12:15 AM, Parag Warudkar <[EMAIL PROTECTED]> wrote:
> On Sat, 15 Dec 2007, Parag Warudkar wrote:
>
> >> I will run it for a little longer just to be sure - but I don't think it
> >> will be a problem.
>
> No problems for last 10 hours - I consider this fixed.
>
Arghh - spoke 8
On Dec 16, 2007 12:15 AM, Parag Warudkar [EMAIL PROTECTED] wrote:
On Sat, 15 Dec 2007, Parag Warudkar wrote:
I will run it for a little longer just to be sure - but I don't think it
will be a problem.
No problems for last 10 hours - I consider this fixed.
Arghh - spoke 8 hours too soon.
On Sat, 15 Dec 2007, Parag Warudkar wrote:
I will run it for a little longer just to be sure - but I don't think it
will be a problem.
No problems for last 10 hours - I consider this fixed.
Parag
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On Sat, 15 Dec 2007, Thomas Gleixner wrote:
I have a patch staged for Linus, which fixes a thinko in the broadcast
code. It might be related to your problem. Can you give it a try ?
Yep - this looks promising. No soft lockups for last half an hour
with 4-5 Wakeups from idle. It is almost
On Fri, 14 Dec 2007, Parag Warudkar wrote:
> On Dec 14, 2007 6:17 PM, Len Brown <[EMAIL PROTECTED]> wrote:
> > does processor.max_cstate=1 make the failing configuration work?
> > If yes, how about processor.max_cstate=2?
>
> Until now 2 things were necessary to reproduce the problem -
> 1)
On Fri, 14 Dec 2007, Parag Warudkar wrote:
On Dec 14, 2007 6:17 PM, Len Brown [EMAIL PROTECTED] wrote:
does processor.max_cstate=1 make the failing configuration work?
If yes, how about processor.max_cstate=2?
Until now 2 things were necessary to reproduce the problem -
1) CPU_IDLE=y and
On Sat, 15 Dec 2007, Thomas Gleixner wrote:
I have a patch staged for Linus, which fixes a thinko in the broadcast
code. It might be related to your problem. Can you give it a try ?
Yep - this looks promising. No soft lockups for last half an hour
with 4-5 Wakeups from idle. It is almost
On Sat, 15 Dec 2007, Parag Warudkar wrote:
I will run it for a little longer just to be sure - but I don't think it
will be a problem.
No problems for last 10 hours - I consider this fixed.
Parag
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
On Dec 14, 2007 6:17 PM, Len Brown <[EMAIL PROTECTED]> wrote:
> does processor.max_cstate=1 make the failing configuration work?
> If yes, how about processor.max_cstate=2?
Until now 2 things were necessary to reproduce the problem -
1) CPU_IDLE=y and
2) Wakeups from Idle = 5-7 Per second (==
does processor.max_cstate=1 make the failing configuration work?
If yes, how about processor.max_cstate=2?
what do you see in /proc/acpi/processor/*/power?
-Len
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
does processor.max_cstate=1 make the failing configuration work?
If yes, how about processor.max_cstate=2?
what do you see in /proc/acpi/processor/*/power?
-Len
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo
On Dec 14, 2007 6:17 PM, Len Brown [EMAIL PROTECTED] wrote:
does processor.max_cstate=1 make the failing configuration work?
If yes, how about processor.max_cstate=2?
Until now 2 things were necessary to reproduce the problem -
1) CPU_IDLE=y and
2) Wakeups from Idle = 5-7 Per second (==
On Sun, 9 Dec 2007, Parag Warudkar wrote:
> On Dec 8, 2007 6:12 PM, Parag Warudkar <[EMAIL PROTECTED]> wrote:
> > No problems after disabling CONFIG_HIGHRES_TIMERS , CONFIG_CPU_IDLE
> > and CONFIG_NO_HZ.
> >
> > I will try enabling them one by one - HRT, NOHZ and CPU_IDLE last -
> > that way we
On Sun, 9 Dec 2007 16:57:38 -0500
"Parag Warudkar" <[EMAIL PROTECTED]> wrote:
> On Dec 8, 2007 6:12 PM, Parag Warudkar <[EMAIL PROTECTED]>
> wrote:
> > No problems after disabling CONFIG_HIGHRES_TIMERS , CONFIG_CPU_IDLE
> > and CONFIG_NO_HZ.
> >
> > I will try enabling them one by one - HRT, NOHZ
On Dec 8, 2007 6:12 PM, Parag Warudkar <[EMAIL PROTECTED]> wrote:
> No problems after disabling CONFIG_HIGHRES_TIMERS , CONFIG_CPU_IDLE
> and CONFIG_NO_HZ.
>
> I will try enabling them one by one - HRT, NOHZ and CPU_IDLE last -
> that way we can at least tell what is required to be hit with this
>
On Dec 8, 2007 6:12 PM, Parag Warudkar [EMAIL PROTECTED] wrote:
No problems after disabling CONFIG_HIGHRES_TIMERS , CONFIG_CPU_IDLE
and CONFIG_NO_HZ.
I will try enabling them one by one - HRT, NOHZ and CPU_IDLE last -
that way we can at least tell what is required to be hit with this
On Sun, 9 Dec 2007 16:57:38 -0500
Parag Warudkar [EMAIL PROTECTED] wrote:
On Dec 8, 2007 6:12 PM, Parag Warudkar [EMAIL PROTECTED]
wrote:
No problems after disabling CONFIG_HIGHRES_TIMERS , CONFIG_CPU_IDLE
and CONFIG_NO_HZ.
I will try enabling them one by one - HRT, NOHZ and CPU_IDLE
On Sun, 9 Dec 2007, Parag Warudkar wrote:
On Dec 8, 2007 6:12 PM, Parag Warudkar [EMAIL PROTECTED] wrote:
No problems after disabling CONFIG_HIGHRES_TIMERS , CONFIG_CPU_IDLE
and CONFIG_NO_HZ.
I will try enabling them one by one - HRT, NOHZ and CPU_IDLE last -
that way we can at least
No problems after disabling CONFIG_HIGHRES_TIMERS , CONFIG_CPU_IDLE
and CONFIG_NO_HZ.
I will try enabling them one by one - HRT, NOHZ and CPU_IDLE last -
that way we can at least tell what is required to be hit with this
problem.
Parag
--
To unsubscribe from this list: send the line "unsubscribe
On Dec 8, 2007 3:51 PM, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> what chipset is this?
> (I wonder if there's one where we shouldn't be force-enabling the hpet)
It's an Intel Mac Mini - Intel 945GM chipset.
I believe OSX requires HPET and so there shouldn't be a need to force
enable it on
On Sat, 8 Dec 2007 15:46:54 -0500
"Parag Warudkar" <[EMAIL PROTECTED]> wrote:
> On Dec 8, 2007 3:11 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >
> > * Parag Warudkar <[EMAIL PROTECTED]> wrote:
> >
> > > But there are still fluctuations under 100% idle -
> >
> > do you have
On Dec 8, 2007 3:11 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Parag Warudkar <[EMAIL PROTECTED]> wrote:
>
> > But there are still fluctuations under 100% idle -
>
> do you have CONFIG_HIGH_RES_TIMERS=y?
Yes - NO_HZ=y and HIGH_RES_TIMERS=y.
My ssh connection still died with hpet=disable
* Parag Warudkar <[EMAIL PROTECTED]> wrote:
> But there are still fluctuations under 100% idle -
do you have CONFIG_HIGH_RES_TIMERS=y?
> IDLE
> real0m1.112s
> real0m1.131s
> real0m1.112s
> real0m1.112s
> real0m1.139s
these fluctuations would still be OK if they are due to
On Dec 8, 2007 2:42 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Parag Warudkar <[EMAIL PROTECTED]> wrote:
>
> > Even on 100% idle I get variations that are approx in the same range
> > when not idle. Clocksource is hpet if that matters. Next I think I
> > will disable CPU_IDLE, Tickless
>
>
* Parag Warudkar <[EMAIL PROTECTED]> wrote:
> Even on 100% idle I get variations that are approx in the same range
> when not idle. Clocksource is hpet if that matters. Next I think I
> will disable CPU_IDLE, Tickless
also try the hpet=disable boot option.
> My ssh connection just died -
On Dec 8, 2007 2:13 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Parag Warudkar <[EMAIL PROTECTED]> wrote:
>
> > >while :; do time usleep 111; done
> > >
> > > or do these sleeps fluctuate?
> >
> > They seem to fluctuate - not sure if that's supposed to be exact or if
> > below
* Parag Warudkar <[EMAIL PROTECTED]> wrote:
> >while :; do time usleep 111; done
> >
> > or do these sleeps fluctuate?
>
> They seem to fluctuate - not sure if that's supposed to be exact or if
> below variations are normal - This is when my compiles are running -
it's normal for them
On Dec 8, 2007 10:47 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> does the patch below help? But the root cause is likely some timer
> problems - do you get consistent results from:
>
Haven't yet tried the patch - will try a little later.
>while :; do time usleep 111; done
>
> or do
* Parag Warudkar <[EMAIL PROTECTED]> wrote:
> [] tick_broadcast_oneshot_control+0x10/0xda
> [] tick_notify+0x1d4/0x2eb
> [] get_next_timer_interrupt+0x143/0x1b4
> [] notifier_call_chain+0x2a/0x47
> [] raw_notifier_call_chain+0x17/0x1a
> [] clockevents_notify+0x19/0x4f
> []
On Dec 8, 2007 10:10 AM, Parag Warudkar <[EMAIL PROTECTED]> wrote:
> On Dec 7, 2007 9:56 PM, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> >
> > This looks pretty much like the problem I was solving yesterday.
> >
> > Parag, can you please try Linus latest and please check whether there
> > is a
On Dec 7, 2007 9:56 PM, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
>
> This looks pretty much like the problem I was solving yesterday.
>
> Parag, can you please try Linus latest and please check whether there
> is a stack trace with clockevents_program_event on the top in your
> dmesg.
>
Just
On Dec 8, 2007 10:47 AM, Ingo Molnar [EMAIL PROTECTED] wrote:
does the patch below help? But the root cause is likely some timer
problems - do you get consistent results from:
Haven't yet tried the patch - will try a little later.
while :; do time usleep 111; done
or do these
* Parag Warudkar [EMAIL PROTECTED] wrote:
[c0438293] tick_broadcast_oneshot_control+0x10/0xda
[c0437ce2] tick_notify+0x1d4/0x2eb
[c04281bc] get_next_timer_interrupt+0x143/0x1b4
[c06058a1] notifier_call_chain+0x2a/0x47
[c04345c0] raw_notifier_call_chain+0x17/0x1a
[c043781e]
On Dec 7, 2007 9:56 PM, Thomas Gleixner [EMAIL PROTECTED] wrote:
This looks pretty much like the problem I was solving yesterday.
Parag, can you please try Linus latest and please check whether there
is a stack trace with clockevents_program_event on the top in your
dmesg.
Just booted with
On Dec 8, 2007 10:10 AM, Parag Warudkar [EMAIL PROTECTED] wrote:
On Dec 7, 2007 9:56 PM, Thomas Gleixner [EMAIL PROTECTED] wrote:
This looks pretty much like the problem I was solving yesterday.
Parag, can you please try Linus latest and please check whether there
is a stack trace with
* Parag Warudkar [EMAIL PROTECTED] wrote:
while :; do time usleep 111; done
or do these sleeps fluctuate?
They seem to fluctuate - not sure if that's supposed to be exact or if
below variations are normal - This is when my compiles are running -
it's normal for them to
On Dec 8, 2007 2:13 PM, Ingo Molnar [EMAIL PROTECTED] wrote:
* Parag Warudkar [EMAIL PROTECTED] wrote:
while :; do time usleep 111; done
or do these sleeps fluctuate?
They seem to fluctuate - not sure if that's supposed to be exact or if
below variations are normal - This
* Parag Warudkar [EMAIL PROTECTED] wrote:
Even on 100% idle I get variations that are approx in the same range
when not idle. Clocksource is hpet if that matters. Next I think I
will disable CPU_IDLE, Tickless
also try the hpet=disable boot option.
My ssh connection just died - another
On Dec 8, 2007 2:42 PM, Ingo Molnar [EMAIL PROTECTED] wrote:
* Parag Warudkar [EMAIL PROTECTED] wrote:
Even on 100% idle I get variations that are approx in the same range
when not idle. Clocksource is hpet if that matters. Next I think I
will disable CPU_IDLE, Tickless
also try the
* Parag Warudkar [EMAIL PROTECTED] wrote:
But there are still fluctuations under 100% idle -
do you have CONFIG_HIGH_RES_TIMERS=y?
IDLE
real0m1.112s
real0m1.131s
real0m1.112s
real0m1.112s
real0m1.139s
these fluctuations would still be OK if they are due to HZ
On Dec 8, 2007 3:11 PM, Ingo Molnar [EMAIL PROTECTED] wrote:
* Parag Warudkar [EMAIL PROTECTED] wrote:
But there are still fluctuations under 100% idle -
do you have CONFIG_HIGH_RES_TIMERS=y?
Yes - NO_HZ=y and HIGH_RES_TIMERS=y.
My ssh connection still died with hpet=disable although this
On Sat, 8 Dec 2007 15:46:54 -0500
Parag Warudkar [EMAIL PROTECTED] wrote:
On Dec 8, 2007 3:11 PM, Ingo Molnar [EMAIL PROTECTED] wrote:
* Parag Warudkar [EMAIL PROTECTED] wrote:
But there are still fluctuations under 100% idle -
do you have CONFIG_HIGH_RES_TIMERS=y?
Yes - NO_HZ=y
On Dec 8, 2007 3:51 PM, Arjan van de Ven [EMAIL PROTECTED] wrote:
what chipset is this?
(I wonder if there's one where we shouldn't be force-enabling the hpet)
It's an Intel Mac Mini - Intel 945GM chipset.
I believe OSX requires HPET and so there shouldn't be a need to force
enable it on this
No problems after disabling CONFIG_HIGHRES_TIMERS , CONFIG_CPU_IDLE
and CONFIG_NO_HZ.
I will try enabling them one by one - HRT, NOHZ and CPU_IDLE last -
that way we can at least tell what is required to be hit with this
problem.
Parag
--
To unsubscribe from this list: send the line unsubscribe
G: soft lockup - CPU#1 stuck for 15s! [swapper:0]
> >
> >Got this on today's git (2.6.24-rc4) while compiling stuff - Looks
> >like it is related to CpuIdle stuff.
> >I chose CONFIG_CPU_IDLE for the first time so I don't know when this
> >was introduced.
> >
I chose CONFIG_CPU_IDLE for the first time so I don't know when this
> > was introduced.
> >
> > This is on x86_32, SMP.
> >
> > BUG: soft lockup - CPU#1 stuck for 15s! [swapper:0]
> >
> > Pid: 0, comm: swapper Not tainted (2.6.24-rc4 #3)
> &
On Dec 7, 2007 6:12 PM, Pallipadi, Venkatesh
<[EMAIL PROTECTED]> wrote:
> Looks like tick_broadcast_lock did not get freed in some path.
> You do not see this when you CPU_IDLE is not configured?
>
> Thanks,
> Venki
>
No, I did not see this prior to enabling CPU_IDLE.
All previous kernels
hen this
> was introduced.
>
> This is on x86_32, SMP.
>
> BUG: soft lockup - CPU#1 stuck for 15s! [swapper:0]
>
> Pid: 0, comm: swapper Not tainted (2.6.24-rc4 #3)
> EIP: 0060:[] EFLAGS: 0202 CPU: 1
> EIP is at _spin_lock_irqsave+0x16/0x27
> EAX: c06b4110 EBX: 0001 ECX: f
>-Original Message-
>From: Parag Warudkar [mailto:[EMAIL PROTECTED]
>Sent: Friday, December 07, 2007 2:54 PM
>To: LKML
>Cc: Andrew Morton; Pallipadi, Venkatesh; Linus Torvalds
>Subject: BUG: soft lockup - CPU#1 stuck for 15s! [swapper:0]
>
>Got this on today'
Got this on today's git (2.6.24-rc4) while compiling stuff - Looks
like it is related to CpuIdle stuff.
I chose CONFIG_CPU_IDLE for the first time so I don't know when this
was introduced.
This is on x86_32, SMP.
BUG: soft lockup - CPU#1 stuck for 15s! [swapper:0]
Pid: 0, comm: swapper
.
BUG: soft lockup - CPU#1 stuck for 15s! [swapper:0]
Pid: 0, comm: swapper Not tainted (2.6.24-rc4 #3)
EIP: 0060:[c0603e22] EFLAGS: 0202 CPU: 1
EIP is at _spin_lock_irqsave+0x16/0x27
EAX: c06b4110 EBX: 0001 ECX: f7873808 EDX: 0293
ESI: 0005 EDI: f7873808 EBP: ESP
-Original Message-
From: Parag Warudkar [mailto:[EMAIL PROTECTED]
Sent: Friday, December 07, 2007 2:54 PM
To: LKML
Cc: Andrew Morton; Pallipadi, Venkatesh; Linus Torvalds
Subject: BUG: soft lockup - CPU#1 stuck for 15s! [swapper:0]
Got this on today's git (2.6.24-rc4) while compiling
On Fri, 7 Dec 2007, Pallipadi, Venkatesh wrote:
-Original Message-
From: Parag Warudkar [mailto:[EMAIL PROTECTED]
Sent: Friday, December 07, 2007 2:54 PM
To: LKML
Cc: Andrew Morton; Pallipadi, Venkatesh; Linus Torvalds
Subject: BUG: soft lockup - CPU#1 stuck for 15s! [swapper:0
know when this
was introduced.
This is on x86_32, SMP.
BUG: soft lockup - CPU#1 stuck for 15s! [swapper:0]
Pid: 0, comm: swapper Not tainted (2.6.24-rc4 #3)
EIP: 0060:[c0603e22] EFLAGS: 0202 CPU: 1
EIP is at _spin_lock_irqsave+0x16/0x27
EAX: c06b4110 EBX: 0001 ECX
On Dec 7, 2007 6:12 PM, Pallipadi, Venkatesh
[EMAIL PROTECTED] wrote:
Looks like tick_broadcast_lock did not get freed in some path.
You do not see this when you CPU_IDLE is not configured?
Thanks,
Venki
No, I did not see this prior to enabling CPU_IDLE.
All previous kernels without
Got this on today's git (2.6.24-rc4) while compiling stuff - Looks
like it is related to CpuIdle stuff.
I chose CONFIG_CPU_IDLE for the first time so I don't know when this
was introduced.
This is on x86_32, SMP.
BUG: soft lockup - CPU#1 stuck for 15s! [swapper:0]
Pid: 0, comm: swapper
68 matches
Mail list logo
