Messages in this thread |  | | Subject | Re: [PATCH] tsc-disable_B9 | From | Alan Cox <> | Date | 21 Aug 2002 17:25:35 +0100 |
| |
> certainly fair enough argument in theory, but in practice you're not > going to risk running those apps in a laptop or in general with any > power management that will decrease the frequency of the cpu anytime.
Any PIII with speedstep, any Athlon and PIV.
> Furthmore the speedstep right now today can crash any laptop that boots > at reduced mhz and that switches to higher mhz at runtime, that change
Actually the reduced loops in the kernel seem to work fine
> of the tsc frequency simply make udelay run faster, and it'll break > drivers easily. I suspect there's even an unfixable race condition in > the speedstep hardware since it's not the kernel asking for the change
Fixed in the -ac tree for the non APM triggered case because we use cpufreq code
> significant info via the tsc to userspace, and there's no way to know > that your app isn't breaking because of numa, unless you disable the tsc > to userspace.
And you can test that with notsc. Oh and you might also want the code that makes notsc on a tsc only kernel print a warning btw. badtsc lets you say "I have a brain cell" notsc lets you select "clueless app checking mode"
As to the other issue. As soon as we have plug in tsc handling that can use ACPI, x86-64, summit and other timer sources I'm very keen to put the tsc based timer in as a fallback before the PIT, and to do chip sanity checks on it (matching clockmul, not spudstop etc)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |