- 26 Feb, 2019 4 commits
-
-
Chris Wilson authored
In selftests/live_hangcheck, we have a lot of tests for resetting simple spinners, but nothing quite prepared us for how the GPU reacted to triggering a reset outside of the safe spinner. These two subtests fill the ring with plain old empty, non-spinning requests, and then triggers a reset. Without a user-payload to blame, these requests will exercise the 'non-started' paths and mostly be replayed verbatim. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by:
Mika Kuoppala <mika.kuoppala@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190226094922.31617-4-chris@chris-wilson.co.uk
-
Chris Wilson authored
Having weaned the interrupt handling off using a single global execution queue, we no longer need to emit a global_seqno. Note that we still have a few assumptions about execution order along engine timelines, but this removes the most obvious artefact! Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190226094922.31617-3-chris@chris-wilson.co.uk
-
Chris Wilson authored
Stop accessing the HWSP to read the global seqno, and stop tracking the mirror in the engine's execution timeline -- it is unused. Signed-off-by:
-
Chris Wilson authored
To determine whether an engine has 'stuck', we simply check whether or not is still on the same seqno for several seconds. To keep this simple mechanism intact over the loss of a global seqno, we can simply add a new global heartbeat seqno instead. As we cannot know the sequence in which requests will then be completed, we use a primitive random number generator instead (with a cycle long enough to not matter over an interval of a few thousand requests between hangcheck samples). The alternative to using a dedicated seqno on every request is to issue a heartbeat request and query its progress through the system. Sadly this requires us to reduce struct_mutex so that we can issue requests without requiring that bkl. v2: And without the extra CS_STALL for the hangcheck seqno -- we don't need strict serialisation with what comes later, we just need to be sure we don't write the hangcheck seqno before our batch is flushed. Signed-off-by:
-
- 25 Feb, 2019 1 commit
-
-
José Roberto de Souza authored
The commit that this patch fixes changed the order of the parameters of MG_DP_MODE() but din't update the callers, breaking type-c on ICL. Fixes: 58106b7d ("drm/i915: Make MG PHY macros semantically consistent") Cc: Clint Taylor <clinton.a.taylor@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Aditya Swarup <aditya.swarup@intel.com> Cc: Manasi navare <manasi.d.navare@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190222202437.6575-1-jose.souza@intel.com
-
- 23 Feb, 2019 1 commit
-
-
Chris Wilson authored
As we no longer have a precise indication of requests queued to an engine, make no presumptions and just sample the ring registers to see if the engine is busy. v2: Report busy while the ring is idling on a semaphore/event. v3: Give the struct a name! v4: Always 0 outside the powerwell; trusting the powerwell is accurate enough for our sampling pmu. v5: Protect against gen7 mmio madness and try to improve grammar Signed-off-by:
-
- 22 Feb, 2019 4 commits
-
-
Rodrigo Vivi authored
Other than LPT, no other PCH needed to differentiate between LP and HP. So let's remove this before we spread this mistake to future platforms. Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
-
Rodrigo Vivi authored
No functional change. Just a reorg to match the preferred behavior. v2: missing else (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Rodrigo Vivi authored
No functional change. Just a reorg to match the preferred behavior. Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Chris Wilson authored
As we disable the log capture events, flush any residual interrupt before we flush and disable the worker. v2: Mika pointed out that it wasn't the worker re-queueing itself, but a rogue irq. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109716Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190221163833.21393-1-chris@chris-wilson.co.uk
-
- 21 Feb, 2019 4 commits
-
-
Chengguang Xu authored
unlikely has already included in IS_ERR(), so just remove redundant likely/unlikely annotation. Signed-off-by:
Chengguang Xu <cgxu519@gmx.com> Reviewed-by:
-
Chris Wilson authored
Annoyingly, struct_mutex was not entirely eliminated from the reset pathway; for reasons of its own, intel_display_resume() requires struct_mutex to prepare the planes it already captured. To avoid the immediate problem of a deadlock between the struct_mutex and the reset srcu, we have to acquire the reset_lock before struct_mutex in i915_gem_fault(). Now any wait underneath struct_mutex will result us in having to forcibly reset all inflight rendering, less than ideal, but better than a deadlock (and will do for the short term). Signed-off-by:
-
Uma Shankar authored
gamma mode mask was not considering the 30th and 31st bits. Due to this state readout was masking these bits, causing a mismatch and false warning, even though the registers were updated correctly. Dropped the gamma mode mask as it is redundant and ideally entire register content should be matching. This resolves the state mismatch warnings. Signed-off-by:
Uma Shankar <uma.shankar@intel.com> Signed-off-by:
-
Chris Wilson authored
drivers/gpu/drm/i915/intel_hdcp.c:92 intel_hdcp2_capable() warn: inconsistent indenting drivers/gpu/drm/i915/intel_hdcp.c:786:5: error: no previous prototype for ‘intel_hdcp_check_link’ Signed-off-by:
-
- 20 Feb, 2019 26 commits
-
-
Sujaritha Sundaresan authored
This aim of this patch is to call guc_disable_communication in all suspend paths. The reason to introduce this is to resolve a bug that occurred due to suspend late not being called in the hibernate devices path. Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by:
Sujaritha Sundaresan <sujaritha.sundaresan@intel.com> Reviewed-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
-
Sujaritha Sundaresan authored
The aim of this patch is to allow enabling and disabling of CTB without requiring the mutex lock. v2: Phasing out ctch_is_enabled function and replacing it with ctch->enabled (Daniele) Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: -
Chris Wilson authored
Introduce a new ABI method for detecting a wedged driver by reporting -EIO from DRM_IOCTL_I915_GEM_CONTEXT_CREATE. This came up in considering how to handle context recovery from userspace. There we wish to create a new context after the original is banned (the clients opts into the no recovery after reset strategy) in order to rebuild the mesa context from scratch. In doing so, if the device was wedged and not the context banned, we would fall into a loop of permanently trying to recreate the context and never making forward progress. This patch would inform the client that we are no longer able to create a context, and the client would have no choice but to abort (or at least inform its callers about the lost device for anv). References: https://lists.freedesktop.org/archives/mesa-dev/2019-February/215469.htmlSigned-off-by:
-
Ville Syrjälä authored
On skl the crc registers were extended to provide plane crcs for up to 7 planes. Add the new crc sources. The current code uses the ivb+ register definitions for skl+ which does happen to work as the plane1, plane2, and dmux/pf bits happen the match what ivb+ had. So no bug in the current code. v2: Drop the unused set_wa parameter (DK) Signed-off-by:
-
Ville Syrjälä authored
DP CRCs don't really work on g4x. If you want any CRCs on DP you must select the CRC source before the port is enabled, otherwise the CRC source select bits simply ignore any writes to them. And once the port is enabled we mustn't change the CRC source select until the port is disabled. That almost works, but not quite :( Eventually the CRC source select bits get permanently stuck one way or the other, and after that a reboot (or possibly a display reset) is needed to get working CRCs on that pipe (not matter which CRC source we try to use). Additionally the DFT scrambler reset bits we're trying to use don't seem to exist on g4x. There are some potentially relevant looking bits in the pipe registers, but when I tried it I got stable looking CRCs without setting any bits for this. If there is a way to make DP CRCs work reliably on g4x, I wasn't able to find it. So let's just remove the broken code we have. Signed-off-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
-
Ville Syrjälä authored
We assume that the index of the string in the crc source names array matches the enum value for the crc source. Let's use named initializers to make sure that is indeed the case even if someone rearranges either the enum or the array. Signed-off-by:
-
Ville Syrjälä authored
The "pipe" and "pf" crc sources are in fact the same thing. Remove the "pf" one. Signed-off-by:
-
Chris Wilson authored
Limit deboosting and boosting to keep ourselves at the extremes when in the respective power modes (i.e. slowly decrease frequencies while in the HIGH_POWER zone and slowly increase frequencies while in the LOW_POWER zone). On idle, we will hit the timeout and drop to the next level quickly, and conversely if busy we expect to hit a waitboost and rapidly switch into max power. This should improve the UX experience by keeping the GPU clocks higher than they ostensibly should be (based on simple busyness) by switching into the INTERACTIVE mode (due to waiting for pageflips) and increasing clocks via waitboosting. This will incur some additional power, our saving grace should be rc6 and powergating to keep the extra current draw in check. Food for future thought would be deadline scheduling? If we know certain contexts (high priority compositors) absolutely must hit the next vblank then we can raise the frequencies ahead of time. Part of this is covered by per-context frequencies, where userspace is given control over the frequency range they want the GPU to execute at (for largely the same problem as this, where the workload is very latency sensitive but at the EI level appears mostly idle). Indeed, the per-context series does extend the modeset boosting to include a frequency range tweak which seems applicable to solving this jittery UX behaviour. Reported-by:
Lyude Paul <lyude@redhat.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109408 References: 0d55babc ("drm/i915: Drop stray clearing of rps->last_adj") References: 60548c55 ("drm/i915: Interactive RPS mode") Signed-off-by:
-
Ramalingam C authored
HDCP transmitter is supposed to indicate the HDCP encryption status of the link through enc_en signals in a window of time called "window of opportunity" defined by HDCP HDMI spec. But on KBL this timing of signalling has an issue. To fix the issue this WA of resetting the signalling is required. v2: WA is moved into the toggle_signalling [Daniel] v3: Commit msg is rewritten with more information v4: Reviewed-by Daniel. Signed-off-by:
Ramalingam C <ramalingam.c@intel.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Ramalingam C authored
Implements the Waitqueue is created to wait for CP_IRQ Signaling the CP_IRQ arrival through atomic variable. For applicable DP HDCP2.2 msgs read wait for CP_IRQ. As per HDCP2.2 spec "HDCP Transmitters must process CP_IRQ interrupts when they are received from HDCP Receivers" Without CP_IRQ processing, DP HDCP2.2 H_Prime msg was getting corrupted while reading it based on corresponding status bit. This creates the random failures in reading the DP HDCP2.2 msgs. v2: CP_IRQ arrival is tracked based on the atomic val inc [daniel] Recording the reviewed-by Daniel from IRC. Signed-off-by:
-
Ramalingam C authored
Implements the HDMI adaptation specific HDCP2.2 operations. Basically these are DDC read and write for authenticating through HDCP2.2 messages. v2: Rebased. v3: No more special handling of Gmbus burst read for AKE_SEND_CERT. Style fixed with few naming. [Uma] %s/PARING/PAIRING v4: msg_sz is initialized at definition. Lookup table is defined for HDMI HDCP2.2 msgs [Daniel]. v5: Rebased. v6: Make a function as inline [Uma] %s/uintxx_t/uxx v7: Errors due to sinks are reported as DEBUG logs. Adjust to the new mei interface. v8: ARRAY_SIZE for the # of array members [Jon & Daniel]. hdcp adaptation is added as a const in the hdcp_shim [Daniel] Signed-off-by:
-
Ramalingam C authored
Implements the DP adaptation specific HDCP2.2 functions. These functions perform the DPCD read and write for communicating the HDCP2.2 auth message back and forth. v2: wait for cp_irq is merged with this patch. Rebased. v3: wait_queue is used for wait for cp_irq [Chris Wilson] v4: Style fixed. %s/PARING/PAIRING Few style fixes [Uma] v5: Lookup table for DP HDCP2.2 msg details [Daniel]. Extra lines are removed. v6: Rebased. v7: Fixed some regression introduced at v5. [Ankit] Macro HDCP_2_2_RX_CAPS_VERSION_VAL is reused [Uma] Converted a function to inline [Uma] %s/uintxx_t/uxx v8: Error due to the sinks are reported as DEBUG logs. Adjust to the new mei interface. v9: ARRAY_SIZE for no of array members [Jon & Daniel] return of the wait_for_cp_irq is made as void [Daniel] Wait for HDCP2.2 msg is done based on polling the reg bit than CP_IRQ based. [Daniel] hdcp adaptation is added as a const in the hdcp_shim [Daniel] v10: config_stream_type is redefined [Daniel] DP Errata specific defines are moved into intel_dp.c. Signed-off-by:Ankit K Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by:
-
Ramalingam C authored
Since DP ERRATA message is not defined at spec, those structure definition is removed from drm_hdcp.h Signed-off-by:
Dave Airlie <airlied@gmail.com> Signed-off-by:
-
Ramalingam C authored
When repeater notifies a downstream topology change, this patch reauthenticate the repeater alone without disabling the hdcp encryption. If that fails then complete reauthentication is executed. v2: Rebased. v3: Typo in commit msg is fixed [Uma] v4: Rebased as part of patch reordering. Minor style fixes. v5: Rebased. v6: Rebased. v7: Errors due to sinks are reported as DEBUG logs. Signed-off-by:
-
Ramalingam C authored
Implements the link integrity check once in 500mSec. Once encryption is enabled, an ongoing Link Integrity Check is performed by the HDCP Receiver to check that cipher synchronization is maintained between the HDCP Transmitter and the HDCP Receiver. On the detection of synchronization lost, the HDCP Receiver must assert the corresponding bits of the RxStatus register. The Transmitter polls the RxStatus register and it may initiate re-authentication. v2: Rebased. v3: enum check_link_response is used check the link status [Uma] v4: Rebased as part of patch reordering. v5: Required members of intel_hdcp is defined [Sean Paul] v6: hdcp2_check_link is cancelled at required places. v7: Rebased for the component i/f changes. Errors due to the sinks are reported as DEBUG logs. v8: hdcp_check_work is used for both hdcp1 and hdcp2 check_link [Daniel] hdcp2.2 encryption status check is put under WARN_ON [Daniel] drm_hdcp.h changes are moved into separate patch [Daniel] v9: enum check_link_status is defined at intel_drv.h [Daniel] Signed-off-by:
-
Ramalingam C authored
Time period for HDCP2.2 link check. Signed-off-by:
-
Ramalingam C authored
Implements the HDCP2.2 repeaters authentication steps such as verifying the downstream topology and sending stream management information. v2: Rebased. v3: -EINVAL is returned for topology error and rollover scenario. Endianness conversion func from drm_hdcp.h is used [Uma] v4: Rebased as part of patches reordering. Defined the mei service functions [Daniel] v5: Redefined the mei service functions as per comp redesign. v6: %s/uintxx_t/uxx Check for comp_master is removed. v7: Adjust to the new mei interface. style issue fixed. v8: drm_hdcp.h change is moved into separate patch [Daniel] v9: %s/__swab16/cpu_to_be16. [Tomas] Reviewed-by Uma. Signed-off-by:
-
Ramalingam C authored
Implements HDCP2.2 authentication for hdcp2.2 receivers, with following steps: Authentication and Key exchange (AKE). Locality Check (LC). Session Key Exchange(SKE). DP Errata for stream type configuration for receivers. At AKE, the HDCP Receiver’s public key certificate is verified by the HDCP Transmitter. A Master Key k m is exchanged. At LC, the HDCP Transmitter enforces locality on the content by requiring that the Round Trip Time (RTT) between a pair of messages is not more than 20 ms. At SKE, The HDCP Transmitter exchanges Session Key ks with the HDCP Receiver. In DP HDCP2.2 encryption and decryption logics use the stream type as one of the parameter. So Before enabling the Encryption DP HDCP2.2 receiver needs to be communicated with stream type. This is added to spec as ERRATA. This generic implementation is complete only with the hdcp2 specific functions defined at hdcp_shim. v2: Rebased. v3: %s/PARING/PAIRING Coding style fixing [Uma] v4: Rebased as part of patch reordering. Defined the functions for mei services. [Daniel] v5: Redefined the mei service functions as per comp redesign. Required intel_hdcp members are defined [Sean Paul] v6: Typo of cipher is Fixed [Uma] %s/uintxx_t/uxx Check for comp_master is removed. v7: Adjust to the new interface. Avoid using bool structure members. [Tomas] v8: Rebased. v9: bool is used in struct intel_hdcp [Daniel] config_stream_type is redesigned [Daniel] Reviewed-by Uma. Signed-off-by:
-
Ramalingam C authored
Considering that HDCP2.2 is more secure than HDCP1.4, When a setup supports HDCP2.2 and HDCP1.4, HDCP2.2 will be enabled. When HDCP2.2 enabling fails and HDCP1.4 is supported, HDCP1.4 is enabled. This change implements a sequence of enabling and disabling of HDCP2.2 authentication and HDCP2.2 port encryption. v2: Included few optimization suggestions [Chris Wilson] Commit message is updated as per the rebased version. intel_wait_for_register is used instead of wait_for. [Chris Wilson] v3: Extra comment added and Style issue fixed [Uma] v4: Rebased as part of patch reordering. HDCP2 encryption status is tracked. HW state check is moved into WARN_ON [Daniel] v5: Redefined the mei service functions as per comp redesign. Merged patches related to hdcp2.2 enabling and disabling [Sean Paul]. Required shim functionality is defined [Sean Paul] v6: Return values are handles [Uma] Realigned the code. Check for comp_master is removed. v7: HDCP2.2 is attempted only if mei interface is up. Adjust to the new interface Avoid bool usage in struct [Tomas] v8: mei_binded status check is removed. %s/hdcp2_in_use/hdcp2_encrypted v9: bool is used in struct intel_hdcp. [Daniel] v10: panel is replaced with sink [Uma] Mei interface decided the hdcp2_capability. WARN_ON if hdcp_enable is called when hdcp state is ENABLED. Reviewed-by Uma. Signed-off-by:
-
Ramalingam C authored
"hdcp_encrypted" flag is defined to denote the HDCP1.4 encryption status. This SW tracking is used to determine the need for real hdcp1.4 disable and hdcp_check_link upon CP_IRQ. On CP_IRQ we filter the CP_IRQ related to the states like Link failure and reauthentication req etc and handle them in hdcp_check_link. CP_IRQ corresponding to the authentication msg availability are ignored. WARN_ON is added for the abrupt stop of HDCP encryption of a port. v2: bool is used in struct for the cleaner coding. [Daniel] check_link work_fn is scheduled for cp_irq handling [Daniel] v3: rebased. Signed-off-by:
-
Ramalingam C authored
Defining the mei-i915 interface functions and initialization of the interface. v2: Adjust to the new interface changes. [Tomas] Added further debug logs for the failures at MEI i/f. port in hdcp_port data is equipped to handle -ve values. v3: mei comp is matched for global i915 comp master. [Daniel] In hdcp_shim hdcp_protocol() is replaced with const variable. [Daniel] mei wrappers are adjusted as per the i/f change [Daniel] v4: port initialization is done only at hdcp2_init only [Danvet] v5: I915 registers a subcomponent to be matched with mei_hdcp [Daniel] v6: HDCP_disable for all connectors incase of comp_unbind. Tear down HDCP comp interface at i915_unload [Daniel] v7: Component init and fini are moved out of connector ops [Daniel] hdcp_disable is not called from unbind. [Daniel] v8: subcomponent name is dropped as it is already merged. Signed-off-by:
-
Ramalingam C authored
Add the HDCP2.2 initialization to the existing HDCP1.4 stack. v2: mei interface handle is protected with mutex. [Chris Wilson] v3: Notifiers are used for the mei interface state. v4: Poll for mei client device state Error msg for out of mem [Uma] Inline req for init function removed [Uma] v5: Rebase as Part of reordering. Component is used for the I915 and MEI_HDCP interface [Daniel] v6: HDCP2.2 uses the I915 component master to communicate with mei_hdcp - [Daniel] Required HDCP2.2 variables defined [Sean Paul] v7: intel_hdcp2.2_init returns void [Uma] Realigning the codes. v8: Avoid using bool structure members. MEI interface related changes are moved into separate patch. Commit msg is updated accordingly. intel_hdcp_exit is defined and used from i915_unload v9: Movement of the hdcp_check_link is moved to new patch [Daniel] intel_hdcp2_exit is removed as mei_comp will be unbind in i915_unload. v10: bool is used in struct to make coding simpler. [Daniel] hdmi hdcp init is placed correctly after encoder attachment. v11: hdcp2_capability check is moved into hdcp.c [Tomas] Signed-off-by:
-
Ramalingam C authored
All HDCP1.4 routines are gathered together, followed by the generic functions those can be extended for HDCP2.2 too. Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Signed-off-by:
-
Chris Wilson authored
The idea of taking the reset lock around writing the fence register was to serialise the mmio write we also perform during the reset where those registers get clobbered. However, the lock is overkill as write tearing between reset and fence_update() is harmless; the final value of the fence register is the same. A race between revoke_fences() and fence_update() is also harmless at this point as on the fault path where this is necessary, we acquire the reset lock to coordinate ourselves in the upper layer. The danger of acquiring the reset lock again in fence_update() is that we may recurse from the shrinker along the i915_gem_fault() path. <4> [125.739646] ============================================ <4> [125.739652] WARNING: possible recursive locking detected <4> [125.739659] 5.0.0-rc6-ga6e4cbf00557-drmtip_223+ #1 Tainted: G U <4> [125.739666] -------------------------------------------- <4> [125.739672] gem_mmap_gtt/1017 is trying to acquire lock: <4> [125.739679] 00000000a730190a (&dev_priv->gpu_error.reset_backoff_srcu){+.+.}, at: i915_reset_trylock+0x0/0x310 [i915] <4> [125.739848] but task is already holding lock: <4> [125.739854] 00000000a730190a (&dev_priv->gpu_error.reset_backoff_srcu){+.+.}, at: i915_reset_trylock+0x192/0x310 [i915] <4> [125.739918] other info that might help us debug this: <4> [125.739925] Possible unsafe locking scenario: <4> [125.739930] CPU0 <4> [125.739934] ---- <4> [125.739937] lock(&dev_priv->gpu_error.reset_backoff_srcu); <4> [125.739944] lock(&dev_priv->gpu_error.reset_backoff_srcu); <4> [125.739950] *** DEADLOCK *** <4> [125.739958] May be due to missing lock nesting notation <4> [125.739966] 5 locks held by gem_mmap_gtt/1017: <4> [125.739972] #0: 00000000471f682c (&mm->mmap_sem){++++}, at: __do_page_fault+0x133/0x500 <4> [125.739987] #1: 0000000026542685 (&dev->struct_mutex){+.+.}, at: i915_gem_fault+0x1f6/0x860 [i915] <4> [125.740061] #2: 00000000a730190a (&dev_priv->gpu_error.reset_backoff_srcu){+.+.}, at: i915_reset_trylock+0x192/0x310 [i915] <4> [125.740126] #3: 00000000c828eb4f (fs_reclaim){+.+.}, at: fs_reclaim_acquire.part.25+0x0/0x30 <4> [125.740140] #4: 000000002d360d65 (shrinker_rwsem){++++}, at: shrink_slab+0x1cb/0x2c0 <4> [125.740151] stack backtrace: <4> [125.740159] CPU: 1 PID: 1017 Comm: gem_mmap_gtt Tainted: G U 5.0.0-rc6-ga6e4cbf00557-drmtip_223+ #1 <4> [125.740170] Hardware name: Dell Inc. OptiPlex 745 /0GW726, BIOS 2.3.1 05/21/2007 <4> [125.740180] Call Trace: <4> [125.740189] dump_stack+0x67/0x9b <4> [125.740199] __lock_acquire+0xc75/0x1b00 <4> [125.740209] ? arch_tlb_finish_mmu+0x2a/0xa0 <4> [125.740216] ? tlb_finish_mmu+0x1a/0x30 <4> [125.740222] ? zap_page_range_single+0xe2/0x130 <4> [125.740230] ? lock_acquire+0xa6/0x1c0 <4> [125.740237] lock_acquire+0xa6/0x1c0 <4> [125.740296] ? i915_clear_error_registers+0x280/0x280 [i915] <4> [125.740357] i915_reset_trylock+0x44/0x310 [i915] <4> [125.740417] ? i915_clear_error_registers+0x280/0x280 [i915] <4> [125.740426] ? lockdep_hardirqs_on+0xe0/0x1b0 <4> [125.740434] ? _raw_spin_unlock_irqrestore+0x39/0x60 <4> [125.740499] fence_update+0x218/0x470 [i915] <4> [125.740571] i915_vma_unbind+0xa6/0x550 [i915] <4> [125.740640] i915_gem_object_unbind+0xfa/0x190 [i915] <4> [125.740711] i915_gem_shrink+0x2dc/0x590 [i915] <4> [125.740722] ? ___preempt_schedule+0x16/0x18 <4> [125.740792] ? i915_gem_shrinker_scan+0xc9/0x130 [i915] <4> [125.740861] i915_gem_shrinker_scan+0xc9/0x130 [i915] <4> [125.740870] do_shrink_slab+0x143/0x3f0 <4> [125.740878] shrink_slab+0x228/0x2c0 <4> [125.740886] shrink_node+0x167/0x450 <4> [125.740894] do_try_to_free_pages+0xc4/0x340 <4> [125.740902] try_to_free_pages+0xdc/0x2e0 <4> [125.740911] __alloc_pages_nodemask+0x662/0x1110 <4> [125.740921] ? reacquire_held_locks+0xb5/0x1b0 <4> [125.740928] ? reacquire_held_locks+0xb5/0x1b0 <4> [125.740986] ? i915_reset_trylock+0x192/0x310 [i915] <4> [125.741045] ? i915_memcpy_init_early+0x30/0x30 [i915] <4> [125.741054] pte_alloc_one+0x12/0x70 <4> [125.741060] __pte_alloc+0x11/0xf0 <4> [125.741067] apply_to_page_range+0x37e/0x440 <4> [125.741127] remap_io_mapping+0x6c/0x100 [i915] <4> [125.741196] i915_gem_fault+0x5a9/0x860 [i915] <4> [125.741204] ? ptlock_alloc+0x15/0x30 <4> [125.741212] __do_fault+0x2c/0xb0 <4> [125.741218] __handle_mm_fault+0x8ee/0xfa0 <4> [125.741227] handle_mm_fault+0x196/0x3a0 <4> [125.741235] __do_page_fault+0x246/0x500 <4> [125.741243] ? page_fault+0x8/0x30 <4> [125.741250] page_fault+0x1e/0x30 <4> [125.741256] RIP: 0033:0x55d0cc456e12 <4> [125.741264] Code: b0 df ff ff 89 c2 8b 85 70 df ff ff 01 c2 8b 85 70 df ff ff 48 98 48 8d 0c 85 00 00 00 00 48 8b 85 e0 df ff ff 48 01 c8 f7 d2 <89> 10 83 85 70 df ff ff 01 81 bd 70 df ff ff ff 03 00 00 7e be 48 <4> [125.741280] RSP: 002b:00007ffc1bab7ab0 EFLAGS: 00010206 <4> [125.741287] RAX: 00007fc787cb6000 RBX: 0000000000000000 RCX: 0000000000000000 <4> [125.741295] RDX: 00000000ffffffff RSI: 0000000000005401 RDI: 0000000000000002 <4> [125.741303] RBP: 00007ffc1bab9b70 R08: 00007ffc1bab7920 R09: 000000000000001b <4> [125.741310] R10: 7165722074736554 R11: 0000000000000246 R12: 000055d0cc454a80 <4> [125.741318] R13: 00007ffc1bab9f60 R14: 0000000000000000 R15: 0000000000000000 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109665Signed-off-by: -
Chris Wilson authored
At a few points in our uABI, we check to see if the driver is wedged and report -EIO back to the user in that case. However, as we perform the check and reset asynchronously (where once before they were both serialised by the struct_mutex), we may instead see the temporary wedging used to cancel inflight rendering to avoid a deadlock during reset (caused by either us timing out in our reset handler, i915_wedge_on_timeout or with malice aforethought in intel_reset_prepare for a stuck modeset). If we suspect this is the case, that is we see a wedged driver *and* reset in progress, then wait until the reset is resolved before reporting upon the wedged status. v2: might_sleep() (Mika) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109580Signed-off-by:
-
Joonas Lahtinen authored
Signed-off-by:Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
