On Wed, 2006-11-08 at 17:13 -0800, john stultz wrote: > On Thu, 2006-11-09 at 00:39 +0000, Sergio Monteiro Basto wrote: > > On Wed, 2006-11-08 at 20:53 +0100, Thomas Gleixner wrote: > > > This one is a lock dependency problem, which is fixed in -rc5-mm1 > > > > yes, oops fixed w/ and w/o notsc option. > > Other question, hrtimer in 2.6.18 found acpi_pm clocksource and use it. > > With 2.6.19-rcx can't get acpi_pm clocksource even trying force at boot > > kernel with clocksource=acpi_pm, any idea ? > > because with this clocksource my lost ticket disappears > > Looking at the dmesg in the bugzilla: > http://bugzilla.kernel.org/show_bug.cgi?id=6419 > > I noticed you're using x86_64. yes, I _just_ use x86_64 never test it on i386. > x86_64 doesn't yet support clocksource > overrides in mainline, petty , can I have a experimental patch to test it? > as it is not converted to GENERIC_TIME. (Probably > printing out such a warning if an override is used would be nice. I'll > try to get to that soon.) > > Now, the code to convert x86_64 is in tglx's hrtimer patch set, so I'm > glad to hear its working for you, however I'm not sure if it really is > solving the issue or just hiding it (as lost ticks won't affect > timekeeping when you use continuous clocksources and GENERIC_TIME). Well, the only kernel where I can work (yes I use computer to work) is 2.6.18 + dyntick. I think don't hid neither solve the issue, is just use other resource (clocksource) that works better ! . > > To use the ACPI PM w/ a 2.6.19-rcX kernel, use "notsc", and you'll see > the line: > time.c: Using 3.579545 MHz WALL PM GTOD PM timer. > > Using the "notsc" option, do you continue to see lost tick messages > after bootup? I just test 2.6.19-RC5-mm2 and still very unstable even with notsc. And after bootup, yes appears some lost tick messages. Just trying rebuild other kernel and use command yum to update others things, at same time, have lock up my computer. So I back to kernel 2.6.18 + dyntick Thanks, > > thanks > -john > > -- Sérgio M.B.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
- References:
- AMD X2 unsynced TSC fix?
- From: Lee Revell <[email protected]>
- Re: AMD X2 unsynced TSC fix?
- From: Sergio Monteiro Basto <[email protected]>
- Re: AMD X2 unsynced TSC fix?
- From: Sergio Monteiro Basto <[email protected]>
- Re: AMD X2 unsynced TSC fix?
- From: Andi Kleen <[email protected]>
- Re: AMD X2 unsynced TSC fix?
- From: "Siddha, Suresh B" <[email protected]>
- Re: AMD X2 unsynced TSC fix?
- From: Sergio Monteiro Basto <[email protected]>
- Re: AMD X2 unsynced TSC fix?
- From: "Siddha, Suresh B" <[email protected]>
- Re: AMD X2 unsynced TSC fix?
- From: Sergio Monteiro Basto <[email protected]>
- Re: AMD X2 unsynced TSC fix?
- From: Thomas Gleixner <[email protected]>
- Re: AMD X2 unsynced TSC fix?
- From: Sergio Monteiro Basto <[email protected]>
- Re: AMD X2 unsynced TSC fix?
- From: john stultz <[email protected]>
- AMD X2 unsynced TSC fix?
- Prev by Date: Re: [PATCH] ALSA: hda-intel - Disable MSI support by default
- Next by Date: [PATCH] aic94xx: delete ascb timers when freeing queues
- Previous by thread: Re: AMD X2 unsynced TSC fix?
- Next by thread: Re: AMD X2 unsynced TSC fix?
- Index(es):