Skip to content
Snippets Groups Projects
Select Git revision
  • master default protected
  • pve2
  • pve1
  • v6.6-rc2
  • v6.6-rc1
  • v6.5
  • v6.5-rc7
  • v6.5-rc6
  • v6.5-rc5
  • v6.5-rc4
  • v6.5-rc3
  • v6.5-rc2
  • v6.5-rc1
  • v6.4
  • v6.4-rc7
  • v6.4-rc6
  • v6.4-rc5
  • v6.4-rc4
  • v6.4-rc3
  • v6.4-rc2
  • v6.4-rc1
21 results
Search by author
  • Any Author
  • jan.koester jan.koester jan.koester
1 author
  1. Feb 13, 2012
  3. Feb 11, 2012
  5. Feb 07, 2012
    • Borislav Petkov's avatar
      x86/sched/perf/AMD: Set sched_clock_stable · c98fdeaa
      Borislav Petkov authored 
      
Stephane Eranian reported that doing a scheduler latency
measurements with perf on AMD doesn't work out as expected due
to the fact that the sched_clock() granularity is too coarse,
i.e. done in jiffies due to the sched_clock_stable not set,
which, if set, would mean that we get to use the TSC as sample
source which would give us much higher precision.

However, there's no reason not to set sched_clock_stable on AMD
because all families from F10h and upwards do have an invariant
TSC and have the CPUID flag to prove (CPUID_8000_0007_EDX[8]).

Make it so, #1.

Signed-off-by: default avatarBorislav Petkov <bp@alien8.de>
Cc: Borislav Petkov <bp@amd64.org>
Cc: Venki Pallipadi <venki@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Arnaldo Carvalho de Melo <acme@infradead.org>
Cc: Robert Richter <robert.richter@amd.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
Link: http://lkml.kernel.org/r/20120206132546.GA30854@quad


[ Should any non-standard system break the TSC, we should
  mark them so explicitly, in their platform init handler, or
  in a DMI quirk. ]
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      c98fdeaa
  7. Feb 03, 2012
    • Stephane Eranian's avatar
      perf: Remove deprecated WARN_ON_ONCE() · 84f2b9b2
      Stephane Eranian authored 
      
With the new throttling/unthrottling code introduced with
commit:

  e050e3f0 ("perf: Fix broken interrupt rate throttling")

we occasionally hit two WARN_ON_ONCE() checks in:

  - intel_pmu_pebs_enable()
  - intel_pmu_lbr_enable()
  - x86_pmu_start()

The assertions are no longer problematic. There is a valid
path where they can trigger but it is harmless.

The assertion can be triggered with:

  $ perf record -e instructions:pp ....

Leading to paths:

  intel_pmu_pebs_enable
  intel_pmu_enable_event
  x86_perf_event_set_period
  x86_pmu_start
  perf_adjust_freq_unthr_context
  perf_event_task_tick
  scheduler_tick

And:

  intel_pmu_lbr_enable
  intel_pmu_enable_event
  x86_perf_event_set_period
  x86_pmu_start
  perf_adjust_freq_unthr_context.
  perf_event_task_tick
  scheduler_tick

cpuc->enabled is always on because when we get to
perf_adjust_freq_unthr_context() the PMU is not totally
disabled. Furthermore when we need to adjust a period,
we only stop the event we need to change and not the
entire PMU. Thus, when we re-enable, cpuc->enabled is
already set. Note that when we stop the event, both
pebs and lbr are stopped if necessary (and possible).

Signed-off-by: default avatarStephane Eranian <eranian@google.com>
Cc: peterz@infradead.org
Link: http://lkml.kernel.org/r/20120202110401.GA30911@quad


Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      84f2b9b2
  9. Feb 01, 2012
  11. Jan 31, 2012
    • Michal Simek's avatar
      Revert "microblaze: Add topology init" · 9afc4165
      Michal Simek authored 
      
This reverts commit d761f0c5.

Patch: "cpu: Register a generic CPU device on architectures that currently do not"
(sha1: 9f13a1fd)

selects GENERIC_CPU_DEVICES for Microblaze which register cpu.
My patch was done in the same time that's why cpu was registered twice which
caused this warning log:

------------[ cut here ]------------
WARNING: at fs/sysfs/dir.c:481 sysfs_add_one+0xb0/0xdc()
sysfs: cannot create duplicate filename '/devices/system/cpu/cpu0'
Modules linked in:
...

Signed-off-by: default avatarMichal Simek <monstr@monstr.eu>
      9afc4165
  13. Jan 30, 2012
    • Michael D Labriola's avatar
      x86/reboot: Remove VersaLogic Menlow reboot quirk · e6d36a65
      Michael D Labriola authored 
      
This commit removes the reboot quirk originally added by commit
e19e074b ("x86: Fix reboot problem on VersaLogic Menlow boards").

Testing with a VersaLogic Ocelot (VL-EPMs-21a rev 1.00 w/ BIOS
6.5.102) revealed the following regarding the reboot hang
problem:

- v2.6.37 reboot=bios was needed.

- v2.6.38-rc1: behavior changed, reboot=acpi is needed,
  reboot=kbd and reboot=bios results in system hang.

- v2.6.38: VersaLogic patch (e19e074b "x86: Fix reboot problem on
  VersaLogic Menlow boards") was applied prior to v2.6.38-rc7.  This
  patch sets a quirk for VersaLogic Menlow boards that forces the use
  of reboot=bios, which doesn't work anymore.

- v3.2: It seems that commit 660e34ce ("x86: Reorder reboot method
  preferences") changed the default reboot method to acpi prior to
  v3.0-rc1, which means the default behavior is appropriate for the
  Ocelot.  No VersaLogic quirk is required.

The Ocelot board used for testing can successfully reboot w/out
having to pass any reboot= arguments for all 3 current versions
of the BIOS.

Signed-off-by: default avatarMichael D Labriola <michael.d.labriola@gmail.com>
Cc: Matthew Garrett <mjg@redhat.com>
Cc: Michael D Labriola <mlabriol@gdeb.com>
Cc: Kushal Koolwal <kushalkoolwal@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: http://lkml.kernel.org/r/87vcnub9hu.fsf@gmail.com


Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      e6d36a65
    • Michael D Labriola's avatar
      x86/reboot: Skip DMI checks if reboot set by user · 5955633e
      Michael D Labriola authored 
      
Skip DMI checks for vendor specific reboot quirks if the user
passed in a reboot= arg on the command line - we should never
override user choices.

Signed-off-by: default avatarMichael D Labriola <michael.d.labriola@gmail.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Michael D Labriola <mlabriol@gdeb.com>
Cc: Matthew Garrett <mjg@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: http://lkml.kernel.org/r/87wr8ab9od.fsf@gmail.com


Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      5955633e
  15. Jan 28, 2012
  17. Jan 27, 2012
  19. Jan 26, 2012
  21. Jan 25, 2012
  23. Jan 24, 2012
    • Christian Kujau's avatar
      powerpc/crash: Fix build error without SMP · 897e01a0
      Christian Kujau authored 
      
I could not find cpus_in_crash anywhere in the sourcetree, except for
arch/powerpc/kernel/crash.c. Moving the definition into the CONFIG_SMP
fixes it.

Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      897e01a0
    • Deepthi Dharwar's avatar
      powerpc/cpuidle: Make it a bool, not a tristate · f7aa5545
      Deepthi Dharwar authored 
      
As pointed out, asm/system.h has empty inline implementations for
update_smt_snooze_delay and pseries_notify_cpuidle_add_cpu, which are
used when CONFIG_PSERIES_IDLE is undefined. Since those two functions
are used in core power architecture functions (store_smt_snooze_delay
at kernel/sysfs.c and smp_xics_setup_cpu at platforms/pseries/smp.c),

Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      f7aa5545
    • Paul Walmsley's avatar
      tty: serial: OMAP: transmit FIFO threshold interrupts don't wake the chip · 43cf7c0b
      Paul Walmsley authored 
      
It seems that when the transmit FIFO threshold is reached on OMAP
UARTs, it does not result in a PRCM wakeup.  This appears to be a
silicon bug.  This means that if the MPU powerdomain is in a low-power
state, the MPU will not be awakened to refill the FIFO until the next
interrupt from another device.

The best solution, at least for the short term, would be for the OMAP
serial driver to call a OMAP subarchitecture function to prevent the
MPU powerdomain from entering a low power state while the FIFO has
data to transmit.  However, we no longer have a clean way to do this,
since patches that add platform_data function pointers have been
deprecated by the OMAP maintainer.  So we attempt to work around this
as well.  The workarounds depend on the setting of CONFIG_CPU_IDLE.

When CONFIG_CPU_IDLE=n, the driver will now only transmit one byte at
a time.  This causes the transmit FIFO threshold interrupt to stay
active until there is no more data to be sent.  Thus, the MPU
powerdomain stays on during transmits.  Aside from that energy
consumption penalty, each transmitted byte results in a huge number of
UART interrupts -- about five per byte.  This wastes CPU time and is
quite inefficient, but is probably the most expedient workaround in
this case.

When CONFIG_CPU_IDLE=y, there is a slightly more direct workaround:
the PM QoS constraint can be abused to keep the MPU powerdomain on.
This results in a normal number of interrupts, but, similar to the
above workaround, wastes power by preventing the MPU from entering
WFI.

Future patches are planned for the 3.4 merge window to implement more
efficient, but also more disruptive, workarounds to these problems.

DMA operation is unaffected by this patch.

Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Govindraj Raja <govindraj.r@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      43cf7c0b
    • David Vrabel's avatar
      x86: xen: size struct xen_spinlock to always fit in arch_spinlock_t · 7a7546b3
      David Vrabel authored 
      
If NR_CPUS < 256 then arch_spinlock_t is only 16 bits wide but struct
xen_spinlock is 32 bits.  When a spin lock is contended and
xl->spinners is modified the two bytes immediately after the spin lock
would be corrupted.

This is a regression caused by 84eb950d
(x86, ticketlock: Clean up types and accessors) which reduced the size
of arch_spinlock_t.

Fix this by making xl->spinners a u8 if NR_CPUS < 256.  A
BUILD_BUG_ON() is also added to check the sizes of the two structures
are compatible.

In many cases this was not noticable as there would often be padding
bytes after the lock (e.g., if any of CONFIG_GENERIC_LOCKBREAK,
CONFIG_DEBUG_SPINLOCK, or CONFIG_DEBUG_LOCK_ALLOC were enabled).

The bnx2 driver is affected. In struct bnx2, phy_lock and
indirect_lock may have no padding after them.  Contention on phy_lock
would corrupt indirect_lock making it appear locked and the driver
would deadlock.

Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
Signed-off-by: default avatarJeremy Fitzhardinge <jeremy@goop.org>
Acked-by: default avatarIan Campbell <ian.campbell@citrix.com>
CC: stable@kernel.org #only 3.2
Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      7a7546b3
  25. Jan 23, 2012