Mark Lord wrote:
Thomas Gleixner wrote:
..
I try to come up with something, but I'm travelling tomorrow, so it
might be not before end of week.
Thanks, Thomas.
I believe we definitely want to nail this down before 2.6.22-final,
but there's a good workaround in the interim
Mark Lord wrote:
Thomas Gleixner wrote:
..
I try to come up with something, but I'm travelling tomorrow, so it
might be not before end of week.
Thanks, Thomas.
I believe we definitely want to nail this down before 2.6.22-final,
but there's a good workaround in the interim
Thomas Gleixner wrote:
..
I try to come up with something, but I'm travelling tomorrow, so it
might be not before end of week.
Thanks, Thomas.
I believe we definitely want to nail this down before 2.6.22-final,
but there's a good workaround in the interim (CONFIG_DETECT_SOFTLOCKUP=y)
and
On Wed, 2007-05-02 at 18:29 -0400, Mark Lord wrote:
> Oh crap. It's back.
>
> I don't know what's different from before,
> but the system now locks up again exactly the same way,
> even with the lock contention fix applied.
Which is less surprising and confusing than the previous result. It
Oh crap. It's back.
I don't know what's different from before,
but the system now locks up again exactly the same way,
even with the lock contention fix applied.
With or without CONFIG_PROVE_LOCKING=y in the config.
I've gotta get some work done here (this is my primary development machine),
On Wed, 2007-05-02 at 01:05 -0700, Andrew Morton wrote:
> > thanks. Can you apply this patch please:
> > http://lkml.org/lkml/2007/4/13/190
> >
> > It somehow did not make it into 2.6.21.
> >
>
> Alas, poor me. I ain't going to merge a contention-reduction patch when
> we're at -rc6. If a
re: [PATCH] highres/dyntick: prevent xtime lock contention
|mark> I have a new notebook (Dell Inspiron 9400) with Core2-Duo T7400 @ 2.1Ghz.
|mark> When either/both of CONFIG_NO_HZ, CONFIG_HIGH_RES_TIMERS is used,
|mark> the 2.6.21 kernel hangs on startup just after printing one/both of these:
On Wed, 02 May 2007 09:47:15 +0200 Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> Mark,
>
> On Tue, 2007-05-01 at 12:52 -0400, Mark Lord wrote:
> > Done, and done.
> > And I managed to capture more of the boot messages, too.
> > This new capture is in the "sequence" subdir at the previous link.
>
Mark,
On Tue, 2007-05-01 at 12:52 -0400, Mark Lord wrote:
> Done, and done.
> And I managed to capture more of the boot messages, too.
> This new capture is in the "sequence" subdir at the previous link.
thanks. Can you apply this patch please:
http://lkml.org/lkml/2007/4/13/190
It somehow did
Mark,
On Tue, 2007-05-01 at 12:52 -0400, Mark Lord wrote:
Done, and done.
And I managed to capture more of the boot messages, too.
This new capture is in the sequence subdir at the previous link.
thanks. Can you apply this patch please:
http://lkml.org/lkml/2007/4/13/190
It somehow did not
On Wed, 02 May 2007 09:47:15 +0200 Thomas Gleixner [EMAIL PROTECTED] wrote:
Mark,
On Tue, 2007-05-01 at 12:52 -0400, Mark Lord wrote:
Done, and done.
And I managed to capture more of the boot messages, too.
This new capture is in the sequence subdir at the previous link.
thanks. Can
re: [PATCH] highres/dyntick: prevent xtime lock contention
|mark I have a new notebook (Dell Inspiron 9400) with Core2-Duo T7400 @ 2.1Ghz.
|mark When either/both of CONFIG_NO_HZ, CONFIG_HIGH_RES_TIMERS is used,
|mark the 2.6.21 kernel hangs on startup just after printing one/both of these:
|mark
On Wed, 2007-05-02 at 01:05 -0700, Andrew Morton wrote:
thanks. Can you apply this patch please:
http://lkml.org/lkml/2007/4/13/190
It somehow did not make it into 2.6.21.
Alas, poor me. I ain't going to merge a contention-reduction patch when
we're at -rc6. If a patch fixes a
Oh crap. It's back.
I don't know what's different from before,
but the system now locks up again exactly the same way,
even with the lock contention fix applied.
With or without CONFIG_PROVE_LOCKING=y in the config.
I've gotta get some work done here (this is my primary development machine),
On Wed, 2007-05-02 at 18:29 -0400, Mark Lord wrote:
Oh crap. It's back.
I don't know what's different from before,
but the system now locks up again exactly the same way,
even with the lock contention fix applied.
Which is less surprising and confusing than the previous result. It
points
Thomas Gleixner wrote:
..
I try to come up with something, but I'm travelling tomorrow, so it
might be not before end of week.
Thanks, Thomas.
I believe we definitely want to nail this down before 2.6.22-final,
but there's a good workaround in the interim (CONFIG_DETECT_SOFTLOCKUP=y)
and
Thomas Gleixner wrote:
On Tue, 2007-05-01 at 10:13 -0400, Mark Lord wrote:
Of possible interest is that the bottom of the 25line screen capture
differs somewhat from the 50line capture.. see for yourself.
This is 100% consistent from boot to boot.
Using CONFIG_DETECT_SOFTLOCKUP=y eliminates
On Tue, 2007-05-01 at 12:31 -0400, Mark Lord wrote:
> Thomas Gleixner wrote:
> >
> > I meant disable HPET via: hpet=disable on the commandline
> >
> >> Screenshots for that are available here: http://rtr.ca/hrtimers/
>
> hpet=disable fails, without the "switched to high resolution timer"
>
Thomas Gleixner wrote:
I meant disable HPET via: hpet=disable on the commandline
Screenshots for that are available here: http://rtr.ca/hrtimers/
hpet=disable fails, without the "switched to high resolution timer" message(s).
New snapshot of it now at the link above.
I also applied
On Tue, 2007-05-01 at 10:13 -0400, Mark Lord wrote:
> Of possible interest is that the bottom of the 25line screen capture
> differs somewhat from the 50line capture.. see for yourself.
> This is 100% consistent from boot to boot.
>
> Using CONFIG_DETECT_SOFTLOCKUP=y eliminates the problem,
> so
On Tue, 2007-05-01 at 10:13 -0400, Mark Lord wrote:
> Thomas Gleixner wrote:
> > On Tue, 2007-05-01 at 09:34 -0400, Mark Lord wrote:
> >>> now at 3232363876949 nsecs
> >> ...
> >>
> >> Oh, in case it matters any:
> >> that /proc/timer_list is from the system with CFS-V7 also patched in.
> >
> >
Michal Piotrowski wrote:
On 01/05/07, Mark Lord <[EMAIL PROTECTED]> wrote:
Thomas Gleixner wrote:
> On Tue, 2007-05-01 at 09:34 -0400, Mark Lord wrote:
>>> now at 3232363876949 nsecs
>> ...
>>
>> Oh, in case it matters any:
>> that /proc/timer_list is from the system with CFS-V7 also patched
On 01/05/07, Mark Lord <[EMAIL PROTECTED]> wrote:
Thomas Gleixner wrote:
> On Tue, 2007-05-01 at 09:34 -0400, Mark Lord wrote:
>>> now at 3232363876949 nsecs
>> ...
>>
>> Oh, in case it matters any:
>> that /proc/timer_list is from the system with CFS-V7 also patched in.
>
> It should not. What
Thomas Gleixner wrote:
On Tue, 2007-05-01 at 09:34 -0400, Mark Lord wrote:
now at 3232363876949 nsecs
...
Oh, in case it matters any:
that /proc/timer_list is from the system with CFS-V7 also patched in.
It should not. What happens when you disable HPET ?
Booting with clocksource=tsc
On Tue, 2007-05-01 at 09:34 -0400, Mark Lord wrote:
> > now at 3232363876949 nsecs
> ...
>
> Oh, in case it matters any:
> that /proc/timer_list is from the system with CFS-V7 also patched in.
It should not. What happens when you disable HPET ?
tglx
-
To unsubscribe from this list:
Mark Lord wrote:
Thomas Gleixner wrote:
Mark,
On Mon, 2007-04-30 at 20:02 -0400, Mark Lord wrote:
When it does boot with the modified .config file,
the log looks like the one attached to this email.
Can you please send me the output of /proc/timer_list ?
Timer List Version: v0.3
Thomas Gleixner wrote:
Mark,
On Mon, 2007-04-30 at 20:02 -0400, Mark Lord wrote:
When it does boot with the modified .config file,
the log looks like the one attached to this email.
Can you please send me the output of /proc/timer_list ?
Timer List Version: v0.3
HRTIMER_MAX_CLOCK_BASES: 2
Mark,
On Mon, 2007-04-30 at 20:02 -0400, Mark Lord wrote:
> When it does boot with the modified .config file,
> the log looks like the one attached to this email.
Can you please send me the output of /proc/timer_list ?
tglx
-
To unsubscribe from this list: send the line "unsubscribe
Mark,
On Mon, 2007-04-30 at 20:02 -0400, Mark Lord wrote:
When it does boot with the modified .config file,
the log looks like the one attached to this email.
Can you please send me the output of /proc/timer_list ?
tglx
-
To unsubscribe from this list: send the line unsubscribe
Thomas Gleixner wrote:
Mark,
On Mon, 2007-04-30 at 20:02 -0400, Mark Lord wrote:
When it does boot with the modified .config file,
the log looks like the one attached to this email.
Can you please send me the output of /proc/timer_list ?
Timer List Version: v0.3
HRTIMER_MAX_CLOCK_BASES: 2
Mark Lord wrote:
Thomas Gleixner wrote:
Mark,
On Mon, 2007-04-30 at 20:02 -0400, Mark Lord wrote:
When it does boot with the modified .config file,
the log looks like the one attached to this email.
Can you please send me the output of /proc/timer_list ?
Timer List Version: v0.3
On Tue, 2007-05-01 at 09:34 -0400, Mark Lord wrote:
now at 3232363876949 nsecs
...
Oh, in case it matters any:
that /proc/timer_list is from the system with CFS-V7 also patched in.
It should not. What happens when you disable HPET ?
tglx
-
To unsubscribe from this list: send the
Thomas Gleixner wrote:
On Tue, 2007-05-01 at 09:34 -0400, Mark Lord wrote:
now at 3232363876949 nsecs
...
Oh, in case it matters any:
that /proc/timer_list is from the system with CFS-V7 also patched in.
It should not. What happens when you disable HPET ?
Booting with clocksource=tsc
On 01/05/07, Mark Lord [EMAIL PROTECTED] wrote:
Thomas Gleixner wrote:
On Tue, 2007-05-01 at 09:34 -0400, Mark Lord wrote:
now at 3232363876949 nsecs
...
Oh, in case it matters any:
that /proc/timer_list is from the system with CFS-V7 also patched in.
It should not. What happens when you
Michal Piotrowski wrote:
On 01/05/07, Mark Lord [EMAIL PROTECTED] wrote:
Thomas Gleixner wrote:
On Tue, 2007-05-01 at 09:34 -0400, Mark Lord wrote:
now at 3232363876949 nsecs
...
Oh, in case it matters any:
that /proc/timer_list is from the system with CFS-V7 also patched in.
It should
On Tue, 2007-05-01 at 10:13 -0400, Mark Lord wrote:
Thomas Gleixner wrote:
On Tue, 2007-05-01 at 09:34 -0400, Mark Lord wrote:
now at 3232363876949 nsecs
...
Oh, in case it matters any:
that /proc/timer_list is from the system with CFS-V7 also patched in.
It should not. What
On Tue, 2007-05-01 at 10:13 -0400, Mark Lord wrote:
Of possible interest is that the bottom of the 25line screen capture
differs somewhat from the 50line capture.. see for yourself.
This is 100% consistent from boot to boot.
Using CONFIG_DETECT_SOFTLOCKUP=y eliminates the problem,
so that's
Thomas Gleixner wrote:
I meant disable HPET via: hpet=disable on the commandline
Screenshots for that are available here: http://rtr.ca/hrtimers/
hpet=disable fails, without the switched to high resolution timer message(s).
New snapshot of it now at the link above.
I also applied
On Tue, 2007-05-01 at 12:31 -0400, Mark Lord wrote:
Thomas Gleixner wrote:
I meant disable HPET via: hpet=disable on the commandline
Screenshots for that are available here: http://rtr.ca/hrtimers/
hpet=disable fails, without the switched to high resolution timer
message(s).
Thomas Gleixner wrote:
On Tue, 2007-05-01 at 10:13 -0400, Mark Lord wrote:
Of possible interest is that the bottom of the 25line screen capture
differs somewhat from the 50line capture.. see for yourself.
This is 100% consistent from boot to boot.
Using CONFIG_DETECT_SOFTLOCKUP=y eliminates
On Mon, 2007-04-30 at 23:33 -0400, Mark Lord wrote:
> Daniel Walker wrote:
> >
> > I'm interested in which clocksource is getting used, which is in the
> > boot log.
>
> Well then, send me a patch that dumps that information out just before it
> locks up.
> We know (first post in this thread)
On Mon, 2007-04-30 at 23:33 -0400, Mark Lord wrote:
> Daniel Walker wrote:
> >
> > I'm interested in which clocksource is getting used, which is in the
> > boot log.
>
> Well then, send me a patch that dumps that information out just before it
> locks up.
> We know (first post in this thread)
Daniel Walker wrote:
I'm interested in which clocksource is getting used, which is in the
boot log.
Well then, send me a patch that dumps that information out just before it locks
up.
We know (first post in this thread) that the lockup occurs just after
these two messages:
"switched to
On Mon, 2007-04-30 at 20:11 -0400, Mark Lord wrote:
> Michal Piotrowski wrote:
> >
> > Please read chapter 3 {serial,net}console
> > http://www.stardust.webpages.pl/files/handbook/handbook-en.pdf
>
> No thanks.
>
> No serial, and netconsole doesn't work during early boot when it locks up.
>
Michal Piotrowski wrote:
Please read chapter 3 {serial,net}console
http://www.stardust.webpages.pl/files/handbook/handbook-en.pdf
No thanks.
No serial, and netconsole doesn't work during early boot when it locks up.
Besides, we already know as much as the existing messages show.
-ml
-
To
Hi Mark,
On 01/05/07, Mark Lord <[EMAIL PROTECTED]> wrote:
Daniel Walker wrote:
>
> Hmm, Do you have a boot log ? I didn't see one in any of the last emails.
When it doesn't boot, there's no log.
When it does boot with the modified .config file,
the log looks like the one attached to this
Daniel Walker wrote:
Hmm, Do you have a boot log ? I didn't see one in any of the last emails.
When it doesn't boot, there's no log.
When it does boot with the modified .config file,
the log looks like the one attached to this email.
Cheers
success.log.gz
Description: application/gzip
On Mon, 2007-04-30 at 19:36 -0400, Mark Lord wrote:
> Mark Lord wrote:
> > Mark Lord wrote:
> >> Mark Lord wrote:
> >>> I have a new notebook (Dell Inspiron 9400) with Core2-Duo T7400 @
> >>> 2.1Ghz.
> >>> When either/both of CONFIG_NO_HZ, CONFIG_HIGH_RES_TIMERS is used,
> >>> the 2.6.21 kernel
On Mon, 2007-04-30 at 19:36 -0400, Mark Lord wrote:
> Well, in case this helps. If I take the exact same .config that fails,
> and add *only* this to it, it then boots just fine.
>
>CONFIG_DETECT_SOFTLOCKUP=y
That's definitely helpful. Thanks for tracking it down. I look at it
tomorrow
Mark Lord wrote:
Mark Lord wrote:
Mark Lord wrote:
I have a new notebook (Dell Inspiron 9400) with Core2-Duo T7400 @
2.1Ghz.
When either/both of CONFIG_NO_HZ, CONFIG_HIGH_RES_TIMERS is used,
the 2.6.21 kernel hangs on startup just after printing one/both of
these:
..
That's a hard hang, by
Mark Lord wrote:
Mark Lord wrote:
I have a new notebook (Dell Inspiron 9400) with Core2-Duo T7400 @ 2.1Ghz.
When either/both of CONFIG_NO_HZ, CONFIG_HIGH_RES_TIMERS is used,
the 2.6.21 kernel hangs on startup just after printing one/both of these:
..
That's a hard hang, by the way. No magic
Mark Lord wrote:
I have a new notebook (Dell Inspiron 9400) with Core2-Duo T7400 @ 2.1Ghz.
When either/both of CONFIG_NO_HZ, CONFIG_HIGH_RES_TIMERS is used,
the 2.6.21 kernel hangs on startup just after printing one/both of these:
..
That's a hard hang, by the way. No magic sysrq key or
Mark Lord wrote:
I have a new notebook (Dell Inspiron 9400) with Core2-Duo T7400 @ 2.1Ghz.
When either/both of CONFIG_NO_HZ, CONFIG_HIGH_RES_TIMERS is used,
the 2.6.21 kernel hangs on startup just after printing one/both of these:
..
That's a hard hang, by the way. No magic sysrq key or
Mark Lord wrote:
Mark Lord wrote:
I have a new notebook (Dell Inspiron 9400) with Core2-Duo T7400 @ 2.1Ghz.
When either/both of CONFIG_NO_HZ, CONFIG_HIGH_RES_TIMERS is used,
the 2.6.21 kernel hangs on startup just after printing one/both of these:
..
That's a hard hang, by the way. No magic
Mark Lord wrote:
Mark Lord wrote:
Mark Lord wrote:
I have a new notebook (Dell Inspiron 9400) with Core2-Duo T7400 @
2.1Ghz.
When either/both of CONFIG_NO_HZ, CONFIG_HIGH_RES_TIMERS is used,
the 2.6.21 kernel hangs on startup just after printing one/both of
these:
..
That's a hard hang, by
On Mon, 2007-04-30 at 19:36 -0400, Mark Lord wrote:
Well, in case this helps. If I take the exact same .config that fails,
and add *only* this to it, it then boots just fine.
CONFIG_DETECT_SOFTLOCKUP=y
That's definitely helpful. Thanks for tracking it down. I look at it
tomorrow
On Mon, 2007-04-30 at 19:36 -0400, Mark Lord wrote:
Mark Lord wrote:
Mark Lord wrote:
Mark Lord wrote:
I have a new notebook (Dell Inspiron 9400) with Core2-Duo T7400 @
2.1Ghz.
When either/both of CONFIG_NO_HZ, CONFIG_HIGH_RES_TIMERS is used,
the 2.6.21 kernel hangs on startup just
Daniel Walker wrote:
Hmm, Do you have a boot log ? I didn't see one in any of the last emails.
When it doesn't boot, there's no log.
When it does boot with the modified .config file,
the log looks like the one attached to this email.
Cheers
success.log.gz
Description: application/gzip
Hi Mark,
On 01/05/07, Mark Lord [EMAIL PROTECTED] wrote:
Daniel Walker wrote:
Hmm, Do you have a boot log ? I didn't see one in any of the last emails.
When it doesn't boot, there's no log.
When it does boot with the modified .config file,
the log looks like the one attached to this email.
Michal Piotrowski wrote:
Please read chapter 3 {serial,net}console
http://www.stardust.webpages.pl/files/handbook/handbook-en.pdf
No thanks.
No serial, and netconsole doesn't work during early boot when it locks up.
Besides, we already know as much as the existing messages show.
-ml
-
To
On Mon, 2007-04-30 at 20:11 -0400, Mark Lord wrote:
Michal Piotrowski wrote:
Please read chapter 3 {serial,net}console
http://www.stardust.webpages.pl/files/handbook/handbook-en.pdf
No thanks.
No serial, and netconsole doesn't work during early boot when it locks up.
Besides, we
Daniel Walker wrote:
I'm interested in which clocksource is getting used, which is in the
boot log.
Well then, send me a patch that dumps that information out just before it locks
up.
We know (first post in this thread) that the lockup occurs just after
these two messages:
switched to high
On Mon, 2007-04-30 at 23:33 -0400, Mark Lord wrote:
Daniel Walker wrote:
I'm interested in which clocksource is getting used, which is in the
boot log.
Well then, send me a patch that dumps that information out just before it
locks up.
We know (first post in this thread) that the
On Mon, 2007-04-30 at 23:33 -0400, Mark Lord wrote:
Daniel Walker wrote:
I'm interested in which clocksource is getting used, which is in the
boot log.
Well then, send me a patch that dumps that information out just before it
locks up.
We know (first post in this thread) that the
64 matches
Mail list logo
