Skip to content

L
linux-davinci
Switch branch/tag
  1. 03 Oct, 2008 1 commit
  3. 30 Sep, 2008 1 commit
  5. 23 Sep, 2008 9 commits
    • Ingo Molnar's avatar
      Merge branch 'timers/urgent' into x86/xen · 07bbc16a
      Ingo Molnar authored 
      Conflicts:
	arch/x86/kernel/process_32.c
	arch/x86/kernel/process_64.c

Manual merge:

	arch/x86/kernel/smpboot.c
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      07bbc16a
    • Ingo Molnar's avatar
      timers: fix build error in !oneshot case · f8e256c6
      Ingo Molnar authored 
       kernel/time/tick-common.c: In function ‘tick_setup_periodic’:
 kernel/time/tick-common.c:113: error: implicit declaration of function ‘tick_broadcast_oneshot_active’
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      f8e256c6
    • Andreas Herrmann's avatar
      x86: c1e_idle: don't mark TSC unstable if CPU has invariant TSC · 09bfeea1
      Andreas Herrmann authored 
      Impact: Functional TSC is marked unstable on AMD family 0x10 and 0x11 CPUs.

This would be wrong because for those CPUs "invariant TSC" means:

   "The TSC counts at the same rate in all P-states, all C states, S0,
   or S1"

(See "Processor BIOS and Kernel Developer's Guides" for those CPUs.)

[ tglx: Changed C1E to AMD C1E in the printks to avoid confusion 
	with Intel C1E ]
Signed-off-by: default avatarAndreas Herrmann <andreas.herrmann3@amd.com>
Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      09bfeea1
    • Thomas Gleixner's avatar
      x86: prevent C-states hang on AMD C1E enabled machines · a8d68290
      Thomas Gleixner authored 
      Impact: System hang when AMD C1E machines switch into C2/C3

AMD C1E enabled systems do not work with normal ACPI C-states 
even if the BIOS is advertising them. Limit the C-states to 
C1 for the ACPI processor idle code.
Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      a8d68290
    • Thomas Gleixner's avatar
      clockevents: prevent mode mismatch on cpu online · 27ce4cb4
      Thomas Gleixner authored 
      Impact: timer hang on CPU online observed on AMD C1E systems

When a CPU is brought online then the broadcast machinery can
be in the one shot state already. Check this and setup the timer 
device of the new CPU in one shot mode so the broadcast code
can pick up the next_event value correctly.

Another AMD C1E oddity, as we switch to broadcast immediately and
not after the full bring up via the ACPI cpu idle code.
Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      27ce4cb4
    • Thomas Gleixner's avatar
      clockevents: check broadcast device not tick device · 30274569
      Thomas Gleixner authored 
      Impact: Possible hang on CPU online observed on AMD C1E machines.

The broadcast setup code looks at the mode of the tick device to
determine whether it needs to be shut down or setup. This is wrong
when the broadcast mode is set to one shot already. This can happen
when a CPU is brought online as it goes through the periodic setup
first.

The problem went unnoticed as sane systems do not call into that code
before the switch to one shot for the clock event device happens.
The AMD C1E idle routine switches over immediately and thereby shuts
down the just setup device before the first interrupt happens.
Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      30274569
    • Thomas Gleixner's avatar
      clockevents: prevent stale tick_next_period for onlining CPUs · 49d670fb
      Thomas Gleixner authored 
      Impact: possible hang on CPU onlining in timer one shot mode.

The tick_next_period variable is only used during boot on nohz/highres
enabled systems, but for CPU onlining it needs to be maintained when
the per cpu clock events device operates in one shot mode.
Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      49d670fb
    • Thomas Gleixner's avatar
      x86: prevent stale state of c1e_mask across CPU offline/online · 4faac97d
      Thomas Gleixner authored 
      Impact: hang which happens across CPU offline/online on AMD C1E systems.

When a CPU goes offline then the corresponding bit in the broadcast
mask is cleared. For AMD C1E enabled CPUs we do not reenable the
broadcast when the CPU comes online again as we do not clear the
corresponding bit in the c1e_mask, which keeps track which CPUs
have been switched to broadcast already. So on those !$@#& machines
we never switch back to broadcasting after a CPU offline/online cycle.

Clear the bit when the CPU plays dead.
Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      4faac97d
    • Thomas Gleixner's avatar
      clockevents: prevent cpu online to interfere with nohz · 6441402b
      Thomas Gleixner authored 
      Impact: rare hang which can be triggered on CPU online.

tick_do_timer_cpu keeps track of the CPU which updates jiffies
via do_timer. The value -1 is used to signal, that currently no
CPU is doing this. There are two cases, where the variable can 
have this state:

 boot:
    necessary for systems where the boot cpu id can be != 0

 nohz long idle sleep:
    When the CPU which did the jiffies update last goes into
    a long idle sleep it drops the update jiffies duty so
    another CPU which is not idle can pick it up and keep
    jiffies going.

Using the same value for both situations is wrong, as the CPU online
code can see the -1 state when the timer of the newly onlined CPU is
setup. The setup for a newly onlined CPU goes through periodic mode
and can pick up the do_timer duty without being aware of the nohz /
highres mode of the already running system.

Use two separate states and make them constants to avoid magic
numbers confusion. 
Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      6441402b
  7. 21 Sep, 2008 11 commits
  9. 20 Sep, 2008 10 commits
  11. 19 Sep, 2008 8 commits