Messages in this thread |  | | Date | Mon, 16 Jun 2008 08:58:02 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH 2.6.26-rc6] x86-32: fix boot failure on TSC-less processors |
| |
* Mikael Pettersson <mikpe@it.uu.se> wrote:
> Booting 2.6.26-rc6 on my 486 DX/4 fails with a "BUG: Int 6" (invalid > opcode) and a kernel halt immediately after the kernel has been > uncompressed. The BUG shows EIP pointing to an rdtsc instruction in > native_read_tsc(), invoked from native_sched_clock(). > > (This error occurs so early that not even the serial console can > capture it.) > > A bisection showed that this bug first occurs in 2.6.26-rc3-git7, via > commit 9ccc906c97e34fd91dc6aaf5b69b52d824386910: > > >x86: distangle user disabled TSC from unstable > > > >tsc_enabled is set to 0 from the command line switch "notsc" and from > >the mark_tsc_unstable code. Seperate those functionalities and replace > >tsc_enable with tsc_disable. This makes also the native_sched_clock() > >decision when to use TSC understandable. > > > >Preparatory patch to solve the sched_clock() issue on 32 bit. > > > >Signed-off-by: Thomas Gleixner <tglx@linutronix.de> > > The core reason for this bug is that native_sched_clock() gets > called before tsc_init(). > > Before the commit above, tsc_32.c used a "tsc_enabled" variable > which defaulted to 0 == disabled, and which only got enabled late > in tsc_init(). Thus early calls to native_sched_clock() would skip > the TSC and use jiffies instead. > > After the commit above, tsc_32.c uses a "tsc_disabled" variable > which defaults to 0, meaning that the TSC is Ok to use. Early calls > to native_sched_clock() now erroneously try to use the TSC on > !cpu_has_tsc processors, leading to invalid opcode exceptions. > > My proposed fix is to initialise tsc_disabled to a "soft disabled" > state distinct from the hard disabled state set up by the "notsc" > kernel option. This fixes the native_sched_clock() problem. It also > allows tsc_init() to be simplified: instead of setting tsc_disabled = 1 > on every error return, we just set tsc_disabled = 0 once when all > checks have succeeded. > > I've verified that this lets my 486 boot again. I've also verified > that a Core2 machine still uses the TSC as clocksource after the > patch.
applied to tip/x86/urgent - thanks Mikael! The soft-disabled state is a pretty good solution.
Ingo
|  |