Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
接近 2 年 前同步成功

通知 170
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 09 7月, 2008 2 次提交
  3. 24 6月, 2008 2 次提交
    • A
      x86: use cpu_khz for loops_per_jiffy calculation, cleanup · f3f3149f
      由 Alok Kataria 提交于 
      As suggested by Ingo, remove all references to tsc from init/calibrate.c

TSC is x86 specific, and using tsc in variable names in a generic file should
be avoided. lpj_tsc is now called lpj_fine, since it is related to fine tuning
of lpj value. Also tsc_rate_*  is called timer_rate_*
Signed-off-by: NAlok N Kataria <akataria@vmware.com>
Cc: Arjan van de Ven <arjan@infradead.org>
Cc: Daniel Hecht <dhecht@vmware.com>
Cc: Tim Mann <mann@vmware.com>
Cc: Zach Amsden <zach@vmware.com>
Cc: Sahil Rihan <srihan@vmware.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      f3f3149f
    • A
      x86: use cpu_khz for loops_per_jiffy calculation · 3da757da
      由 Alok Kataria 提交于 
      On the x86 platform we can use the value of tsc_khz computed during tsc
calibration to calculate the loops_per_jiffy value. Its very important
to keep the error in lpj values to minimum as any error in that may
result in kernel panic in check_timer. In virtualization environment, On
a highly overloaded host the guest delay calibration may sometimes
result in errors beyond the ~50% that timer_irq_works can handle,
resulting in the guest panicking.

Does some formating changes to lpj_setup code to now have a single
printk to print the bogomips value.

We do this only for the boot processor because the AP's can have
different base frequencies or the BIOS might boot a AP at a different
frequency.
Signed-off-by: NAlok N Kataria <akataria@vmware.com>
Cc: Arjan van de Ven <arjan@infradead.org>
Cc: Daniel Hecht <dhecht@vmware.com>
Cc: Tim Mann <mann@vmware.com>
Cc: Zach Amsden <zach@vmware.com>
Cc: Sahil Rihan <srihan@vmware.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      3da757da
  5. 09 2月, 2008 1 次提交
  7. 30 1月, 2008 7 次提交
  9. 17 11月, 2007 2 次提交
    • D
      x86: on x86_64, correct reading of PC RTC when update in progress in time_64.c · bbbd9995
      由 David P. Reed 提交于 
      Correct potentially unstable PC RTC time register reading in time_64.c

Stop the use of an incorrect technique for reading the standard PC RTC
timer, which is documented to "disconnect" time registers from the bus
while updates are in progress.  The use of UIP flag while interrupts
are disabled to protect a 244 microsecond window is one of the
Motorola spec sheet's documented ways to read the RTC time registers
reliably.

tglx: removed locking changes from original patch, as they gain nothing
(read_persistent_clock is only called during boot, suspend, resume - so
no hot path affected) and conflict with the paravirt locking scheme
(see 32bit code), which we do not want to complicate for no benefit.
Signed-off-by: NDavid P. Reed <dpreed@reed.com>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      bbbd9995
    • D
      x86: fix freeze in x86_64 RTC update code in time_64.c · c399da0d
      由 David P. Reed 提交于 
      Fix hard freeze on x86_64 when the ntpd service calls 
update_persistent_clock()

A repeatable but randomly timed freeze has been happening in Fedora 6
and 7 for the last year, whenever I run the ntpd service on my AMD64x2
HP Pavilion dv9000z laptop.  This freeze is due to the use of
spin_lock(&rtc_lock) under the assumption (per a bad comment) that
set_rtc_mmss is called only with interrupts disabled.  The call from
ntp.c to update_persistent_clock is made with interrupts enabled.
Signed-off-by: NDavid P. Reed <dpreed@reed.com>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      c399da0d
  11. 14 10月, 2007 1 次提交
    • D
      Delete filenames in comments. · 835c34a1
      由 Dave Jones 提交于 
      Since the x86 merge, lots of files that referenced their own filenames
are no longer correct.  Rather than keep them up to date, just delete
them, as they add no real value.

Additionally:
- fix up comment formatting in scx200_32.c
- Remove a credit from myself in setup_64.c from a time when we had no SCM
- remove longwinded history from tsc_32.c which can be figured out from
  git.
Signed-off-by: NDave Jones <davej@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      835c34a1
  13. 13 10月, 2007 7 次提交
  15. 11 10月, 2007 2 次提交
  17. 22 7月, 2007 5 次提交
  19. 09 5月, 2007 1 次提交
  21. 03 5月, 2007 4 次提交
  23. 05 3月, 2007 1 次提交
    • J
      [PATCH] clocksource init adjustments (fix bug #7426) · 6bb74df4
      由 john stultz 提交于 
      This patch resolves the issue found here:
http://bugme.osdl.org/show_bug.cgi?id=7426

The basic summary is:
Currently we register most of i386/x86_64 clocksources at module_init
time. Then we enable clocksource selection at late_initcall time. This
causes some problems for drivers that use gettimeofday for init
calibration routines (specifically the es1968 driver in this case),
where durring module_init, the only clocksource available is the low-res
jiffies clocksource. This may cause slight calibration errors, due to
the small sampling time used.

It should be noted that drivers that require fine grained time may not
function on architectures that do not have better then jiffies
resolution timekeeping (there are a few). However, this does not
discount the reasonable need for such fine-grained timekeeping at init
time.

Thus the solution here is to register clocksources earlier (ideally when
the hardware is being initialized), and then we enable clocksource
selection at fs_initcall (before device_initcall).

This patch should probably get some testing time in -mm, since
clocksource selection is one of the most important issues for correct
timekeeping, and I've only been able to test this on a few of my own
boxes.
Signed-off-by: NJohn Stultz <johnstul@us.ibm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6bb74df4
  25. 18 2月, 2007 1 次提交
  27. 17 2月, 2007 4 次提交