On 1/13/2023 01:22, Tvrtko Ursulin wrote:
On 12/01/2023 20:59, John Harrison wrote:
On 1/12/2023 02:15, Tvrtko Ursulin wrote:
On 12/01/2023 02:53, john.c.harri...@intel.com wrote:
From: John Harrison
Engine resets are supposed to never fail. But in the case when one
does (due to unknown reas
== Series Details ==
Series: vfio: fix potential deadlock on vfio group lock (rev3)
URL : https://patchwork.freedesktop.org/series/112759/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12585 -> Patchwork_112759v3
Summary
--
Currently it is possible that the final put of a KVM reference comes from
vfio during its device close operation. This occurs while the vfio group
lock is held; however, if the vfio device is still in the kvm device list,
then the following call chain could result in a deadlock:
kvm_put_kvm
-> k
== Series Details ==
Series: vfio: fix potential deadlock on vfio group lock (rev2)
URL : https://patchwork.freedesktop.org/series/112759/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12583 -> Patchwork_112759v2
Summary
--
== Series Details ==
Series: drm/i915: Implement UHBR bandwidth check
URL : https://patchwork.freedesktop.org/series/112806/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12582_full -> Patchwork_112806v1_full
Summary
--
== Series Details ==
Series: drm/i915/selftests: Unwind hugepages to drop wakeref on error (rev2)
URL : https://patchwork.freedesktop.org/series/112801/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12582_full -> Patchwork_112801v2_full
== Series Details ==
Series: DRM_USE_DYNAMIC_DEBUG regression (rev2)
URL : https://patchwork.freedesktop.org/series/111651/
State : failure
== Summary ==
Error: patch
https://patchwork.freedesktop.org/api/1.0/series/111651/revisions/2/mbox/ not
applied
Applying: test-dyndbg: fixup CLASSMAP u
On 1/13/2023 09:46, Hellstrom, Thomas wrote:
On Fri, 2023-01-13 at 09:51 +, Tvrtko Ursulin wrote:
On 12/01/2023 20:40, John Harrison wrote:
On 1/12/2023 02:01, Tvrtko Ursulin wrote:
On 12/01/2023 02:53, john.c.harri...@intel.com wrote:
From: John Harrison
There was a report of error cap
On 1/12/23 23:36, Arun R Murthy wrote:
> DP2.0 E11 defines a new register to facilitate SDP error detection by a
> 128B/132B capable DPRX device.
>
> Signed-off-by: Arun R Murthy
> ---
> include/drm/display/drm_dp.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/include/drm/disp
On Fri, Jan 13, 2023 at 03:09:01PM -0500, Matthew Rosato wrote:
> > This still doesn't seem right, another thread could have incr'd the
> > open_count already
> >
> > This has to be done at the moment open_count is decremented to zero,
> > while still under the original lock.
>
> Hmm.. Fair.
On 1/13/23 1:52 PM, Jason Gunthorpe wrote:
> On Fri, Jan 13, 2023 at 12:11:32PM -0500, Matthew Rosato wrote:
>> @@ -462,9 +520,19 @@ static inline void vfio_device_pm_runtime_put(struct
>> vfio_device *device)
>> static int vfio_device_fops_release(struct inode *inode, struct file *filep)
>> {
>
On 1/13/2023 13:28, Lyude Paul wrote:
On Fri, 2023-01-13 at 11:25 +0100, Daniel Vetter wrote:
On Fri, Jan 13, 2023 at 12:16:57PM +0200, Jani Nikula wrote:
Cc: intel-gfx, drm maintainers
Please have the courtesy of Cc'ing us for changes impacting us, and
maybe try to involve us earlier instead
The inner func has a base arg which is unused in the body, so theres
no point in having the inner fn.
Its one-time purpose was to expose a wider interface to the internal
caller: dynamic_debug_init(), to allow communicating each module's
offset in the builtin _ddebug[] table.
That purpose was obs
__jump_label_patch currently will "crash the box" if it finds a
jump_entry not as expected. ISTM this overly harsh; it doesn't
distinguish between "alternate/opposite" state, and truly
"insane/corrupted".
The "opposite" (but well-formed) state is a milder mis-initialization
problem, and some less
The dyndbg-to-trace feature is WIP, and not in mainline, so the
presence of the interface to use/test it is unhelpful/confusing.
So define DYNDBG_CLASSMAP_PARAM_T() as DYNDBG_CLASSMAP_PARAM() or
blank, depending upon ifdef DYDBG_TRACE, and update 4 params
controlling the T-flag to use it.
Signed-
ddebug_apply_class_bitmap() does not alter its 2 bitmap args, make
this guarantee in the interface.
NOTE: the bitmap is also available in the dcp arg, but the 2 vars
serve a 2nd purpose; the CLASS_TYPE callers use them to translate
levels into their underlying disjoint representation.
Signed-off-
lib/test_dynamic_debug.c is used to build 2 modules:
test_dynamic_debug.ko and test_dynamic_debug_submod.ko
Define DEBUG only in the main module, not in the submod. Its purpose
is to insure that prdbgs are enabled by default, so that a modprobe
without params actually logs something, showing that
Change function's 1st arg-type, by derefing in the caller.
The fn doesnt need any other fields in the old type.
no functional change.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynami
patch 1 in this series fixed a CLASSMAP usage error, this improves the
api so that misuse is less likely.
changes here:
0- Add William Swanson's public domain map macro:
https://github.com/swansontec/map-macro/blob/master/map.h
this makes 1 possible.
1- classnames were formerly specified a
CONFIG_DRM_USE_DYNAMIC_DEBUG=y has a regression; drm subsystem
modules, which depend upon drm.ko and use the drm.debug API, do not
get enabled when __drm_debug is set by `modprobe drm debug=0x1f`.
With =N, __drm_debug is checked before logging the msg, so the
end-of-modprobe debug=$init affected a
Original name was a punt; but the macro is maybe general enough to put
in the API later. Rename and improve the macro towards that end.
Also tweak internal name constructed in the macro, to add a '_'
between the name components. This changes the .i file only.
no functional change.
Signed-off-b
Cited commit uses stale macro name, fix this, and explain better.
When DRM_USE_DYNAMIC_DEBUG=y, DYNDBG_CLASSMAP_DEFINE() maps DRM_UT_*
onto BITs in drm.debug. This still uses enum drm_debug_category, but
it is somewhat indirect, with the ordered set of DRM_UT_* enum-vals.
This requires that the m
ddebug_apply_class_bitmap() currently applies the class settings to
all modules, by calling ddebug_exec_queries(query, NULL), where NULL
is wildcard ("*" does the same). Make it more selective, by adding
query_module param, and passing it into ddebug_exec_queries, instead
of the NULL.
This allows
Drop macro args after _var. Since DYNDBG_CLASSMAP_USE no longer
forwards to DYNDBG_CLASSMAP_DEFINE, it doesn't need those args to
forward. Keep only the _var arg, which is the extern'd struct
classmap with all the class info.
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.
DECLARE_DYNDBG_CLASSMAP's job was to allow modules to declare the debug
classes/categories they want dyndbg to >control on their behalf. Its
args give the class-names, their mapping to class_ids, and the sysfs
interface style (usually a class-bitmap). Modules wanting a drm.debug
style knob need t
Now that the DECLARE_DYNDBG_CLASSMAP macro has been split into
DYNDBG_CLASSMAP_DEFINE and DYNDBG_CLASSMAP_USE, lets differentiate
them according to their separate jobs.
Dyndbg's existing __dyndbg_classes[] section does:
. catalogs the classmaps defined by the module (or builtin modules)
. authori
currently, for verbose=3, this is logged:
dyndbg: query 0: "class DRM_UT_CORE +p" mod:*
dyndbg: split into words: "class" "DRM_UT_CORE" "+p"
dyndbg: op='+'
dyndbg: flags=0x1
dyndbg: *flagsp=0x1 *maskp=0x
dyndbg: parsed: func="" file="" module="" format="" lineno=0-0
class=DRM_UT_C
ARRAY_SIZE works here, since array decl is complete.
Signed-off-by: Jim Cromie
---
include/linux/dynamic_debug.h | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index bf47bcfad8e6..81b643ab7f6e 100644
--- a/incl
Split param_set_dyndbg_classes() to interface-preserving wrapper &
inner function with an additional param: mod_name, which is passed
into ddebug_apply_class_bitmap() to allow adjusting a single module's
prdbgs. Wrapper passes NULL, preserving current behavior for now.
no functional change.
Sign
Classmaps are stored/linked in a section/array, but are each added to
the module's ddebug_table.maps list-head.
This is unnecessary; even when ddebug_attach_classmap() is handling
the builtin section (with classmaps for multiple builtin modules), its
contents are ordered, so a module's possibly mu
Dyndbg is required to enable prdbgs at compile-time if DEBUG is
defined. Show this works; add the defn to test_dynamic_debug.c,
and manually inspect/verify its effect at module load:
[ 15.292810] dyndbg: module:test_dynamic_debug attached 4 classes
[ 15.293189] dyndbg: 32 debug prints in mod
more careful reading of test output reveals:
lib/test_dynamic_debug.c:103 [test_dynamic_debug]do_cats =pmf "doing
categories\n"
lib/test_dynamic_debug.c:105 [test_dynamic_debug]do_cats =p "LOW msg\n"
class:MID
lib/test_dynamic_debug.c:106 [test_dynamic_debug]do_cats =p "MID msg\n" class:HI
lib/t
Hi everyone,
DRM_USE_DYNAMIC_DEBUG=y has a regression enabling drm.debug in drivers
It is due to a chicken-egg problem loading modules; on `modprobe
i915`, drm is loaded 1st, and drm/parameters/debug is set. When
drm_debug_enabled() tested it at runtime, things just worked.
But with DRM_USE_DYN
On Fri, 2023-01-13 at 11:25 +0100, Daniel Vetter wrote:
> On Fri, Jan 13, 2023 at 12:16:57PM +0200, Jani Nikula wrote:
> >
> > Cc: intel-gfx, drm maintainers
> >
> > Please have the courtesy of Cc'ing us for changes impacting us, and
> > maybe try to involve us earlier instead of surprising us li
== Series Details ==
Series: drm/i915: update src and dst scaler limits for display ver 12 and 13
(rev2)
URL : https://patchwork.freedesktop.org/series/112213/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12580_full -> Patchwork_112213v2_full
On Wed, Jan 11, 2023 at 09:20:40PM +0530, Deepak R Varma wrote:
> This patch series proposes to replace a combination of
> DEFINE_SIMPLE_ATTRIBUTE() +
> debugfs_create_file() by a combination of DEFINE_DEBUGFS_ATTRIBUTE() +
> debugfs_create_file_unsafe(). The change reduced overhead in terms of ma
On Fri, Jan 13, 2023 at 12:11:32PM -0500, Matthew Rosato wrote:
> @@ -462,9 +520,19 @@ static inline void vfio_device_pm_runtime_put(struct
> vfio_device *device)
> static int vfio_device_fops_release(struct inode *inode, struct file *filep)
> {
> struct vfio_device *device = filep->privat
On Fri, Jan 13, 2023 at 11:29:57AM -0700, jim.cro...@gmail.com wrote:
> On Wed, Jan 11, 2023 at 4:09 PM Daniel Vetter wrote:
> >
> > On Mon, Dec 05, 2022 at 05:34:07PM -0700, Jim Cromie wrote:
> > > Hi everyone,
> > >
> > > DRM_USE_DYNAMIC_DEBUG=y has a regression on rc-*
> > >
> > > Regression is
On Wed, Jan 11, 2023 at 4:09 PM Daniel Vetter wrote:
>
> On Mon, Dec 05, 2022 at 05:34:07PM -0700, Jim Cromie wrote:
> > Hi everyone,
> >
> > DRM_USE_DYNAMIC_DEBUG=y has a regression on rc-*
> >
> > Regression is due to a chicken-egg problem loading modules; on
> > `modprobe i915`, drm is loaded 1
On Tue, Jan 10, 2023 at 05:48:45PM -0800, Zanoni, Paulo R wrote:
On Mon, 2022-12-12 at 15:15 -0800, Niranjana Vishwanathapura wrote:
Add support for handling out fence for vm_bind call.
v2: Reset vma->vm_bind_fence.syncobj to NULL at the end
of vm_bind call.
v3: Remove vm_unbind out fence u
== Series Details ==
Series: vfio: fix potential deadlock on vfio group lock (rev2)
URL : https://patchwork.freedesktop.org/series/112759/
State : warning
== Summary ==
Error: dim checkpatch failed
3ddf9fe96184 vfio: fix potential deadlock on vfio group lock
-:109: CHECK:BRACES: Blank lines ar
On Fri, 2023-01-13 at 09:51 +, Tvrtko Ursulin wrote:
>
> On 12/01/2023 20:40, John Harrison wrote:
> > On 1/12/2023 02:01, Tvrtko Ursulin wrote:
> > > On 12/01/2023 02:53, john.c.harri...@intel.com wrote:
> > > > From: John Harrison
> > > >
> > > > There was a report of error captures occurr
Currently it is possible that the final put of a KVM reference comes from
vfio during its device close operation. This occurs while the vfio group
lock is held; however, if the vfio device is still in the kvm device list,
then the following call chain could result in a deadlock:
kvm_put_kvm
-> k
== Series Details ==
Series: Enable YCbCr420 for VDSC
URL : https://patchwork.freedesktop.org/series/112777/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12579_full -> Patchwork_112777v1_full
Summary
---
**SUCCESS**
On 1/13/23 05:25, Daniel Vetter wrote:
> On Fri, Jan 13, 2023 at 12:16:57PM +0200, Jani Nikula wrote:
>>
>> Cc: intel-gfx, drm maintainers
>>
>> Please have the courtesy of Cc'ing us for changes impacting us, and
>> maybe try to involve us earlier instead of surprising us like
>> this. Looks lik
== Series Details ==
Series: series starting with [1/2] drm: Add SDP Error Detection Configuration
Register
URL : https://patchwork.freedesktop.org/series/112774/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12579_full -> Patchwork_112774v1_full
=
On Thu, Jan 12, 2023 at 04:51:36PM -0500, Matthew Rosato wrote:
> Yep, thanks. I will surround this bit of code with
>
> mutex_lock(&device->dev_set->lock);
> ..
> mutex_unlock(&device->dev_set->lock);
Don't do it like that, copy the kvm out of the struct device to the
stack and NULL it. Then d
On Fri, Jan 13, 2023 at 02:05:14AM +, Sean Christopherson wrote:
> On Thu, Jan 12, 2023, Alex Williamson wrote:
> > On Thu, 12 Jan 2023 23:29:53 +
> > Sean Christopherson wrote:
> >
> > > On Thu, Jan 12, 2023, Matthew Rosato wrote:
> > > > On 1/12/23 4:05 PM, Alex Williamson wrote:
> >
On Fri, Jan 13, 2023 at 03:06:28PM +0200, Stanislav Lisovskiy wrote:
> According to spec, we should check if output_bpp * pixel_rate is less
> than DDI clock * 72, if UHBR is used.
>
> HSDES: 1406899791
> BSPEC: 49259
>
> v2: - Removed wrong comment(Rodrigo Vivi)
> - Added HSDES to the commit
On Wed, Jan 11, 2023 at 03:59:14PM +, Manna, Animesh wrote:
>
>
> > -Original Message-
> > From: Intel-gfx On Behalf Of Ville
> > Syrjala
> > Sent: Friday, December 16, 2022 6:08 AM
> > To: intel-gfx@lists.freedesktop.org
> > Subject: [Intel-gfx] [PATCH 12/13] drm/i915/dsb: Define mo
== Series Details ==
Series: drm/i915: Implement UHBR bandwidth check
URL : https://patchwork.freedesktop.org/series/112806/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12582 -> Patchwork_112806v1
Summary
---
**SUC
On 13/01/2023 03:15, Dixit, Ashutosh wrote:
On Thu, 12 Jan 2023 18:27:52 -0800, Vinay Belgaumkar wrote:
Reading current root sysfs entries gives a min/max of all
GTs. Updating this so we return default (GT0) values when root
level sysfs entries are accessed, instead of min/max for the card.
T
== Series Details ==
Series: drm/i915/mtl: Connect root sysfs entries to GT0
URL : https://patchwork.freedesktop.org/series/112767/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12578_full -> Patchwork_112767v1_full
Summary
== Series Details ==
Series: drm/i915/selftests: Unwind hugepages to drop wakeref on error (rev2)
URL : https://patchwork.freedesktop.org/series/112801/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12582 -> Patchwork_112801v2
==
== Series Details ==
Series: drm/i915/gt: Move LSC_CHICKEN_BIT* workarounds to correct function
URL : https://patchwork.freedesktop.org/series/112764/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12578_full -> Patchwork_112764v1_full
==
According to spec, we should check if output_bpp * pixel_rate is less
than DDI clock * 72, if UHBR is used.
HSDES: 1406899791
BSPEC: 49259
v2: - Removed wrong comment(Rodrigo Vivi)
- Added HSDES to the commit msg(Rodrigo Vivi)
- Moved UHBR check to the MST specific code
v3: - Changed com
On 1/12/23 3:38 PM, Matthew Rosato wrote:
> Currently it is possible that the final put of a KVM reference comes from
> vfio during its device close operation. This occurs while the vfio group
> lock is held; however, if the vfio device is still in the kvm device list,
> then the following call ch
== Series Details ==
Series: Add module oriented dmesg output (rev5)
URL : https://patchwork.freedesktop.org/series/111050/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12578_full -> Patchwork_111050v5_full
Summary
---
== Series Details ==
Series: drm/i915: update src and dst scaler limits for display ver 12 and 13
(rev2)
URL : https://patchwork.freedesktop.org/series/112213/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12580 -> Patchwork_112213v2
==
On 1/13/2023 1:05 PM, Matthew Auld wrote:
On 13/01/2023 12:02, Das, Nirmoy wrote:
Thanks Matt, I missed the Fixes tag so resent it with fixes and Cc to
stable.
I don't think kernel selftests are really stable material. AFAIK it's
not something normal users care about.
True, in that case
On 13/01/2023 12:02, Das, Nirmoy wrote:
Thanks Matt, I missed the Fixes tag so resent it with fixes and Cc to
stable.
I don't think kernel selftests are really stable material. AFAIK it's
not something normal users care about.
On 1/13/2023 12:51 PM, Matthew Auld wrote:
On 13/01/2023 11:49
Thanks Matt, I missed the Fixes tag so resent it with fixes and Cc to
stable.
On 1/13/2023 12:51 PM, Matthew Auld wrote:
On 13/01/2023 11:49, Nirmoy Das wrote:
From: Chris Wilson
Make sure that upon error after we have acquired the wakeref we do
release it again.
Signed-off-by: Chris Wilson
From: Chris Wilson
Make sure that upon error after we have acquired the wakeref we do
release it again.
Fixes: 027c38b4121e ("drm/i915/selftests: Grab the runtime pm in shrink_thp")
Reviewed-by: Matthew Auld
Signed-off-by: Chris Wilson
Signed-off-by: Nirmoy Das
Cc: # v6.0+
---
drivers/gpu/d
== Series Details ==
Series: vfio: fix potential deadlock on vfio group lock
URL : https://patchwork.freedesktop.org/series/112759/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12578_full -> Patchwork_112759v1_full
Summary
On 13/01/2023 11:49, Nirmoy Das wrote:
From: Chris Wilson
Make sure that upon error after we have acquired the wakeref we do
release it again.
Signed-off-by: Chris Wilson
Signed-off-by: Nirmoy Das
Reviewed-by: Matthew Auld
From: Chris Wilson
Make sure that upon error after we have acquired the wakeref we do
release it again.
Signed-off-by: Chris Wilson
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/g
The bspec has been updated and now display versions 12 and 13 support
source width up to 5120 pixels, source height up to 8192 lines,
destination width up to 8192 and destination height up to 8192.
Update the code accordingly.
BSpec: 50441
Reviewed-by: Ankit Nautiyal
Signed-off-by: Luca Coelho
On 12.1.2023 20.28, Ville Syrjälä wrote:
On Mon, Dec 26, 2022 at 10:53:24PM -0700, Drew Davenport wrote:
The error message suggests that the height of the src rect must be at
least 1. Reject source with height of 0.
Signed-off-by: Drew Davenport
---
I was investigating some divide-by-zero cra
== Series Details ==
Series: drm: Generic fbdev and vga-switcheroo
URL : https://patchwork.freedesktop.org/series/112754/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12578_full -> Patchwork_112754v1_full
Summary
---
On Fri, 2023-01-13 at 16:04 +0530, Nautiyal, Ankit K wrote:
> Hi Luca,
Hi Ankit,
> Patch looks good to me. Please add 'Bspec:50441' in commit message for
> reference.
Good point, I'll add it and resend.
> Also, you might need to re-submit for test, as last time the other
> scaler changes we
Hi Luca,
Patch looks good to me. Please add 'Bspec:50441' in commit message for
reference.
Also, you might need to re-submit for test, as last time the other
scaler changes were not merged, and CI build had failed.
Reviewed-by: Ankit Nautiyal
Thanks & Regards,
Ankit
On 12/24/2022 12:2
On Fri, Jan 13, 2023 at 12:16:57PM +0200, Jani Nikula wrote:
>
> Cc: intel-gfx, drm maintainers
>
> Please have the courtesy of Cc'ing us for changes impacting us, and
> maybe try to involve us earlier instead of surprising us like
> this. Looks like this has been debugged for at least three mont
Cc: intel-gfx, drm maintainers
Please have the courtesy of Cc'ing us for changes impacting us, and
maybe try to involve us earlier instead of surprising us like
this. Looks like this has been debugged for at least three months, and
the huge revert at this point is going to set us back with what'
On 12/01/2023 20:40, John Harrison wrote:
On 1/12/2023 02:01, Tvrtko Ursulin wrote:
On 12/01/2023 02:53, john.c.harri...@intel.com wrote:
From: John Harrison
There was a report of error captures occurring without any hung
context being indicated despite the capture being initiated by a 'hun
On 12/01/2023 20:59, John Harrison wrote:
On 1/12/2023 02:15, Tvrtko Ursulin wrote:
On 12/01/2023 02:53, john.c.harri...@intel.com wrote:
From: John Harrison
Engine resets are supposed to never fail. But in the case when one
does (due to unknown reasons that normally come down to a missing
On 12/01/2023 20:46, John Harrison wrote:
On 1/12/2023 02:06, Tvrtko Ursulin wrote:
On 12/01/2023 02:53, john.c.harri...@intel.com wrote:
From: John Harrison
A hang situation has been observed where the only requests on the
context were either completed or not yet started according to the
b
On Fri, 13 Jan 2023, Arun R Murthy wrote:
> Enable SDP error detection configuration, this will set CRC16 in
> 128b/132b link layer.
> For DISPLAY13 a hardware bit31 in register VIDEO_DIP_CTL is added to
> enable/disable SDP CRC applicable for DP2.0 only, but the default value
> of this bit will e
On 12/01/2023 16:56, Nathan Chancellor wrote:
Hi Jocelyn,
On Thu, Jan 12, 2023 at 11:08:17AM +0100, Jocelyn Falempe wrote:
This patch does also solve a kernel crash when reading
/sys/class/drm/card1/gt/gt0/* on a skylake machine:
https://bugzilla.redhat.com/show_bug.cgi?id=2154880
Interesting
78 matches
Mail list logo
