| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into HEAD
KVM: s390: Fix for master (4.12)
- The newly created AIS capability enables the feature unconditionally
and ignores the cpu model
|
|
Christoph writes:
"A few NVMe fixes for 4.12-rc, PCIe reset fixes and APST fixes, a
RDMA reconnect fix, two FC fixes and a general controller removal fix."
|
|
drivers/gpu/drm/i915/intel_engine_cs.c: In function ‘intel_engine_is_idle’:
drivers/gpu/drm/i915/intel_engine_cs.c:1103:27: error: unused variable ‘dev_priv’ [-Werror=unused-variable]
struct drm_i915_private *dev_priv = engine->i915;
^~~~~~~~
Reviewed-by: Chris Wilson <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
|
|
While installing SLES-12 (based on v4.4), I found that the installer
will stall for 60+ seconds during LVM disk scan. The root cause was
determined to be the removal of a bound device check in loop_flush()
by commit b5dd2f6047ca ("block: loop: improve performance via blk-mq").
Restoring this check, examining ->lo_state as set by loop_set_fd()
eliminates the bad behavior.
Test method:
modprobe loop max_loop=64
dd if=/dev/zero of=disk bs=512 count=200K
for((i=0;i<4;i++))do losetup -f disk; done
mkfs.ext4 -F /dev/loop0
for((i=0;i<4;i++))do mkdir t$i; mount /dev/loop$i t$i;done
for f in `ls /dev/loop[0-9]*|sort`; do \
echo $f; dd if=$f of=/dev/null bs=512 count=1; \
done
Test output: stock patched
/dev/loop0 18.1217e-05 8.3842e-05
/dev/loop1 6.1114e-05 0.000147979
/dev/loop10 0.414701 0.000116564
/dev/loop11 0.7474 6.7942e-05
/dev/loop12 0.747986 8.9082e-05
/dev/loop13 0.746532 7.4799e-05
/dev/loop14 0.480041 9.3926e-05
/dev/loop15 1.26453 7.2522e-05
Note that from loop10 onward, the device is not mounted, yet the
stock kernel consumes several orders of magnitude more wall time
than it does for a mounted device.
(Thanks for Mike Galbraith <[email protected]>, give a changelog review.)
Reviewed-by: Hannes Reinecke <[email protected]>
Reviewed-by: Ming Lei <[email protected]>
Signed-off-by: James Wang <[email protected]>
Fixes: b5dd2f6047ca ("block: loop: improve performance via blk-mq")
Signed-off-by: Jens Axboe <[email protected]>
|
|
If "i" is the last element in the vcpu->arch.cpuid_entries[] array, it
potentially can be exploited the vulnerability. this will out-of-bounds
read and write. Luckily, the effect is small:
/* when no next entry is found, the current entry[i] is reselected */
for (j = i + 1; ; j = (j + 1) % nent) {
struct kvm_cpuid_entry2 *ej = &vcpu->arch.cpuid_entries[j];
if (ej->function == e->function) {
It reads ej->maxphyaddr, which is user controlled. However...
ej->flags |= KVM_CPUID_FLAG_STATE_READ_NEXT;
After cpuid_entries there is
int maxphyaddr;
struct x86_emulate_ctxt emulate_ctxt; /* 16-byte aligned */
So we have:
- cpuid_entries at offset 1B50 (6992)
- maxphyaddr at offset 27D0 (6992 + 3200 = 10192)
- padding at 27D4...27DF
- emulate_ctxt at 27E0
And it writes in the padding. Pfew, writing the ops field of emulate_ctxt
would have been much worse.
This patch fixes it by modding the index to avoid the out-of-bounds
access. Worst case, i == j and ej->function == e->function,
the loop can bail out.
Reported-by: Moguofang <[email protected]>
Cc: Paolo Bonzini <[email protected]>
Cc: Radim Krčmář <[email protected]>
Cc: Guofang Mo <[email protected]>
Cc: [email protected]
Signed-off-by: Wanpeng Li <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD
KVM/ARM Fixes for v4.12-rc5 - Take 2
Changes include:
- Fix an issue with migrating GICv2 VMs on GICv3 systems.
- Squashed a bug for gicv3 when figuring out preemption levels.
- Fix a potential null pointer derefence in KVM happening under memory
pressure.
- Maintain RES1 bits in the SCTLR_EL2 to make sure KVM works on new
architecture revisions.
- Allow unaligned accesses at EL2/HYP
|
|
The PPC_DT_CPU_FTRs is a bit misplaced in menuconfig, it shows up with
other general kernel options. It's really more at home in the "Platform
Support" section, so move it there.
Also enable it by default, for Book3s 64. It does mostly nothing unless
the device tree properties are found, and we will want it enabled
eventually in distro kernels, so turn it on to start getting more
testing.
Fixes: 5a61ef74f269 ("powerpc/64s: Support new device tree binding for discovering CPU features")
Signed-off-by: Michael Ellerman <[email protected]>
|
|
Supporting 512TB requires us to do a order 3 allocation for level 1 page
table (pgd). This results in page allocation failures with certain workloads.
For now limit 4k linux page size config to 64TB.
Fixes: f6eedbba7a26 ("powerpc/mm/hash: Increase VA range to 128TB")
Reported-by: Hugh Dickins <[email protected]>
Signed-off-by: Aneesh Kumar K.V <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
|
|
Fix error path if we can't copy user structure on CXL_IOCTL_START_WORK
ioctl. We shouldn't unlock the context status mutex as it was not
locked (yet).
Fixes: 0712dc7e73e5 ("cxl: Fix issues when unmapping contexts")
Cc: [email protected] # v3.19+
Signed-off-by: Frederic Barrat <[email protected]>
Reviewed-by: Vaibhav Jain <[email protected]>
Reviewed-by: Andrew Donnellan <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
|
|
This reverts commit cf39bf58afdaabc0b86f141630fb3fd18190294e.
The commit regression to users that define both console=ttyS1
and console=ttyS0 on the command line, see
https://lkml.kernel.org/r/[email protected]
The kernel log messages always appeared only on one serial port. It is
even documented in Documentation/admin-guide/serial-console.rst:
"Note that you can only define one console per device type (serial,
video)."
The above mentioned commit changed the order in which the command line
parameters are searched. As a result, the kernel log messages go to
the last mentioned ttyS* instead of the first one.
We long thought that using two console=ttyS* on the command line
did not make sense. But then we realized that console= parameters
were handled also by systemd, see
http://0pointer.de/blog/projects/serial-console.html
"By default systemd will instantiate one [email protected] on
the main kernel console, if it is not a virtual terminal."
where
"[4] If multiple kernel consoles are used simultaneously, the main
console is the one listed first in /sys/class/tty/console/active,
which is the last one listed on the kernel command line."
This puts the original report into another light. The system is running
in qemu. The first serial port is used to store the messages into a file.
The second one is used to login to the system via a socket. It depends
on systemd and the historic kernel behavior.
By other words, systemd causes that it makes sense to define both
console=ttyS1 console=ttyS0 on the command line. The kernel fix
caused regression related to userspace (systemd) and need to be
reverted.
In addition, it went out that the fix helped only partially.
The messages still were duplicated when the boot console was
removed early by late_initcall(printk_late_init). Then the entire
log was replayed when the same console was registered as a normal one.
Link: [email protected]
Cc: Aleksey Makarov <[email protected]>
Cc: Sabrina Dubroca <[email protected]>
Cc: Sudeep Holla <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Peter Hurley <[email protected]>
Cc: Jiri Slaby <[email protected]>
Cc: Robin Murphy <[email protected]>,
Cc: Steven Rostedt <[email protected]>
Cc: "Nair, Jayachandran" <[email protected]>
Cc: [email protected]
Cc: [email protected]
Reported-by: Sabrina Dubroca <[email protected]>
Acked-by: Sergey Senozhatsky <[email protected]>
Signed-off-by: Petr Mladek <[email protected]>
|
|
When doing sampling, for example:
perf record -e cycles:u ...
On workloads that do a lot of kernel entry/exits we see kernel
samples, even though :u is specified. This is due to skid existing.
This might be a security issue because it can leak kernel addresses even
though kernel sampling support is disabled.
The patch drops the kernel samples if exclude_kernel is specified.
For example, test on Haswell desktop:
perf record -e cycles:u <mgen>
perf report --stdio
Before patch applied:
99.77% mgen mgen [.] buf_read
0.20% mgen mgen [.] rand_buf_init
0.01% mgen [kernel.vmlinux] [k] apic_timer_interrupt
0.00% mgen mgen [.] last_free_elem
0.00% mgen libc-2.23.so [.] __random_r
0.00% mgen libc-2.23.so [.] _int_malloc
0.00% mgen mgen [.] rand_array_init
0.00% mgen [kernel.vmlinux] [k] page_fault
0.00% mgen libc-2.23.so [.] __random
0.00% mgen libc-2.23.so [.] __strcasestr
0.00% mgen ld-2.23.so [.] strcmp
0.00% mgen ld-2.23.so [.] _dl_start
0.00% mgen libc-2.23.so [.] sched_setaffinity@@GLIBC_2.3.4
0.00% mgen ld-2.23.so [.] _start
We can see kernel symbols apic_timer_interrupt and page_fault.
After patch applied:
99.79% mgen mgen [.] buf_read
0.19% mgen mgen [.] rand_buf_init
0.00% mgen libc-2.23.so [.] __random_r
0.00% mgen mgen [.] rand_array_init
0.00% mgen mgen [.] last_free_elem
0.00% mgen libc-2.23.so [.] vfprintf
0.00% mgen libc-2.23.so [.] rand
0.00% mgen libc-2.23.so [.] __random
0.00% mgen libc-2.23.so [.] _int_malloc
0.00% mgen libc-2.23.so [.] _IO_doallocbuf
0.00% mgen ld-2.23.so [.] do_lookup_x
0.00% mgen ld-2.23.so [.] open_verify.constprop.7
0.00% mgen ld-2.23.so [.] _dl_important_hwcaps
0.00% mgen libc-2.23.so [.] sched_setaffinity@@GLIBC_2.3.4
0.00% mgen ld-2.23.so [.] _start
There are only userspace symbols.
Signed-off-by: Jin Yao <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Cc: <[email protected]>
Cc: Alexander Shishkin <[email protected]>
Cc: Arnaldo Carvalho de Melo <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Stephane Eranian <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Vince Weaver <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
|
|
During early boot, load_ucode_intel_ap() uses __load_ucode_intel()
to obtain a pointer to the relevant microcode patch (embedded in the
initrd), and stores this value in 'intel_ucode_patch' to speed up the
microcode patch application for subsequent CPUs.
On resuming from suspend-to-RAM, however, load_ucode_ap() calls
load_ucode_intel_ap() for each non-boot-CPU. By then the initramfs is
long gone so the pointer stored in 'intel_ucode_patch' no longer points to
a valid microcode patch.
Clear that pointer so that we effectively fall back to the CPU hotplug
notifier callbacks to update the microcode.
Signed-off-by: Dominik Brodowski <[email protected]>
[ Edit and massage commit message. ]
Signed-off-by: Borislav Petkov <[email protected]>
Cc: <[email protected]> # 4.10..
Cc: Linus Torvalds <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
|
|
I will be traveling in the upcoming months and it'll be much easier for me
to access my kernel.org email rather than my work one. Change my email
address in the MAINTAINERS file from [email protected] to [email protected].
Signed-off-by: Jessica Yu <[email protected]>
|
|
It's possible that get_random_{u32,u64} is used before the crng has
initialized, in which case, its output might not be cryptographically
secure. For this problem, directly, this patch set is introducing the
*_wait variety of functions, but even with that, there's a subtle issue:
what happens to our batched entropy that was generated before
initialization. Prior to this commit, it'd stick around, supplying bad
numbers. After this commit, we force the entropy to be re-extracted
after each phase of the crng has initialized.
In order to avoid a race condition with the position counter, we
introduce a simple rwlock for this invalidation. Since it's only during
this awkward transition period, after things are all set up, we stop
using it, so that it doesn't have an impact on performance.
Signed-off-by: Jason A. Donenfeld <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Theodore Ts'o <[email protected]>
Cc: [email protected] # v4.11+
|
|
Few shell command examples in perf-script-python.txt has few nitpicks
include:
- tools/perf/scripts/python directory listing command is unnecessarily
repeated.
- few examples contain additional information in command prompt
unnecessarily and inconsistently.
This commit fixes them to enhance readability of the document.
Signed-off-by: SeongJae Park <[email protected]>
Cc: Alexander Shishkin <[email protected]>
Cc: Frederic Weisbecker <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Tom Zanussi <[email protected]>
Fixes: cff68e582237 ("perf/scripts: Add perf-trace-python Documentation")
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
|
|
Default function signature of trace_unhandled() got changed to include a
field dict, but its documentation, perf-script-python.txt has not been
updated. Fix it.
Signed-off-by: SeongJae Park <[email protected]>
Cc: Alexander Shishkin <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Pierre Tardy <[email protected]>
Fixes: c02514850d67 ("perf scripts python: Give field dict to unhandled callback")
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
|
|
This commit fixes wrong code snippets for trace_begin() and trace_end()
function example definition.
Signed-off-by: SeongJae Park <[email protected]>
Cc: Alexander Shishkin <[email protected]>
Cc: Frederic Weisbecker <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Tom Zanussi <[email protected]>
Fixes: cff68e582237 ("perf/scripts: Add perf-trace-python Documentation")
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
|
|
This commit fixes two errors in documents for perf-script-python and
perf-script-perl as below:
- /sys/kernel/debug/tracing events -> /sys/kernel/debug/tracing/events/
- trace_handled -> trace_unhandled
Signed-off-by: SeongJae Park <[email protected]>
Cc: Alexander Shishkin <[email protected]>
Cc: Frederic Weisbecker <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Tom Zanussi <[email protected]>
Fixes: cff68e582237 ("perf/scripts: Add perf-trace-python Documentation")
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
|
|
Script generated by the '--gen-script' option contains an outdated
comment. It mentions a 'perf-trace-python' document while it has been
renamed to 'perf-script-python'. Fix it.
Signed-off-by: SeongJae Park <[email protected]>
Cc: Alexander Shishkin <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Fixes: 133dc4c39c57 ("perf: Rename 'perf trace' to 'perf script'")
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
|
|
An example in perf-probe documentation for pattern of function name
based probe addition is not providing example command for that case.
This commit fixes the example to give appropriate example command.
Signed-off-by: SeongJae Park <[email protected]>
Acked-by: Masami Hiramatsu <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Taeung Song <[email protected]>
Fixes: ee391de876ae ("perf probe: Update perf probe document")
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
|
|
Linus pointed out that there is a much more efficient way of avoiding
the problem that we were trying to address in commit 9dfa7bba35ac0:
"fix race in drivers/char/random.c:get_reg()".
Signed-off-by: Theodore Ts'o <[email protected]>
|
|
The Lifebook E546 and E557 touchpad were also not functioning and
worked after running:
echo "1" > /sys/devices/platform/i8042/serio2/crc_enabled
Add them to the list of machines that need this workaround.
Signed-off-by: Ulrik De Bie <[email protected]>
Reviewed-by: Arjan Opmeer <[email protected]>
Cc: [email protected]
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent
Pull perf/urgent fixes from Arnaldo Carvalho de Melo:
- Only print NMI watchdog hint in 'perf stat' when it is enabled (Andi Kleen)
- Fix sys_mmap/sys_old_mmap shandling in s390 in 'perf trace' (Jiri Olsa)
- Disable breakpoint signal tests in powerpc, that lacks the perf kernel
glue to set breakpoint events and makes 'perf test' always fail (Jiri Olsa)
- Fix 'perf annotate' for branch instruction with multiple operands (Kim Phillips)
- Add missing powerpc triplet when disassembling with 'objdump' in 'perf
annotate' (Kim Phillips)
- Do not trow away partial unwound stacks when using libdw, making
callchains produced with it similar to those produced when linked with
the other DWARF unwind library supported in perf, libunwind (Milian Wolff)
- Fixes to properly handle kernel modules when processing build-id meta
events (Namhyung Kim)
- Fix handling of compressed modules in the build-id cache (Namhyung Kim)
- Fix 'perf annotate' failure when filename has special chars (Ravi Bangoria)
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
|
|
hard disk IO latency varies a lot depending on spindle move. The latency
range could be from several microseconds to several milliseconds. It's
pretty hard to get the baseline latency used by io.low.
We will use a different stragety here. The idea is only using IO with
spindle move to determine if cgroup IO is in good state. For HD, if io
latency is small (< 1ms), we ignore the IO. Such IO is likely from
sequential IO, and is helpless to help determine if a cgroup's IO is
impacted by other cgroups. With this, we only account IO with big
latency. Then we can choose a hardcoded baseline latency for HD (4ms,
which is typical IO latency with seek). With all these settings, the
io.low latency works for both HD and SSD.
Signed-off-by: Shaohua Li <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
|
|
While introducing HDMI support, component matching on connectors node
were bypassed since no driver would actually bind on the DT node.
But when only a CVBS connector is present, only a single node is found
in the graph, but ignored and a NULL match table is given to the
component code.
This code permits bypassing the components framework by binding directly
the DRM driver when no components needs to be loaded.
Fixes: a41e82e6c457 ("drm/meson: Add support for components")
Signed-off-by: Neil Armstrong <[email protected]>
Signed-off-by: Sean Paul <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
I have encountered a NULL pointer dereference in
throtl_schedule_pending_timer:
[ 413.735396] BUG: unable to handle kernel NULL pointer dereference at 0000000000000038
[ 413.735535] IP: [<ffffffff812ebbbf>] throtl_schedule_pending_timer+0x3f/0x210
[ 413.735643] PGD 22c8cf067 PUD 22cb34067 PMD 0
[ 413.735713] Oops: 0000 [#1] SMP
......
This is caused by the following case:
blk_throtl_bio
throtl_schedule_next_dispatch <= sq is top level one without parent
throtl_schedule_pending_timer
sq_to_tg(sq)->td->throtl_slice <= sq_to_tg(sq) returns NULL
Fix it by using sq_to_td instead of sq_to_tg(sq)->td, which will always
return a valid td.
Fixes: 297e3d854784 ("blk-throttle: make throtl_slice tunable")
Signed-off-by: Joseph Qi <[email protected]>
Reviewed-by: Shaohua Li <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
|
|
The clipped src coordinates have already been rotated by 270 degrees for
when the plane rotation is 90/270 degrees, hence the FBC code should no
longer swap the width and height.
Cc: [email protected]
Cc: Tvrtko Ursulin <[email protected]>
Cc: Paulo Zanoni <[email protected]>
Fixes: b63a16f6cd89 ("drm/i915: Compute display surface offset in the plane check hook for SKL+")
Signed-off-by: Ville Syrjälä <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Paulo Zanoni <[email protected]>
Tested-by: Tvrtko Ursulin <[email protected]>
Reviewed-by: Maarten Lankhorst <[email protected]>
(cherry picked from commit 73714c05df97d7527e7eaaa771472ef2ede46fa3)
Signed-off-by: Jani Nikula <[email protected]>
|
|
Restore the lost has_fbc flag for mobile ILK.
Cc: Carlos Santa <[email protected]>
Cc: Rodrigo Vivi <[email protected]>
Fixes: a13233804686 ("drm/i915: Introduce GEN5_FEATURES for device info")
Signed-off-by: Ville Syrjälä <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Rodrigo Vivi <[email protected]>
(cherry picked from commit c2d1a0ced2603c4a17fa9c53c37e415905cf5a6d)
Signed-off-by: Jani Nikula <[email protected]>
|
|
The scanline counter is bonkers on VLV/CHV DSI. The scanline counter
increment is not lined up with the start of vblank like it is on
every other platform and output type. This causes problems for
both the vblank timestamping and atomic update vblank evasion.
On my FFRD8 machine at least, the scanline counter increment
happens about 1/3 of a scanline ahead of the start of vblank (which
is where all register latching happens still). That means we can't
trust the scanline counter to tell us whether we're in vblank or not
while we're on that particular line. In order to keep vblank
timestamping in working condition when called from the vblank irq,
we'll leave scanline_offset at one, which means that the entire
line containing the start of vblank is considered to be inside
the vblank.
For the vblank evasion we'll need to consider that entire line
to be bad, since we can't tell whether the registers already
got latched or not. And we can't actually use the start of vblank
interrupt to get us past that line as the interrupt would fire
too soon, and then we'd up waiting for the next start of vblank
instead. One way around that would using the frame start
interrupt instead since that wouldn't fire until the next
scanline, but that would require some bigger changes in the
interrupt code. So for simplicity we'll just poll until we get
past the bad line.
v2: Adjust the comments a bit
Cc: [email protected]
Cc: Jonas Aaberg <[email protected]>
Tested-by: Jonas Aaberg <[email protected]>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99086
Signed-off-by: Ville Syrjälä <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Tested-by: Mika Kahola <[email protected]>
Reviewed-by: Mika Kahola <[email protected]>
(cherry picked from commit ec1b4ee2834e66884e5b0d3d465f347ff212e372)
Signed-off-by: Jani Nikula <[email protected]>
|
|
The assertion that we want to make before disabling the pin of the pages
for the unknown swizzling quirk is that the quirk is indeed active, and
that the quirk is disabled before we do apply it to the pages.
Fixes: 2c3a3f44dc13 ("drm/i915: Fix pages pin counting around swizzle quirk")
Fixes: 957870f93412 ("drm/i915: Split out i915_gem_object_set_tiling()")
Signed-off-by: Chris Wilson <[email protected]>
Cc: Chris Wilson <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Cc: Tvrtko Ursulin <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-bhy: Joonas Lahtinen <[email protected]>
(cherry picked from commit 20bb377106af69d16269b1837e9a945b9f508a2e)
Signed-off-by: Jani Nikula <[email protected]>
|
|
Commit 7c3f86b6dc51 ("drm/i915: Invalidate the guc ggtt TLB upon
insertion") added the restoration of the invalidation routine after the
GuC was disabled, but missed that the GuC was unconditionally disabled
when not used. This then overwrites the invalidate routine for the older
chipsets, causing havoc and breaking resume as the most obvious victim.
We place the guard inside i915_ggtt_disable_guc() to be backport
friendly (the bug was introduced into v4.11) but it would be preferred
to be in more control over when this was guard (i.e. do not try and
teardown the data structures before we have enabled them). That should
be true with the reorganisation of the guc loaders.
Reported-by: Ville Syrjälä <[email protected]>
Signed-off-by: Chris Wilson <[email protected]>
Fixes: 7c3f86b6dc51 ("drm/i915: Invalidate the guc ggtt TLB upon insertion")
Cc: Tvrtko Ursulin <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Cc: Oscar Mateo <[email protected]>
Cc: Daniele Ceraolo Spurio <[email protected]>
Cc: Michal Wajdeczko <[email protected]>
Cc: Arkadiusz Hiler <[email protected]>
Cc: <[email protected]> # v4.11+
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Michel Thierry <[email protected]>
(cherry picked from commit cb60606d835ca8b2f744835116bcabe64ce88849)
Signed-off-by: Jani Nikula <[email protected]>
|
|
On some systems there can be a race condition in which no crtc state is
added to the first atomic commit. This results in all crtc's having a
null DDB allocation, causing a FIFO underrun on any update until the
first modeset.
Changes since v1:
- Do not take the connection_mutex, this is already done below.
Reported-by: Maarten Lankhorst <[email protected]>
Inspired-by: Mahesh Kumar <[email protected]>
Signed-off-by: Maarten Lankhorst <[email protected]>
Fixes: 98d39494d375 ("drm/i915/gen9: Compute DDB allocation at atomic
check time (v4)")
Cc: <[email protected]> # v4.8+
Cc: Mahesh Kumar <[email protected]>
Cc: Matt Roper <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Mahesh Kumar <[email protected]>
Reviewed-by: Matt Roper <[email protected]>
(cherry picked from commit 367d73d2806085bb507ab44c1f532640917fd5ca)
Signed-off-by: Jani Nikula <[email protected]>
|
|
Since
commit bac2a909a096c9110525c18cbb8ce73c660d5f71
Author: Rafael J. Wysocki <[email protected]>
Date: Wed Jan 21 02:17:42 2015 +0100
PCI / PM: Avoid resuming PCI devices during system suspend
PCI devices will default to allowing the system suspend complete
optimization where devices are not woken up during system suspend if
they were already runtime suspended. This however breaks the i915/HDA
drivers for two reasons:
- The i915 driver has system suspend specific steps that it needs to
run, that bring the device to a different state than its runtime
suspended state.
- The HDA driver's suspend handler requires power that it will request
from the i915 driver's power domain handler. This in turn requires the
i915 driver to runtime resume itself, but this won't be possible if the
suspend complete optimization is in effect: in this case the i915
runtime PM is disabled and trying to get an RPM reference returns
-EACCESS.
Solve this by requiring the PCI/PM core to resume the device during
system suspend which in effect disables the suspend complete optimization.
Regardless of the above commit the optimization stayed disabled for DRM
devices until
commit d14d2a8453d650bea32a1c5271af1458cd283a0f
Author: Lukas Wunner <[email protected]>
Date: Wed Jun 8 12:49:29 2016 +0200
drm: Remove dev_pm_ops from drm_class
so this patch is in practice a fix for this commit. Another reason for
the bug staying hidden for so long is that the optimization for a device
is disabled if it's disabled for any of its children devices. i915 may
have a backlight device as its child which doesn't support runtime PM
and so doesn't allow the optimization either. So if this backlight
device got registered the bug stayed hidden.
Credits to Marta, Tomi and David who enabled pstore logging,
that caught one instance of this issue across a suspend/
resume-to-ram and Ville who rememberd that the optimization was enabled
for some devices at one point.
The first WARN triggered by the problem:
[ 6250.746445] WARNING: CPU: 2 PID: 17384 at drivers/gpu/drm/i915/intel_runtime_pm.c:2846 intel_runtime_pm_get+0x6b/0xd0 [i915]
[ 6250.746448] pm_runtime_get_sync() failed: -13
[ 6250.746451] Modules linked in: snd_hda_intel i915 vgem snd_hda_codec_hdmi x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul
snd_hda_codec_realtek snd_hda_codec_generic ghash_clmulni_intel e1000e snd_hda_codec snd_hwdep snd_hda_core ptp mei_me pps_core snd_pcm lpc_ich mei prime_
numbers i2c_hid i2c_designware_platform i2c_designware_core [last unloaded: i915]
[ 6250.746512] CPU: 2 PID: 17384 Comm: kworker/u8:0 Tainted: G U W 4.11.0-rc5-CI-CI_DRM_334+ #1
[ 6250.746515] Hardware name: /NUC5i5RYB, BIOS RYBDWi35.86A.0362.2017.0118.0940 01/18/2017
[ 6250.746521] Workqueue: events_unbound async_run_entry_fn
[ 6250.746525] Call Trace:
[ 6250.746530] dump_stack+0x67/0x92
[ 6250.746536] __warn+0xc6/0xe0
[ 6250.746542] ? pci_restore_standard_config+0x40/0x40
[ 6250.746546] warn_slowpath_fmt+0x46/0x50
[ 6250.746553] ? __pm_runtime_resume+0x56/0x80
[ 6250.746584] intel_runtime_pm_get+0x6b/0xd0 [i915]
[ 6250.746610] intel_display_power_get+0x1b/0x40 [i915]
[ 6250.746646] i915_audio_component_get_power+0x15/0x20 [i915]
[ 6250.746654] snd_hdac_display_power+0xc8/0x110 [snd_hda_core]
[ 6250.746661] azx_runtime_resume+0x218/0x280 [snd_hda_intel]
[ 6250.746667] pci_pm_runtime_resume+0x76/0xa0
[ 6250.746672] __rpm_callback+0xb4/0x1f0
[ 6250.746677] ? pci_restore_standard_config+0x40/0x40
[ 6250.746682] rpm_callback+0x1f/0x80
[ 6250.746686] ? pci_restore_standard_config+0x40/0x40
[ 6250.746690] rpm_resume+0x4ba/0x740
[ 6250.746698] __pm_runtime_resume+0x49/0x80
[ 6250.746703] pci_pm_suspend+0x57/0x140
[ 6250.746709] dpm_run_callback+0x6f/0x330
[ 6250.746713] ? pci_pm_freeze+0xe0/0xe0
[ 6250.746718] __device_suspend+0xf9/0x370
[ 6250.746724] ? dpm_watchdog_set+0x60/0x60
[ 6250.746730] async_suspend+0x1a/0x90
[ 6250.746735] async_run_entry_fn+0x34/0x160
[ 6250.746741] process_one_work+0x1f2/0x6d0
[ 6250.746749] worker_thread+0x49/0x4a0
[ 6250.746755] kthread+0x107/0x140
[ 6250.746759] ? process_one_work+0x6d0/0x6d0
[ 6250.746763] ? kthread_create_on_node+0x40/0x40
[ 6250.746768] ret_from_fork+0x2e/0x40
[ 6250.746778] ---[ end trace 102a62fd2160f5e6 ]---
v2:
- Use the new pci_dev->needs_resume flag, to avoid any overhead during
the ->pm_prepare hook. (Rafael)
v3:
- Update commit message to reference the actual regressing commit.
(Lukas)
v4:
- Rebase on v4 of patch 1/2.
Fixes: d14d2a8453d6 ("drm: Remove dev_pm_ops from drm_class")
References: https://bugs.freedesktop.org/show_bug.cgi?id=100378
References: https://bugs.freedesktop.org/show_bug.cgi?id=100770
Cc: Rafael J. Wysocki <[email protected]>
Cc: Marta Lofstedt <[email protected]>
Cc: David Weinehall <[email protected]>
Cc: Tomi Sarvela <[email protected]>
Cc: Ville Syrjälä <[email protected]>
Cc: Mika Kuoppala <[email protected]>
Cc: Chris Wilson <[email protected]>
Cc: Takashi Iwai <[email protected]>
Cc: Bjorn Helgaas <[email protected]>
Cc: Lukas Wunner <[email protected]>
Cc: [email protected]
Cc: <[email protected]> # v4.10.x: 4d071c3 - PCI/PM: Add needs_resume flag
Cc: <[email protected]> # v4.10.x
Signed-off-by: Imre Deak <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Reported-and-tested-by: Marta Lofstedt <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit adfdf85d795f4d4f487b61ee0b169d64c6e19081)
Signed-off-by: Jani Nikula <[email protected]>
|
|
psr1 is also disabled for panel resolution greater than 32X20.
Added psr2 check to disable only for psr2 panels having resolution
greater than 32X20.
issue was introduced by
commit-id : "acf45d11050abd751dcec986ab121cb2367dcbba"
commit message: "PSR2 is restricted to work with panel resolutions
upto 3200x2000, move the check to intel_psr_match_conditions and fully
block psr."
v2: (Rodrigo)
Add previous commit details which introduced the issue
Fixes: acf45d11050a ("drm/i915/psr: disable psr2 for resolution greater than 32X20")
Cc: Rodrigo Vivi <[email protected]>
Cc: Jim Bride <[email protected]>
Cc: Yaroslav Shabalin <[email protected]>
Reported-by: Yaroslav Shabalin <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: vathsala nagaraju <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/49935bdff896ee3140bed471012b9f9110a863a4.1495729964.git.vathsala.nagaraju@intel.com
(cherry picked from commit bef8c056fba09aa4629fe5a2d3efe64068d049db)
Signed-off-by: Jani Nikula <[email protected]>
|
|
Allow intel_engine_is_idle() to be called outside of the GT wakeref by
acquiring the device runtime pm for ourselves. This allows the function
to act as check after we assume the engine is idle and we release the GT
wakeref held whilst we have requests. At the moment, we do not call it
outside of an awake context but taking the wakeref as required makes it
more convenient to use for quick debugging in future.
[ 2613.401647] RPM wakelock ref not held during HW access
[ 2613.401684] ------------[ cut here ]------------
[ 2613.401720] WARNING: CPU: 5 PID: 7739 at drivers/gpu/drm/i915/intel_drv.h:1787 gen6_read32+0x21f/0x2b0 [i915]
[ 2613.401731] Modules linked in: snd_hda_intel i915 vgem snd_hda_codec_hdmi x86_pkg_temp_thermal intel_powerclamp snd_hda_codec_realtek coretemp snd_hda_codec_generic crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm r8169 mii mei_me lpc_ich mei prime_numbers [last unloaded: i915]
[ 2613.401823] CPU: 5 PID: 7739 Comm: drv_missed_irq Tainted: G U 4.12.0-rc2-CI-CI_DRM_421+ #1
[ 2613.401825] Hardware name: MSI MS-7924/Z97M-G43(MS-7924), BIOS V1.12 02/15/2016
[ 2613.401840] task: ffff880409e3a740 task.stack: ffffc900084dc000
[ 2613.401861] RIP: 0010:gen6_read32+0x21f/0x2b0 [i915]
[ 2613.401863] RSP: 0018:ffffc900084dfce8 EFLAGS: 00010292
[ 2613.401869] RAX: 000000000000002a RBX: ffff8804016a8000 RCX: 0000000000000006
[ 2613.401871] RDX: 0000000000000006 RSI: ffffffff81cbf2d9 RDI: ffffffff81c9e3a7
[ 2613.401874] RBP: ffffc900084dfd18 R08: ffff880409e3afc8 R09: 0000000000000000
[ 2613.401877] R10: 000000008a1c483f R11: 0000000000000000 R12: 000000000000209c
[ 2613.401879] R13: 0000000000000001 R14: ffff8804016a8000 R15: ffff8804016ac150
[ 2613.401882] FS: 00007f39ef3dd8c0(0000) GS:ffff88041fb40000(0000) knlGS:0000000000000000
[ 2613.401885] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 2613.401887] CR2: 00000000023717c8 CR3: 00000002e7b34000 CR4: 00000000001406e0
[ 2613.401889] Call Trace:
[ 2613.401912] intel_engine_is_idle+0x76/0x90 [i915]
[ 2613.401931] i915_gem_wait_for_idle+0xe6/0x1e0 [i915]
[ 2613.401951] fault_irq_set+0x40/0x90 [i915]
[ 2613.401970] i915_ring_test_irq_set+0x42/0x50 [i915]
[ 2613.401976] simple_attr_write+0xc7/0xe0
[ 2613.401981] full_proxy_write+0x4f/0x70
[ 2613.401987] __vfs_write+0x23/0x120
[ 2613.401992] ? rcu_read_lock_sched_held+0x75/0x80
[ 2613.401996] ? rcu_sync_lockdep_assert+0x2a/0x50
[ 2613.401999] ? __sb_start_write+0xfa/0x1f0
[ 2613.402004] vfs_write+0xc5/0x1d0
[ 2613.402008] ? trace_hardirqs_on_caller+0xe7/0x1c0
[ 2613.402013] SyS_write+0x44/0xb0
[ 2613.402020] entry_SYSCALL_64_fastpath+0x1c/0xb1
[ 2613.402022] RIP: 0033:0x7f39eded6670
[ 2613.402025] RSP: 002b:00007fffdcdcb1a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 2613.402030] RAX: ffffffffffffffda RBX: ffffffff81470203 RCX: 00007f39eded6670
[ 2613.402033] RDX: 0000000000000001 RSI: 000000000041bc33 RDI: 0000000000000006
[ 2613.402036] RBP: ffffc900084dff88 R08: 00007f39ef3dd8c0 R09: 0000000000000001
[ 2613.402038] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000041bc33
[ 2613.402041] R13: 0000000000000006 R14: 0000000000000000 R15: 0000000000000000
[ 2613.402046] ? __this_cpu_preempt_check+0x13/0x20
[ 2613.402052] Code: 01 9b fa e0 0f ff e9 28 fe ff ff 80 3d 6a dd 0e 00 00 0f 85 29 fe ff ff 48 c7 c7 48 19 29 a0 c6 05 56 dd 0e 00 01 e8 da 9a fa e0 <0f> ff e9 0f fe ff ff b9 01 00 00 00 ba 01 00 00 00 44 89 e6 48
[ 2613.402199] ---[ end trace 31f0cfa93ab632bf ]---
Fixes: 5400367a864d ("drm/i915: Ensure the engine is idle before manually changing HWS")
Signed-off-by: Chris Wilson <[email protected]>
Cc: Mika Kuoppala <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Cc: Tvrtko Ursulin <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Tvrtko Ursulin <[email protected]>
(cherry picked from commit a091d4ee931b16ce4fef945d39a20b851a7e17b7)
Signed-off-by: Jani Nikula <[email protected]>
|
|
If the device is asleep (no GT wakeref), we know the GPU is already idle.
If we add an early return, we can avoid touching registers and checking
hw state outside of the assumed GT wakelock. This prevents causing such
errors whilst debugging:
[ 2613.401647] RPM wakelock ref not held during HW access
[ 2613.401684] ------------[ cut here ]------------
[ 2613.401720] WARNING: CPU: 5 PID: 7739 at drivers/gpu/drm/i915/intel_drv.h:1787 gen6_read32+0x21f/0x2b0 [i915]
[ 2613.401731] Modules linked in: snd_hda_intel i915 vgem snd_hda_codec_hdmi x86_pkg_temp_thermal intel_powerclamp snd_hda_codec_realtek coretemp snd_hda_codec_generic crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm r8169 mii mei_me lpc_ich mei prime_numbers [last unloaded: i915]
[ 2613.401823] CPU: 5 PID: 7739 Comm: drv_missed_irq Tainted: G U 4.12.0-rc2-CI-CI_DRM_421+ #1
[ 2613.401825] Hardware name: MSI MS-7924/Z97M-G43(MS-7924), BIOS V1.12 02/15/2016
[ 2613.401840] task: ffff880409e3a740 task.stack: ffffc900084dc000
[ 2613.401861] RIP: 0010:gen6_read32+0x21f/0x2b0 [i915]
[ 2613.401863] RSP: 0018:ffffc900084dfce8 EFLAGS: 00010292
[ 2613.401869] RAX: 000000000000002a RBX: ffff8804016a8000 RCX: 0000000000000006
[ 2613.401871] RDX: 0000000000000006 RSI: ffffffff81cbf2d9 RDI: ffffffff81c9e3a7
[ 2613.401874] RBP: ffffc900084dfd18 R08: ffff880409e3afc8 R09: 0000000000000000
[ 2613.401877] R10: 000000008a1c483f R11: 0000000000000000 R12: 000000000000209c
[ 2613.401879] R13: 0000000000000001 R14: ffff8804016a8000 R15: ffff8804016ac150
[ 2613.401882] FS: 00007f39ef3dd8c0(0000) GS:ffff88041fb40000(0000) knlGS:0000000000000000
[ 2613.401885] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 2613.401887] CR2: 00000000023717c8 CR3: 00000002e7b34000 CR4: 00000000001406e0
[ 2613.401889] Call Trace:
[ 2613.401912] intel_engine_is_idle+0x76/0x90 [i915]
[ 2613.401931] i915_gem_wait_for_idle+0xe6/0x1e0 [i915]
[ 2613.401951] fault_irq_set+0x40/0x90 [i915]
[ 2613.401970] i915_ring_test_irq_set+0x42/0x50 [i915]
[ 2613.401976] simple_attr_write+0xc7/0xe0
[ 2613.401981] full_proxy_write+0x4f/0x70
[ 2613.401987] __vfs_write+0x23/0x120
[ 2613.401992] ? rcu_read_lock_sched_held+0x75/0x80
[ 2613.401996] ? rcu_sync_lockdep_assert+0x2a/0x50
[ 2613.401999] ? __sb_start_write+0xfa/0x1f0
[ 2613.402004] vfs_write+0xc5/0x1d0
[ 2613.402008] ? trace_hardirqs_on_caller+0xe7/0x1c0
[ 2613.402013] SyS_write+0x44/0xb0
[ 2613.402020] entry_SYSCALL_64_fastpath+0x1c/0xb1
[ 2613.402022] RIP: 0033:0x7f39eded6670
[ 2613.402025] RSP: 002b:00007fffdcdcb1a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 2613.402030] RAX: ffffffffffffffda RBX: ffffffff81470203 RCX: 00007f39eded6670
[ 2613.402033] RDX: 0000000000000001 RSI: 000000000041bc33 RDI: 0000000000000006
[ 2613.402036] RBP: ffffc900084dff88 R08: 00007f39ef3dd8c0 R09: 0000000000000001
[ 2613.402038] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000041bc33
[ 2613.402041] R13: 0000000000000006 R14: 0000000000000000 R15: 0000000000000000
[ 2613.402046] ? __this_cpu_preempt_check+0x13/0x20
[ 2613.402052] Code: 01 9b fa e0 0f ff e9 28 fe ff ff 80 3d 6a dd 0e 00 00 0f 85 29 fe ff ff 48 c7 c7 48 19 29 a0 c6 05 56 dd 0e 00 01 e8 da 9a fa e0 <0f> ff e9 0f fe ff ff b9 01 00 00 00 ba 01 00 00 00 44 89 e6 48
[ 2613.402199] ---[ end trace 31f0cfa93ab632bf ]---
Fixes: 25112b64b3d2 ("drm/i915: Wait for all engines to be idle as part of i915_gem_wait_for_idle()")
Signed-off-by: Chris Wilson <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Cc: Tvrtko Ursulin <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Joonas Lahtinen <[email protected]>
(cherry picked from commit 863e9fde1a7061dad09bb299c65bed5f1ccb44ff)
Signed-off-by: Jani Nikula <[email protected]>
|
|
The decoupled MMIO feature doesn't work as intended by HW team. Enabling
it with forcewake will only make debugging efforts more difficult, so
let's disable it.
Fixes: 85ee17ebeedd ("drm/i915/bxt: Broxton decoupled MMIO")
Cc: Zhe Wang <[email protected]>
Cc: Praveen Paneri <[email protected]>
Cc: Tvrtko Ursulin <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Jani Nikula <[email protected]>
Cc: [email protected]
Cc: <[email protected]> # v4.10+
Signed-off-by: Kai Chen <[email protected]>
Reviewed-by: Tvrtko Ursulin <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit 0051c10acabb631cfd439eae73289e6e4c39b2b7)
Signed-off-by: Jani Nikula <[email protected]>
|
|
This member was dropped long time ago.
Fixes: 774439e1 ("drm/i915/guc: re-optimise i915_guc_client layout")
Signed-off-by: Michal Wajdeczko <[email protected]>
Cc: Tvrtko Ursulin <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Chris Wilson <[email protected]>
Signed-off-by: Chris Wilson <[email protected]>
(cherry picked from commit 4afc67be8e203ee8f5e95e829c0777eae7a14702)
Signed-off-by: Jani Nikula <[email protected]>
|
|
While the atomic modesetting capability is signaled also elsewhere, also
reflect it by a driver minor bump.
Signed-off-by: Thomas Hellstrom <[email protected]>
|
|
These function implementations and/or declarations are no longer used
now that atomic is enabled.
Signed-off-by: Sinclair Yeh <[email protected]>
Reported-by: Daniel Vetter <[email protected]>
Reviewed-by: Thomas Hellstrom <[email protected]>
|
|
Trivial fix to spelling mistake in DRM_ERROR error message.
Signed-off-by: Colin Ian King <[email protected]>
Reviewed-by: Sinclair Yeh <[email protected]>
|
|
The previous attempt at this had an issue with with num_clips > 1
because it would always end up using the coordinates of the last
clip while using width and height calculated from the bounding
box of all the clips.
So if the last clip happens to be not at the top-left corner of
the bounding box, the CPU blit operation would go out of bounds.
The original intent was to coalesce all the clips into one blit,
and to do that we need to also track the starting point of the
content buffer.
Signed-off-by: Sinclair Yeh <[email protected]>
Reviewed-by: Thomas Hellstrom <[email protected]>
|
|
When a new FB is bound, we have to send an update command otherwise
the new FB may not be shown
Signed-off-by: Sinclair Yeh <[email protected]>
Reviewed-by: Thomas Hellstrom <[email protected]>
|
|
When vmw_gb_surface_define_ioctl() is called with an existing buffer,
we end up returning an uninitialized variable in the backup_handle.
The fix is to first initialize backup_handle to 0 just to be sure, and
second, when a user-provided buffer is found, we will use the
req->buffer_handle as the backup_handle.
Cc: <[email protected]>
Reported-by: Murray McAllister <[email protected]>
Signed-off-by: Sinclair Yeh <[email protected]>
Reviewed-by: Deepak Rawat <[email protected]>
|
|
If vmalloc() fails then we need to a bit of cleanup before returning.
Cc: <[email protected]>
Fixes: fb1d9738ca05 ("drm/vmwgfx: Add DRM driver for VMware Virtual GPU")
Signed-off-by: Dan Carpenter <[email protected]>
Reviewed-by: Sinclair Yeh <[email protected]>
|
|
With atomic, the cursor surface is treated like a FB. Creating
a proxy surface for cursor doesn't gain us much benefit.
This fixes the issue on atomic enabled 2D VMs where the cursor
disappears.
Signed-off-by: Sinclair Yeh <[email protected]>
Reviewed-by: Thomas Hellstrom <[email protected]>
|
|
The 'req->mip_levels' parameter in vmw_gb_surface_define_ioctl() is
a user-controlled 'uint32_t' value which is used as a loop count limit.
This can lead to a kernel lockup and DoS. Add check for 'req->mip_levels'.
References:
https://bugzilla.redhat.com/show_bug.cgi?id=1437431
Cc: <[email protected]>
Signed-off-by: Vladis Dronov <[email protected]>
Reviewed-by: Sinclair Yeh <[email protected]>
|
|
BXT has a H/W issue with IOMMU which can lead to system hangs when
Aperture accesses are queued within the GAM behind GTT Accesses.
This patch avoids the condition by wrapping all GTT updates in stop_machine
and using a flushing read prior to restarting the machine.
The stop_machine guarantees no new Aperture accesses can begin while
the PTE writes are being emmitted. The flushing read ensures that
any following Aperture accesses cannot begin until the PTE writes
have been cleared out of the GAM's fifo.
Only FOLLOWING Aperture accesses need to be separated from in flight
PTE updates. PTE Writes may follow tightly behind already in flight
Aperture accesses, so no flushing read is required at the start of
a PTE update sequence.
This issue was reproduced by running
igt/gem_readwrite and
igt/gem_render_copy
simultaneously from different processes, each in a tight loop,
with INTEL_IOMMU enabled.
This patch was originally published as:
drm/i915: Serialize GTT Updates on BXT
[Note: This will cause a performance penalty for some use cases, but
avoiding hangs trumps performance hits. This may need to be worked
around in Mesa to recover the lost performance.]
v2: Move bxt/iommu detection into static function
Remove #ifdef CONFIG_INTEL_IOMMU protection
Make function names more reflective of purpose
Move flushing read into static function
v3: Tidy up for checkpatch.pl
Testcase: igt/gem_concurrent_blit
Signed-off-by: Jon Bloomfield <[email protected]>
Cc: John Harrison <[email protected]>
Cc: Chris Wilson <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Tvrtko Ursulin <[email protected]>
Cc: [email protected]
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Tvrtko Ursulin <[email protected]>
Signed-off-by: Chris Wilson <[email protected]>
(cherry picked from commit 0ef34ad6222abfa513117515fec720c33a58f105)
Signed-off-by: Jani Nikula <[email protected]>
|
|
Commit 5995a68 "xen/privcmd: Add support for Linux 64KB page granularity" did
not go far enough to support 64KB in mmap_batch_fn.
The variable 'nr' is the number of 4KB chunk to map. However, when Linux
is using 64KB page granularity the array of pages (vma->vm_private_data)
contain one page per 64KB. Fix it by incrementing st->index correctly.
Furthermore, st->va is not correctly incremented as PAGE_SIZE !=
XEN_PAGE_SIZE.
Fixes: 5995a68 ("xen/privcmd: Add support for Linux 64KB page granularity")
CC: [email protected]
Reported-by: Feng Kan <[email protected]>
Signed-off-by: Julien Grall <[email protected]>
Reviewed-by: Boris Ostrovsky <[email protected]>
Signed-off-by: Juergen Gross <[email protected]>
|
|
Christoph Hellwig suggests we should to make APST work out of the box.
Hence relax the the default max latency to make them able to enter
deepest power state on default.
Here are id-ctrl excerpts from two high latency NVMes:
vid : 0x14a4
ssvid : 0x1b4b
mn : CX2-GB1024-Q11 NVMe LITEON 1024GB
ps 3 : mp:0.1000W non-operational enlat:5000 exlat:5000 rrt:3 rrl:3
rwt:3 rwl:3 idle_power:- active_power:-
ps 4 : mp:0.0100W non-operational enlat:50000 exlat:100000 rrt:4 rrl:4
rwt:4 rwl:4 idle_power:- active_power:-
vid : 0x15b7
ssvid : 0x1b4b
mn : A400 NVMe SanDisk 512GB
ps 3 : mp:0.0500W non-operational enlat:51000 exlat:10000 rrt:0 rrl:0
rwt:0 rwl:0 idle_power:- active_power:-
ps 4 : mp:0.0055W non-operational enlat:1000000 exlat:100000 rrt:0 rrl:0
rwt:0 rwl:0 idle_power:- active_power:-
Signed-off-by: Kai-Heng Feng <[email protected]>
Signed-off-by: Christoph Hellwig <[email protected]>
|