2.4.26 doesn't boot on a 386 without "Unsynced TSC support"

From: Erik Mouw (erik_at_harddisk-recovery.com)
Date: 07/28/04

  • Next message: Karim Yaghmour: "Re: [patch] IRQ threads"
    Date:	Wed, 28 Jul 2004 17:47:49 +0200
    To: linux-kernel@vger.kernel.org
    
    

    Hi,

    I tried to boot 2.4.26 on my good old 386 board, but got a kernel
    panic:

      CPU: 386
      Kernel panic: Kernel compiled for Pentium+, requires TSC feature!

    The error message comes from the function check_config() in
    include/asm-i386/bugs.h (thanks to wli for figuring out faster than I
    did).

    I am sure I selected support for a 80386 CPU, so the error message
    looks wrong to me. CONFIG_M586TSC is not set, but CONFIG_X86_TSC is
    enabled by default. The only way to disable it, is to enable "Unsynced
    TSC support", (CONFIG_X86_TSC_DISABLE).

    The help for CONFIG_X86_TSC_DISABLE mentions to use it for "NUMA
    mult-mode boxes, laptops and other systems suffering from unsynced TSCs
    or TSC drift, which can cause gettimeofday to return non-monotonic
    values." A simple 80386 board doesn't belong to these, and I can't
    remember having problmes with gettimeofday() in the past (IIRC the
    board last ran linux-1.2 or 2.0).

    My question is: is this a code bug, or a documentation bug? Right now,
    I guess 2.4.26 will not run on anything < Pentium without
    CONFIG_X86_TSC_DISABLE enabled.

    Erik

    -- 
    +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
    | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
    -
    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/
    

  • Next message: Karim Yaghmour: "Re: [patch] IRQ threads"

    Relevant Pages

    • Re: [PATCH] Skip tsc synchronization checks if CONSTANT_TSC bit is set.
      ... Hypervisor couldn't as well be fixed. ... However, when running the kernel on virtual cpus, as compared to running on a physical cpus, the timing characteristics are different -- virtual cpus have to time share physical cpus with each other. ... The fast-path TSC calibration code makes assumptions about being able to sample various counters in sequence in a set amount of time that are not true when running virtualized. ...
      (Linux-Kernel)
    • Re: Improving the kernel/i386 timecounter performance (GSoC proposal)
      ... functions that can be called by user applications, ... chosen by the kernel at boot time depending on processor capabilities. ... TSC may be ti=king at this CPU, and export in the same page. ...
      (freebsd-current)
    • Re: Improving the kernel/i386 timecounter performance (GSoC proposal)
      ... one global for gettimeofday and one per-process for static data like getpid/getgid. ... a page in the kernel mapped read-only to all the user pr=cesses. ... TSC may be ti=king at this CPU, and export in the same page. ...
      (freebsd-current)
    • Re: Improving the kernel/i386 timecounter performance (GSoC proposal)
      ... one global for gettimeofday and one per-process for static data like getpid/getgid. ... a page in the kernel mapped read-only to all the user pr=cesses. ... TSC may be ti=king at this CPU, and export in the same page. ...
      (freebsd-hackers)
    • TSC cannot be used as a timesource -> SOLVED
      ... DMA, I always had it off for that disk; ... since its release, kernel 2.6.0 ... TSC cannot be used as a timesource. ... the system clock was running behind ca. 45 minutes! ...
      (Linux-Kernel)