02 Nov, 2013
1 commit
-
This patch uses CONFIG_PAGE_OFFSET to filter symbols which
are not in kernel address space because these symbols are
generally for generating code purpose and can't be run at
kernel mode, so we needn't keep them in /proc/kallsyms.For example, on ARM there are some symbols which may be
linked in relocatable code section, then perf can't parse
symbols any more from /proc/kallsyms, this patch fixes the
problem (introduced b9b32bf70f2fb710b07c94e13afbc729afe221da)Cc: Russell King
Cc: linux-arm-kernel@lists.infradead.org
Cc: Michal Marek
Signed-off-by: Ming Lei
Signed-off-by: Rusty Russell
Cc: stable@vger.kernel.org
31 Oct, 2013
15 commits
-
Merge three fixes from Andrew Morton.
* emailed patches from Andrew Morton :
memcg: use __this_cpu_sub() to dec stats to avoid incorrect subtrahend casting
percpu: fix this_cpu_sub() subtrahend casting for unsigneds
mm/pagewalk.c: fix walk_page_range() access of wrong PTEs -
As of commit 3ea67d06e467 ("memcg: add per cgroup writeback pages
accounting") memcg counter errors are possible when moving charged
memory to a different memcg. Charge movement occurs when processing
writes to memory.force_empty, moving tasks to a memcg with
memcg.move_charge_at_immigrate=1, or memcg deletion.An example showing error after memory.force_empty:
$ cd /sys/fs/cgroup/memory
$ mkdir x
$ rm /data/tmp/file
$ (echo $BASHPID >> x/tasks && exec mmap_writer /data/tmp/file 1M) &
[1] 13600
$ grep ^mapped x/memory.stat
mapped_file 1048576
$ echo 13600 > tasks
$ echo 1 > x/memory.force_empty
$ grep ^mapped x/memory.stat
mapped_file 4503599627370496mapped_file should end with 0.
4503599627370496 == 0x10,0000,0000,0000 == 0x100,0000,0000 pages
1048576 == 0x10,0000 == 0x100 pagesThis issue only affects the source memcg on 64 bit machines; the
destination memcg counters are correct. So the rmdir case is not too
important because such counters are soon disappearing with the entire
memcg. But the memcg.force_empty and memory.move_charge_at_immigrate=1
cases are larger problems as the bogus counters are visible for the
(possibly long) remaining life of the source memcg.The problem is due to memcg use of __this_cpu_from(.., -nr_pages), which
is subtly wrong because it subtracts the unsigned int nr_pages (either
-1 or -512 for THP) from a signed long percpu counter. When
nr_pages=-1, -nr_pages=0xffffffff. On 64 bit machines stat->count[idx]
is signed 64 bit. So memcg's attempt to simply decrement a count (e.g.
from 1 to 0) boils down to:long count = 1
unsigned int nr_pages = 1
count += -nr_pages /* -nr_pages == 0xffff,ffff */
count is now 0x1,0000,0000 instead of 0The fix is to subtract the unsigned page count rather than adding its
negation. This only works once "percpu: fix this_cpu_sub() subtrahend
casting for unsigneds" is applied to fix this_cpu_sub().Signed-off-by: Greg Thelen
Acked-by: Tejun Heo
Acked-by: Johannes Weiner
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
this_cpu_sub() is implemented as negation and addition.
This patch casts the adjustment to the counter type before negation to
sign extend the adjustment. This helps in cases where the counter type
is wider than an unsigned adjustment. An alternative to this patch is
to declare such operations unsupported, but it seemed useful to avoid
surprises.This patch specifically helps the following example:
unsigned int delta = 1
preempt_disable()
this_cpu_write(long_counter, 0)
this_cpu_sub(long_counter, delta)
preempt_enable()Before this change long_counter on a 64 bit machine ends with value
0xffffffff, rather than 0xffffffffffffffff. This is because
this_cpu_sub(pcp, delta) boils down to this_cpu_add(pcp, -delta),
which is basically:
long_counter = 0 + 0xffffffffAlso apply the same cast to:
__this_cpu_sub()
__this_cpu_sub_return()
this_cpu_sub_return()All percpu_test.ko passes, especially the following cases which
previously failed:l -= ui_one;
__this_cpu_sub(long_counter, ui_one);
CHECK(l, long_counter, -1);l -= ui_one;
this_cpu_sub(long_counter, ui_one);
CHECK(l, long_counter, -1);
CHECK(l, long_counter, 0xffffffffffffffff);ul -= ui_one;
__this_cpu_sub(ulong_counter, ui_one);
CHECK(ul, ulong_counter, -1);
CHECK(ul, ulong_counter, 0xffffffffffffffff);ul = this_cpu_sub_return(ulong_counter, ui_one);
CHECK(ul, ulong_counter, 2);ul = __this_cpu_sub_return(ulong_counter, ui_one);
CHECK(ul, ulong_counter, 1);Signed-off-by: Greg Thelen
Acked-by: Tejun Heo
Acked-by: Johannes Weiner
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
When walk_page_range walk a memory map's page tables, it'll skip
VM_PFNMAP area, then variable 'next' will to assign to vma->vm_end, it
maybe larger than 'end'. In next loop, 'addr' will be larger than
'next'. Then in /proc/XXXX/pagemap file reading procedure, the 'addr'
will growing forever in pagemap_pte_range, pte_to_pagemap_entry will
access the wrong pte.BUG: Bad page map in process procrank pte:8437526f pmd:785de067
addr:9108d000 vm_flags:00200073 anon_vma:f0d99020 mapping: (null) index:9108d
CPU: 1 PID: 4974 Comm: procrank Tainted: G B W O 3.10.1+ #1
Call Trace:
dump_stack+0x16/0x18
print_bad_pte+0x114/0x1b0
vm_normal_page+0x56/0x60
pagemap_pte_range+0x17a/0x1d0
walk_page_range+0x19e/0x2c0
pagemap_read+0x16e/0x200
vfs_read+0x84/0x150
SyS_read+0x4a/0x80
syscall_call+0x7/0xbSigned-off-by: Liu ShuoX
Signed-off-by: Chen LinX
Acked-by: Kirill A. Shutemov
Reviewed-by: Naoya Horiguchi
Cc: [3.10.x+]
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
I've seen a fair number of issues with kswapd and other processes
appearing to get stuck in v3.12-rc. Using sysrq-p many times seems to
indicate that it gets stuck somewhere in list_lru_walk_node(), called
from prune_icache_sb() and super_cache_scan().I never seem to be able to trigger a calltrace for functions above that
point.So I decided to add the following to super_cache_scan():
@@ -81,10 +81,14 @@ static unsigned long super_cache_scan(struct shrinker *shrink,
inodes = list_lru_count_node(&sb->s_inode_lru, sc->nid);
dentries = list_lru_count_node(&sb->s_dentry_lru, sc->nid);
total_objects = dentries + inodes + fs_objects + 1;
+printk("%s:%u: %s: dentries %lu inodes %lu total %lu\n", current->comm, current->pid, __func__, dentries, inodes, total_objects);/* proportion the scan between the caches */
dentries = mult_frac(sc->nr_to_scan, dentries, total_objects);
inodes = mult_frac(sc->nr_to_scan, inodes, total_objects);
+printk("%s:%u: %s: dentries %lu inodes %lu\n", current->comm, current->pid, __func__, dentries, inodes);
+BUG_ON(dentries == 0);
+BUG_ON(inodes == 0);/*
* prune the dcache first as the icache is pinned by it, then
@@ -99,7 +103,7 @@ static unsigned long super_cache_scan(struct shrinker *shrink,
freed += sb->s_op->free_cached_objects(sb, fs_objects,
sc->nid);
}
-
+printk("%s:%u: %s: dentries %lu inodes %lu freed %lu\n", current->comm, current->pid, __func__, dentries, inodes, freed);
drop_super(sb);
return freed;
}and shortly thereafter, having applied some pressure, I got this:
update-apt-xapi:1616: super_cache_scan: dentries 25632 inodes 2 total 25635
update-apt-xapi:1616: super_cache_scan: dentries 1023 inodes 0
------------[ cut here ]------------
Kernel BUG at c0101994 [verbose debug info unavailable]
Internal error: Oops - BUG: 0 [#3] SMP ARM
Modules linked in: fuse rfcomm bnep bluetooth hid_cypress
CPU: 0 PID: 1616 Comm: update-apt-xapi Tainted: G D 3.12.0-rc7+ #154
task: daea1200 ti: c3bf8000 task.ti: c3bf8000
PC is at super_cache_scan+0x1c0/0x278
LR is at trace_hardirqs_on+0x14/0x18
Process update-apt-xapi (pid: 1616, stack limit = 0xc3bf8240)
...
Backtrace:
(super_cache_scan) from [] (shrink_slab+0x254/0x4c8)
(shrink_slab) from [] (try_to_free_pages+0x3a0/0x5e0)
(try_to_free_pages) from [] (__alloc_pages_nodemask+0x5)
(__alloc_pages_nodemask) from [] (__pte_alloc+0x2c/0x13)
(__pte_alloc) from [] (handle_mm_fault+0x84c/0x914)
(handle_mm_fault) from [] (do_page_fault+0x1f0/0x3bc)
(do_page_fault) from [] (do_translation_fault+0xac/0xb8)
(do_translation_fault) from [] (do_DataAbort+0x38/0xa0)
(do_DataAbort) from [] (__dabt_usr+0x38/0x40)Notice that we had a very low number of inodes, which were reduced to
zero my mult_frac().Now, prune_icache_sb() calls list_lru_walk_node() passing that number of
inodes (0) into that as the number of objects to scan:long prune_icache_sb(struct super_block *sb, unsigned long nr_to_scan,
int nid)
{
LIST_HEAD(freeable);
long freed;freed = list_lru_walk_node(&sb->s_inode_lru, nid, inode_lru_isolate,
&freeable, &nr_to_scan);which does:
unsigned long
list_lru_walk_node(struct list_lru *lru, int nid, list_lru_walk_cb isolate,
void *cb_arg, unsigned long *nr_to_walk)
{struct list_lru_node *nlru = &lru->node[nid];
struct list_head *item, *n;
unsigned long isolated = 0;spin_lock(&nlru->lock);
restart:
list_for_each_safe(item, n, &nlru->list) {
enum lru_status ret;/*
* decrement nr_to_walk first so that we don't livelock if we
* get stuck on large numbesr of LRU_RETRY items
*/
if (--(*nr_to_walk) == 0)
break;So, if *nr_to_walk was zero when this function was entered, that means
we're wanting to operate on (~0UL)+1 objects - which might as well be
infinite.Clearly this is not correct behaviour. If we think about the behaviour
of this function when *nr_to_walk is 1, then clearly it's wrong - we
decrement first and then test for zero - which results in us doing
nothing at all. A post-decrement would give the desired behaviour -
we'd try to walk one object and one object only if *nr_to_walk were one.It also gives the correct behaviour for zero - we exit at this point.
Fixes: 5cedf721a7cd ("list_lru: fix broken LRU_RETRY behaviour")
Signed-off-by: Russell King
Cc: Dave Chinner
Cc: Al Viro
Cc: Andrew Morton
[ Modified to make sure we never underflow the count: this function gets
called in a loop, so the 0 -> ~0ul transition is dangerous - Linus ]
Signed-off-by: Linus Torvalds -
Pull serial fixes from Greg KH:
"Here are 3 tiny fixes that are needed for 3.12-final for some serial
drivers.One of them is a revert of a broken patch, and two others are fixes
for reported bugs. All of these have been in linux-next for a while,
I forgot I had not sent them to you yet, my fault"(Actually, Greg, you _had_ sent two of the three, so this pulls in just
one actual new fix)* tag 'tty-3.12-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
tty/serial: at91: fix uart/usart selection for older products -
Pull drm fixes from Dave Airlie:
"Mainly Intel regression fixes and quirks, along with a simple one
liner to fix rendernodes ioctl access (off by default, but testers
want to test it)"* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
drm: allow DRM_IOCTL_VERSION on render-nodes
drm/i915: Fix the PPT fdi lane bifurcate state handling on ivb
drm/i915: No LVDS hardware on Intel D410PT and D425KT
drm/i915/dp: workaround BIOS eDP bpp clamping issue
drm/i915: Add HSW CRT output readout support
drm/i915: Add support for pipe_bpp readout -
Pull sound fixes from Takashi Iwai:
"A few small HD-audio regression fixes, mostly for stable kernels, too"* tag 'sound-3.12' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: hda - Fix silent headphone on Thinkpads with AD1984A codec
ALSA: hda - Add missing initial vmaster hook at build_controls callback
ALSA: hda - Fix unbalanced runtime PM refcount after S3/S4 -
Pull KVM fixes from Paolo Bonzini:
"Fixes for the 3.12 debugfs problem - removing the duplicate directory
name, and using a better the error code"* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
KVM: use a more sensible error number when debugfs directory creation fails
KVM: Fix modprobe failure for kvm_intel/kvm_amd -
The icount.reserved[] array isn't initialized so it leaks stack
information to userspace.Reported-by: Nico Golde
Reported-by: Fabian Yamaguchi
Signed-off-by: Dan Carpenter
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds -
The DevInfo.u32Reserved[] array isn't initialized so it leaks kernel
information to user space.Reported-by: Nico Golde
Reported-by: Fabian Yamaguchi
Signed-off-by: Dan Carpenter
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds -
We need to check the length parameter before doing the memcpy(). I've
actually changed it to strlcpy() as well so that it's NUL terminated.You need CAP_NET_ADMIN to trigger these so it's not the end of the
world.Reported-by: Nico Golde
Reported-by: Fabian Yamaguchi
Signed-off-by: Dan Carpenter
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds -
In commit d496f94d22d1 ('[SCSI] aacraid: fix security weakness') we
added a check on CAP_SYS_RAWIO to the ioctl. The compat ioctls need the
check as well.Signed-off-by: Dan Carpenter
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds -
We need to check "count" so we don't overflow the ei->data buffer.
Reported-by: Nico Golde
Reported-by: Fabian Yamaguchi
Signed-off-by: Dan Carpenter
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds -
We don't cap the size of buffer from the user so we could write past the
end of the array here. Only root can write to this file.Reported-by: Nico Golde
Reported-by: Fabian Yamaguchi
Signed-off-by: Dan Carpenter
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds
30 Oct, 2013
5 commits
-
I don't know if this was due to cut and paste, or somebody was really
using a D20 to pick the error code for kvm_init_debugfs as suggested by
Linus (EFAULT is 14, so the possibility cannot be entirely ruled out).In any case, this patch fixes it.
Reported-by: Tim Gardner
Signed-off-by: Paolo Bonzini -
The x86 specific kvm init creates a new conflicting
debugfs directory which causes modprobe issues
with kvm_intel and kvm_amd. For example,sudo modprobe kvm_amd
modprobe: ERROR: could not insert 'kvm_amd': Bad addressThe simplest fix is to just rename the directory. The following
KVM config options are set:CONFIG_KVM_GUEST=y
CONFIG_KVM_DEBUG_FS=y
CONFIG_HAVE_KVM=y
CONFIG_HAVE_KVM_IRQCHIP=y
CONFIG_HAVE_KVM_IRQ_ROUTING=y
CONFIG_HAVE_KVM_EVENTFD=y
CONFIG_KVM_APIC_ARCHITECTURE=y
CONFIG_KVM_MMIO=y
CONFIG_KVM_ASYNC_PF=y
CONFIG_HAVE_KVM_MSI=y
CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT=y
CONFIG_KVM=m
CONFIG_KVM_INTEL=m
CONFIG_KVM_AMD=m
CONFIG_KVM_DEVICE_ASSIGNMENT=yCc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Gleb Natapov
Cc: Raghavendra K T
Cc: Marcelo Tosatti
Signed-off-by: Tim Gardner
[Change debugfs directory name. - Paolo]
Signed-off-by: Paolo Bonzini -
DRM_IOCTL_VERSION is a reliable way to get the driver-name and version
information. It's not related to the interface-version (SET_VERSION ioctl)
so we can safely enable it on render-nodes.Note that gbm uses udev-BUSID to load the correct mesa driver. However,
the VERSION ioctl should be the more reliable way to do this (in case we
add new DRM-bus drivers which have no BUSID or similar).Signed-off-by: David Herrmann
Reviewed-by: Daniel Vetter
Signed-off-by: Dave Airlie -
…rm-intel into drm-fixes
Regression and warn fixes for i915.
* tag 'drm-intel-fixes-2013-10-29' of git://people.freedesktop.org/~danvet/drm-intel:
drm/i915: Fix the PPT fdi lane bifurcate state handling on ivb
drm/i915: No LVDS hardware on Intel D410PT and D425KT
drm/i915/dp: workaround BIOS eDP bpp clamping issue
drm/i915: Add HSW CRT output readout support
drm/i915: Add support for pipe_bpp readout -
Nico Golde reports a few straggling uses of [io_]remap_pfn_range() that
really should use the vm_iomap_memory() helper. This trivially converts
two of them to the helper, and comments about why the third one really
needs to continue to use remap_pfn_range(), and adds the missing size
check.Reported-by: Nico Golde
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org.
29 Oct, 2013
13 commits
-
Pull perf tooling fixes from Ingo Molnar:
"This contains five tooling fixes:- fix a remaining mmap2 assumption which resulted in perf top output
breakage
- fix mmap ring-buffer processing bug that corrupts data
- fix for a severe python scripting memory leak
- fix broken (and user-visible) -g option handling
- fix stdio outputThe diffstat size is larger than what we'd like to see this late :-/"
* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
perf tools: Fixup mmap event consumption
perf top: Split -G and --call-graph
perf record: Split -g and --call-graph
perf hists: Add color overhead for stdio output buffer
perf tools: Fix up /proc/PID/maps parsing
perf script python: Fix mem leak due to missing Py_DECREFs on dict entries -
Without the timer debugging, the delayed kobject release will just
result in undebuggable oopses if it triggers any latent bugs. That
doesn't actually help debugging at all.So make DEBUG_KOBJECT_RELEASE depend on DEBUG_OBJECTS_TIMERS to avoid
having people enable one without the other.Signed-off-by: Linus Torvalds
-
Originally I've thought that this is leftover hw state dirt from the
BIOS. But after way too much helpless flailing around on my part I've
noticed that the actual bug is when we change the state of an already
active pipe.For example when we change the fdi lines from 2 to 3 without switching
off outputs in-between we'll never see the crucial on->off transition
in the ->modeset_global_resources hook the current logic relies on.Patch version 2 got this right by instead also checking whether the
pipe is indeed active. But that in turn broke things when pipes have
been turned off through dpms since the bifurcate enabling is done in
the ->crtc_mode_set callback.To address this issues discussed with Ville in the patch review move
the setting of the bifurcate bit into the ->crtc_enable hook. That way
we won't wreak havoc with this state when userspace puts all other
outputs into dpms off state. This also moves us forward with our
overall goal to unify the modeset and dpms on paths (which we need to
have to allow runtime pm in the dpms off state).Unfortunately this requires us to move the bifurcate helpers around a
bit.Also update the commit message, I've misanalyzed the bug rather badly.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70507
Tested-by: Jan-Michael Brummer
Cc: stable@vger.kernel.org
Cc: Ville Syrjälä
Reviewed-by: Ville Syrjälä
Signed-off-by: Daniel Vetter -
…it/acme/linux into perf/urgent
Pull perf/urgent fixes from Arnaldo Carvalho de Melo:
* Add color overhead for stdio output buffer, which fixes
--stdio output being chopped up on the hot (red) entries,
fix from Jiri Olsa.* Get 'perf record -g -a sleep 1' working again, removing the
need for -- separating perf options from the workload, restoring
ages old behaviour, fix from Jiri Olsa.
More patches allowing ~/.perfconfig setting up of default
callchain collecting method ("fp" or "dwarf") left for next
merge window.* Fixup mmap event consumption, where we were acking the
consumption by writing the tail before actually accessing
the event, which could lead to using overwritten records
in things like 'perf record --call-graph'. From Zhouyi Zhou.Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
-
Pull Xtensa patchset from Chris Zankel:
"The main patch fixes a bug that can cause a kernel panic, and was
introduced in rc1. The other two have been discovered by a uclibc
test and 'coccinelle'"* tag 'xtensa-next-20131015' of git://github.com/czankel/xtensa-linux:
xtensa: Cocci spatch "noderef"
xtensa: don't use alternate signal stack on threads
xtensa: fix fast_syscall_spill_registers_fixup -
Pull SCSI fixes from James Bottomley:
"This is a set of four patches that revert functionality introduced in
the merge window to sg. The locking changes turned out to introduce
this bug:[ 205.372901] [ BUG: lock held when returning to user space! ]
[...]
[ 205.373285] #0: (&sdp->o_sem){.+.+..}, at: [] sg_open+0x3a0/0x4d0The fix is large, so at this late stage we'd like to revert the
functionality and start again in the next merge window"* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
[SCSI] Revert "sg: use rwsem to solve race during exclusive open"
[SCSI] Revert "sg: no need sg_open_exclusive_lock"
[SCSI] Revert "sg: checking sdp->detached isn't protected when open"
[SCSI] Revert "sg: push file descriptor list locking down to per-device locking" -
The tail position of the event buffer should only be modified after
actually use that event.If not the event buffer could be invalid before use, and segment fault
occurs when invoking perf top -G.Signed-off-by: Zhouyi Zhou
Cc: David Ahern
Cc: Zhouyi Zhou
Link: http://lkml.kernel.org/r/1382600613-32177-1-git-send-email-zhouzhouyi@gmail.com
[ Simplified the logic using exit gotos and renamed write_tail method to mmap_consume ]
Signed-off-by: Arnaldo Carvalho de Melo -
Splitting -G and --call-graph for record command, so we could use '-G'
with no option.The '-G' option now takes NO argument and enables the configured unwind
method, which is currently the frame pointers method.It will be possible to configure unwind method via config file in
upcoming patches.All current '-G' arguments is overtaken by --call-graph option.
NOTE: The documentation for top --call-graph option
was wrongly copied from report command.Signed-off-by: Jiri Olsa
Tested-by: David Ahern
Tested-by: Ingo Molnar
Reviewed-by: David Ahern
Acked-by: Ingo Molnar
Cc: Adrian Hunter
Cc: Andi Kleen
Cc: Corey Ashford
Cc: David Ahern
Cc: Ingo Molnar
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Link: http://lkml.kernel.org/r/1382797536-32303-3-git-send-email-jolsa@redhat.com
Signed-off-by: Arnaldo Carvalho de Melo -
Splitting -g and --call-graph for record command, so we could use '-g'
with no option.The '-g' option now takes NO argument and enables the configured unwind
method, which is currently the frame pointers method.It will be possible to configure unwind method via config file in
upcoming patches.All current '-g' arguments is overtaken by --call-graph option.
Signed-off-by: Jiri Olsa
Tested-by: David Ahern
Tested-by: Ingo Molnar
Reviewed-by: David Ahern
Acked-by: Ingo Molnar
Cc: Adrian Hunter
Cc: Andi Kleen
Cc: Corey Ashford
Cc: David Ahern
Cc: Ingo Molnar
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Link: http://lkml.kernel.org/r/1382797536-32303-2-git-send-email-jolsa@redhat.com
[ reordered -g/--call-graph on --help and expanded the man page
according to comments by David Ahern and Namhyung Kim ]
Signed-off-by: Arnaldo Carvalho de Melo -
Following commit tightened up the buffer size for output to strict width
of used format columns:99cf666 perf hists: Fix formatting of long symbol names
This works fine until you hit color overhead output which places extra
bytes into output buffer. We need to account for color overhead in the
output buffer. Adding maximum color byte size to the output buffer size.Signed-off-by: Jiri Olsa
Cc: Adrian Hunter
Cc: Corey Ashford
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Link: http://lkml.kernel.org/r/1382700293-1803-1-git-send-email-jolsa@redhat.com
Signed-off-by: Arnaldo Carvalho de Melo -
The Intel D410PT(LW) and D425KT Mini-ITX desktop boards both show up as
having LVDS but the hardware is not populated. This patch adds them to
the list of such systems. Patch is against 3.11.4v2: Patch revised to match the D425KT exactly as the D425KTW does have
LVDS. According to Intel's documentation, the D410PTL and D410PLTW
don't.Signed-off-by: Rob Pearce
Cc: stable@vger.kernel.org
[danvet: Pimp commit message to my liking and add cc: stable.]
Signed-off-by: Daniel Vetter -
This isn't a real fix to the problem, but rather a stopgap measure while
trying to find a proper solution.There are several laptops out there that fail to light up the eDP panel
in UEFI boot mode. They seem to be mostly IVB machines, including but
apparently not limited to Dell XPS 13, Asus TX300, Asus UX31A, Asus
UX32VD, Acer Aspire S7. They seem to work in CSM or legacy boot.The difference between UEFI and CSM is that the BIOS provides a
different VBT to the kernel. The UEFI VBT typically specifies 18 bpp and
1.62 GHz link for eDP, while CSM VBT has 24 bpp and 2.7 GHz link. We end
up clamping to 18 bpp in UEFI mode, which we can fit in the 1.62 Ghz
link, and for reasons yet unknown fail to light up the panel.Dithering from 24 to 18 bpp itself seems to work; if we use 18 bpp with
2.7 GHz link, the eDP panel lights up. So essentially this is a link
speed issue, and *not* a bpp clamping issue.The bug raised its head since
commit 657445fe8660100ad174600ebfa61536392b7624
Author: Daniel Vetter
Date: Sat May 4 10:09:18 2013 +0200Revert "drm/i915: revert eDP bpp clamping code changes"
which started clamping bpp *before* computing the link requirements, and
thus affecting the required bandwidth. Clamping after the computations
kept the link at 2.7 GHz.Even though the BIOS tells us to use 18 bpp through the VBT, it happily
boots up at 24 bpp and 2.7 GHz itself! Use this information to
selectively ignore the VBT provided value.We can't ignore the VBT eDP bpp altogether, as there are other laptops
that do require the clamping to be used due to EDID reporting higher bpp
than the panel can support.Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=59841
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67950
Tested-by: Ulf Winkelvos
Tested-by: jkp
CC: stable@vger.kernel.org
Signed-off-by: Jani Nikula
Signed-off-by: Daniel Vetter -
Call intel_ddi_get_config() to get the pipe_bpp settings from
DDI.The sync polarity settings from DDI are irrelevant for CRT
output, so override them with data from the ADPA register.Note: This is already merged in drm-intel-next-queued as
commit 6801c18c0a43386bb44712cbc028a7e05adb9f0d
Author: Ville Syrjälä
Date: Tue Sep 24 14:24:05 2013 +0300drm/i915: Add HSW CRT output readout support
but is required for the following edp bpp bugfix.
v2: Extract intel_crt_get_flags()
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69691
Tested-by: Qingshuai Tian
Signed-off-by: Ville Syrjälä
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter
28 Oct, 2013
6 commits
-
…it/acme/linux into perf/urgent
Pull perf/urgent fixes from Arnaldo Carvalho de Melo:
* Fix up /proc/PID/maps parsing, where perfectly fine mmap entries
were being trown away when synthesizing PERF_RECORD_MMAP for
preexisting threads, prevenging symbol resolution to work
for those threads, broken in the MMAP2 removal. Reported and
pinpointed by Markus Trippelsdorf,* Fix mem leak in the python 'perf script' backend, due to missing Py_DECREFs
on dict entries, fix from Joseph Schuchart.Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org> -
When introducing support for MMAP2 we considered more parts of each map
representation in /proc/PID/maps, and when disabling it we forgot to
reduce the number of expected parsed/assigned entries in the sscanf
call, fix it to expect the right number of desired fields, 5.Reported-by: Markus Trippelsdorf
Based-on-a-patch-by: Markus Trippelsdorf
Cc: Adrian Hunter
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Mike Galbraith
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link: http://lkml.kernel.org/n/tip-vrbo1wik997ahjzl1chm3bdm@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo -
On CTG+ read out the pipe bpp setting from hardware and fill it into
pipe config. Also check it appropriately.v2: Don't do the pipe_bpp extraction inside the PCH only code block on
ILK+.
Avoid the PIPECONF read as we already have read it for the
PIPECONF_EANBLE check.Note: This is already in drm-intel-next-queued as
commit 42571aefafb1d330ef84eb29418832f72e7dfb4c
Author: Ville Syrjälä
Date: Fri Sep 6 23:29:00 2013 +0300drm/i915: Add support for pipe_bpp readout
but is needed for the following bugfix.
Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter -
Pull parisc fix from Helge Deller:
"This is a 2-line patch to save the CPU register which holds our task
thread info pointer before calling a firmware function and then to
restore it again afterwards.This is necessary because on some 64bit machines the high-order 32bits
are being clobbered by the firmware call, and thus we failed to bring
up secondary CPUs (and instead crashed the kernel) in some situations
eg if we had more than 4GB RAM. This patch fixes a bug which has been
since ever in the parisc linux kernel and which prevented some people
to use a 64bit kernel"* 'parisc-3.12' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
parisc: Do not crash 64bit SMP kernels on machines with >= 4GB RAM -
Pull timer fix from Ingo Molnar:
"This tree contains a clockevents regression fix for certain ARM
subarchitectures"* 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
clockevents: Sanitize ticks to nsec conversion
