Paul Mackerras [Tue, 12 May 2009 11:59:01 +0000 (21:59 +1000)]
perf_counter: call hw_perf_save_disable/restore around group_sched_in
I noticed that when enabling a group via the PERF_COUNTER_IOC_ENABLE
ioctl on the group leader, the counters weren't enabled and counting
immediately on return from the ioctl, but did start counting a little
while later (presumably after a context switch).
The reason was that __perf_counter_enable calls group_sched_in which
calls hw_perf_group_sched_in, which on powerpc assumes that the caller
has called hw_perf_save_disable already. Until commit 46d686c6
("perf_counter: put whole group on when enabling group leader") it was
true that all callers of group_sched_in had called
hw_perf_save_disable first, and the powerpc hw_perf_group_sched_in
relies on that (there isn't an x86 version).
This fixes the problem by putting calls to hw_perf_save_disable /
hw_perf_restore around the calls to group_sched_in and
counter_sched_in in __perf_counter_enable. Having the calls to
hw_perf_save_disable/restore around the counter_sched_in call is
harmless and makes this call consistent with the other call sites
of counter_sched_in, which have all called hw_perf_save_disable first.
[ Impact: more precise counter group disable/enable functionality ]
Signed-off-by: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
LKML-Reference: <18953.25733.53359.147452@cargo.ozlabs.ibm.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
* in fact, only collect_cpu_info and apply_microcode callbacks
must run on a target cpu, others will do just fine on any other.
smp_call_function_single() (as suggested by Ingo) is used to run
these callbacks on a target cpu.
* cleanup of synchronization logic of the 'microcode_core' part
The generic 'microcode_core' part guarantees that only a single cpu
(be it a full-fledged cpu, one of the cores or HT)
is being updated at any particular moment of time.
In general, there is no need for any additional sync. mechanism in
arch-specific parts (the patch removes existing spinlocks).
See also the "Synchronization" section in microcode_core.c.
* return -EINVAL instead of -1 (which is translated into -EPERM) in
microcode_write(), reload_cpu() and mc_sysdev_add(). Other suggestions
for an error code?
* use 'enum ucode_state' as return value of request_microcode_{fw, user}
to gain more flexibility by distinguishing between real error cases
and situations when an appropriate ucode was not found (which is not an
error per-se).
* some minor cleanups
Thanks a lot to Hugh Dickins for review/suggestions/testing!
john stultz [Tue, 12 May 2009 01:13:13 +0000 (18:13 -0700)]
ntp: fix comment typos
Bernhard Schiffner noticed I had a few comment typos in this patch,
(note: to save embarrassment, when making typos, avoid copying and
pasting them) so this patch corrects them.
[ Impact: cleanup ]
Reported-by: Bernhard Schiffner <bernhard@schiffner-limbach.de> Signed-off-by: John Stultz <johnstul@us.ibm.com> Cc: riel@redhat.com Cc: akpm@linux-foundation.org
LKML-Reference: <1242090794.7214.131.camel@localhost.localdomain> Signed-off-by: Ingo Molnar <mingo@elte.hu>
Steven Rostedt [Tue, 12 May 2009 02:11:05 +0000 (22:11 -0400)]
ring-buffer: move code around to remove some branches
This is a bit of micro-optimizations. But since the ring buffer is used
in tracing every function call, it is an extreme hot path. Every nanosecond
counts.
This change shows over 5% improvement in the ring-buffer-benchmark.
[ Impact: more efficient code ]
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Steven Rostedt [Mon, 11 May 2009 20:28:23 +0000 (16:28 -0400)]
ring-buffer: use internal time stamp function
The ring_buffer_time_stamp that is exported adds a little more overhead
than is needed for using it internally. This patch adds an internal
timestamp function that can be inlined (a single line function)
and used internally for the ring buffer.
[ Impact: a little less overhead to the ring buffer ]
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
sched: Don't export sched_mc_power_savings on multi-socket single core system
Fix to prevent sched_mc_power_saving from being exported through sysfs
for multi-scoket single core system. Max cores should be always greater than
one (1). My earlier patch that introduced fix for not exporting
'sched_mc_power_saving' on laptops broke it on multi-socket single core
system. This fix addresses issue on both laptop and multi-socket single
core system.
Below are the Test results:
1. Single socket - multi-core
Before Patch: Does not export 'sched_mc_power_saving'
After Patch: Does not export 'sched_mc_power_saving'
Result: Pass
2. Multi Socket - single core
Before Patch: exports 'sched_mc_power_saving'
After Patch: Does not export 'sched_mc_power_saving'
Result: Pass
3. Multi Socket - Multi core
Before Patch: exports 'sched_mc_power_saving'
After Patch: exports 'sched_mc_power_saving'
[ Impact: make the sched_mc_power_saving control available more consistently ]
Linus Torvalds [Mon, 11 May 2009 19:42:55 +0000 (12:42 -0700)]
Merge branch 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev
* 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev:
ata_piix: The Sony TZ90 needs the cable type hardcoding
ata_piix: ICH7 does not support correct MWDMA timings
Avoid world-writable sysfs files in libata driver.
libata: fix suspend/resume for ATA SEMB devices
libata: clear ering on resume
pata_pdc202xx_old: fix UDMA33 handling
sata_mv: use new sata phy register settings for new devices
libata: fix attach error handling
Jeff Mahoney [Mon, 11 May 2009 18:25:34 +0000 (14:25 -0400)]
dup2: Fix return value with oldfd == newfd and invalid fd
The return value of dup2 when oldfd == newfd and the fd isn't valid is
not getting properly sign extended. We end up with 4294967287 instead
of -EBADF.
I've reproduced this on SLE11 (2.6.27.21), openSUSE Factory
(2.6.29-rc5), and Ubuntu 9.04 (2.6.28).
This patch uses a signed int for the error value so it is properly
extended.
Steven Rostedt [Mon, 11 May 2009 18:42:53 +0000 (14:42 -0400)]
ring-buffer: move calculation of event length
The event length is calculated and passed in to rb_reserve_next_event
in two different locations. Having rb_reserve_next_event do the
calculations directly makes only one location to do the change and
causes the calculation to be inlined by gcc.
Before:
text data bss dec hex filename
16538 24 12 16574 40be kernel/trace/ring_buffer.o
After:
text data bss dec hex filename
16490 24 12 16526 408e kernel/trace/ring_buffer.o
[ Impact: smaller more efficient code ]
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
79b42babbac2a5a522b8e269fb2811b6e1063030 fixed identifying ATA devices
reporting 3c/c3 signature which belongs to SEMB devices now. However,
suspending the machine with such device (WDC WD2500AAJS-6 01.0) fails
with the following:
hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4
hda: UDMA/100 mode selected
hdb: host max PIO4 wanted PIO255(auto-tune) selected PIO4
hdb: UDMA/66 mode selected
sd 1:0:0:0: [sda] Starting disk
ata5: SATA link down (SStatus 0 SControl 300)
ata1: SATA link down (SStatus 0 SControl 300)
ata3: SATA link down (SStatus 0 SControl 300)
ata6: SATA link down (SStatus 0 SControl 300)
ata2: softreset failed (device not ready)
ata2: failed due to HW bug, retry pmp=0
ata4: softreset failed (device not ready)
ata4: failed due to HW bug, retry pmp=0
ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata2.00: class mismatch 1 != 7
ata2.00: revalidation failed (errno=-19)
ata2: limiting SATA link speed to 1.5 Gbps
ata4.00: configured for UDMA/133
ata2: softreset failed (device not ready)
ata2: failed due to HW bug, retry pmp=0
ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata2.00: class mismatch 1 != 7
ata2.00: revalidation failed (errno=-19)
ata2.00: disabled
sd 1:0:0:0: rejecting I/O to offline device
sd 1:0:0:0: [sda] START_STOP FAILED
sd 1:0:0:0: [sda] Result: hostbyte=0x01 driverbyte=0x00
PM: Device 1:0:0:0 failed to thaw: error 65536
sd 3:0:0:0: [sdb] Starting disk
due to a class mismatch in ata_dev_revalidate(). Fix it by adding the
ATA_DEV_SEMB device class to the check.
Error timestamps are in jiffies which doesn't run while suspended and
PHY events during resume isn't too uncommon. When the two are
combined, it can lead to unnecessary speed downs if the machine is
suspended and resumed repeatedly. Clear error history on resume.
This was reported and verified in bnc#486803 by Vladimir Botka.
Signed-off-by: Tejun Heo <tj@kernel.org> Reported-by: Vladimir Botka <vbotka@novell.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
The original driver doesn't use 66 MHz clock for UDMA33.
[ The alternative solution would be to adjust UDMA33 timings
for 66 MHz clock but I think that it is safer to stick with
old & tested behavior for now. ]
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Tejun Heo [Sat, 9 May 2009 16:06:54 +0000 (01:06 +0900)]
libata: fix attach error handling
New device attach path in ata_eh_revalidate_and_attach() is divided
into two separate loops because ATA requires IDENTIFY to be issued to
slave first while the user expects to see device probe messages from
the master device. new_mask is used to track which devices are the
new ones between the first loop and the second.
This usually works well but if an error occurs during configuration
stage, ata_dev_revalidate_and_attach() returns with error code and
forgets new_mask. On the retry run, dev->class is set and new_mask
for the device is clear, so the device just gets revalidated and thus
ends up skipping post-configuration procedure including scheduling of
SCSI_HOTPLUG for the device. When this occurs, ATA part of probing
works fine but SCSI probing usually doesn't happen and makes the
device unreachable.
The behavior has been around for a very long time but it has been
uncovered with the recent addition of 1_5_GBPS horkage which uses
-EAGAIN return value from ata_dev_configure() to restart the probing
sequence after forcing cable speed.
This can be fixed by making sure dev->class is permanently set only
after all configurations are successfully complete. Fix it.
Signed-off-by: Tejun Heo <tj@kernel.org> Reported-by: Tim Connors <tconnors+linuxkml@astro.swin.edu.au> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
David Woodhouse [Sun, 10 May 2009 22:57:41 +0000 (23:57 +0100)]
intel-iommu: PAE memory corruption fix
PAGE_MASK is 0xFFFFF000 on i386 -- even with PAE.
So it's not sufficient to ensure that you use phys_addr_t or uint64_t
everywhere you handle physical addresses -- you also have to avoid using
the construct 'addr & PAGE_MASK', because that will strip the high 32
bits of the address.
This patch avoids that problem by using PHYSICAL_PAGE_MASK instead of
PAGE_MASK where appropriate. It leaves '& PAGE_MASK' in a few instances
that don't matter -- where it's being used on the virtual bus addresses
we're dishing out, which are 32-bit anyway.
Since PHYSICAL_PAGE_MASK is not present on other architectures, we have
to define it (to PAGE_MASK) if it's not already defined.
Maybe it would be better just to fix PAGE_MASK for i386/PAE?
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Alexey Dobriyan [Sun, 3 May 2009 23:29:52 +0000 (03:29 +0400)]
x86, 32-bit: ifdef out struct thread_struct::fs
After commit 464d1a78fbf8cf6c7fd970e7b3e2db50a320ce28 aka
"[PATCH] i386: Convert i386 PDA code to use %fs"
%fs saved during context switch moved from thread_struct to pt_regs
and value on thread_struct became unused.
x86: display extended apic registers with print_local_APIC and cpu_debug code
Both print_local_APIC (used when apic=debug kernel param is set) and
cpu_debug code missed support for some extended APIC registers that
I'd like to see.
Catalin Marinas [Mon, 11 May 2009 12:22:00 +0000 (13:22 +0100)]
x86: Provide _sdata in the vmlinux.lds.S file
_sdata is a common symbol defined by many architectures and made
available to the kernel via asm-generic/sections.h. Kmemleak uses this
symbol when scanning the data sections.
Paul Mackerras [Mon, 11 May 2009 05:50:21 +0000 (15:50 +1000)]
perf_counter: call atomic64_set for counter->count
A compile warning triggered because we are calling
atomic_set(&counter->count). But since counter->count
is an atomic64_t, we have to use atomic64_set.
So the count can be set short, resulting in the reset ioctl
only resetting the low word.
[ Impact: clear counter properly during the reset ioctl ]
Signed-off-by: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
LKML-Reference: <18951.48285.270311.981806@drongo.ozlabs.ibm.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
projects / people / ssmith / netchannel2-pvops.bak.git / .git / log