notsc doesn't work on a box with a TSC, when we need need the option the
most...
Index: linux-2.5.46-bochs/arch/i386/kernel/cpu/common.c
===================================================================
RCS file: /build/cvsroot/linux-2.5.46/arch/i386/kernel/cpu/common.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 common.c
--- linux-2.5.46-bochs/arch/i386/kernel/cpu/common.c 5 Nov 2002 01:47:31 -0000 1.1.1.1
+++ linux-2.5.46-bochs/arch/i386/kernel/cpu/common.c 9 Nov 2002 03:10:45 -0000
@@ -12,6 +12,11 @@
static int cachesize_override __initdata = -1;
static int disable_x86_fxsr __initdata = 0;
+#ifdef CONFIG_X86_TSC
+static int tsc_disable __initdata = 0;
+#else
+#define tsc_disable 1
+#endif
struct cpu_dev * cpu_devs[X86_VENDOR_NUM] = {};
@@ -42,24 +47,14 @@
}
__setup("cachesize=", cachesize_setup);
-#ifndef CONFIG_X86_TSC
-static int tsc_disable __initdata = 0;
-
+#ifdef CONFIG_X86_TSC
static int __init tsc_setup(char *str)
{
tsc_disable = 1;
return 1;
}
-#else
-#define tsc_disable 0
-
-static int __init tsc_setup(char *str)
-{
- printk("notsc: Kernel compiled with CONFIG_X86_TSC, cannot disable TSC.\n");
- return 1;
-}
-#endif
__setup("notsc", tsc_setup);
+#endif
int __init get_model_name(struct cpuinfo_x86 *c)
{
--
function.linuxpower.ca
Zwane Mwaikambo writes:
> notsc doesn't work on a box with a TSC, when we need need the option the
> most...
>
> Index: linux-2.5.46-bochs/arch/i386/kernel/cpu/common.c
> ===================================================================
> RCS file: /build/cvsroot/linux-2.5.46/arch/i386/kernel/cpu/common.c,v
> retrieving revision 1.1.1.1
> diff -u -r1.1.1.1 common.c
> --- linux-2.5.46-bochs/arch/i386/kernel/cpu/common.c 5 Nov 2002 01:47:31 -0000 1.1.1.1
> +++ linux-2.5.46-bochs/arch/i386/kernel/cpu/common.c 9 Nov 2002 03:10:45 -0000
> @@ -12,6 +12,11 @@
>
> static int cachesize_override __initdata = -1;
> static int disable_x86_fxsr __initdata = 0;
> +#ifdef CONFIG_X86_TSC
> +static int tsc_disable __initdata = 0;
> +#else
> +#define tsc_disable 1
> +#endif
CONFIG_X86_TSC means "I have a TSC, period" not "I may have a TSC".
It's an optimisation option, not a "try this" option.
If we configure for "I have a TSC, period" you add the option
to disable it, which nullifies any benefit of the config option
in the first place since we can't assume TSC presence any more.
If we don't configure for TSC, you force tsc_disable, which means
that a generic kernel _can't_ use the TSC.
People with broken TSCs need to run non-TSC-assuming kernels.
/Mikael
On Sat, 2002-11-09 at 12:00, Mikael Pettersson wrote:
> If we configure for "I have a TSC, period" you add the option
> to disable it, which nullifies any benefit of the config option
> in the first place since we can't assume TSC presence any more.
> If we don't configure for TSC, you force tsc_disable, which means
> that a generic kernel _can't_ use the TSC.
2.4 was modified to printk a message that TSC was not disabled. This
does confuse people
>> If we configure for "I have a TSC, period" you add the option
>> to disable it, which nullifies any benefit of the config option
>> in the first place since we can't assume TSC presence any more.
>> If we don't configure for TSC, you force tsc_disable, which means
>> that a generic kernel _can't_ use the TSC.
>
> 2.4 was modified to printk a message that TSC was not disabled. This
> does confuse people
Having this config option ass-backwards is mind-bogglingly confusing,
and there seems no real reason for it. John had a plan to just put
in CONFIG_X86_PIT instead as the inverse of this, and delete
CONFIG_X86_TSC. He seems to have gone off this idea for some reason
I can't understand ... I think it solves a lot of these issues ...
Having a config option called TSC that in fact has nothing to directly
do with the TSC, but disables the PIT seems silly. The first time I
read all this code I spend quite a while thinking it was all the
incorrect, and the wrong way around ... things should be more intuitive
than that.
M.
> having this config option ass-backwards is mind-bogglingly confusing,
> and there seems no real reason for it. John had a plan to just put in
> CONFIG_X86_PIT instead as the inverse of this, and delete
> CONFIG_X86_TSC. He seems to have gone off this idea for some reason I
> can't understand ... I think it solves a lot of these issues ...
Actually, this is partly my fault. When the subarch code went in, the meaning
of CONFIG_X86_TSC got altered to mean, 'If not y, don't use tsc at all' (so I
could disable the TSC entirely for Voyager). Then, when code moved to
kernel/timers we got some code with the old meaning and some with the new,
hence the confusion.
The CONFIG_X86_PIT was something I added to try to clarify. There are three
cases with this:
PIT y, TSC n: Never use TSC, always use PIT
PIT y, TSC y: Try TSC at first, if it doesn't work, fall back to PIT
PIT n, TSC y: TSC always works, use it without testing.
Obviously PIT n, TSC n is bogus.
There are also two distinct usages of TSC:
1. do_fast_gettimeofday (now in timers) which *requires* the TSCs to be
synchronised across all CPUs
2. more accurate udelay (which already has the mechanisms in place to cope
with TSCs running at different rates).
1. is usually the reason why numa like machines want to disable the TSC
entirely.
Linus isn't very happy with the global TSC disable patch (see
http://marc.theaimsgroup.com/?t=103652952900006&r=1&w=2). And wants a better
solution. (Then, of course, there are the additional timer options, like the
cyclone).
James
On 9 Nov 2002, Alan Cox wrote:
> On Sat, 2002-11-09 at 12:00, Mikael Pettersson wrote:
> > If we configure for "I have a TSC, period" you add the option
> > to disable it, which nullifies any benefit of the config option
> > in the first place since we can't assume TSC presence any more.
> > If we don't configure for TSC, you force tsc_disable, which means
> > that a generic kernel _can't_ use the TSC.
>
> 2.4 was modified to printk a message that TSC was not disabled. This
> does confuse people
This is all very confusing, notsc isnn't supposed to work with cpus with
TSCs?
Zwane
--
function.linuxpower.ca
On Sat, 2002-11-09 at 18:09, Zwane Mwaikambo wrote:
> > 2.4 was modified to printk a message that TSC was not disabled. This
> > does confuse people
>
> This is all very confusing, notsc isnn't supposed to work with cpus with
> TSCs?
User boots TSC only kernel
User gets problem
User reads docs and says "notsc"
User still has problem
User confused.
In the TSC only case printing a message that the TSC disable was not
possible is IMHO good
On Sat, 9 Nov 2002, Zwane Mwaikambo wrote:
> This is all very confusing, notsc isnn't supposed to work with cpus with
> TSCs?
No.
You have two different cases:
- a kernel compiled for TSC-only. This one simply will not _work_ without
a TSC, since it is statically compiled for the TSC case. Here, "notsc"
simply cannot do anything, so it just prints a message saying that it
doesn't work.
- a "generic" kernel, which can do the TSC decision dynamically, will use
the TSC flag in the CPU features field to decide whether to use the TSC
or not. Here, "notsc" will clear the flag unconditionally, so even if
your CPU claims to have a TSC, it won't get used.
NOTE! We used to do a lot more statically, and on the whole the hard-coded
CONFIG_X86_TSC usage has pretty much disappeared in modern kernels. It's
used mainly by the "get_cycles()" macro, which is not all that commonly
used any more (it used to be used by the scheduler, I think that's gone
too these days).
Linus
On Sat, 9 Nov 2002, J.E.J. Bottomley wrote:
> The CONFIG_X86_PIT was something I added to try to clarify. There are three
> cases with this:
>
> PIT y, TSC n: Never use TSC, always use PIT
> PIT y, TSC y: Try TSC at first, if it doesn't work, fall back to PIT
> PIT n, TSC y: TSC always works, use it without testing.
>
> Obviously PIT n, TSC n is bogus.
<n00b> How does one go about building a kernel with PIT y and TSC y ? My
current kernels obviously are incapable of disabling the TSC </n00b>
Zwane
--
function.linuxpower.ca
[email protected] said:
> <n00b> How does one go about building a kernel with PIT y and TSC y ?
> My current kernels obviously are incapable of disabling the TSC </
> n00b>
The PIT patches come with the voyager stuff (which isn't integrated yet).
However, they are broken out at
http://linux-voyager.bkbits.net/timer-2.5
if you have bitkeeper.
On a current kernel, if you build with TSC n, it should have the same effect.
James
Linus Torvalds <[email protected]> writes:
> - a kernel compiled for TSC-only. This one simply will not _work_ without
> a TSC, since it is statically compiled for the TSC case. Here, "notsc"
> simply cannot do anything, so it just prints a message saying that it
> doesn't work.
IMHO, if you boot a "TSC-only" kernel on a machine without TSC, the correct
answer should be
Panic: This kernel is compiled for TSC-only. No TSC found.
Machine halted.
Same goes IMHO for "i686 on lower", "i586 on lower" and so on.
Everything else leads to strange effects and hard to decipher bug
reports. If in doubt, boot i386 compiled kernel.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [email protected]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
D-91054 Buckenhof Fax.: 09131 / 50654-20
On Sat, Nov 09, 2002 at 10:51:27AM -0800, Linus Torvalds wrote:
> No.
> You have two different cases:
> - a kernel compiled for TSC-only. This one simply will not _work_ without
> a TSC, since it is statically compiled for the TSC case. Here, "notsc"
> simply cannot do anything, so it just prints a message saying that it
> doesn't work.
> - a "generic" kernel, which can do the TSC decision dynamically, will use
> the TSC flag in the CPU features field to decide whether to use the TSC
> or not. Here, "notsc" will clear the flag unconditionally, so even if
> your CPU claims to have a TSC, it won't get used.
> NOTE! We used to do a lot more statically, and on the whole the hard-coded
> CONFIG_X86_TSC usage has pretty much disappeared in modern kernels. It's
> used mainly by the "get_cycles()" macro, which is not all that commonly
> used any more (it used to be used by the scheduler, I think that's gone
> too these days).
Then the options have been mangled and it doesn't do this right anymore,
with the net result that there's no way to turn off TSC synch ever. I've
narrowed this down to config options setting CONFIG_X86_TSC for at least for
all cpu revisions > 586 plus unconditional TSC usage given CONFIG_X86_TSC.
Bill
On Sun, 10 Nov 2002, William Lee Irwin III wrote:
>
> Then the options have been mangled and it doesn't do this right anymore,
> with the net result that there's no way to turn off TSC synch ever. I've
> narrowed this down to config options setting CONFIG_X86_TSC for at least for
> all cpu revisions > 586
But that's the point. If you specify that you have a CPU > 586, then you
specify at compile-time that you have TSC.
If your TSC is broken, then you shouldn't do that. You should compile for
"generic x86" (386), and then say "notsc".
(Yeah, it should work for i486 too, but in general it's the "generic 386"
that should work on all machines because it doesn't assume anything about
the capabilities of the machine).
But considering that we don't use the static TSC knowledge very much any
more, you might want to remove CONFIG_X86_TSC altogether, though, and
replace its uses with run-time checks. We've done that with a lot of the
other config stuff earlier (SSE/XMM) because the static compiled options
are just too inconvenient and not worth the maintenance hassles..
Linus
On Sun, Nov 10, 2002 at 05:51:37PM -0800, Linus Torvalds wrote:
> But that's the point. If you specify that you have a CPU > 586, then you
> specify at compile-time that you have TSC.
> If your TSC is broken, then you shouldn't do that. You should compile for
> "generic x86" (386), and then say "notsc".
> (Yeah, it should work for i486 too, but in general it's the "generic 386"
> that should work on all machines because it doesn't assume anything about
> the capabilities of the machine).
> But considering that we don't use the static TSC knowledge very much any
> more, you might want to remove CONFIG_X86_TSC altogether, though, and
> replace its uses with run-time checks. We've done that with a lot of the
> other config stuff earlier (SSE/XMM) because the static compiled options
> are just too inconvenient and not worth the maintenance hassles..
Performance considerations make compiling for 386 a relatively poor
solution. I'm very much in favor of the runtime checks and will
intensively investigate that method of dealing with the situation, and
with any luck follow up soon with a solution acceptable to both you and
others for this dynamic TSC usage issue.
Thanks,
Bill
On Mon, 2002-11-11 at 01:51, Linus Torvalds wrote:
> But considering that we don't use the static TSC knowledge very much any
> more, you might want to remove CONFIG_X86_TSC altogether, though, and
> replace its uses with run-time checks. We've done that with a lot of the
> other config stuff earlier (SSE/XMM) because the static compiled options
> are just too inconvenient and not worth the maintenance hassles..
Or we use the new config stuff to stick in
Twiddle Advanced Bits Y/N
Include PPro fence fix
Include ...
Include ...
On Sun, 10 Nov 2002, Henning P. Schmiedehausen wrote:
> > - a kernel compiled for TSC-only. This one simply will not _work_ without
> > a TSC, since it is statically compiled for the TSC case. Here, "notsc"
> > simply cannot do anything, so it just prints a message saying that it
> > doesn't work.
>
> IMHO, if you boot a "TSC-only" kernel on a machine without TSC, the correct
> answer should be
>
> Panic: This kernel is compiled for TSC-only. No TSC found.
> Machine halted.
And that happens -- see check_config() in <asm-i386/bugs.h>.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: [email protected], PGP key available +