Re: 2.6.21-rt2..8 troubles
Hi, I'm back but with good news this time :)... On Tue, June 12, 2007 11:10, Rui Nuno Capela wrote: > On Tue, June 12, 2007 00:08, Thomas Gleixner wrote: >> On Mon, 2007-06-11 at 15:34 -0700, Daniel Walker wrote: >>> On Mon, 2007-06-11 at 23:42 +0200, Thomas Gleixner wrote: On Mon, 2007-06-11 at 22:25 +0100, Rui Nuno Capela wrote: > Nope. It's a Fujitsu-Siemens Amilo Si 1520 -- Intel Core2 Duo > [EMAIL PROTECTED] > Yeah, there are Dell ones which have similar or worse symptoms. > Works great with 2.6.21-rt1, and 2.6.22-rc4-hrt5, but that you > already know :) Ok. I go back and figure out which differences we have between 2.6.21-rt>8 and the -hrt queue. >>> >>> Are you sure it's strictly and HRT issue? I didn't see a >>> !CONFIG_HIGH_RES_TIMERS test .. >> >> The main difference between -rt1 and -rt2 was the update of -hrt, which >> not only affects CONFIG_HIGH_RES_TIMERS. There are enough >> CONFIG_HIGH_RES_TIMERS=n related changes to clock events and friends as >> well. > > In deed, FWIW and IIRC, I can confirm that the show-stopper problem was > still present when tried with CONFIG_HIGH_RES_TIMERS not set (=N). > Although I'm still with my fingers crossed, I can tell that 2.6.21.5-rt19 (and -rt20) does behave far better now on the very same box. I've more than 8 hours up and running now, without a single glimpse of the bad symptoms, which used to show in a matter of minutes if not earlier during init time. Congratulations, -rt is usable again here and that just makes me happier :) Cheers. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rt2..8 troubles
Hi, I'm back but with good news this time :)... On Tue, June 12, 2007 11:10, Rui Nuno Capela wrote: On Tue, June 12, 2007 00:08, Thomas Gleixner wrote: On Mon, 2007-06-11 at 15:34 -0700, Daniel Walker wrote: On Mon, 2007-06-11 at 23:42 +0200, Thomas Gleixner wrote: On Mon, 2007-06-11 at 22:25 +0100, Rui Nuno Capela wrote: Nope. It's a Fujitsu-Siemens Amilo Si 1520 -- Intel Core2 Duo [EMAIL PROTECTED] Yeah, there are Dell ones which have similar or worse symptoms. Works great with 2.6.21-rt1, and 2.6.22-rc4-hrt5, but that you already know :) Ok. I go back and figure out which differences we have between 2.6.21-rt8 and the -hrt queue. Are you sure it's strictly and HRT issue? I didn't see a !CONFIG_HIGH_RES_TIMERS test .. The main difference between -rt1 and -rt2 was the update of -hrt, which not only affects CONFIG_HIGH_RES_TIMERS. There are enough CONFIG_HIGH_RES_TIMERS=n related changes to clock events and friends as well. In deed, FWIW and IIRC, I can confirm that the show-stopper problem was still present when tried with CONFIG_HIGH_RES_TIMERS not set (=N). Although I'm still with my fingers crossed, I can tell that 2.6.21.5-rt19 (and -rt20) does behave far better now on the very same box. I've more than 8 hours up and running now, without a single glimpse of the bad symptoms, which used to show in a matter of minutes if not earlier during init time. Congratulations, -rt is usable again here and that just makes me happier :) Cheers. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rt2..8 troubles
On Tue, June 12, 2007 00:08, Thomas Gleixner wrote: > On Mon, 2007-06-11 at 15:34 -0700, Daniel Walker wrote: > >> On Mon, 2007-06-11 at 23:42 +0200, Thomas Gleixner wrote: >> >>> On Mon, 2007-06-11 at 22:25 +0100, Rui Nuno Capela wrote: >>> Nope. It's a Fujitsu-Siemens Amilo Si 1520 -- Intel Core2 Duo [EMAIL PROTECTED] >>> >>> Yeah, there are Dell ones which have similar or worse symptoms. >>> >>> Works great with 2.6.21-rt1, and 2.6.22-rc4-hrt5, but that you already know :) >>> >>> Ok. I go back and figure out which differences we have between >>> 2.6.21-rt>8 and the -hrt queue. >>> >> >> Are you sure it's strictly and HRT issue? I didn't see a >> !CONFIG_HIGH_RES_TIMERS test .. >> > > The main difference between -rt1 and -rt2 was the update of -hrt, which > not only affects CONFIG_HIGH_RES_TIMERS. There are enough > CONFIG_HIGH_RES_TIMERS=n related changes to clock events and friends as > well. > In deed, FWIW and IIRC, I can confirm that the show-stopper problem was still present when tried with CONFIG_HIGH_RES_TIMERS not set (=N). Bye now. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rt2..8 troubles
On Tue, June 12, 2007 00:08, Thomas Gleixner wrote: On Mon, 2007-06-11 at 15:34 -0700, Daniel Walker wrote: On Mon, 2007-06-11 at 23:42 +0200, Thomas Gleixner wrote: On Mon, 2007-06-11 at 22:25 +0100, Rui Nuno Capela wrote: Nope. It's a Fujitsu-Siemens Amilo Si 1520 -- Intel Core2 Duo [EMAIL PROTECTED] Yeah, there are Dell ones which have similar or worse symptoms. Works great with 2.6.21-rt1, and 2.6.22-rc4-hrt5, but that you already know :) Ok. I go back and figure out which differences we have between 2.6.21-rt8 and the -hrt queue. Are you sure it's strictly and HRT issue? I didn't see a !CONFIG_HIGH_RES_TIMERS test .. The main difference between -rt1 and -rt2 was the update of -hrt, which not only affects CONFIG_HIGH_RES_TIMERS. There are enough CONFIG_HIGH_RES_TIMERS=n related changes to clock events and friends as well. In deed, FWIW and IIRC, I can confirm that the show-stopper problem was still present when tried with CONFIG_HIGH_RES_TIMERS not set (=N). Bye now. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rt2..8 troubles
On Mon, 2007-06-11 at 15:34 -0700, Daniel Walker wrote: > On Mon, 2007-06-11 at 23:42 +0200, Thomas Gleixner wrote: > > On Mon, 2007-06-11 at 22:25 +0100, Rui Nuno Capela wrote: > > > Nope. It's a Fujitsu-Siemens Amilo Si 1520 -- Intel Core2 Duo [EMAIL > > > PROTECTED] > > > > Yeah, there are Dell ones which have similar or worse symptoms. > > > > > Works great with 2.6.21-rt1, and 2.6.22-rc4-hrt5, but that you already > > > know :) > > > > Ok. I go back and figure out which differences we have between > > 2.6.21-rt>8 and the -hrt queue. > > Are you sure it's strictly and HRT issue? I didn't see a > !CONFIG_HIGH_RES_TIMERS test .. The main difference between -rt1 and -rt2 was the update of -hrt, which not only affects CONFIG_HIGH_RES_TIMERS. There are enough CONFIG_HIGH_RES_TIMERS=n related changes to clock events and friends as well. tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rt2..8 troubles
On Mon, 2007-06-11 at 23:42 +0200, Thomas Gleixner wrote: > On Mon, 2007-06-11 at 22:25 +0100, Rui Nuno Capela wrote: > > Nope. It's a Fujitsu-Siemens Amilo Si 1520 -- Intel Core2 Duo [EMAIL > > PROTECTED] > > Yeah, there are Dell ones which have similar or worse symptoms. > > > Works great with 2.6.21-rt1, and 2.6.22-rc4-hrt5, but that you already > > know :) > > Ok. I go back and figure out which differences we have between > 2.6.21-rt>8 and the -hrt queue. Are you sure it's strictly and HRT issue? I didn't see a !CONFIG_HIGH_RES_TIMERS test .. Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rt2..8 troubles
On Mon, 2007-06-11 at 22:25 +0100, Rui Nuno Capela wrote: > Nope. It's a Fujitsu-Siemens Amilo Si 1520 -- Intel Core2 Duo [EMAIL > PROTECTED] Yeah, there are Dell ones which have similar or worse symptoms. > Works great with 2.6.21-rt1, and 2.6.22-rc4-hrt5, but that you already > know :) Ok. I go back and figure out which differences we have between 2.6.21-rt>8 and the -hrt queue. tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rt2..8 troubles
Thomas Gleixner wrote: > On Mon, 2007-06-11 at 21:50 +0100, Rui Nuno Capela wrote: >> Thomas, >> >> Yes, "maxcpus=1" seems to keep it running, but then I render my Core2 >> just half-baked ;) > > Yes, I know :( > > /me goes into desperate mode > > Is this a DELL laptop ? > Nope. It's a Fujitsu-Siemens Amilo Si 1520 -- Intel Core2 Duo [EMAIL PROTECTED] Works great with 2.6.21-rt1, and 2.6.22-rc4-hrt5, but that you already know :) Cheers. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rt2..8 troubles
On Mon, 2007-06-11 at 21:50 +0100, Rui Nuno Capela wrote: > Thomas, > > Yes, "maxcpus=1" seems to keep it running, but then I render my Core2 > just half-baked ;) Yes, I know :( /me goes into desperate mode Is this a DELL laptop ? tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rt2..8 troubles
Daniel Walker wrote: > On Mon, 2007-06-11 at 21:45 +0200, Thomas Gleixner wrote: >> On Mon, 2007-06-11 at 20:36 +0100, Rui Nuno Capela wrote: I'm spinning -rt10 with a couple of fixes. Should be out sometimes tomorrow. If the problem persists, we need to dig deeper. >>> Uhoh. I'm sorry to tell, but the problem is still creeping on >>> 2.6.21.4-rt11 and -rt12 :( >>> >>> So sorry. >> Hmm. Does it happen, when you boot with maxcpus=1 on the kernel >> commandline ? > > I think 2.6.21-rt2 had some apic updates also, (along with hpet updates) > so testing with "noapic" on the command line might be helpful too .. > Thomas, Yes, "maxcpus=1" seems to keep it running, but then I render my Core2 just half-baked ;) Daniel, No, "noapic" does not seem to help any better. HTH -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rt2..8 troubles
On Mon, 2007-06-11 at 21:45 +0200, Thomas Gleixner wrote: > On Mon, 2007-06-11 at 20:36 +0100, Rui Nuno Capela wrote: > > > I'm spinning -rt10 with a couple of fixes. Should be out sometimes > > > tomorrow. If the problem persists, we need to dig deeper. > > > > > > > Uhoh. I'm sorry to tell, but the problem is still creeping on > > 2.6.21.4-rt11 and -rt12 :( > > > > So sorry. > > Hmm. Does it happen, when you boot with maxcpus=1 on the kernel > commandline ? I think 2.6.21-rt2 had some apic updates also, (along with hpet updates) so testing with "noapic" on the command line might be helpful too .. Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rt2..8 troubles
On Mon, 2007-06-11 at 20:36 +0100, Rui Nuno Capela wrote: > > I'm spinning -rt10 with a couple of fixes. Should be out sometimes > > tomorrow. If the problem persists, we need to dig deeper. > > > > Uhoh. I'm sorry to tell, but the problem is still creeping on > 2.6.21.4-rt11 and -rt12 :( > > So sorry. Hmm. Does it happen, when you boot with maxcpus=1 on the kernel commandline ? tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rt2..8 troubles
Thomas Gleixner wrote: > On Fri, 2007-06-08 at 19:21 +0100, Rui Nuno Capela wrote: >> Just built from linux-2.6.22-rc4.tar.bz2, with patch-2.6.22-rc4-hrt5. >> All's working apparentely nice on this offending machine (laptop, intel >> core2 T7200). In fact, I'm writing this very reply under it and through >> ipw3945 wifi module--which never was so pragmatic on -rt2..9 ;) >> >> Nevertheless, this is not preempt-realtime (-rt) is it? And I it never >> complained about vanilla. >> >> Is this good news though? > > Well, the patch carries the same high resolution timer fixes as -rt, so > I just wanted to exclude those. Thanks for testing. > > I'm spinning -rt10 with a couple of fixes. Should be out sometimes > tomorrow. If the problem persists, we need to dig deeper. > Uhoh. I'm sorry to tell, but the problem is still creeping on 2.6.21.4-rt11 and -rt12 :( So sorry. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rt2..8 troubles
Thomas Gleixner wrote: On Fri, 2007-06-08 at 19:21 +0100, Rui Nuno Capela wrote: Just built from linux-2.6.22-rc4.tar.bz2, with patch-2.6.22-rc4-hrt5. All's working apparentely nice on this offending machine (laptop, intel core2 T7200). In fact, I'm writing this very reply under it and through ipw3945 wifi module--which never was so pragmatic on -rt2..9 ;) Nevertheless, this is not preempt-realtime (-rt) is it? And I it never complained about vanilla. Is this good news though? Well, the patch carries the same high resolution timer fixes as -rt, so I just wanted to exclude those. Thanks for testing. I'm spinning -rt10 with a couple of fixes. Should be out sometimes tomorrow. If the problem persists, we need to dig deeper. Uhoh. I'm sorry to tell, but the problem is still creeping on 2.6.21.4-rt11 and -rt12 :( So sorry. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rt2..8 troubles
On Mon, 2007-06-11 at 20:36 +0100, Rui Nuno Capela wrote: I'm spinning -rt10 with a couple of fixes. Should be out sometimes tomorrow. If the problem persists, we need to dig deeper. Uhoh. I'm sorry to tell, but the problem is still creeping on 2.6.21.4-rt11 and -rt12 :( So sorry. Hmm. Does it happen, when you boot with maxcpus=1 on the kernel commandline ? tglx - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rt2..8 troubles
On Mon, 2007-06-11 at 21:45 +0200, Thomas Gleixner wrote: On Mon, 2007-06-11 at 20:36 +0100, Rui Nuno Capela wrote: I'm spinning -rt10 with a couple of fixes. Should be out sometimes tomorrow. If the problem persists, we need to dig deeper. Uhoh. I'm sorry to tell, but the problem is still creeping on 2.6.21.4-rt11 and -rt12 :( So sorry. Hmm. Does it happen, when you boot with maxcpus=1 on the kernel commandline ? I think 2.6.21-rt2 had some apic updates also, (along with hpet updates) so testing with noapic on the command line might be helpful too .. Daniel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rt2..8 troubles
Daniel Walker wrote: On Mon, 2007-06-11 at 21:45 +0200, Thomas Gleixner wrote: On Mon, 2007-06-11 at 20:36 +0100, Rui Nuno Capela wrote: I'm spinning -rt10 with a couple of fixes. Should be out sometimes tomorrow. If the problem persists, we need to dig deeper. Uhoh. I'm sorry to tell, but the problem is still creeping on 2.6.21.4-rt11 and -rt12 :( So sorry. Hmm. Does it happen, when you boot with maxcpus=1 on the kernel commandline ? I think 2.6.21-rt2 had some apic updates also, (along with hpet updates) so testing with noapic on the command line might be helpful too .. Thomas, Yes, maxcpus=1 seems to keep it running, but then I render my Core2 just half-baked ;) Daniel, No, noapic does not seem to help any better. HTH -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rt2..8 troubles
On Mon, 2007-06-11 at 21:50 +0100, Rui Nuno Capela wrote: Thomas, Yes, maxcpus=1 seems to keep it running, but then I render my Core2 just half-baked ;) Yes, I know :( /me goes into desperate mode Is this a DELL laptop ? tglx - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rt2..8 troubles
Thomas Gleixner wrote: On Mon, 2007-06-11 at 21:50 +0100, Rui Nuno Capela wrote: Thomas, Yes, maxcpus=1 seems to keep it running, but then I render my Core2 just half-baked ;) Yes, I know :( /me goes into desperate mode Is this a DELL laptop ? Nope. It's a Fujitsu-Siemens Amilo Si 1520 -- Intel Core2 Duo [EMAIL PROTECTED] Works great with 2.6.21-rt1, and 2.6.22-rc4-hrt5, but that you already know :) Cheers. -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rt2..8 troubles
On Mon, 2007-06-11 at 22:25 +0100, Rui Nuno Capela wrote: Nope. It's a Fujitsu-Siemens Amilo Si 1520 -- Intel Core2 Duo [EMAIL PROTECTED] Yeah, there are Dell ones which have similar or worse symptoms. Works great with 2.6.21-rt1, and 2.6.22-rc4-hrt5, but that you already know :) Ok. I go back and figure out which differences we have between 2.6.21-rt8 and the -hrt queue. tglx - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rt2..8 troubles
On Mon, 2007-06-11 at 23:42 +0200, Thomas Gleixner wrote: On Mon, 2007-06-11 at 22:25 +0100, Rui Nuno Capela wrote: Nope. It's a Fujitsu-Siemens Amilo Si 1520 -- Intel Core2 Duo [EMAIL PROTECTED] Yeah, there are Dell ones which have similar or worse symptoms. Works great with 2.6.21-rt1, and 2.6.22-rc4-hrt5, but that you already know :) Ok. I go back and figure out which differences we have between 2.6.21-rt8 and the -hrt queue. Are you sure it's strictly and HRT issue? I didn't see a !CONFIG_HIGH_RES_TIMERS test .. Daniel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rt2..8 troubles
On Mon, 2007-06-11 at 15:34 -0700, Daniel Walker wrote: On Mon, 2007-06-11 at 23:42 +0200, Thomas Gleixner wrote: On Mon, 2007-06-11 at 22:25 +0100, Rui Nuno Capela wrote: Nope. It's a Fujitsu-Siemens Amilo Si 1520 -- Intel Core2 Duo [EMAIL PROTECTED] Yeah, there are Dell ones which have similar or worse symptoms. Works great with 2.6.21-rt1, and 2.6.22-rc4-hrt5, but that you already know :) Ok. I go back and figure out which differences we have between 2.6.21-rt8 and the -hrt queue. Are you sure it's strictly and HRT issue? I didn't see a !CONFIG_HIGH_RES_TIMERS test .. The main difference between -rt1 and -rt2 was the update of -hrt, which not only affects CONFIG_HIGH_RES_TIMERS. There are enough CONFIG_HIGH_RES_TIMERS=n related changes to clock events and friends as well. tglx - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rt2..8 troubles
On Fri, 2007-06-08 at 19:21 +0100, Rui Nuno Capela wrote: > >> There's no way around. On one box it works flawlessly (desktop, > >> [EMAIL PROTECTED]) while on the patient one (laptop, core2 T7200) it bricks > >> silently. > > > > Sorry for responding late. To have some idea where the breakage comes > > from, can you please try > > > > http://www.tglx.de/projects/hrtimers/2.6.22-rc4/patch-2.6.22-rc4-hrt5.pat > > ch > > > > whether it has the same behaviour. > > > > Just built from linux-2.6.22-rc4.tar.bz2, with patch-2.6.22-rc4-hrt5. > All's working apparentely nice on this offending machine (laptop, intel > core2 T7200). In fact, I'm writing this very reply under it and through > ipw3945 wifi module--which never was so pragmatic on -rt2..9 ;) > > Nevertheless, this is not preempt-realtime (-rt) is it? And I it never > complained about vanilla. > > Is this good news though? Well, the patch carries the same high resolution timer fixes as -rt, so I just wanted to exclude those. Thanks for testing. I'm spinning -rt10 with a couple of fixes. Should be out sometimes tomorrow. If the problem persists, we need to dig deeper. Thanks, tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rt2..8 troubles
Hi Thomas, On Fri, June 8, 2007 16:47, Thomas Gleixner wrote: > On Wed, 2007-06-06 at 01:44 +0100, Rui Nuno Capela wrote: > >> Just for the heads-up, I'm still suffering from this same illness, and >> it seems even worse (big freeze happens earlier) on 2.6.21.3-rt9. >> >> There's no way around. On one box it works flawlessly (desktop, >> [EMAIL PROTECTED]) while on the patient one (laptop, core2 T7200) it bricks >> silently. > > Sorry for responding late. To have some idea where the breakage comes > from, can you please try > > http://www.tglx.de/projects/hrtimers/2.6.22-rc4/patch-2.6.22-rc4-hrt5.pat > ch > > whether it has the same behaviour. > Just built from linux-2.6.22-rc4.tar.bz2, with patch-2.6.22-rc4-hrt5. All's working apparentely nice on this offending machine (laptop, intel core2 T7200). In fact, I'm writing this very reply under it and through ipw3945 wifi module--which never was so pragmatic on -rt2..9 ;) Nevertheless, this is not preempt-realtime (-rt) is it? And I it never complained about vanilla. Is this good news though? -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rt2..8 troubles
On Wed, 2007-06-06 at 01:44 +0100, Rui Nuno Capela wrote: > Just for the heads-up, I'm still suffering from this same illness, and > it seems even worse (big freeze happens earlier) on 2.6.21.3-rt9. > > There's no way around. On one box it works flawlessly (desktop, > [EMAIL PROTECTED]) while on the patient one (laptop, core2 T7200) it bricks > silently. Sorry for responding late. To have some idea where the breakage comes from, can you please try http://www.tglx.de/projects/hrtimers/2.6.22-rc4/patch-2.6.22-rc4-hrt5.patch whether it has the same behaviour. Thanks, tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rt2..8 troubles
On Wed, 2007-06-06 at 01:44 +0100, Rui Nuno Capela wrote: Just for the heads-up, I'm still suffering from this same illness, and it seems even worse (big freeze happens earlier) on 2.6.21.3-rt9. There's no way around. On one box it works flawlessly (desktop, [EMAIL PROTECTED]) while on the patient one (laptop, core2 T7200) it bricks silently. Sorry for responding late. To have some idea where the breakage comes from, can you please try http://www.tglx.de/projects/hrtimers/2.6.22-rc4/patch-2.6.22-rc4-hrt5.patch whether it has the same behaviour. Thanks, tglx - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rt2..8 troubles
Hi Thomas, On Fri, June 8, 2007 16:47, Thomas Gleixner wrote: On Wed, 2007-06-06 at 01:44 +0100, Rui Nuno Capela wrote: Just for the heads-up, I'm still suffering from this same illness, and it seems even worse (big freeze happens earlier) on 2.6.21.3-rt9. There's no way around. On one box it works flawlessly (desktop, [EMAIL PROTECTED]) while on the patient one (laptop, core2 T7200) it bricks silently. Sorry for responding late. To have some idea where the breakage comes from, can you please try http://www.tglx.de/projects/hrtimers/2.6.22-rc4/patch-2.6.22-rc4-hrt5.pat ch whether it has the same behaviour. Just built from linux-2.6.22-rc4.tar.bz2, with patch-2.6.22-rc4-hrt5. All's working apparentely nice on this offending machine (laptop, intel core2 T7200). In fact, I'm writing this very reply under it and through ipw3945 wifi module--which never was so pragmatic on -rt2..9 ;) Nevertheless, this is not preempt-realtime (-rt) is it? And I it never complained about vanilla. Is this good news though? -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rt2..8 troubles
On Fri, 2007-06-08 at 19:21 +0100, Rui Nuno Capela wrote: There's no way around. On one box it works flawlessly (desktop, [EMAIL PROTECTED]) while on the patient one (laptop, core2 T7200) it bricks silently. Sorry for responding late. To have some idea where the breakage comes from, can you please try http://www.tglx.de/projects/hrtimers/2.6.22-rc4/patch-2.6.22-rc4-hrt5.pat ch whether it has the same behaviour. Just built from linux-2.6.22-rc4.tar.bz2, with patch-2.6.22-rc4-hrt5. All's working apparentely nice on this offending machine (laptop, intel core2 T7200). In fact, I'm writing this very reply under it and through ipw3945 wifi module--which never was so pragmatic on -rt2..9 ;) Nevertheless, this is not preempt-realtime (-rt) is it? And I it never complained about vanilla. Is this good news though? Well, the patch carries the same high resolution timer fixes as -rt, so I just wanted to exclude those. Thanks for testing. I'm spinning -rt10 with a couple of fixes. Should be out sometimes tomorrow. If the problem persists, we need to dig deeper. Thanks, tglx - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rt2..8 troubles
Rui Nuno Capela wrote: > Thomas Gleixner wrote: >> On Fri, 2007-05-25 at 21:58 +0100, Rui Nuno Capela wrote: >>> Is there anything I can do better to help myself figuring out this >>> issue? As this is a modern laptop such things like a serial console are >>> unavailable, but it would be nice to track things up over netconsole >>> perhaps? >>> >>> I just need some bright and nice directions now ;) Hope someone finds >>> this worth of attention too. Meanwhile, I'll be happy with 2.6.21-rt1 :) >> Can you boot with "hpet=disable" on the command line ? >> > > Nope. It doesn't seem to have significant effect. Same time-bomb > behavior: after an indeterminate period of uptime, the systems stops > responding and cannot spawn new processes (current running ones still > live on, strange). > >> If that does not help, please provide the output of /proc/timer_list. >> > > This is with my latest iteration: > http://www.rncbc.org/datahub/config-2.6.21.1-rt8.0 > > Normal boot on which it behaves as badly as reported: > http://www.rncbc.org/datahub/dmesg-2.6.21.1-rt8.0 > > # cat /proc/timer_list > Timer List Version: v0.3 > HRTIMER_MAX_CLOCK_BASES: 2 > now at 131736771907 nsecs > > cpu: 0 > clock 0: > .index: 0 > .resolution: 1 nsecs > .get_time: ktime_get_real > .offset: 1180213690448299114 nsecs > active timers: > clock 1: > .index: 1 > .resolution: 1 nsecs > .get_time: ktime_get > .offset: 0 nsecs > active timers: > #0: , tick_sched_timer, S:01 > # expires at 13173700 nsecs [in 228093 nsecs] > #1: , it_real_fn, S:01 > # expires at 131751277843 nsecs [in 14505936 nsecs] > #2: , hrtimer_wakeup, S:01 > # expires at 131802703679 nsecs [in 65931772 nsecs] > #3: , hrtimer_wakeup, S:01 > # expires at 131802705006 nsecs [in 65933099 nsecs] > #4: , hrtimer_wakeup, S:01 > # expires at 132412838830 nsecs [in 676066923 nsecs] > #5: , it_real_fn, S:01 > # expires at 137026607454 nsecs [in 5289835547 nsecs] > #6: , hrtimer_wakeup, S:01 > # expires at 141381493725 nsecs [in 9644721818 nsecs] > #7: , hrtimer_wakeup, S:01 > # expires at 170796028701 nsecs [in 39059256794 nsecs] > .expires_next : 13173700 nsecs > .hres_active: 1 > .nr_events : 40634 > .nohz_mode : 2 > .idle_tick : 13172400 nsecs > .tick_stopped : 0 > .idle_jiffies : 4294799020 > .idle_calls : 178848 > .idle_sleeps: 133212 > .idle_entrytime : 131736069830 nsecs > .idle_sleeptime : 100895567465 nsecs > .last_jiffies : 4294799033 > .next_jiffies : 4294799039 > .idle_expires : 13173600 nsecs > jiffies: 4294799033 > > cpu: 1 > clock 0: > .index: 0 > .resolution: 1 nsecs > .get_time: ktime_get_real > .offset: 1180213690448299114 nsecs > active timers: > clock 1: > .index: 1 > .resolution: 1 nsecs > .get_time: ktime_get > .offset: 0 nsecs > active timers: > #0: , hrtimer_wakeup, S:01 > # expires at 131737067173 nsecs [in 295266 nsecs] > #1: , tick_sched_timer, S:01 > # expires at 13173725 nsecs [in 478093 nsecs] > #2: , hrtimer_wakeup, S:01 > # expires at 139151071745 nsecs [in 7414299838 nsecs] > #3: , hrtimer_wakeup, S:01 > # expires at 139151133755 nsecs [in 7414361848 nsecs] > #4: , hrtimer_wakeup, S:01 > # expires at 139151154005 nsecs [in 7414382098 nsecs] > .expires_next : 131737067173 nsecs > .hres_active: 1 > .nr_events : 31510 > .nohz_mode : 2 > .idle_tick : 13173425 nsecs > .tick_stopped : 0 > .idle_jiffies : 4294799030 > .idle_calls : 151213 > .idle_sleeps: 107018 > .idle_entrytime : 131735193036 nsecs > .idle_sleeptime : 108256832194 nsecs > .last_jiffies : 4294799032 > .next_jiffies : 4294799040 > .idle_expires : 13174300 nsecs > jiffies: 4294799033 > > > Tick Device: mode: 1 > Clock Event Device: hpet > max_delta_ns: 2147483647 > min_delta_ns: 3352 > mult: 61496110 > shift: 32 > mode: 3 > next_event: 13173700 nsecs > set_next_event: hpet_legacy_next_event > set_mode: hpet_legacy_set_mode > event_handler: tick_handle_oneshot_broadcast > tick_broadcast_mask: 0003 > tick_broadcast_oneshot_mask: 0001 > > > Tick Device: mode: 1 > Clock Event Device: lapic > max_delta_ns: 806914928 > min_delta_ns: 1442 > mult: 44650051 > shift: 32 > mode: 1 > next_event: 13173700 nsecs > set_next_event: lapic_next_event > set_mode: lapic_timer_setup > event_handler: hrtimer_interrupt > > Tick Device: mode: 1 > Clock Event Device: lapic > max_delta_ns: 806914928 > min_delta_ns: 1442 > mult: 44650051 > shift: 32 > mode: 3 > next_event: 131737067173 nsecs > set_next_event: lapic_next_event > set_mode: lapic_timer_setup > event_handler: hrtimer_interrupt > -- > > > Alternate boot with hpet=disabled as suggested, but no
Re: 2.6.21-rt2..8 troubles
Rui Nuno Capela wrote: Thomas Gleixner wrote: On Fri, 2007-05-25 at 21:58 +0100, Rui Nuno Capela wrote: Is there anything I can do better to help myself figuring out this issue? As this is a modern laptop such things like a serial console are unavailable, but it would be nice to track things up over netconsole perhaps? I just need some bright and nice directions now ;) Hope someone finds this worth of attention too. Meanwhile, I'll be happy with 2.6.21-rt1 :) Can you boot with hpet=disable on the command line ? Nope. It doesn't seem to have significant effect. Same time-bomb behavior: after an indeterminate period of uptime, the systems stops responding and cannot spawn new processes (current running ones still live on, strange). If that does not help, please provide the output of /proc/timer_list. This is with my latest iteration: http://www.rncbc.org/datahub/config-2.6.21.1-rt8.0 Normal boot on which it behaves as badly as reported: http://www.rncbc.org/datahub/dmesg-2.6.21.1-rt8.0 # cat /proc/timer_list Timer List Version: v0.3 HRTIMER_MAX_CLOCK_BASES: 2 now at 131736771907 nsecs cpu: 0 clock 0: .index: 0 .resolution: 1 nsecs .get_time: ktime_get_real .offset: 1180213690448299114 nsecs active timers: clock 1: .index: 1 .resolution: 1 nsecs .get_time: ktime_get .offset: 0 nsecs active timers: #0: ed7c4ef4, tick_sched_timer, S:01 # expires at 13173700 nsecs [in 228093 nsecs] #1: ed7c4ef4, it_real_fn, S:01 # expires at 131751277843 nsecs [in 14505936 nsecs] #2: ed7c4ef4, hrtimer_wakeup, S:01 # expires at 131802703679 nsecs [in 65931772 nsecs] #3: ed7c4ef4, hrtimer_wakeup, S:01 # expires at 131802705006 nsecs [in 65933099 nsecs] #4: ed7c4ef4, hrtimer_wakeup, S:01 # expires at 132412838830 nsecs [in 676066923 nsecs] #5: ed7c4ef4, it_real_fn, S:01 # expires at 137026607454 nsecs [in 5289835547 nsecs] #6: ed7c4ef4, hrtimer_wakeup, S:01 # expires at 141381493725 nsecs [in 9644721818 nsecs] #7: ed7c4ef4, hrtimer_wakeup, S:01 # expires at 170796028701 nsecs [in 39059256794 nsecs] .expires_next : 13173700 nsecs .hres_active: 1 .nr_events : 40634 .nohz_mode : 2 .idle_tick : 13172400 nsecs .tick_stopped : 0 .idle_jiffies : 4294799020 .idle_calls : 178848 .idle_sleeps: 133212 .idle_entrytime : 131736069830 nsecs .idle_sleeptime : 100895567465 nsecs .last_jiffies : 4294799033 .next_jiffies : 4294799039 .idle_expires : 13173600 nsecs jiffies: 4294799033 cpu: 1 clock 0: .index: 0 .resolution: 1 nsecs .get_time: ktime_get_real .offset: 1180213690448299114 nsecs active timers: clock 1: .index: 1 .resolution: 1 nsecs .get_time: ktime_get .offset: 0 nsecs active timers: #0: ed7c4ef4, hrtimer_wakeup, S:01 # expires at 131737067173 nsecs [in 295266 nsecs] #1: ed7c4ef4, tick_sched_timer, S:01 # expires at 13173725 nsecs [in 478093 nsecs] #2: ed7c4ef4, hrtimer_wakeup, S:01 # expires at 139151071745 nsecs [in 7414299838 nsecs] #3: ed7c4ef4, hrtimer_wakeup, S:01 # expires at 139151133755 nsecs [in 7414361848 nsecs] #4: ed7c4ef4, hrtimer_wakeup, S:01 # expires at 139151154005 nsecs [in 7414382098 nsecs] .expires_next : 131737067173 nsecs .hres_active: 1 .nr_events : 31510 .nohz_mode : 2 .idle_tick : 13173425 nsecs .tick_stopped : 0 .idle_jiffies : 4294799030 .idle_calls : 151213 .idle_sleeps: 107018 .idle_entrytime : 131735193036 nsecs .idle_sleeptime : 108256832194 nsecs .last_jiffies : 4294799032 .next_jiffies : 4294799040 .idle_expires : 13174300 nsecs jiffies: 4294799033 Tick Device: mode: 1 Clock Event Device: hpet max_delta_ns: 2147483647 min_delta_ns: 3352 mult: 61496110 shift: 32 mode: 3 next_event: 13173700 nsecs set_next_event: hpet_legacy_next_event set_mode: hpet_legacy_set_mode event_handler: tick_handle_oneshot_broadcast tick_broadcast_mask: 0003 tick_broadcast_oneshot_mask: 0001 Tick Device: mode: 1 Clock Event Device: lapic max_delta_ns: 806914928 min_delta_ns: 1442 mult: 44650051 shift: 32 mode: 1 next_event: 13173700 nsecs set_next_event: lapic_next_event set_mode: lapic_timer_setup event_handler: hrtimer_interrupt Tick Device: mode: 1 Clock Event Device: lapic max_delta_ns: 806914928 min_delta_ns: 1442 mult: 44650051 shift: 32 mode: 3 next_event: 131737067173 nsecs set_next_event: lapic_next_event set_mode: lapic_timer_setup event_handler: hrtimer_interrupt -- Alternate boot with hpet=disabled as suggested, but no better results:
Re: 2.6.21-rt2..8 troubles
On Fri, May 25, 2007 at 09:58:12PM +0100, Rui Nuno Capela wrote: > > I wish I could give you more details, but the fact is I don't know > where > to look. The machine just freezes silently, again and again, with all > kernels from -rt2 to -rt8 inclusive, with no traceable evidence, at > least to my knowledge. The only symptom that I can come about is that, > from some moment on and ever since, the system cannot start any new > process anymore, or otherwise takes forever to realize and launch any > new started process thread. > I have a box that looks like it's doing the same thing. Unfortunately for now it's being used to test other things. But I did do a show-task and see a bunch of D processes. I'll post that output when I get that box free again. -- Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rt2..8 troubles
On Fri, May 25, 2007 at 09:58:12PM +0100, Rui Nuno Capela wrote: I wish I could give you more details, but the fact is I don't know where to look. The machine just freezes silently, again and again, with all kernels from -rt2 to -rt8 inclusive, with no traceable evidence, at least to my knowledge. The only symptom that I can come about is that, from some moment on and ever since, the system cannot start any new process anymore, or otherwise takes forever to realize and launch any new started process thread. I have a box that looks like it's doing the same thing. Unfortunately for now it's being used to test other things. But I did do a show-task and see a bunch of D processes. I'll post that output when I get that box free again. -- Steve - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rt2..8 troubles
Thomas Gleixner wrote: > On Fri, 2007-05-25 at 21:58 +0100, Rui Nuno Capela wrote: >> Is there anything I can do better to help myself figuring out this >> issue? As this is a modern laptop such things like a serial console are >> unavailable, but it would be nice to track things up over netconsole >> perhaps? >> >> I just need some bright and nice directions now ;) Hope someone finds >> this worth of attention too. Meanwhile, I'll be happy with 2.6.21-rt1 :) > > Can you boot with "hpet=disable" on the command line ? > Nope. It doesn't seem to have significant effect. Same time-bomb behavior: after an indeterminate period of uptime, the systems stops responding and cannot spawn new processes (current running ones still live on, strange). > If that does not help, please provide the output of /proc/timer_list. > This is with my latest iteration: http://www.rncbc.org/datahub/config-2.6.21.1-rt8.0 Normal boot on which it behaves as badly as reported: http://www.rncbc.org/datahub/dmesg-2.6.21.1-rt8.0 # cat /proc/timer_list Timer List Version: v0.3 HRTIMER_MAX_CLOCK_BASES: 2 now at 131736771907 nsecs cpu: 0 clock 0: .index: 0 .resolution: 1 nsecs .get_time: ktime_get_real .offset: 1180213690448299114 nsecs active timers: clock 1: .index: 1 .resolution: 1 nsecs .get_time: ktime_get .offset: 0 nsecs active timers: #0: , tick_sched_timer, S:01 # expires at 13173700 nsecs [in 228093 nsecs] #1: , it_real_fn, S:01 # expires at 131751277843 nsecs [in 14505936 nsecs] #2: , hrtimer_wakeup, S:01 # expires at 131802703679 nsecs [in 65931772 nsecs] #3: , hrtimer_wakeup, S:01 # expires at 131802705006 nsecs [in 65933099 nsecs] #4: , hrtimer_wakeup, S:01 # expires at 132412838830 nsecs [in 676066923 nsecs] #5: , it_real_fn, S:01 # expires at 137026607454 nsecs [in 5289835547 nsecs] #6: , hrtimer_wakeup, S:01 # expires at 141381493725 nsecs [in 9644721818 nsecs] #7: , hrtimer_wakeup, S:01 # expires at 170796028701 nsecs [in 39059256794 nsecs] .expires_next : 13173700 nsecs .hres_active: 1 .nr_events : 40634 .nohz_mode : 2 .idle_tick : 13172400 nsecs .tick_stopped : 0 .idle_jiffies : 4294799020 .idle_calls : 178848 .idle_sleeps: 133212 .idle_entrytime : 131736069830 nsecs .idle_sleeptime : 100895567465 nsecs .last_jiffies : 4294799033 .next_jiffies : 4294799039 .idle_expires : 13173600 nsecs jiffies: 4294799033 cpu: 1 clock 0: .index: 0 .resolution: 1 nsecs .get_time: ktime_get_real .offset: 1180213690448299114 nsecs active timers: clock 1: .index: 1 .resolution: 1 nsecs .get_time: ktime_get .offset: 0 nsecs active timers: #0: , hrtimer_wakeup, S:01 # expires at 131737067173 nsecs [in 295266 nsecs] #1: , tick_sched_timer, S:01 # expires at 13173725 nsecs [in 478093 nsecs] #2: , hrtimer_wakeup, S:01 # expires at 139151071745 nsecs [in 7414299838 nsecs] #3: , hrtimer_wakeup, S:01 # expires at 139151133755 nsecs [in 7414361848 nsecs] #4: , hrtimer_wakeup, S:01 # expires at 139151154005 nsecs [in 7414382098 nsecs] .expires_next : 131737067173 nsecs .hres_active: 1 .nr_events : 31510 .nohz_mode : 2 .idle_tick : 13173425 nsecs .tick_stopped : 0 .idle_jiffies : 4294799030 .idle_calls : 151213 .idle_sleeps: 107018 .idle_entrytime : 131735193036 nsecs .idle_sleeptime : 108256832194 nsecs .last_jiffies : 4294799032 .next_jiffies : 4294799040 .idle_expires : 13174300 nsecs jiffies: 4294799033 Tick Device: mode: 1 Clock Event Device: hpet max_delta_ns: 2147483647 min_delta_ns: 3352 mult: 61496110 shift: 32 mode: 3 next_event: 13173700 nsecs set_next_event: hpet_legacy_next_event set_mode: hpet_legacy_set_mode event_handler: tick_handle_oneshot_broadcast tick_broadcast_mask: 0003 tick_broadcast_oneshot_mask: 0001 Tick Device: mode: 1 Clock Event Device: lapic max_delta_ns: 806914928 min_delta_ns: 1442 mult: 44650051 shift: 32 mode: 1 next_event: 13173700 nsecs set_next_event: lapic_next_event set_mode: lapic_timer_setup event_handler: hrtimer_interrupt Tick Device: mode: 1 Clock Event Device: lapic max_delta_ns: 806914928 min_delta_ns: 1442 mult: 44650051 shift: 32 mode: 3 next_event: 131737067173 nsecs set_next_event: lapic_next_event set_mode: lapic_timer_setup event_handler: hrtimer_interrupt -- Alternate boot with hpet=disabled as suggested, but no better results: http://www.rncbc.org/datahub/dmesg-2.6.21.1-rt8.0-hpet_disabled # cat /proc/timer_list Timer List Version: v0.3 HRTIMER_MAX_CLOCK_BASES: 2 now at 269529706096 nsecs cpu: 0 clock 0: .index: 0 .resolution: 1 nsecs .get_time: ktime_get_real .offset: 1180214106093436428 nsecs active
Re: 2.6.21-rt2..8 troubles
On Fri, 2007-05-25 at 21:58 +0100, Rui Nuno Capela wrote: > Is there anything I can do better to help myself figuring out this > issue? As this is a modern laptop such things like a serial console are > unavailable, but it would be nice to track things up over netconsole > perhaps? > > I just need some bright and nice directions now ;) Hope someone finds > this worth of attention too. Meanwhile, I'll be happy with 2.6.21-rt1 :) Can you boot with "hpet=disable" on the command line ? If that does not help, please provide the output of /proc/timer_list. Thanks, tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rt2..8 troubles
On Fri, 2007-05-25 at 21:58 +0100, Rui Nuno Capela wrote: Is there anything I can do better to help myself figuring out this issue? As this is a modern laptop such things like a serial console are unavailable, but it would be nice to track things up over netconsole perhaps? I just need some bright and nice directions now ;) Hope someone finds this worth of attention too. Meanwhile, I'll be happy with 2.6.21-rt1 :) Can you boot with hpet=disable on the command line ? If that does not help, please provide the output of /proc/timer_list. Thanks, tglx - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rt2..8 troubles
Thomas Gleixner wrote: On Fri, 2007-05-25 at 21:58 +0100, Rui Nuno Capela wrote: Is there anything I can do better to help myself figuring out this issue? As this is a modern laptop such things like a serial console are unavailable, but it would be nice to track things up over netconsole perhaps? I just need some bright and nice directions now ;) Hope someone finds this worth of attention too. Meanwhile, I'll be happy with 2.6.21-rt1 :) Can you boot with hpet=disable on the command line ? Nope. It doesn't seem to have significant effect. Same time-bomb behavior: after an indeterminate period of uptime, the systems stops responding and cannot spawn new processes (current running ones still live on, strange). If that does not help, please provide the output of /proc/timer_list. This is with my latest iteration: http://www.rncbc.org/datahub/config-2.6.21.1-rt8.0 Normal boot on which it behaves as badly as reported: http://www.rncbc.org/datahub/dmesg-2.6.21.1-rt8.0 # cat /proc/timer_list Timer List Version: v0.3 HRTIMER_MAX_CLOCK_BASES: 2 now at 131736771907 nsecs cpu: 0 clock 0: .index: 0 .resolution: 1 nsecs .get_time: ktime_get_real .offset: 1180213690448299114 nsecs active timers: clock 1: .index: 1 .resolution: 1 nsecs .get_time: ktime_get .offset: 0 nsecs active timers: #0: ed7c4ef4, tick_sched_timer, S:01 # expires at 13173700 nsecs [in 228093 nsecs] #1: ed7c4ef4, it_real_fn, S:01 # expires at 131751277843 nsecs [in 14505936 nsecs] #2: ed7c4ef4, hrtimer_wakeup, S:01 # expires at 131802703679 nsecs [in 65931772 nsecs] #3: ed7c4ef4, hrtimer_wakeup, S:01 # expires at 131802705006 nsecs [in 65933099 nsecs] #4: ed7c4ef4, hrtimer_wakeup, S:01 # expires at 132412838830 nsecs [in 676066923 nsecs] #5: ed7c4ef4, it_real_fn, S:01 # expires at 137026607454 nsecs [in 5289835547 nsecs] #6: ed7c4ef4, hrtimer_wakeup, S:01 # expires at 141381493725 nsecs [in 9644721818 nsecs] #7: ed7c4ef4, hrtimer_wakeup, S:01 # expires at 170796028701 nsecs [in 39059256794 nsecs] .expires_next : 13173700 nsecs .hres_active: 1 .nr_events : 40634 .nohz_mode : 2 .idle_tick : 13172400 nsecs .tick_stopped : 0 .idle_jiffies : 4294799020 .idle_calls : 178848 .idle_sleeps: 133212 .idle_entrytime : 131736069830 nsecs .idle_sleeptime : 100895567465 nsecs .last_jiffies : 4294799033 .next_jiffies : 4294799039 .idle_expires : 13173600 nsecs jiffies: 4294799033 cpu: 1 clock 0: .index: 0 .resolution: 1 nsecs .get_time: ktime_get_real .offset: 1180213690448299114 nsecs active timers: clock 1: .index: 1 .resolution: 1 nsecs .get_time: ktime_get .offset: 0 nsecs active timers: #0: ed7c4ef4, hrtimer_wakeup, S:01 # expires at 131737067173 nsecs [in 295266 nsecs] #1: ed7c4ef4, tick_sched_timer, S:01 # expires at 13173725 nsecs [in 478093 nsecs] #2: ed7c4ef4, hrtimer_wakeup, S:01 # expires at 139151071745 nsecs [in 7414299838 nsecs] #3: ed7c4ef4, hrtimer_wakeup, S:01 # expires at 139151133755 nsecs [in 7414361848 nsecs] #4: ed7c4ef4, hrtimer_wakeup, S:01 # expires at 139151154005 nsecs [in 7414382098 nsecs] .expires_next : 131737067173 nsecs .hres_active: 1 .nr_events : 31510 .nohz_mode : 2 .idle_tick : 13173425 nsecs .tick_stopped : 0 .idle_jiffies : 4294799030 .idle_calls : 151213 .idle_sleeps: 107018 .idle_entrytime : 131735193036 nsecs .idle_sleeptime : 108256832194 nsecs .last_jiffies : 4294799032 .next_jiffies : 4294799040 .idle_expires : 13174300 nsecs jiffies: 4294799033 Tick Device: mode: 1 Clock Event Device: hpet max_delta_ns: 2147483647 min_delta_ns: 3352 mult: 61496110 shift: 32 mode: 3 next_event: 13173700 nsecs set_next_event: hpet_legacy_next_event set_mode: hpet_legacy_set_mode event_handler: tick_handle_oneshot_broadcast tick_broadcast_mask: 0003 tick_broadcast_oneshot_mask: 0001 Tick Device: mode: 1 Clock Event Device: lapic max_delta_ns: 806914928 min_delta_ns: 1442 mult: 44650051 shift: 32 mode: 1 next_event: 13173700 nsecs set_next_event: lapic_next_event set_mode: lapic_timer_setup event_handler: hrtimer_interrupt Tick Device: mode: 1 Clock Event Device: lapic max_delta_ns: 806914928 min_delta_ns: 1442 mult: 44650051 shift: 32 mode: 3 next_event: 131737067173 nsecs set_next_event: lapic_next_event set_mode: lapic_timer_setup event_handler: hrtimer_interrupt -- Alternate boot with hpet=disabled as suggested, but no better results: http://www.rncbc.org/datahub/dmesg-2.6.21.1-rt8.0-hpet_disabled # cat /proc/timer_list Timer List Version: v0.3 HRTIMER_MAX_CLOCK_BASES: 2 now at 269529706096 nsecs cpu: 0 clock 0: .index: 0 .resolution: 1 nsecs
