10 Apr, 2006

2 commits


01 Apr, 2006

1 commit

  • The boot cmdline is parsed in parse_early_param() and
    parse_args(,unknown_bootoption).

    And __setup() is used in obsolete_checksetup().

    start_kernel()
    -> parse_args()
    -> unknown_bootoption()
    -> obsolete_checksetup()

    If __setup()'s callback (->setup_func()) returns 1 in
    obsolete_checksetup(), obsolete_checksetup() thinks a parameter was
    handled.

    If ->setup_func() returns 0, obsolete_checksetup() tries other
    ->setup_func(). If all ->setup_func() that matched a parameter returns 0,
    a parameter is seted to argv_init[].

    Then, when runing /sbin/init or init=app, argv_init[] is passed to the app.
    If the app doesn't ignore those arguments, it will warning and exit.

    This patch fixes a wrong usage of it, however fixes obvious one only.

    Signed-off-by: OGAWA Hirofumi
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    OGAWA Hirofumi
     

29 Mar, 2006

1 commit


26 Mar, 2006

4 commits


22 Mar, 2006

1 commit


27 Feb, 2006

1 commit

  • SMP time selection originally ran after all CPUs were brought up because
    it needed to know the number of CPUs to decide if it needs an MP safe
    timer or not.

    This is not needed anymore because we know present CPUs early.

    This fixes a couple of problems:
    - apicmaintimer didn't always work because it relied on state that was
    set up time_init_gtod too late.
    - The output for the used timer in early kernel log was misleading
    because time_init_gtod could actually change it later. Now always
    print the final timer choice

    Signed-off-by: Andi Kleen
    Signed-off-by: Linus Torvalds

    Andi Kleen
     

18 Feb, 2006

1 commit


12 Feb, 2006

1 commit

  • [description from AK]

    The IBM Summit 3 chipset doesn't implement the HPET timer replacement
    option. Since the current Linux code relies on it use a mixed mode with
    both PIT for the interrupt and HPET counters for the time keeping. That
    was already implemented, but didn't work properly because it was still
    using the last interrupt offset in HPET. This resulted in x460 not
    booting. Fix this up by using the free running HPET counter.

    Shouldn't affect any other machine because they either use full HPET mode
    or no HPET at all.

    TBD needs a similar 32bit fix.

    Signed-off-by: Andi Kleen
    Cc: Pallipadi, Venkatesh"
    Cc: Bob Picco
    Cc: Bjorn Helgaas
    Cc: john stultz
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Chris McDermott
     

08 Feb, 2006

1 commit


05 Feb, 2006

3 commits

  • SIgned-off-by: Shaohua Li
    Signed-off-by: Andi Kleen
    Signed-off-by: Linus Torvalds

    Shaohua Li
     
  • At resume time, TSC's value or something similar might be changed a lot
    against suspend time. This could make system gets a very big lost ticks.
    See http://bugzilla.kernel.org/show_bug.cgi?id=5825

    Signed-off-by: Shaohua Li
    Signed-off-by: Andi Kleen
    Signed-off-by: Linus Torvalds

    Shaohua Li
     
  • Another piece from the no-idle-tick patch.

    This can be enabled with the "apicmaintimer" option.

    This is mainly useful when the PIT/HPET interrupt is unreliable.
    Note there are some systems that are known to stop the APIC
    timer in C3. For those it will never work, but this case
    should be automatically detected.

    It also only works with PM timer right now. When HPET is used
    the way the main timer handler computes the delay doesn't work.

    It should be a bit more efficient because there is one less
    regular interrupt to process on the boot processor.

    Requires earlier bugfix from Venkatesh

    Signed-off-by: Andi Kleen
    Signed-off-by: Linus Torvalds

    Andi Kleen
     

12 Jan, 2006

6 commits


09 Jan, 2006

1 commit

  • This patch moves the rtc_interrupt() prototype to rtc.h and removes the
    prototypes from C files.

    It also renames static rtc_interrupt() functions in
    arch/arm/mach-integrator/time.c and arch/sh64/kernel/time.c to avoid compile
    problems.

    Signed-off-by: Adrian Bunk
    Signed-off-by: Paul Gortmaker
    Acked-by: Paul Mundt
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Adrian Bunk
     

13 Dec, 2005

2 commits


31 Oct, 2005

5 commits

  • Reads from an HPET register require a round trip to the south bridge and are
    almost as slow as PCI reads. By caching the last value we've written to the
    comparator register, we can eliminate all HPET reads from the fast path in the
    emulated RTC interrupt handler.

    Signed-off-by: Clemens Ladisch
    Acked-by: Venkatesh Pallipadi
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Clemens Ladisch
     
  • Make sure that the RTC timer is in non-periodic mode; some stupid BIOS might
    have initialized it to periodic mode.

    Furthermore, don't set the SETVAL bit in the config register. This wouldn't
    have any effect unless the timer was in period mode (which it isn't), and then
    the actual timer frequency would be half that of the desired one because
    incrementing the comparator in the interrupt handler would be done after the
    hardware has already incremented it itself.

    Signed-off-by: Clemens Ladisch
    Acked-by: Venkatesh Pallipadi
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Clemens Ladisch
     
  • When the emulated RTC interrupt is no longer needed, we better disable it;
    otherwise, we get a spurious interrupt whenever the timer has rolled over and
    reaches the same comparator value.

    Having a superfluous interrupt every five minutes doesn't hurt much, but it's
    bad style anyway. ;-)

    Signed-off-by: Clemens Ladisch
    Acked-by: "Pallipadi, Venkatesh"
    Cc: Andi Kleen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Clemens Ladisch
     
  • Define jiffies_64 in kernel/timer.c rather than having 24 duplicated
    defines in each architecture.

    Signed-off-by: Thomas Gleixner
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Thomas Gleixner
     
  • I just found out that some precision is unnecessarily lost in the
    arch/i386/kernel/timers/timer_tsc.c:set_cyc2ns_scale function. It uses a
    cpu_mhz parameter when it could use a cpu_khz. In the specific case of an
    Intel P4 running at 3001.171 Mhz, the truncation to 3001 Mhz leads to an
    imprecision of 19 microseconds per second : this is very sad for a timer with
    nearly nanosecond accuracy.

    Fix the x86_64 architecture too.

    Cc: george anzinger
    Cc: john stultz
    Cc: Andi Kleen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mathieu Desnoyers
     

28 Sep, 2005

1 commit

  • This should resolve the issue seen in bugme bug #5105, where it is assumed
    that dualcore x86_64 systems have synced TSCs. This is not the case, and
    alternate timesources should be used instead.

    For more details, see:
    http://bugzilla.kernel.org/show_bug.cgi?id=5105

    Andi's earlier concerns that the TSCs should be synced on dualcore systems
    have been resolved by confirmation from AMD folks that they can be
    unsynced.

    Acked-by: Andi Kleen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    john stultz
     

13 Sep, 2005

2 commits


08 Sep, 2005

2 commits

  • This patch cleans up a commonly repeated set of changes to the NTP state
    variables by adding two helper inline functions:

    ntp_clear(): Clears the ntp state variables

    ntp_synced(): Returns 1 if the system is synced with a time server.

    This was compile tested for alpha, arm, i386, x86-64, ppc64, s390, sparc,
    sparc64.

    Signed-off-by: John Stultz
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    john stultz
     
  • This patch adds a new kernel debug feature: CONFIG_DETECT_SOFTLOCKUP.

    When enabled then per-CPU watchdog threads are started, which try to run
    once per second. If they get delayed for more than 10 seconds then a
    callback from the timer interrupt detects this condition and prints out a
    warning message and a stack dump (once per lockup incident). The feature
    is otherwise non-intrusive, it doesnt try to unlock the box in any way, it
    only gets the debug info out, automatically, and on all CPUs affected by
    the lockup.

    Signed-off-by: Ingo Molnar
    Signed-off-by: Nishanth Aravamudan
    Signed-Off-By: Matthias Urlichs
    Signed-off-by: Richard Purdie
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ingo Molnar
     

24 Jun, 2005

1 commit

  • Currently the x86-64 HPET code assumes the entire HPET implementation from
    the spec is present. This breaks on boxes that do not implement the
    optional legacy timer replacement functionality portion of the spec.

    This patch fixes this issue, allowing x86-64 systems that cannot use the
    HPET for the timer interrupt and RTC to still use the HPET as a time
    source. I've tested this patch on a system systems without HPET, with HPET
    but without legacy timer replacement, as well as HPET with legacy timer
    replacement.

    This version adds a minor check to cap the HPET counter value in
    gettimeoffset_hpet to avoid possible time inconsistencies. Please ignore
    the A2 version I sent to you earlier.

    Acked-by: Andi Kleen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    john stultz
     

01 Jun, 2005

1 commit


17 May, 2005

1 commit

  • There are unfortunately more and more multi processor Opteron systems which
    don't have HPET timer support in the southbridge. This covers in particular
    Nvidia and VIA chipsets. They also don't guarantee that the TSCs are
    synchronized between CPUs; and especially with MP powernow the systems are
    nearly unusable because the time gets very inconsistent between CPUs.

    The timer code for x86-64 was originally written under the assumption that we
    could fall back to the HPET timer on such systems. But this doesn't work
    there.

    Another alternative is to use the ACPI PM timer as primary time source. This
    patch does that. The kernel only uses PM timer when there is no other choice
    because it has some disadvantages.

    Ported over from i386. It should be faster than the i386 version because I
    dropped the "read three times" workaround, but is still considerable slower
    than HPET and also does not work together with vsyscalls which have to be
    disabled.

    Cc:
    Signed-off-by: Andi Kleen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andi Kleen
     

17 Apr, 2005

2 commits

  • I thought I'm done with fixing u32 vs. pm_message_t ... unfortunately that
    turned out not to be the case... Here are fixes x86-64.

    Signed-off-by: Pavel Machek
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Pavel Machek
     
  • This will allow hotplug CPU in the future and in general cleans up a lot of
    crufty code. It also should plug some races that the old hackish way
    introduces. Remove one old race workaround in NMI watchdog setup that is not
    needed anymore.

    I removed the old total sum of bogomips reporting code. The brag value of
    BogoMips has been greatly devalued in the last years on the open market.

    Real CPU hotplug will need some more work, but the infrastructure for it is
    there now.

    One drawback: the new TSC sync algorithm is less accurate than before. The
    old way of zeroing TSCs is too intrusive to do later. Instead the TSC of the
    BP is duplicated now, which is less accurate.

    akpm:

    - sync_tsc_bp_init seems to have the sense of `init' inverted.

    - SPIN_LOCK_UNLOCKED is deprecated - use DEFINE_SPINLOCK.

    Cc:
    Cc:
    Signed-off-by: Andi Kleen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andi Kleen