The per_cpu buffers are created one per possible CPU. But these do
not mean that those CPUs are online, nor do they even exist.
With the addition of the ring buffer polling, it assumes that the
caller polls on an existing buffer. But this is not the case if
the user reads trace_pipe from a CPU that does not exist, and this
causes the kernel to crash.
Simple fix is to check the cpu against buffer bitmask against to see
if the buffer was allocated or not and return -ENODEV if it is
not.
More updates were done to pass the -ENODEV back up to userspace.
Link: http://lkml.kernel.org/r/5393DB61.6060707@oracle.com
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Cc: stable@vger.kernel.org # 3.10+
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Improve error messages of 'perf probe --line' mode.
Currently 'perf probe' shows the "Debuginfo analysis failed" message with
an error code when the given symbol is not found:
-----
# perf probe -L page_cgroup_init_flatmem
Debuginfo analysis failed. (-2)
Error: Failed to show lines.
-----
But -2 (-ENOENT) means that the given source line or function was not
found. With this patch, 'perf probe' shows the correct error message:
-----
# perf probe -L page_cgroup_init_flatmem
Specified source line is not found.
Error: Failed to show lines.
-----
There is also another debug error code is shown in the same function
after get_real_path(). This removes that too.
Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/20140606071406.6788.47850.stgit@kbuild-fedora.novalocal
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
For example,
$ scripts/objdiff record init drivers/usb
disassembles all the objects under init and drivers/usb directories.
This feature would be useful when we change various files under the
specific directory.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Prior to this commit, the command "scripts/objdiff record path/to/*.o"
disassembled the given object into ".tmp_objdiff/path/to/*.o" file.
The problem here is that recorded disassemblies are lost if we run
"make clean" because it removes all the *.o files.
Disassembled code should be dumped into *.dis instead of *.o files.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Prior to this commit, scripts/objdiff expected to be run at the top
directory and only the relative path of objects.
This commit provides more flexibility in terms of object path:
[1] scripts/objdiff can be run in any directory
For example,
$ scripts/objdiff record init/main.o
and
$ cd init; ../scripts/objdiff record main.o
produce the same result.
[2] Support absolute path for objects
$ scripts/objdiff record /home/foo/bar/linux/init/main.o
work as well.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Michal Marek <mmarek@suse.cz>
The directories for objdump is created by the code
a few lines below:
[ ! -d "$OBJDIFFD/$dn" ] && mkdir -p "$OBJDIFFD/$dn"
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Michal Marek <mmarek@suse.cz>
This commit is a minor refactoring.
Temporary files for objdiff are stored in .tmp_objdiff directory
which is located at the top directory.
To get the path to this directory,
SRCTREE=`git rev-parse --show-toplevel`
TMPD=$SRCTREE/.tmp_objdiff
seems easier to understand than
GIT_DIR=`git rev-parse --git-dir`
TMPD=${GIT_DIR%git}tmp_objdiff
Besides, it is not always necessary to create .tmp_objdiff dicrectory.
It should be created only for "record" command.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Michal Marek <mmarek@suse.cz>
The Debian s390x architecture has 64-bit userland whereas s390 has
32-bit userland. A 64-bit kernel can be used with either. Now that
Debian supports multiarch and officially supports s390x, it makes more
sense to assign a 64-bit kernel package to s390x.
Reported-by: Stephen Powell <zlinuxman@wowway.com>
References: https://bugs.debian.org/750925
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Michal Marek <mmarek@suse.cz>
This semantic patch looks for variables that are initialized with a
constant, are never updated, and are only used as parameter of return.
Return the constant instead of using a variable.
Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
airq_iv_(alloc|free) is called by some users with interrupts enabled
and by some with interrupts disabled which leads to the following
lockdep warning:
[ INFO: possible irq lock inversion dependency detected ]
3.14.0-15249-gbf29b7b-dirty #25 Not tainted
---------------------------------------------------------
insmod/2108 just changed the state of lock:
(&(&iv->lock)->rlock){+.....}, at: [<000000000046ee3e>] airq_iv_alloc+0x62/0x228
but this lock was taken by another, HARDIRQ-READ-safe lock in the past:
(&info->lock){.-.-..}
and interrupts could create inverse lock ordering between them.
other info that might help us debug this:
Possible interrupt unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&(&iv->lock)->rlock);
local_irq_disable();
lock(&info->lock);
lock(&(&iv->lock)->rlock);
<Interrupt>
lock(&info->lock);
*** DEADLOCK ***
Although this is a false alarm (since each airq user consistently
calls these functions from the same context) fix this by ensuring
that interrupts are disabled when the airq lock is held.
Reported-by: Frank Blaschka <frank.blaschka@de.ibm.com>
Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Add the LPAR variant of the diag 288 watchdog to the driver.
The only available action on timeout for LPAR is a PSW restart.
Signed-off-by: Philipp Hachtmann <phacht@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Converted the vmwatchdog driver to use the kernel's watchdog API.
Signed-off-by: Philipp Hachtmann <phacht@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
When you want to use the HMC's ASCII console as console device for
a z/VM guest you have to specify console=ttyS1 on the kernel command
line. But it won't work until you specify conmode=sclp as well.
This behavior is inconsistent with the use of the ASCII console as
TTY device which works on z/VM without the need to specify a conmode.
Fix this inconsistency by removing the check for conmode=sclp in the
ASCII console registration function.
Signed-off-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
On systems where a ccw based console device is used a lockdep false alarm
could be triggered when a device driver calls printk while holding a
subchannels lock (e.g. in it's irq handler). Since this is valid behavior
fix this by introducing a separate lock class for the console subchannels
lock.
The lockdep warning was revealed by "printk: enable interrupts before calling
console_trylock_for_printk()" which changed console_unlock() to be called with
lockdep enabled.
[ INFO: possible recursive locking detected ]
3.15.0-rc5-next-20140520 #1 Not tainted
---------------------------------------------
ccwgroup/2239 is trying to acquire lock:
(&(sch->lock)->rlock){-.-...}, at: [<0000000000642a52>] raw3215_write+0x52/0x200
but task is already holding lock:
(&(sch->lock)->rlock){-.-...}, at: [<00000000005fd160>] do_cio_interrupt+0x60/0x108
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&(sch->lock)->rlock);
lock(&(sch->lock)->rlock);
*** DEADLOCK ***
May be due to missing lock nesting notation
8 locks held by ccwgroup/2239:
stack backtrace:
CPU: 3 PID: 2239 Comm: ccwgroup Not tainted 3.15.0-rc5-next-20140520 #1
0000000036fab518 0000000036fab528 0000000000000002 0000000000000000
0000000036fab5b8 0000000036fab530 0000000036fab530 00000000001116e8
0000000000000000 0000000000986ec4 00000000009701b6 000000000000000b
0000000036fab578 0000000036fab518 0000000000000000 0000000000000000
0000000000000000 00000000001116e8 0000000036fab518 0000000036fab578
Call Trace:
([<0000000000111626>] show_trace+0x14e/0x158)
[<000000000011169a>] show_stack+0x6a/0xe8
[<00000000007c6e72>] dump_stack+0x82/0xb0
[<00000000001a95f2>] validate_chain.isra.37+0xa4a/0xbb0
[<00000000001acaca>] __lock_acquire+0x4da/0xcd0
[<00000000001ada1a>] lock_acquire+0xba/0x218
[<00000000007cd634>] _raw_spin_lock_irqsave+0x6c/0xb8
[<0000000000642a52>] raw3215_write+0x52/0x200
[<0000000000643d16>] con3215_write+0x76/0xf8
[<00000000001bd87a>] call_console_drivers.constprop.25+0xfa/0x210
[<00000000001be0b0>] console_unlock+0x3e0/0x4e8
[<00000000001be450>] vprintk_emit+0x298/0x6e0
[<00000000005aa210>] dev_vprintk_emit+0xe0/0x1a8
[<00000000005aa320>] dev_printk_emit+0x48/0x50
[<00000000005aa390>] __dev_printk+0x68/0xb0
[<00000000005aa7c2>] _dev_info+0x62/0x70
[<0000000000657bf0>] qeth_l2_send_setmac_cb+0xd0/0x190
[<0000000000651a1e>] qeth_send_control_data_cb+0x3a6/0x6a8
[<0000000000655546>] qeth_irq+0x1a6/0xac0
[<000000000060a0ac>] ccw_device_call_handler+0xa4/0xc0
[<0000000000608b62>] ccw_device_irq+0x5a/0x190
[<00000000005fd1ca>] do_cio_interrupt+0xca/0x108
[<00000000001c0a2e>] handle_irq_event_percpu+0x5e/0x378
[<00000000001c46fc>] handle_percpu_irq+0x6c/0x98
[<00000000001c0066>] generic_handle_irq+0x46/0x68
[<000000000010b5b6>] do_IRQ+0x5e/0x88
[<00000000007cf304>] io_call+0x6/0x20
[<000000000064c63a>] qeth_send_control_data+0x322/0x570
([<000000000064c50e>] qeth_send_control_data+0x1f6/0x570)
[<0000000000651db2>] qeth_send_ipa_cmd+0x92/0x120
[<000000000065b310>] __qeth_l2_set_online+0x170/0xaa8
[<000000000060ebb6>] ccwgroup_set_online+0x56/0x90
[<000000000060ef96>] ccwgroup_online_store+0xd6/0xe0
[<000000000033d11a>] kernfs_fop_write+0x10a/0x188
[<00000000002bbd00>] vfs_write+0x98/0x1c0
[<00000000002bc8a0>] SyS_write+0x60/0xd0
[<00000000007cee3a>] sysc_nr_ok+0x22/0x28
[<000003fffd0c3f28>] 0x3fffd0c3f28
Reported-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
This patch fixes a problem introduced with git commit beef560b4c
"s390/uaccess: simplify control register updates".
The switch_mm function is not called if the next process is a kernel
thread without an attached mm or is a nop if the mm does not change.
But CR1 still needs to be loaded with the kernel ASCE in case the
code returns to a uaccess function that uses the secondary space mode.
In addition move the set_fs call from finish_arch_switch to
finish_arch_post_lock_switch and then remove finish_arch_switch.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Change the visibility of the module parameters ap_domain_index and
ap_thread_flag for the owner and the members of the owners group in
sysfs.
Previously the parameters where invisible due to a value of zero
as permissions parameter in the module_param_named macro.
Signed-off-by: Michael Veigel <veigel@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
There's really not a great deal this time due to me spending most of this window on Maxwell. But, here's the random bits and pieces that's currently queued.
* 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6: (25 commits)
drm/gk208/gr: add missing registers to grctx init
drm/nouveau/kms/nv04-nv40: fix pageflip events via special case.
drm/nv50-/mc: fix kms pageflip events by reordering irq handling order.
drm/nouveau/disp/nv04-nv40: abort scanoutpos query on vga analog.
drm/nv50-/kms: wait for enough ring space in crtc_prepare()
drm/nouveau/disp/dp: support training pattern 3
drm/nouveau/disp/dp: support aux read interval during link training
drm/gk104/gpio: fix incorrect interrupt register usage
drm/nouveau/core: punt all object state change messages to trace level
drm/nouveau/clk: allow end-user reclocking for nv40, nvaa, and nve0 clock types
drm/nouveau/fb: default NvMemExec to on, turning it off is used for debugging only
drm/nouveau/bios: fix a potential NULL deref in the PROM shadowing function
drm/nouveau/i2c: bump the i2c delay for the adt7473
drm/nouveau/therm/fan/tach: default to 2 pulses per revolution
drm/nvf0/device: enable video decoding engines on gk110/gk208
drm/nvf1/device: add support for 0xf1 (gk110b)
drm/nouveau/device: support for probing GK20A
drm/nouveau/graph: add GK20A support
drm/nouveau/graph: pad firmware code at load time
drm/nouveau/graph: enable when using external fw
...
Cards with nv04 display engine can't reliably use vblank
counts and timestamps computed via drm_handle_vblank(), as
the function gets invoked after sending the pageflip events.
Fix this by defaulting to the old crtcid = -1 fallback path
on <= NV-50 cards, and only using the precise path on NV-50
and later.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Cc: <stable@vger.kernel.org> # 3.13+
Whenever a single nouveau_mc_intr() main gpu irq-handler invocation was
responsible for calling both, the vblank-irq handler (display engine irq)
and kms-pageflip completion handler (from fifo irq), the order of
invocation was wrong. nouveau_finish_flip() was called before
drm_handle_vblank() for the vblank of pageflip completion, so the
emitted pageflip event contained stale vblank count and timestamp
from previous vblank. This caused failure in userspace to timestamp
properly.
Reorder order of invocation of engine irq handlers: Put
NVDEV_ENGINE_DISP always on top, and thereby before NVDEV_ENGINE_FIFO,
so that drm_handle_vblank() gets called to update vblank timestamps
and count before potential pageflip events make use of that
information.
This works on nv-50 and later, where kms-pageflip completion triggers
an irq either after a separate vblank irq, or both pageflip and vblank
trigger one common irq invocation, but never before vblank irqs.
v2 (Ben):
- removed mods for nv04-nv40, it doesn't help there anyway
- this is considered a hack, and a better solution should be found
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Cc: <stable@vger.kernel.org> # 3.13+
nv04_disp_scanoutpos() must abort to trigger simple timestamping
fallback if vtotal/htotal regs return zero. This happens if the
output isn't a digital output, but a vga analog output, as the
regs don't get initialized in that case.
Fixes timestamping failure on nv-40 and earlier with vga output.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Cc: <stable@vger.kernel.org> # 3.14+
Some adt7473 can't manage the 20µs delay we use for the bitbanging, bumping
it to 40µs seem to do the trick.
Signed-off-by: Martin Peres <martin.peres@free.fr>
Tested-by: Marcel Dopita <mdop@seznam.cz>
I spent some time this weekend trying to find in the vbios the number of
pulses per revolutions in the vbios but couldn't find it. It would seem
all my cards have 2 pulses per revolution so let's stick to that until
further notice.
Thermal table's id 0x48 may indicate this information but it would seem
that changing the value results in the blob power or clock gating the
RPM counter... We should ask NVIDIA about that, should be trivial-enough
for them to answer.
Signed-off-by: Martin Peres <martin.peres@free.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Set the correct subdev/engine classes when GK20A (0xea) is probed.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Add a GR device for GK20A based on NVE4, with the correct classes
definitions (GK20A's 3D class is 0xa297).
Most of the NVE4 code can be used on GK20A, so make relevant bits of
NVE4 available to other chips as well.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Pad the microcode to a multiple of 0x40 words, otherwise firmware will
fail to run from non-prepadded firmware files.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
nvc0_graph_ctor() would only let the graphics engine be enabled if its
oclass has a proper microcode linked to it. This prevents GR from being
enabled at all on chips that rely exclusively on external firmware, even
though such a use-case is valid.
Relax the conditions enabling the GR engine to also include the case
where an external firmware has also been loaded.
Also switch to external firmware if the graph class has no microcode
linked to it.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
GK20A's FIFO is compatible with NVE0, but only features 128 channels and
1 runlist.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Add a simple FB device for GK20A, as well as a RAM implementation
suitable for chips that use system memory as video RAM.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Add support for initializing the priv ring of GK20A. This is done by the
BIOS on desktop GPUs, but needs to be done by hand on Tegra.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Adapt the NVC0 BAR driver to make it able to support chips that do not
expose a BAR3. When this happens, BAR1 is then used for USERD mapping
and the BAR alloc() functions is disabled, making GPU objects unable
to rely on BAR for data access and falling back to PRAMIN.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Some chips that use system memory exclusively (e.g. GK20A) do not
expose 2 BAR regions. For them only BAR1 exists, and it should be used
for USERD mapping. Do not map BAR3 if its resource does not exist.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This patch fixes a iscsi_queue_req memory leak when ABORT_TASK response
has been queued by TFO->queue_tm_rsp() -> lio_queue_tm_rsp() after a
long standing I/O completes, but the connection has already reset and
waiting for cleanup to complete in iscsit_release_commands_from_conn()
-> transport_generic_free_cmd() -> transport_wait_for_tasks() code.
It moves iscsit_free_queue_reqs_for_conn() after the per-connection command
list has been released, so that the associated se_cmd tag can be completed +
released by target-core before freeing any remaining iscsi_queue_req memory
for the connection generated by lio_queue_tm_rsp().
Cc: Thomas Glanzmann <thomas@glanzmann.de>
Cc: Charalampos Pournaris <charpour@gmail.com>
Cc: stable@vger.kernel.org # 3.10+
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
This patch fixes a bug where multiple waiters on ->t_transport_stop_comp
occurs due to a concurrent ABORT_TASK and session reset both invoking
transport_wait_for_tasks(), while waiting for the associated se_cmd
descriptor backend processing to complete.
For this case, complete_all() should be invoked in order to wake up
both waiters in core_tmr_abort_task() + transport_generic_free_cmd()
process contexts.
Cc: Thomas Glanzmann <thomas@glanzmann.de>
Cc: Charalampos Pournaris <charpour@gmail.com>
Cc: stable@vger.kernel.org # 3.10+
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
