28 Jan, 2015
27 commits
-
commit 7f1241ed1a06b4846ad7a2a57eb088b757e58e16 upstream.
pps_{lock,unlock}() call intel_display_power_{get,put}() outside
pps_mutes to avoid deadlocks with the power_domain mutex. In theory
during aux transfers we should usually have the relevant power domain
references already held by some higher level code, so this should not
result in much overhead (exception being userspace i2c-dev access).
However thanks to the check_power_well() calls in
intel_display_power_{get/put}() we end up doing a few Punit reads for
each aux transfer. Obviously doing this for each byte transferred via
i2c-over-aux is not a good idea.I can't think of a good way to keep check_power_well() while eliminating
the overhead, so let's just remove check_power_well() entirely.Fixes a driver init time regression introduced by:
commit 773538e86081d146e0020435d614f4b96996c1f9
Author: Ville Syrjälä
Date: Thu Sep 4 14:54:56 2014 +0300drm/i915: Reset power sequencer pipe tracking when disp2d is off
Credit goes to Jani for figuring this out.
v2: Add the regression note in the commit message.
Cc: Egbert Eich
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86201
Tested-by: Wendy Wang
Signed-off-by: Ville Syrjälä
[Jani: s/intel_runtime_pm.c/intel_pm.c/g and wiggle for 3.18]
Signed-off-by: Jani Nikula
Signed-off-by: Greg Kroah-Hartman -
commit 01f5a6261cea395f72877aeb7c2fe2d42e1b1e00 upstream.
The VGA_2X_MODE bit apparently affects the display even when the VGA
plane is disabled. The bit will set by the BIOS when the panel width
is at least 1280 pixels. So by preserving the bit from the BIOS we
end up with corrupted display on machines with such high res panels.
I only have 1024x768 panels on my gen2 machines so never ran into
this problem.The original reason for preserving the VGACNTR register was to make
my 830 survive S3 with acpi_sleep=s3_bios option. However after
further 830 fixes that option is no longer needed to make S3 work
and preserving VGACNTR doesn't seem to be necessary without it,
so we can just revert the entire patch.This reverts
commit 69769f9a422bfc62e17399da3590c5e31ac37f24
Author: Ville Syrjälä
Date: Fri Aug 15 01:22:08 2014 +0300drm/i915: Preserve VGACNTR bits from the BIOS
Cc: Bruno Prémont
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87171
Signed-off-by: Ville Syrjälä
Signed-off-by: Jani Nikula
Signed-off-by: Greg Kroah-Hartman -
commit 7f907bf284ba7bb8d271f094b226699d3fef2142 upstream.
Let's make things a bit easier to debug when things go bad (potentially
under console_lock).Signed-off-by: Rob Clark
Reviewed-by: Michel Dänzer
Signed-off-by: Dave Airlie
Cc: Anand Moon
Signed-off-by: Greg Kroah-Hartman -
commit 7d47559ee84b3ac206aa9e675606fafcd7c0b500 upstream.
The flip stall detector kicks in when pending>=INTEL_FLIP_COMPLETE. That
means if we first call intel_prepare_page_flip() but don't call
intel_finish_page_flip(), the next stall check will erroneosly think
the page flip was somehow stuck.With enough debug spew emitted from the interrupt handler my 830 hangs
when this happens. My theory is that the previous vblank interrupt gets
sufficiently delayed that the handler will see the pending bit set in
IIR, but ISR still has the bit set as well (ie. the flip was processed
by CS but didn't complete yet). In this case the handler will proceed
to call intel_check_page_flip() immediately after
intel_prepare_page_flip(). It then tries to print a backtrace for the
stuck flip WARN, which apparetly results in way too much debug spew
delaying interrupt processing further. That then seems to cause an
endless loop in the interrupt handler, and the machine is dead until
the watchdog kicks in and reboots. At least limiting the number of
iterations of the loop in the interrupt handler also prevented the
hang.So it seems better to not call intel_prepare_page_flip() without
immediately calling intel_finish_page_flip(). The IIR/ISR trickery
avoids races here so this is a perfectly safe thing to do.v2: Fix typo in commit message (checkpatch)
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88381
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85888
Reviewed-by: Chris Wilson
Signed-off-by: Ville Syrjälä
Signed-off-by: Jani Nikula
Signed-off-by: Greg Kroah-Hartman -
commit 2c550183476dfa25641309ae9a28d30feed14379 upstream.
There exists a current workaround to prevent a hang on context switch
should the ring go to sleep in the middle of the restore,
WaProgramMiArbOnOffAroundMiSetContext (applicable to all gen7+). In
spite of disabling arbitration (which prevents the ring from powering
down during the critical section) we were still hitting hangs that had
the hallmarks of the known erratum. That is we are still seeing hangs
"on the last instruction in the context restore". By comparing -nightly
(broken) with requests (working), we were able to deduce that it was the
semaphore LRI cross-talk that reproduced the original failure. The key
was that requests implemented deferred semaphore signalling, and
disabling that, i.e. emitting the semaphore signal to every other ring
after every batch restored the frequent hang. Explicitly disabling PSMI
sleep on the RCS ring was insufficient, all the rings had to be awake to
prevent the hangs. Fortunately, we can reduce the wakelock to the
MI_SET_CONTEXT operation itself, and so should be able to limit the extra
power implications.Since the MI_ARB_ON_OFF workaround is listed for all gen7 and above
products, we should apply this extra hammer for all of the same
platforms despite so far that we have only been able to reproduce the
hang on certain ivb and hsw models. The last question is whether we want
to always use the extra hammer or only when we know semaphores are in
operation. At the moment, we only use LRI on non-RCS rings for
semaphores, but that may change in the future with the possibility of
reintroducing this bug under subtle conditions.v2: Make it explicit that the PSMI LRI are an extension to the original
workaround for the other rings.
v3: Bikeshedding variable names and whitespacingBugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80660
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83677
Cc: Simon Farnsworth
Cc: Daniel Vetter
Cc: Ville Syrjälä
Signed-off-by: Chris Wilson
Tested-by: Peter Frühberger
Reviewed-by: Daniel Vetter
Signed-off-by: Jani Nikula
Signed-off-by: Greg Kroah-Hartman -
commit add284a3a2481e759d6bec35f6444c32c8ddc383 upstream.
In order to act as a full command barrier by itself, we need to tell the
pipecontrol to actually stall the command streamer while the flush runs.
We require the full command barrier before operations like
MI_SET_CONTEXT, which currently rely on a prior invalidate flush.References: https://bugs.freedesktop.org/show_bug.cgi?id=83677
Cc: Simon Farnsworth
Cc: Daniel Vetter
Cc: Ville Syrjälä
Signed-off-by: Chris Wilson
Signed-off-by: Jani Nikula
Signed-off-by: Greg Kroah-Hartman -
commit 148b83d0815a3778c8949e6a97cb798cbaa0efb3 upstream.
In the gen7 pipe control there is an extra bit to flush the media
caches, so let's set it during cache invalidation flushes.v2: Rename to MEDIA_STATE_CLEAR to be more inline with spec.
Cc: Simon Farnsworth
Cc: Ville Syrjälä
Cc: Daniel Vetter
Signed-off-by: Chris Wilson
Reviewed-by: Daniel Vetter
Signed-off-by: Jani Nikula
Signed-off-by: Greg Kroah-Hartman -
commit 4761703bd04bbdf56396d264903cc5a1fdcb3c01 upstream.
Several users have, over time, reported issues with MSI on these IGPs.
They're old, rarely available, and MSI doesn't provide such huge
advantages on them. Just disable.Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87361
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74492
Fixes: fa8c9ac72fe ("drm/nv4c/mc: nv4x igp's have a different msi rearm register")
Signed-off-by: Ilia Mirkin
Signed-off-by: Ben Skeggs
Signed-off-by: Greg Kroah-Hartman -
commit 9f49c37635d5c2a801f7670d5fbf0b25ec461f2c upstream.
Should probably just init this in the GMbus code all the time, based on
the cdclk and HPLL like we do on newer platforms. Ville has code for
that in a rework branch, but until then we can fix this bug fairly
easily.Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76301
Signed-off-by: Jesse Barnes
Reviewed-by: Ville Syrjälä
Tested-by: Nikolay
Signed-off-by: Jani Nikula
Signed-off-by: Greg Kroah-Hartman -
commit e7d6f7d708290da1b7c92f533444b042c79412e0 upstream.
Otherwise the MST resume paths can hit DPMS paths
which hit state checker paths, which hit WARN_ON,
because the state checker is inconsistent with the
hw.This fixes a bunch of WARN_ON's on resume after
undocking.Signed-off-by: Dave Airlie
Reviewed-by: Daniel Vetter
Signed-off-by: Jani Nikula
Signed-off-by: Greg Kroah-Hartman -
commit 2b387059817fd100cddc5a97118d63e3f3fade74 upstream.
In all likelihood we will do a few hundred errnoneous register
operations if we do a single invalid register access whilst the device
is suspended. As each instance causes a WARN, this floods the system
logs and can make the system unresponsive.The warning was first introduced in
commit b2ec142cb0101f298f8e091c7d75b1ec5b809b65
Author: Paulo Zanoni
Date: Fri Feb 21 13:52:25 2014 -0300drm/i915: call assert_device_not_suspended at gen6_force_wake_work
and despite the claims the WARN is still encountered in the wild today.
Signed-off-by: Chris Wilson
Cc: Paulo Zanoni
Cc: Imre Deak
Signed-off-by: Daniel Vetter
Signed-off-by: Greg Kroah-Hartman -
commit d472fcc8379c062bd56a3876fc6ef22258f14a91 upstream.
The problem here is that SNA pins batchbuffers to etch out a bit more
performance. Iirc it started out as a w/a for i830M (which we've
implemented in the kernel since a long time already). The problem is
that the pin ioctl wasn't added incommit d23db88c3ab233daed18709e3a24d6c95344117f
Author: Chris Wilson
Date: Fri May 23 08:48:08 2014 +0200drm/i915: Prevent negative relocation deltas from wrapping
Fix this by simply disallowing pinning from userspace so that the
kernel is in full control of batch placement again. Especially since
distros are moving towards running X as non-root, so most users won't
even be able to see any benefits.UMS support is dead now, but we need this minimal patch for
backporting. Follow-up patch will remove the pin ioctl code
completely.Note to backporters: You must have both
commit b45305fce5bb1abec263fcff9d81ebecd6306ede
Author: Daniel Vetter
Date: Mon Dec 17 16:21:27 2012 +0100drm/i915: Implement workaround for broken CS tlb on i830/845
which laned in 3.8 and
commit c4d69da167fa967749aeb70bc0e94a457e5d00c1
Author: Chris Wilson
Date: Mon Sep 8 14:25:41 2014 +0100drm/i915: Evict CS TLBs between batches
which is also marked cc: stable. Otherwise this could introduce a
regression by disabling the userspace w/a without the kernel w/a being
fully functional on i830/45.References: https://bugs.freedesktop.org/show_bug.cgi?id=76554#c116
Cc: Chris Wilson
Signed-off-by: Daniel Vetter
Signed-off-by: Greg Kroah-Hartman -
commit 0b6d24c01932db99fc95304235e751e7f7625c41 upstream.
Apparently stuff works that way on those machines.
I agree with Chris' concern that this is a bit risky but imo worth a
shot in -next just for fun. Afaics all these machines have the pci
resources allocated like that by the BIOS, so I suspect that it's all
ok.This regression goes back to
commit eaba1b8f3379b5d100bd146b9a41d28348bdfd09
Author: Chris Wilson
Date: Thu Jul 4 12:28:35 2013 +0100drm/i915: Verify that our stolen memory doesn't conflict
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76983
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71031
Tested-by: lu hua
Signed-off-by: Daniel Vetter
Reviewed-by: Jesse Barnes
Tested-by: Paul Menzel
Signed-off-by: Jani Nikula
Signed-off-by: Greg Kroah-Hartman -
commit 410cce2a6b82299b46ff316c6384e789ce275ecb upstream.
The check was already in place in the dp mode_valid check, but
radeon_dp_get_dp_link_clock() never returned the high clock
mode_valid was checking for because that function clipped the
clock based on the hw capabilities. Add an explicit check
in the mode_valid function.bug:
https://bugs.freedesktop.org/show_bug.cgi?id=87172Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit 02ae7af53a451a1b0a51022c4693f5b339133e79 upstream.
Enabling bapm seems to cause clocking problems on some
KV configurations. Disable it by default for now.Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit 5665c3ebe5ee8a2c516925461f7214ba59c2e6d7 upstream.
Make it consistent with the sad code for other asics to deal
with monitors that don't report sads.bug:
https://bugzilla.kernel.org/show_bug.cgi?id=89461Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit fbedf1c3fc3a1e9f249c2efe2f4553d8df9d86d3 upstream.
Enable all three in the driver. Early documentation
indicated the 3rd one was used for something else, but
that is not the case.v2: handle disable as well
Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit 5e5c21cac1001089007260c48b0c89ebaace0e71 upstream.
Check the that ring we are using for copies is functional
rather than the GFX ring. On newer asics we use the DMA
ring for bo moves.Reviewed-by: Christian König
Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit 4bb62c95a7e781a238b2ab374f34b1bf91e01ddc upstream.
Always need to set bit 0 of RLC_CGTT_MGCG_OVERRIDE
to avoid unreliable doorbell updates in some cases.Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit 129acb7c0b682512e89c4f65c33593d50f2f49a9 upstream.
Need to disable DS, not enable it when disabling dpm.
Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit 0391359ddf79b52bb7e7bb9ace08e34fb08b0e76 upstream.
When we unplug a dp mst branch we unreference the entire tree from
the root towards the leaves. Which is ok, since that's the way the
pointers and so also the refcounts go.But when we drop the reference we must make sure that we remove the
branches/ports from the lists/pointers before dropping the reference.
Otherwise the get_validated functions will still return it instead
of returning NULL (which indicates a potentially on-going unplug).The mst branch destroy gets this right for ports: First it deletes
the port from the ports list, then it unrefs. But the ports destroy
function gets it wrong: First it unrefs, then it drops the ref. Which
means a zombie mst branch can still be validate with get_validated_mstb_ref
when it shouldn't.Fix this.
This should address a backtrace Dave dug out somewhere on unplug:
[] drm_dp_mst_get_validated_mstb_ref_locked+0x92/0xa0 [drm_kms_helper]
[] drm_dp_mst_get_validated_mstb_ref_locked+0x41/0xa0 [drm_kms_helper]
[] drm_dp_get_validated_mstb_ref+0x3a/0x60 [drm_kms_helper]
[] drm_dp_payload_send_msg.isra.14+0x2b/0x100 [drm_kms_helper]
[] drm_dp_update_payload_part1+0x177/0x360 [drm_kms_helper]
[] intel_mst_disable_dp+0x3e/0x80 [i915]
[] haswell_crtc_disable+0x1cb/0x340 [i915]
[] intel_crtc_control+0x49/0x100 [i915]
[] intel_crtc_update_dpms+0x67/0x80 [i915]
[] intel_connector_dpms+0x59/0x70 [i915]
[] intel_dp_destroy_mst_connector+0x32/0xc0 [i915]
[] drm_dp_destroy_port+0x6b/0xa0 [drm_kms_helper]
[] drm_dp_destroy_mst_branch_device+0x108/0x130 [drm_kms_helper]
[] drm_dp_port_teardown_pdt+0x3d/0x50 [drm_kms_helper]
[] drm_dp_mst_handle_up_req+0x499/0x540 [drm_kms_helper]
[] ? trace_hardirqs_on_caller+0x15d/0x200 []
drm_dp_mst_hpd_irq+0x53/0xa00 [drm_kms_helper] []
? drm_dp_dpcd_read+0x1b/0x20 [drm_kms_helper] []
? intel_dp_dpcd_read_wake+0x38/0x70 [i915] []
intel_dp_check_mst_status+0xb5/0x250 [i915] []
intel_dp_hpd_pulse+0x181/0x210 [i915] []
i915_digport_work_func+0x96/0x120 [i915]Signed-off-by: Daniel Vetter
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman -
commit 19a93f042fc241ecdf98543cedfe7c171f8cdf53 upstream.
At least on two MST devices I've tested with, when
they are link training downstream, they are totally
unable to handle aux ch msgs, so they defer like nuts.
I tried 16, it wasn't enough, 32 seems better.This fixes one Dell 4k monitor and one of the
MST hubs.v1.1: fixup comment (Tom).
Acked-by: Alex Deucher
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman -
commit e2809c7db818df6bbd0edf843e1beb2fbc9d8541 upstream.
On MST systems the monitors don't appear when we set the fb up,
but plymouth opens the drm device and holds it open while they
come up, when plymouth finishes and lastclose gets called we
don't do the delayed fb probe, so the monitor never appears on the
console.Fix this by moving the delayed checking into the mode restore.
v2: Daniel suggested that ->delayed_hotplug is set under
the mode_config mutex, so we should check it under that as
well, while we are in the area.Reviewed-by: Daniel Vetter
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman -
commit 881fdaa5e4cb0d68e52acab0ad4e1820e2bfffa4 upstream.
Andrew Morton wrote:
> On Wed, 12 Nov 2014 13:08:55 +0900 Tetsuo Handa wrote:
>
> > Andrew Morton wrote:
> > > Poor ttm guys - this is a bit of a trap we set for them.
> >
> > Commit a91576d7916f6cce ("drm/ttm: Pass GFP flags in order to avoid deadlock.")
> > changed to use sc->gfp_mask rather than GFP_KERNEL.
> >
> > - pages_to_free = kmalloc(npages_to_free * sizeof(struct page *),
> > - GFP_KERNEL);
> > + pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), gfp);
> >
> > But this bug is caused by sc->gfp_mask containing some flags which are not
> > in GFP_KERNEL, right? Then, I think
> >
> > - pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), gfp);
> > + pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), gfp & GFP_KERNEL);
> >
> > would hide this bug.
> >
> > But I think we should use GFP_ATOMIC (or drop __GFP_WAIT flag)
>
> Well no - ttm_page_pool_free() should stop calling kmalloc altogether.
> Just do
>
> struct page *pages_to_free[16];
>
> and rework the code to free 16 pages at a time. Easy.Well, ttm code wants to process 512 pages at a time for performance.
Memory footprint increased by 512 * sizeof(struct page *) buffer is
only 4096 bytes. What about using static buffer like below?
----------
>From d3cb5393c9c8099d6b37e769f78c31af1541fe8c Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Thu, 13 Nov 2014 22:21:54 +0900
Subject: drm/ttm: Avoid memory allocation from shrinker functions.Commit a91576d7916f6cce ("drm/ttm: Pass GFP flags in order to avoid
deadlock.") caused BUG_ON() due to sc->gfp_mask containing flags
which are not in GFP_KERNEL.https://bugzilla.kernel.org/show_bug.cgi?id=87891
Changing from sc->gfp_mask to (sc->gfp_mask & GFP_KERNEL) would
avoid the BUG_ON(), but avoiding memory allocation from shrinker
function is better and reliable fix.Shrinker function is already serialized by global lock, and
clean up function is called after shrinker function is unregistered.
Thus, we can use static buffer when called from shrinker function
and clean up function.Signed-off-by: Tetsuo Handa
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman -
commit 89669e7a7f96be3ee8d9a22a071d7c0d3b4428fc upstream.
The commit "vmwgfx: Rework fence event action" introduced a number of bugs
that are fixed with this commit:a) A forgotten return stateemnt.
b) An if statement with identical branches.Reported-by: Rob Clark
Signed-off-by: Thomas Hellstrom
Reviewed-by: Jakob Bornecrantz
Reviewed-by: Sinclair Yeh
Signed-off-by: Greg Kroah-Hartman -
commit e338c4c2b620ba4e75fd3576f8142eb93be12ce3 upstream.
The function vmw_master_check() might return -ERESTARTSYS if there is a
signal pending, indicating that the IOCTL should be rerun, potentially from
user-space. At that point we shouldn't print out an error message since that
is not an error condition. In short, avoid bloating the kernel log when a
process refuses to die on SIGTERM.Signed-off-by: Thomas Hellstrom
Reviewed-by: Jakob Bornecrantz
Signed-off-by: Greg Kroah-Hartman -
commit 1f563a6a46544602183e7493b6ef69769d3d76d9 upstream.
Kernel side fence objects are used when unbinding resources and may thus be
created as part of a memory reclaim operation. This might trigger recursive
memory reclaims and result in the kernel running out of stack space.So a simple way out is to avoid accounting of these fence objects.
In principle this is OK since while user-space can trigger the creation of
such objects, it can't really hold on to them. However, their lifetime is
quite long, so some form of accounting should perhaps be implemented in the
future.Fixes kernel crashes when running, for example viewperf11 ensight-04 test 3
with low system memory settings.Signed-off-by: Thomas Hellstrom
Reviewed-by: Jakob Bornecrantz
Reviewed-by: Sinclair Yeh
Signed-off-by: Greg Kroah-Hartman
16 Jan, 2015
2 commits
-
commit 2036eaa74031b11028ee8fc1f44f128fdc871dda upstream.
nouveau userspace back at 1.0.1 used to call the X server
DRIOpenDRMMaster interface even for DRI2 (doh!), this attempts
to map the sarea and fails if it can't.Since 884c6dabb0eafe7227f099c9e78e514191efaf13 from Daniel,
this fails, but only ancient drivers would see it.Revert the nouveau bits of that fix.
Acked-by: Daniel Vetter
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman -
commit ff4c0d5213b015e60aa87c1352604f10ba9c3e12 upstream.
On !SMP systems spinlocks do not exist. Thus checking of they
are active will always fail.Use
assert_spin_locked(lock);
instead of
BUG_ON(!spin_is_locked(lock));
to not BUG() on all UP systems.Signed-off-by: Bruno Prémont
Signed-off-by: Ben Skeggs
Signed-off-by: Greg Kroah-Hartman
09 Jan, 2015
1 commit
-
commit dc6057ecb39edb34b0461ca55382094410bd257a upstream.
When creating a dumb buffer object using the DRM_IOCTL_MODE_CREATE_DUMB
IOCTL, only the width, height, bpp and flags parameters are inputs. The
caller is not guaranteed to zero out or set handle, pitch and size, so
the driver must not treat these values as possible inputs.Fixes a bug where running the Weston compositor on Tegra DRM would cause
an attempt to allocate a 3 GiB framebuffer to be allocated.Fixes: de2ba664c30f ("gpu: host1x: drm: Add memory manager and fb")
Signed-off-by: Thierry Reding
Signed-off-by: Greg Kroah-Hartman
05 Dec, 2014
1 commit
-
Silence some pch fifo underrun reports and panel locking backtraces,
both cc: stable.* tag 'drm-intel-fixes-2014-12-04' of git://anongit.freedesktop.org/drm-intel:
drm/i915: Unlock panel even when LVDS is disabled
drm/i915: More cautious with pch fifo underruns
03 Dec, 2014
3 commits
-
I was unable too boot 3.18.0-rc6 because of the following kernel
panic in drm_calc_vbltimestamp_from_scanoutpos():[drm] Initialized drm 1.1.0 20060810
[drm] radeon kernel modesetting enabled.
[drm] initializing kernel modesetting (RV100 0x1002:0x515E 0x15D9:0x8080).
[drm] register mmio base: 0xC8400000
[drm] register mmio size: 65536
radeon 0000:0b:01.0: VRAM: 128M 0x00000000D0000000 - 0x00000000D7FFFFFF (16M used)
radeon 0000:0b:01.0: GTT: 512M 0x00000000B0000000 - 0x00000000CFFFFFFF
[drm] Detected VRAM RAM=128M, BAR=128M
[drm] RAM width 16bits DDR
[TTM] Zone kernel: Available graphics memory: 3829346 kiB
[TTM] Zone dma32: Available graphics memory: 2097152 kiB
[TTM] Initializing pool allocator
[TTM] Initializing DMA pool allocator
[drm] radeon: 16M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] PCI GART of 512M enabled (table at 0x0000000037880000).
radeon 0000:0b:01.0: WB disabled
radeon 0000:0b:01.0: fence driver on ring 0 use gpu addr 0x00000000b0000000 and cpu addr 0xffff8800bbbfa000
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] Driver supports precise vblank timestamp query.
[drm] radeon: irq initialized.
[drm] Loading R100 Microcode
radeon 0000:0b:01.0: Direct firmware load for radeon/R100_cp.bin failed with error -2
radeon_cp: Failed to load firmware "radeon/R100_cp.bin"
[drm:r100_cp_init] *ERROR* Failed to load firmware!
radeon 0000:0b:01.0: failed initializing CP (-2).
radeon 0000:0b:01.0: Disabling GPU acceleration
[drm] radeon: cp finalized
BUG: unable to handle kernel NULL pointer dereference at 000000000000025c
IP: [] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320
PGD 0
Oops: 0000 [#1] SMP
Modules linked in:
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.18.0-rc6-4-default #2649
Hardware name: Supermicro X7DB8/X7DB8, BIOS 6.00 07/26/2006
task: ffff880234da2010 ti: ffff880234da4000 task.ti: ffff880234da4000
RIP: 0010:[] [] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320
RSP: 0000:ffff880234da7918 EFLAGS: 00010086
RAX: ffffffff81557890 RBX: 0000000000000000 RCX: ffff880234da7a48
RDX: ffff880234da79f4 RSI: 0000000000000000 RDI: ffff880232e15000
RBP: ffff880234da79b8 R08: 0000000000000000 R09: 0000000000000000
R10: 000000000000000a R11: 0000000000000001 R12: ffff880232dda1c0
R13: ffff880232e1518c R14: 0000000000000292 R15: ffff880232e15000
FS: 0000000000000000(0000) GS:ffff88023fc40000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 000000000000025c CR3: 0000000002014000 CR4: 00000000000007e0
Stack:
ffff880234da79d8 0000000000000286 ffff880232dcbc00 0000000000002480
ffff880234da7958 0000000000000296 ffff880234da7998 ffffffff8151b51d
ffff880234da7a48 0000000032dcbeb0 ffff880232dcbc00 ffff880232dcbc58
Call Trace:
[] ? drm_vma_offset_remove+0x1d/0x110
[] radeon_get_vblank_timestamp_kms+0x38/0x60
[] ? ttm_bo_release_list+0xba/0x180
[] drm_get_last_vbltimestamp+0x41/0x70
[] vblank_disable_and_save+0x73/0x1d0
[] ? try_to_del_timer_sync+0x4f/0x70
[] drm_vblank_cleanup+0x65/0xa0
[] radeon_irq_kms_fini+0x1a/0x70
[] r100_init+0x26e/0x410
[] radeon_device_init+0x7ae/0xb50
[] radeon_driver_load_kms+0x8f/0x210
[] drm_dev_register+0xb5/0x110
[] drm_get_pci_dev+0x8f/0x200
[] radeon_pci_probe+0xad/0xe0
[] local_pci_probe+0x45/0xa0
[] pci_device_probe+0xd1/0x130
[] driver_probe_device+0x12d/0x3e0
[] __driver_attach+0x9b/0xa0
[] ? __device_attach+0x40/0x40
[] bus_for_each_dev+0x63/0xa0
[] driver_attach+0x1e/0x20
[] bus_add_driver+0x180/0x240
[] driver_register+0x64/0xf0
[] __pci_register_driver+0x4c/0x50
[] drm_pci_init+0xf5/0x120
[] ? ttm_init+0x6a/0x6a
[] radeon_init+0x97/0xb5
[] do_one_initcall+0xbc/0x1f0
[] ? __wake_up+0x48/0x60
[] kernel_init_freeable+0x18a/0x215
[] ? initcall_blacklist+0xc0/0xc0
[] ? rest_init+0x80/0x80
[] kernel_init+0xe/0xf0
[] ret_from_fork+0x7c/0xb0
[] ? rest_init+0x80/0x80
Code: 45 ac 0f 88 a8 01 00 00 3b b7 d0 01 00 00 49 89 ff 0f 83 99 01 00 00 48 8b 47 20 48 8b 80 88 00 00 00 48 85 c0 0f 84 cd 01 00 00 8b b1 5c 02 00 00 41 8b 89 58 02 00 00 89 75 98 41 8b b1 60
RIP [] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320
RSP
CR2: 000000000000025c
---[ end trace ad2c0aadf48e2032 ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009It has helped me to add a NULL pointer check that was suggested at
http://lists.freedesktop.org/archives/dri-devel/2014-October/070663.htmlI am not familiar with the code. But the change looks sane
and we need something fast at this stage of 3.18 development.Suggested-by: Helge Deller
Signed-off-by: Petr Mladek
Tested-by: Petr Mladek
Signed-off-by: Alex Deucher
Cc: stable@vger.kernel.org -
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84627
Signed-off-by: Michel Dänzer
Signed-off-by: Alex Deucher
Cc: stable@vger.kernel.org -
Not just the userspace relocs, otherwise we won't wait
for a swapped out page tables to be swapped in again.v2: rebased on Alex current drm-fixes-3.18
Signed-off-by: Christian König
Cc: stable@vger.kernel.org
Signed-off-by: Alex Deucher
02 Dec, 2014
6 commits
-
Otherwise we'll have backtraces in assert_panel_unlocked because the
BIOS locks the register. In the reporter's case this regression was
introduced incommit c31407a3672aaebb4acddf90944a114fa5c8af7b
Author: Chris Wilson
Date: Thu Oct 18 21:07:01 2012 +0100drm/i915: Add no-lvds quirk for Supermicro X7SPA-H
Reported-by: Alexey Orishko
Cc: Alexey Orishko
Cc: stable@vger.kernel.org
Cc: Chris Wilson
Cc: Francois Tigeot
Signed-off-by: Daniel Vetter
Tested-by: Alexey Orishko
Signed-off-by: Jani Nikula -
Apparently PCH fifo underruns are tricky, we have plenty reports that
we see the occasional underrun (especially at boot-up).So for a change let's see what happens when we don't re-enable pch
fifo underrun reporting when the pipe is disabled. This means that the
kernel can't catch pch fifo underruns when they happen (except when
all pipes are on on the pch). But we'll still catch underruns when
disabling the pipe again. So not a terrible reduction in test
coverage.Since the DRM_ERROR is new and hence a regression plan B would be to
revert it back to a debug output. Which would be a lot worse than this
hack for underrun test coverage in the wild. See the referenced
discussions for more.References: http://mid.gmane.org/CA+gsUGRfGe3t4NcjdeA=qXysrhLY3r4CEu7z4bjTwxi1uOfy+g@mail.gmail.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85898
References: https://bugs.freedesktop.org/show_bug.cgi?id=85898
References: https://bugs.freedesktop.org/show_bug.cgi?id=86233
References: https://bugs.freedesktop.org/show_bug.cgi?id=86478
Signed-off-by: Daniel Vetter
Tested-by: lu hua
Reviewed-by: Paulo Zanoni
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula -
Introduced in b440bde74f, however it was added to
the wrong function in nouveau.https://bugzilla.kernel.org/show_bug.cgi?id=86011
Cc: Bjorn Helgaas
CC: stable@vger.kernel.org # v3.15+
Signed-off-by: Dave Airlie -
Just a couple of fixes for the fallout from the fence rework.
* 'linux-3.18' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
drm/nouveau/gf116: remove copy1 engine
drm/nouveau: prevent stale fence->channel pointers, and protect with rcu
drm/nouveau/fifo/g84-: ack non-stall interrupt before handling it -
Indications are that no GF116's actually have a copy engine there, but
actually have the decompression engine. This engine can be made to do
copies, but that should be done separately.Unclear why this didn't turn up on all GF116's, but perhaps the
non-mobile ones came with enough VRAM to not trigger ttm migrations in
test scenarios.Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=85465
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=59168
Cc: stable@vger.kernel.org
Signed-off-by: Ilia Mirkin
Signed-off-by: Ben Skeggs -
Tested-by: Alexandre Courbot
Signed-off-by: Ben Skeggs
