[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: enhance legacy HPD disconnection flow for 4K pipe compute in GLK
== Series Details == Series: drm/i915: enhance legacy HPD disconnection flow for 4K pipe compute in GLK URL : https://patchwork.freedesktop.org/series/87206/ State : success == Summary == CI Bug Log - changes from CI_DRM_9788 -> Patchwork_19703 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19703/index.html Known issues Here are the changes found in Patchwork_19703 that come from known issues: ### IGT changes ### Issues hit * igt@gem_basic@create-fd-close: - fi-tgl-y: [PASS][1] -> [DMESG-WARN][2] ([i915#402]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9788/fi-tgl-y/igt@gem_ba...@create-fd-close.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19703/fi-tgl-y/igt@gem_ba...@create-fd-close.html * igt@gem_huc_copy@huc-copy: - fi-byt-j1900: NOTRUN -> [SKIP][3] ([fdo#109271]) +27 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19703/fi-byt-j1900/igt@gem_huc_c...@huc-copy.html * igt@kms_chamelium@hdmi-crc-fast: - fi-byt-j1900: NOTRUN -> [SKIP][4] ([fdo#109271] / [fdo#111827]) +8 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19703/fi-byt-j1900/igt@kms_chamel...@hdmi-crc-fast.html Possible fixes * igt@debugfs_test@read_all_entries: - fi-tgl-y: [DMESG-WARN][5] ([i915#402]) -> [PASS][6] +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9788/fi-tgl-y/igt@debugfs_test@read_all_entries.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19703/fi-tgl-y/igt@debugfs_test@read_all_entries.html * igt@gem_exec_suspend@basic-s0: - fi-tgl-u2: [FAIL][7] ([i915#1888]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9788/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19703/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 Participating hosts (45 -> 41) -- Additional (1): fi-byt-j1900 Missing(5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus Build changes - * Linux: CI_DRM_9788 -> Patchwork_19703 CI-20190529: 20190529 CI_DRM_9788: 1a90082e97d6efafec17b1d46a0dd8bb127517be @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6009: a4dccf189b34a55338feec9927dac57c467c4100 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19703: 4aeb74167f4cda404ad9c16aeae2d75f7ff44edb @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 4aeb74167f4c drm/i915: enhance legacy HPD disconnection flow for 4K pipe compute in GLK == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19703/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: enhance legacy HPD disconnection flow for 4K pipe compute in GLK
== Series Details == Series: drm/i915: enhance legacy HPD disconnection flow for 4K pipe compute in GLK URL : https://patchwork.freedesktop.org/series/87206/ State : warning == Summary == $ dim checkpatch origin/drm-tip 4aeb74167f4c drm/i915: enhance legacy HPD disconnection flow for 4K pipe compute in GLK -:7: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #7: HDMI PHY is not available to use when its HDMI disaply plug-in, and power-off total: 0 errors, 1 warnings, 0 checks, 8 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: enhance legacy HPD disconnection flow for 4K pipe compute in GLK
HDMI PHY is not available to use when its HDMI disaply plug-in, and power-off then power-on as soon as getting a hotplug. In above cases where there's a HDMI connector physically connected but it can't be used by GLK with 4K pipe then blank screen (lacking of edid-update & mode-probing) then need return false, since the rest of the driver should pretty much treat the port as disconnected. As previous result, handshaking through is required around connect and disconnect. Otherwise it would be in a inconsistent state as port is disconnected but with a valid HDMI type. Also setting it to return HDMI disconnect for any future calls to intel_digital_port_connected(), this way we don't need to check if port is marked as safe everytime. References: https://gitlab.freedesktop.org/drm/intel/-/issues/3092 Test-steps: setup HDMI 4K@60Hz in GLK then to power monitor off then on to get display recovery correctly Tested-by: Gary C Wang Reviewed-by: Gordon Sylin Signed-off-by: Gary C Wang --- drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gpu/drm/i915/display/intel_hdmi.c index 7f384f259fc8..039cdbfe71a0 100644 --- a/drivers/gpu/drm/i915/display/intel_hdmi.c +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c @@ -2705,7 +2705,7 @@ intel_hdmi_detect(struct drm_connector *connector, bool force) wakeref = intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS); - if (INTEL_GEN(dev_priv) >= 11 && + if ((INTEL_GEN(dev_priv) >= 11 || IS_GEMINILAKE(dev_priv)) && !intel_digital_port_connected(encoder)) goto out; -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 3/9] drm/i915/spi: add driver for on-die spi device
> > On Wed, Feb 17, 2021 at 08:58:12PM +, Winkler, Tomas wrote: > >> > >> On Tue, 16 Feb 2021, Tomas Winkler wrote: > >> > Add the platform driver for i915 on-die spi device, exposed via mfd > >> > framework. > >> > > >> > Cc: Rodrigo Vivi > >> > Cc: Lucas De Marchi > >> > Signed-off-by: Tomas Winkler > >> > --- > >> > drivers/gpu/drm/i915/Kconfig | 2 + > >> > drivers/gpu/drm/i915/Makefile| 3 + > >> > drivers/gpu/drm/i915/spi/intel_spi_drv.c | 116 > >> > +++ > >> > 3 files changed, 121 insertions(+) create mode 100644 > >> > drivers/gpu/drm/i915/spi/intel_spi_drv.c > >> > > >> > diff --git a/drivers/gpu/drm/i915/Kconfig > >> > b/drivers/gpu/drm/i915/Kconfig index abcaa8da45ac..13c870e5878e > >> > 100644 > >> > --- a/drivers/gpu/drm/i915/Kconfig > >> > +++ b/drivers/gpu/drm/i915/Kconfig > >> > @@ -27,6 +27,8 @@ config DRM_I915 > >> > select CEC_CORE if CEC_NOTIFIER > >> > select VMAP_PFN > >> > select MFD_CORE > >> > +select MTD > >> > >> Selecting MTD does not seem to be a popular thing to do, which is > >> usually a clue it's probably the wrong thing to do. > >Depends, if it is not selected you'll end with wrongly configured system. > > no. I believe the idea is that having a CONFIG_I915_SPI, you could do > > depends on MTD > > like the other drivers doing similar thing: > > git grep MTD -- ':(exclude)drivers/mtd' ':(exclude)arch/' '*Kconfig' I know the pattern and it can be done, the issue is that mtd is used mostly in embedded systems so it is not selected by the desktop distros. The intel spi both on PCH and in GFX takes this into different direction and usage. Thanks Tomas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 18/18] drm/i915/display13: Enabling dithering after the CC1 pipe
On Fri, Feb 19, 2021 at 4:22 AM Mario Kleiner wrote: > > > On Thu, Feb 11, 2021 at 1:29 PM Ville Syrjälä < > ville.syrj...@linux.intel.com> wrote: > >> On Thu, Jan 28, 2021 at 11:24:13AM -0800, Matt Roper wrote: >> > From: Nischal Varide >> > >> > If the panel is 12bpc then Dithering is not enabled in the Legacy >> > dithering block , instead its Enabled after the C1 CC1 pipe post >> > color space conversion.For a 6bpc pannel Dithering is enabled in >> > Legacy block. >> >> Dithering is probably going to require a whole uapi bikeshed. >> Not sure we can just enable it unilaterally. >> >> Ccing dri-devel, and Mario who had issues with dithering in the >> past... >> >> Thanks for the cc Ville! > > The problem with dithering on Intel is that various tested Intel gpu's > (Ironlake, IvyBridge, Haswell, Skylake iirc.) are dithering when they > shouldn't. If one has a standard 8 bpc framebuffer feeding into a standard > (legacy) 256 slots, 8 bit wide lut which was loaded with an identity > mapping, feeding into a standard 8 bpc video output (DVI/HDMI/DP), the > expected result is that pixels rendered into the framebuffer show up > unmodified at the video output. What happens instead is that some dithering > is needlessly applied. This is bad for various neuroscience/medical > research equipment that requires pixels to pass unmodified in a pure 8 bpc > configuration, e.g., because some digital info is color-encoded in-band in > the rendered image to control research hardware, a la "if rgb pixel (123, > 12, 23) is detected in the digital video stream, emit some trigger signal, > or timestamp that moment with a hw clock, or start or stop some scientific > recording equipment". Also there exist specialized visual stimulators to > drive special displays with more than 12 bpc, e.g., 16 bpc, and so they > encode the 8MSB of 16 bpc color values in pixels in even columns, and the > 8LSB in the odd columns of the framebuffer. Unexpected dithering makes such > equipment completely unusable. By now I must have spent months of my life, > just trying to deal with dithering induced problems on different gpu's due > to hw quirks or bugs somewhere in the graphics stack. > > Atm. the intel kms driver disables dithering for anything with >= 8 bpc as > a fix for this harmful hardware quirk. > > Ideally we'd have uapi that makes dithering controllable per connector > (on/off/auto, selectable depth), also in a way that those controls are > exposed as RandR output properties, easily controllable by X clients. And > some safe default in case the client can't access the properties (like I'd > expect to happen with the dozens of Wayland compositors under the sun). > Various drivers had this over time, e.g., AMD classic kms path (if i don't > misremember) and nouveau, but some of it also got lost in the new atomic > kms variants, and Intel never exposed this. > > Or maybe some method that checks the values actually stored in the hw > lut's, CTM etc. and if the values suggest no dithering should be needed, > disable the dithering. E.g., if output depth is 8 bpc, one only needs > dithering if the slots in the final active hw lut do have any meaningful > values in the lower bits below the top 8 MSB, ie. if the content is > actually > 8 bpc net bit depth. > > -mario > > One cup of coffee later... I think this specific patch should be ok wrt. my use cases. The majority of the above mentioned research devices are single/dual-link DVI receivers, ie. 8 bpc video sinks. I'm only aware of one recent device that has a DisplayPort receiver who could act as a > 8 bpc video sink. See the following link for advanced examples of such devices: https://vpixx.com/our-products/video-i-o-hub/ I cannot think of a use case that would require more than 8 bits for inband signalling given that that was good enough for the last 20 years, or for encoding very high color precision content -- the 16 bpc precision that one can get out of the current even/odd pixel = 8 MSB + 8 LSB encoding scheme should be enough for the foreseeable future. Therefore dithering shouldn't pose a problem if it leaves the 8 MSB of each pixel color component intact, and spatial dithering as employed here usually only touches the least significant bit (or maybe the 2 LSB's?). As this patch only enables dithering on 12 bpc video sinks, if i understand pipe_bpp correctly, it could only "corrupt" one bit and leave at least the 10-11 MSB's intact, right? pipe_bpp == 24 is the case that would really hurt a lot of researchers if dithering would be enabled without providing good uapi or other mechanisms to prevent it. So: Acked-by: Mario Kleiner One suggestion: It would be good to also add a bit of drm_dbg_kms() logging to the new code-patch, so that this 12 bpc dithering enable on HAS_DISPLAY13 hw also shows up in the logs, not just the standard 6 bpc enable. Helped a lot in debugging dithering issues if there was a reliable trace in the logs of what was active when. One suggestion for
Re: [Intel-gfx] [PATCH 18/18] drm/i915/display13: Enabling dithering after the CC1 pipe
On Thu, Feb 11, 2021 at 1:29 PM Ville Syrjälä
wrote:
> On Thu, Jan 28, 2021 at 11:24:13AM -0800, Matt Roper wrote:
> > From: Nischal Varide
> >
> > If the panel is 12bpc then Dithering is not enabled in the Legacy
> > dithering block , instead its Enabled after the C1 CC1 pipe post
> > color space conversion.For a 6bpc pannel Dithering is enabled in
> > Legacy block.
>
> Dithering is probably going to require a whole uapi bikeshed.
> Not sure we can just enable it unilaterally.
>
> Ccing dri-devel, and Mario who had issues with dithering in the
> past...
>
> Thanks for the cc Ville!
The problem with dithering on Intel is that various tested Intel gpu's
(Ironlake, IvyBridge, Haswell, Skylake iirc.) are dithering when they
shouldn't. If one has a standard 8 bpc framebuffer feeding into a standard
(legacy) 256 slots, 8 bit wide lut which was loaded with an identity
mapping, feeding into a standard 8 bpc video output (DVI/HDMI/DP), the
expected result is that pixels rendered into the framebuffer show up
unmodified at the video output. What happens instead is that some dithering
is needlessly applied. This is bad for various neuroscience/medical
research equipment that requires pixels to pass unmodified in a pure 8 bpc
configuration, e.g., because some digital info is color-encoded in-band in
the rendered image to control research hardware, a la "if rgb pixel (123,
12, 23) is detected in the digital video stream, emit some trigger signal,
or timestamp that moment with a hw clock, or start or stop some scientific
recording equipment". Also there exist specialized visual stimulators to
drive special displays with more than 12 bpc, e.g., 16 bpc, and so they
encode the 8MSB of 16 bpc color values in pixels in even columns, and the
8LSB in the odd columns of the framebuffer. Unexpected dithering makes such
equipment completely unusable. By now I must have spent months of my life,
just trying to deal with dithering induced problems on different gpu's due
to hw quirks or bugs somewhere in the graphics stack.
Atm. the intel kms driver disables dithering for anything with >= 8 bpc as
a fix for this harmful hardware quirk.
Ideally we'd have uapi that makes dithering controllable per connector
(on/off/auto, selectable depth), also in a way that those controls are
exposed as RandR output properties, easily controllable by X clients. And
some safe default in case the client can't access the properties (like I'd
expect to happen with the dozens of Wayland compositors under the sun).
Various drivers had this over time, e.g., AMD classic kms path (if i don't
misremember) and nouveau, but some of it also got lost in the new atomic
kms variants, and Intel never exposed this.
Or maybe some method that checks the values actually stored in the hw
lut's, CTM etc. and if the values suggest no dithering should be needed,
disable the dithering. E.g., if output depth is 8 bpc, one only needs
dithering if the slots in the final active hw lut do have any meaningful
values in the lower bits below the top 8 MSB, ie. if the content is
actually > 8 bpc net bit depth.
-mario
>
> > Cc: Uma Shankar
> > Signed-off-by: Nischal Varide
> > Signed-off-by: Bhanuprakash Modem
> > Signed-off-by: Matt Roper
> > ---
> > drivers/gpu/drm/i915/display/intel_color.c | 16
> > drivers/gpu/drm/i915/display/intel_display.c | 9 -
> > drivers/gpu/drm/i915/i915_reg.h | 3 ++-
> > 3 files changed, 26 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> b/drivers/gpu/drm/i915/display/intel_color.c
> > index ff7dcb7088bf..9a0572bbc5db 100644
> > --- a/drivers/gpu/drm/i915/display/intel_color.c
> > +++ b/drivers/gpu/drm/i915/display/intel_color.c
> > @@ -1604,6 +1604,20 @@ static u32 icl_csc_mode(const struct
> intel_crtc_state *crtc_state)
> > return csc_mode;
> > }
> >
> > +static u32 dither_after_cc1_12bpc(const struct intel_crtc_state
> *crtc_state)
> > +{
> > + u32 gamma_mode = crtc_state->gamma_mode;
> > + struct drm_i915_private *i915 =
> to_i915(crtc_state->uapi.crtc->dev);
> > +
> > + if (HAS_DISPLAY13(i915)) {
> > + if (!crtc_state->dither_force_disable &&
> > + (crtc_state->pipe_bpp == 36))
> > + gamma_mode |= GAMMA_MODE_DITHER_AFTER_CC1;
> > + }
> > +
> > + return gamma_mode;
> > +}
> > +
> > static int icl_color_check(struct intel_crtc_state *crtc_state)
> > {
> > int ret;
> > @@ -1614,6 +1628,8 @@ static int icl_color_check(struct intel_crtc_state
> *crtc_state)
> >
> > crtc_state->gamma_mode = icl_gamma_mode(crtc_state);
> >
> > + crtc_state->gamma_mode = dither_after_cc1_12bpc(crtc_state);
> > +
> > crtc_state->csc_mode = icl_csc_mode(crtc_state);
> >
> > crtc_state->preload_luts = intel_can_preload_luts(crtc_state);
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> > index
[Intel-gfx] [PULL] drm-intel-next-fixes
Hi Dave and Daniel, Here goes drm-intel-next-fixes-2021-02-18: - Restrict DRM_I915_DEBUG to developer builds (Chris) - Fix return and error codes (Dan) - Suspend/Resume fix (Chris) - Disable atomics in L3 for gen9 (Chris) - Flush before changing register state (Chris) - Fix for GLK's HDMI (Ville) - Fix ILK+'s plane strides with Xtiling (Ville) - Correct surface base address for renderclear (Chris) Thanks, Rodrigo. The following changes since commit 4c3a3292730c56591472717d8c5c0faf74f6c6bb: drm/amd/display: fix unused variable warning (2021-02-05 09:49:44 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2021-02-18 for you to fetch changes up to 81ce8f04aa96f7f6cae05770f68b5d15be91f5a2: drm/i915/gt: Correct surface base address for renderclear (2021-02-17 06:19:04 -0500) - Restrict DRM_I915_DEBUG to developer builds (Chris) - Fix return and error codes (Dan) - Suspend/Resume fix (Chris) - Disable atomics in L3 for gen9 (Chris) - Flush before changing register state (Chris) - Fix for GLK's HDMI (Ville) - Fix ILK+'s plane strides with Xtiling (Ville) - Correct surface base address for renderclear (Chris) Chris Wilson (5): drm/i915: Restrict DRM_I915_DEBUG to developer builds drm/i915/gem: Move freeze/freeze_late next to suspend/suspend_late drm/i915: Disable atomics in L3 for gen9 drm/i915/gt: Flush before changing register state drm/i915/gt: Correct surface base address for renderclear Dan Carpenter (2): drm/i915/gvt: fix uninitialized return in intel_gvt_update_reg_whitelist() drm/i915/gem: Fix oops in error handling code Ville Syrjälä (2): drm/i915: Reject 446-480MHz HDMI clock on GLK drm/i915: Disallow plane x+w>stride on ilk+ with X-tiling drivers/gpu/drm/i915/Kconfig.debug | 2 ++ drivers/gpu/drm/i915/display/i9xx_plane.c| 27 ++ drivers/gpu/drm/i915/display/intel_display.c | 12 drivers/gpu/drm/i915/display/intel_display.h | 6 drivers/gpu/drm/i915/display/intel_hdmi.c| 6 +++- drivers/gpu/drm/i915/gem/i915_gem_pm.c | 41 drivers/gpu/drm/i915/gem/i915_gem_pm.h | 3 ++ drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 12 +++- drivers/gpu/drm/i915/gt/gen7_renderclear.c | 3 +- drivers/gpu/drm/i915/gt/intel_workarounds.c | 8 ++ drivers/gpu/drm/i915/gvt/cmd_parser.c| 3 +- drivers/gpu/drm/i915/i915_drv.c | 1 + drivers/gpu/drm/i915/i915_drv.h | 2 -- drivers/gpu/drm/i915/i915_gem.c | 41 drivers/gpu/drm/i915/i915_reg.h | 7 + drivers/gpu/drm/i915/selftests/i915_gem.c| 1 + 16 files changed, 115 insertions(+), 60 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/vblank: Avoid storing a timestamp for the same frame twice (rev2)
== Series Details == Series: drm/vblank: Avoid storing a timestamp for the same frame twice (rev2) URL : https://patchwork.freedesktop.org/series/86672/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9786_full -> Patchwork_19701_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_19701_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19701_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_19701_full: ### IGT changes ### Possible regressions * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: - shard-glk: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9786/shard-glk3/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-b.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19701/shard-glk1/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-b.html Known issues Here are the changes found in Patchwork_19701_full that come from known issues: ### IGT changes ### Issues hit * igt@feature_discovery@psr2: - shard-iclb: [PASS][3] -> [SKIP][4] ([i915#658]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9786/shard-iclb2/igt@feature_discov...@psr2.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19701/shard-iclb7/igt@feature_discov...@psr2.html * igt@gem_ctx_persistence@engines-hostile: - shard-snb: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#1099]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19701/shard-snb7/igt@gem_ctx_persiste...@engines-hostile.html * igt@gem_ctx_persistence@engines-mixed-process: - shard-hsw: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#1099]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19701/shard-hsw5/igt@gem_ctx_persiste...@engines-mixed-process.html * igt@gem_exec_fair@basic-deadline: - shard-apl: NOTRUN -> [FAIL][7] ([i915#2846]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19701/shard-apl1/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-rrul@rcs0: - shard-glk: [PASS][8] -> [FAIL][9] ([i915#2842]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9786/shard-glk5/igt@gem_exec_fair@basic-none-r...@rcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19701/shard-glk8/igt@gem_exec_fair@basic-none-r...@rcs0.html * igt@gem_exec_fair@basic-none@vcs0: - shard-apl: [PASS][10] -> [FAIL][11] ([i915#2842]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9786/shard-apl2/igt@gem_exec_fair@basic-n...@vcs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19701/shard-apl2/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_exec_fair@basic-pace@rcs0: - shard-kbl: NOTRUN -> [FAIL][12] ([i915#2842]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19701/shard-kbl4/igt@gem_exec_fair@basic-p...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-iclb: NOTRUN -> [FAIL][13] ([i915#2842]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19701/shard-iclb2/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_exec_reloc@basic-many-active@vcs0: - shard-kbl: NOTRUN -> [FAIL][14] ([i915#2389]) +4 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19701/shard-kbl4/igt@gem_exec_reloc@basic-many-act...@vcs0.html * igt@gem_exec_reloc@basic-many-active@vcs1: - shard-iclb: NOTRUN -> [FAIL][15] ([i915#2389]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19701/shard-iclb2/igt@gem_exec_reloc@basic-many-act...@vcs1.html * igt@gem_exec_suspend@basic-s3: - shard-kbl: [PASS][16] -> [DMESG-WARN][17] ([i915#180]) +2 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9786/shard-kbl4/igt@gem_exec_susp...@basic-s3.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19701/shard-kbl6/igt@gem_exec_susp...@basic-s3.html * igt@gem_huc_copy@huc-copy: - shard-apl: NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#2190]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19701/shard-apl3/igt@gem_huc_c...@huc-copy.html * igt@gem_pwrite@basic-exhaustion: - shard-skl: NOTRUN -> [WARN][19] ([i915#2658]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19701/shard-skl7/igt@gem_pwr...@basic-exhaustion.html - shard-kbl: NOTRUN -> [WARN][20] ([i915#2658]) +1 similar issue [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19701/shard-kbl1/igt@gem_pwr...@basic-exhaustion.html
[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [1/3] drm/i915/display/adl_s: Fix dpclka_cfgcr0_clk_off mapping (rev2)
== Series Details == Series: series starting with [1/3] drm/i915/display/adl_s: Fix dpclka_cfgcr0_clk_off mapping (rev2) URL : https://patchwork.freedesktop.org/series/87048/ State : failure == Summary == Applying: drm/i915/display/adl_s: Fix dpclka_cfgcr0_clk_off mapping Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/display/intel_ddi.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/display/intel_ddi.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/display/intel_ddi.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 drm/i915/display/adl_s: Fix dpclka_cfgcr0_clk_off mapping When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/vblank: Avoid storing a timestamp for the same frame twice (rev2)
Re-reported. -Original Message- From: Ville Syrjälä Sent: Thursday, February 18, 2021 11:22 AM To: intel-gfx@lists.freedesktop.org Cc: Vudum, Lakshminarayana Subject: Re: ✗ Fi.CI.BAT: failure for drm/vblank: Avoid storing a timestamp for the same frame twice (rev2) On Thu, Feb 18, 2021 at 07:08:27PM -, Patchwork wrote: > == Series Details == > > Series: drm/vblank: Avoid storing a timestamp for the same frame twice (rev2) > URL : https://patchwork.freedesktop.org/series/86672/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_9786 -> Patchwork_19701 > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_19701 absolutely need to be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_19701, please notify your bug team to allow them > to document this new failure mode, which will reduce false positives in CI. > > External URL: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19701/index.html > > Possible new issues > --- > > Here are the unknown changes that may have been introduced in > Patchwork_19701: > > ### IGT changes ### > > Possible regressions > > * igt@gem_exec_suspend@basic-s0: > - fi-cfl-8109u: [PASS][1] -> [INCOMPLETE][2] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9786/fi-cfl-8109u/igt@gem_exec_susp...@basic-s0.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19701/fi-cfl-8109u/ > igt@gem_exec_susp...@basic-s0.html Looks like the machine went AWOL during suspend. Seems unrelated to the patch at hand. -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Issue with cec_register_adapter calling request_module() from an async context when called from intel_dp_detect
Hi Hans,
On Thu, Feb 18, 2021 at 04:33:38PM +0100, Hans de Goede wrote:
> On 2/17/21 5:29 PM, Hans Verkuil wrote:
> > On 17/02/2021 16:11, Sean Young wrote:
> >> Hi,
> >>
> >> On Wed, Feb 17, 2021 at 04:04:11PM +0100, Hans de Goede wrote:
> >>> On 2/17/21 3:32 PM, Sean Young wrote:
> On Wed, Feb 17, 2021 at 01:41:46PM +0100, Hans Verkuil wrote:
> > Hi Hans,
> >
> > On 17/02/2021 13:24, Hans de Goede wrote:
> >>
> >>
> >> Hi Hans,
> >>
> >> Fedora has a (opt-in) system to automatically collect backtraces from
> >> software
> >> crashing on users systems.
> >>
> >> This includes collecting kernel backtraces (including once triggered by
> >> WARN macros) while looking a the top 10 of the most reported backtrace
> >> during the
> >> last 2 weeks report from ABRT:
> >> https://retrace.fedoraproject.org/faf/problems/
> >>
> >> I noticed the following backtrace:
> >> https://retrace.fedoraproject.org/faf/problems/8150/
> >> which has been reported 17 times by Fedora users who have opted-in
> >> during the
> >> last 14 days.
> >>
> >> The issue here is that cec_register_adapter ends up calling
> >> request_module()
> >> from an async context, triggering this warn in kernel/kmod.c
> >> __request_module():
> >>
> >> /*
> >> * We don't allow synchronous module loading from async.
> >> Module
> >> * init may invoke async_synchronize_full() which will end up
> >> * waiting for this task which already is waiting for the
> >> module
> >> * loading to complete, leading to a deadlock.
> >> */
> >> WARN_ON_ONCE(wait && current_is_async());
> >>
> >> The call-path leading to this goes like this:
> >>
> >> ? kvasprintf+0x6d/0xa0
> >> ? kobject_set_name_vargs+0x6f/0x90
> >> rc_map_get+0x30/0x60
> >
> > It's not CEC, it is rc_map_get that calls request_module() for
> > rc-cec.ko.
> >
> > I've added Sean Young to the CC list.
> >
> > Sean, is it possible to treat rc-cec as a built-in if MEDIA_CEC_RC is
> > set?
> >
> > I think this issue is very specific to CEC. I would not expect to see
> > this
> > with any other rc keymap.
>
> So CEC creates an RC device with a keymap (cec keymap, of course) and
> then
> the keymap needs to be loaded. We certainly don't want all keymaps as
> builtins, that would be a waste.
>
> The cec keymap is scanned once to build a map from cec codes to linux
> keycodes; making it builtin is not ideal, and makes the build system a
> bit messy.
>
> I don't think we can load the keymap later, user space may start
> remapping
> the keymap from udev.
>
> Possibly we could create the cec or rc device later but this could be a
> bit
> messy.
>
> Could CEC specify:
>
> #if IS_ENABLED(CONFIG_MEDIA_CEC_RC)
> MODULE_SOFTDEP("rc-cec")
> #endif
> >>>
> >>> That would need to be:
> >>>
> >>> MODULE_SOFTDEP("pre: rc-cec")
> >>>
> >>> I see that the drm_kms_helper and i915 drivers both depend on the cec
> >>> module already,
> >>> so yes if that module will request for rc-cec to be loaded before it is
> >>> loaded
> >>> (and thus before i915 is loaded) then that should work around this.
> >>>
> >>> Assuming the user is using a module-loader which honors the softdep...
> >>>
> >>> Also this assumes that rc_map_get is smart enough to not call
> >>> request_module()
> >>> if the module is already loaded, is that the case ?
> >>
> >> Yes, see rc_map_get().
> >
> > I tried this. It works if CONFIG_RC_CORE is set to m, but setting it to
> > y resulted in the same problem. It looks like MODULE_SOFTDEP only works if
> > rc_main
> > is a module as well.
>
> Yeah that is a known limit of module softdeps, they only work inside modules
> ...
Yes, I assume this is the problem.
> Still, assuming there is no easy other fix, we could still use this somehow.
>
> I do see that at least Fedora actually has CONFIG_RC_CORE=y for some reason.
This is to make BPF IR decoding possible.
> I guess we could maybe add the softdep to the CONFIG_RC_MAP module or
> maybe to the module which contains the code enabled by CONFIG_DRM_DP_CEC ?
>
> At least Fedora has all drm stuff as modules and also has CONFIG_RC_MAP=m,
>
> I know this is not a real fix but a workaround to get rid of 170,000
> backtraces / 14 days being reported by (opted-in) systems running the
> Fedora generic kernel config would be welcome regardless of it being the
> "perfect" fix.
Of course, I totally agree that a solution is needed.
How about:
1) Use MODULE_SOFTDEP("rc-cec");
2) If it's compiled as a module, rc-cec should be builtin
Sean
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/vblank: Avoid storing a timestamp for the same frame twice (rev2)
== Series Details == Series: drm/vblank: Avoid storing a timestamp for the same frame twice (rev2) URL : https://patchwork.freedesktop.org/series/86672/ State : success == Summary == CI Bug Log - changes from CI_DRM_9786 -> Patchwork_19701 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19701/index.html Known issues Here are the changes found in Patchwork_19701 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@sync-compute0: - fi-kbl-r: NOTRUN -> [SKIP][1] ([fdo#109271]) +20 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19701/fi-kbl-r/igt@amdgpu/amd_cs_...@sync-compute0.html * igt@gem_exec_suspend@basic-s0: - fi-cfl-8109u: [PASS][2] -> [INCOMPLETE][3] ([i915#155]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9786/fi-cfl-8109u/igt@gem_exec_susp...@basic-s0.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19701/fi-cfl-8109u/igt@gem_exec_susp...@basic-s0.html * igt@gem_huc_copy@huc-copy: - fi-kbl-r: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#2190]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19701/fi-kbl-r/igt@gem_huc_c...@huc-copy.html * igt@gem_linear_blits@basic: - fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([i915#402]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9786/fi-tgl-y/igt@gem_linear_bl...@basic.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19701/fi-tgl-y/igt@gem_linear_bl...@basic.html * igt@i915_pm_rpm@module-reload: - fi-kbl-guc: [PASS][7] -> [FAIL][8] ([i915#2203] / [i915#579]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9786/fi-kbl-guc/igt@i915_pm_...@module-reload.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19701/fi-kbl-guc/igt@i915_pm_...@module-reload.html * igt@kms_chamelium@hdmi-edid-read: - fi-kbl-r: NOTRUN -> [SKIP][9] ([fdo#109271] / [fdo#111827]) +8 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19701/fi-kbl-r/igt@kms_chamel...@hdmi-edid-read.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d: - fi-kbl-r: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#533]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19701/fi-kbl-r/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html Possible fixes * igt@gem_mmap_gtt@basic: - fi-tgl-y: [DMESG-WARN][11] ([i915#402]) -> [PASS][12] +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9786/fi-tgl-y/igt@gem_mmap_...@basic.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19701/fi-tgl-y/igt@gem_mmap_...@basic.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#155]: https://gitlab.freedesktop.org/drm/intel/issues/155 [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190 [i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533 [i915#579]: https://gitlab.freedesktop.org/drm/intel/issues/579 Participating hosts (46 -> 39) -- Missing(7): fi-cml-u2 fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-ehl-2 fi-bdw-samus Build changes - * Linux: CI_DRM_9786 -> Patchwork_19701 CI-20190529: 20190529 CI_DRM_9786: 487d534b8912194d104e05b66e3a0303800300ff @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6008: 34ccd8e8c38587e7d46ec964d30d17863b166fda @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19701: b9e2377b1bd55114447c010cfd7f8b4302744afa @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == b9e2377b1bd5 drm/vblank: Do not store a new vblank timestamp in drm_vblank_restore() == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19701/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/vblank: Avoid storing a timestamp for the same frame twice (rev2)
On Thu, Feb 18, 2021 at 07:08:27PM -, Patchwork wrote: > == Series Details == > > Series: drm/vblank: Avoid storing a timestamp for the same frame twice (rev2) > URL : https://patchwork.freedesktop.org/series/86672/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_9786 -> Patchwork_19701 > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_19701 absolutely need to be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_19701, please notify your bug team to allow them > to document this new failure mode, which will reduce false positives in CI. > > External URL: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19701/index.html > > Possible new issues > --- > > Here are the unknown changes that may have been introduced in > Patchwork_19701: > > ### IGT changes ### > > Possible regressions > > * igt@gem_exec_suspend@basic-s0: > - fi-cfl-8109u: [PASS][1] -> [INCOMPLETE][2] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9786/fi-cfl-8109u/igt@gem_exec_susp...@basic-s0.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19701/fi-cfl-8109u/igt@gem_exec_susp...@basic-s0.html Looks like the machine went AWOL during suspend. Seems unrelated to the patch at hand. -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/vblank: Avoid storing a timestamp for the same frame twice (rev2)
== Series Details == Series: drm/vblank: Avoid storing a timestamp for the same frame twice (rev2) URL : https://patchwork.freedesktop.org/series/86672/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9786 -> Patchwork_19701 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_19701 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19701, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19701/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_19701: ### IGT changes ### Possible regressions * igt@gem_exec_suspend@basic-s0: - fi-cfl-8109u: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9786/fi-cfl-8109u/igt@gem_exec_susp...@basic-s0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19701/fi-cfl-8109u/igt@gem_exec_susp...@basic-s0.html Known issues Here are the changes found in Patchwork_19701 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@sync-compute0: - fi-kbl-r: NOTRUN -> [SKIP][3] ([fdo#109271]) +20 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19701/fi-kbl-r/igt@amdgpu/amd_cs_...@sync-compute0.html * igt@gem_huc_copy@huc-copy: - fi-kbl-r: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#2190]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19701/fi-kbl-r/igt@gem_huc_c...@huc-copy.html * igt@gem_linear_blits@basic: - fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([i915#402]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9786/fi-tgl-y/igt@gem_linear_bl...@basic.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19701/fi-tgl-y/igt@gem_linear_bl...@basic.html * igt@i915_pm_rpm@module-reload: - fi-kbl-guc: [PASS][7] -> [FAIL][8] ([i915#2203] / [i915#579]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9786/fi-kbl-guc/igt@i915_pm_...@module-reload.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19701/fi-kbl-guc/igt@i915_pm_...@module-reload.html * igt@kms_chamelium@hdmi-edid-read: - fi-kbl-r: NOTRUN -> [SKIP][9] ([fdo#109271] / [fdo#111827]) +8 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19701/fi-kbl-r/igt@kms_chamel...@hdmi-edid-read.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d: - fi-kbl-r: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#533]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19701/fi-kbl-r/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html Possible fixes * igt@gem_mmap_gtt@basic: - fi-tgl-y: [DMESG-WARN][11] ([i915#402]) -> [PASS][12] +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9786/fi-tgl-y/igt@gem_mmap_...@basic.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19701/fi-tgl-y/igt@gem_mmap_...@basic.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190 [i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533 [i915#579]: https://gitlab.freedesktop.org/drm/intel/issues/579 Participating hosts (46 -> 39) -- Missing(7): fi-cml-u2 fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-ehl-2 fi-bdw-samus Build changes - * Linux: CI_DRM_9786 -> Patchwork_19701 CI-20190529: 20190529 CI_DRM_9786: 487d534b8912194d104e05b66e3a0303800300ff @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6008: 34ccd8e8c38587e7d46ec964d30d17863b166fda @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19701: b9e2377b1bd55114447c010cfd7f8b4302744afa @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == b9e2377b1bd5 drm/vblank: Do not store a new vblank timestamp in drm_vblank_restore() == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19701/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Issue with cec_register_adapter calling request_module() from an async context when called from intel_dp_detect
Hi,
On 2/18/21 5:38 PM, Sean Young wrote:
> Hi Hans,
>
> On Thu, Feb 18, 2021 at 04:33:38PM +0100, Hans de Goede wrote:
>> On 2/17/21 5:29 PM, Hans Verkuil wrote:
>>> On 17/02/2021 16:11, Sean Young wrote:
Hi,
On Wed, Feb 17, 2021 at 04:04:11PM +0100, Hans de Goede wrote:
> On 2/17/21 3:32 PM, Sean Young wrote:
>> On Wed, Feb 17, 2021 at 01:41:46PM +0100, Hans Verkuil wrote:
>>> Hi Hans,
>>>
>>> On 17/02/2021 13:24, Hans de Goede wrote:
Hi Hans,
Fedora has a (opt-in) system to automatically collect backtraces from
software
crashing on users systems.
This includes collecting kernel backtraces (including once triggered by
WARN macros) while looking a the top 10 of the most reported backtrace
during the
last 2 weeks report from ABRT:
https://retrace.fedoraproject.org/faf/problems/
I noticed the following backtrace:
https://retrace.fedoraproject.org/faf/problems/8150/
which has been reported 17 times by Fedora users who have opted-in
during the
last 14 days.
The issue here is that cec_register_adapter ends up calling
request_module()
from an async context, triggering this warn in kernel/kmod.c
__request_module():
/*
* We don't allow synchronous module loading from async.
Module
* init may invoke async_synchronize_full() which will end up
* waiting for this task which already is waiting for the
module
* loading to complete, leading to a deadlock.
*/
WARN_ON_ONCE(wait && current_is_async());
The call-path leading to this goes like this:
? kvasprintf+0x6d/0xa0
? kobject_set_name_vargs+0x6f/0x90
rc_map_get+0x30/0x60
>>>
>>> It's not CEC, it is rc_map_get that calls request_module() for
>>> rc-cec.ko.
>>>
>>> I've added Sean Young to the CC list.
>>>
>>> Sean, is it possible to treat rc-cec as a built-in if MEDIA_CEC_RC is
>>> set?
>>>
>>> I think this issue is very specific to CEC. I would not expect to see
>>> this
>>> with any other rc keymap.
>>
>> So CEC creates an RC device with a keymap (cec keymap, of course) and
>> then
>> the keymap needs to be loaded. We certainly don't want all keymaps as
>> builtins, that would be a waste.
>>
>> The cec keymap is scanned once to build a map from cec codes to linux
>> keycodes; making it builtin is not ideal, and makes the build system a
>> bit messy.
>>
>> I don't think we can load the keymap later, user space may start
>> remapping
>> the keymap from udev.
>>
>> Possibly we could create the cec or rc device later but this could be a
>> bit
>> messy.
>>
>> Could CEC specify:
>>
>> #if IS_ENABLED(CONFIG_MEDIA_CEC_RC)
>> MODULE_SOFTDEP("rc-cec")
>> #endif
>
> That would need to be:
>
> MODULE_SOFTDEP("pre: rc-cec")
>
> I see that the drm_kms_helper and i915 drivers both depend on the cec
> module already,
> so yes if that module will request for rc-cec to be loaded before it is
> loaded
> (and thus before i915 is loaded) then that should work around this.
>
> Assuming the user is using a module-loader which honors the softdep...
>
> Also this assumes that rc_map_get is smart enough to not call
> request_module()
> if the module is already loaded, is that the case ?
Yes, see rc_map_get().
>>>
>>> I tried this. It works if CONFIG_RC_CORE is set to m, but setting it to
>>> y resulted in the same problem. It looks like MODULE_SOFTDEP only works if
>>> rc_main
>>> is a module as well.
>>
>> Yeah that is a known limit of module softdeps, they only work inside modules
>> ...
>
> Yes, I assume this is the problem.
>
>> Still, assuming there is no easy other fix, we could still use this somehow.
>>
>> I do see that at least Fedora actually has CONFIG_RC_CORE=y for some reason.
>
> This is to make BPF IR decoding possible.
>
>> I guess we could maybe add the softdep to the CONFIG_RC_MAP module or
>> maybe to the module which contains the code enabled by CONFIG_DRM_DP_CEC ?
>>
>> At least Fedora has all drm stuff as modules and also has CONFIG_RC_MAP=m,
>>
>> I know this is not a real fix but a workaround to get rid of 170,000
>> backtraces / 14 days being reported by (opted-in) systems running the
>> Fedora generic kernel config would be welcome regardless of it being the
>> "perfect" fix.
>
> Of course, I totally agree that a solution is needed.
>
> How about:
>
> 1) Use MODULE_SOFTDEP("rc-cec");
>
> 2) If it's compiled as a module, rc-cec should be builtin
I assume with 2. you
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Fix plane watermark mismatches
On Thu, Feb 18, 2021 at 05:25:54PM +, Souza, Jose wrote: > On Thu, 2021-02-18 at 00:14 +0200, Ville Syrjälä wrote: > > On Wed, Feb 17, 2021 at 05:24:03PM +, Souza, Jose wrote: > > > On Fri, 2021-02-12 at 23:13 +0200, Ville Syrjälä wrote: > > > > On Fri, Feb 12, 2021 at 07:44:22PM +, Souza, Jose wrote: > > > > > On Fri, 2021-02-12 at 20:35 +0200, Ville Syrjälä wrote: > > > > > > On Fri, Feb 12, 2021 at 10:22:01AM -0800, José Roberto de Souza > > > > > > wrote: > > > > > > > Found a system were firmware/BIOS left the plane_res_b and > > > > > > > plane_res_l > > > > > > > set with non-zero values for disable planes. > > > > > > > > > > > > It pretty much happens always since the reset value is not zero. > > > > > > IIRC we made the state chcker pedantic enough to complain about > > > > > > that, so we need to clean it up. > > > > > > > > > > Are you planning to fix it soon? > > > > > > > > Fix what exactly? I guess you're seeing an actual problem of some sort? > > > > > > Your comment above made me understand that you were planning to fix this > > > plane watermark mismatches for disabled planes in other way other than > > > what > > > this patch does. > > > Or should we proceed with this solution? > > > > There should be no mismatches with the current scheme. > > We explicitly program wms to 0 for disabled planes. > > > > It still happens when we take over the state that BIOS/firmware left. That would seem to imply skl_wm_add_affected_planes() isn't working right for some reason. -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Fix plane watermark mismatches
On Thu, 2021-02-18 at 00:14 +0200, Ville Syrjälä wrote: > On Wed, Feb 17, 2021 at 05:24:03PM +, Souza, Jose wrote: > > On Fri, 2021-02-12 at 23:13 +0200, Ville Syrjälä wrote: > > > On Fri, Feb 12, 2021 at 07:44:22PM +, Souza, Jose wrote: > > > > On Fri, 2021-02-12 at 20:35 +0200, Ville Syrjälä wrote: > > > > > On Fri, Feb 12, 2021 at 10:22:01AM -0800, José Roberto de Souza wrote: > > > > > > Found a system were firmware/BIOS left the plane_res_b and > > > > > > plane_res_l > > > > > > set with non-zero values for disable planes. > > > > > > > > > > It pretty much happens always since the reset value is not zero. > > > > > IIRC we made the state chcker pedantic enough to complain about > > > > > that, so we need to clean it up. > > > > > > > > Are you planning to fix it soon? > > > > > > Fix what exactly? I guess you're seeing an actual problem of some sort? > > > > Your comment above made me understand that you were planning to fix this > > plane watermark mismatches for disabled planes in other way other than what > > this patch does. > > Or should we proceed with this solution? > > There should be no mismatches with the current scheme. > We explicitly program wms to 0 for disabled planes. > It still happens when we take over the state that BIOS/firmware left. [ 118.222939] [drm:drm_atomic_commit] committing 676e6290 [ 118.241712] i915 :00:02.0: [drm:intel_panel_actually_set_backlight [i915]] set backlight PWM = 96000 [ 118.242314] i915 :00:02.0: [drm:__intel_fbc_disable [i915]] Disabling FBC on pipe A [ 118.242726] i915 :00:02.0: [drm:intel_fbc_enable [i915]] reserved 16588800 bytes of contiguous stolen space for FBC, threshold: 1 [ 118.243020] i915 :00:02.0: [drm:intel_fbc_enable [i915]] Enabling FBC on pipe A [ 118.257685] i915 :00:02.0: [drm] *ERROR* mismatch in WM pipe A plane 2 level 0 (expected e=0 b=0 l=0, got e=0 b=7 l=1) [ 118.257698] i915 :00:02.0: [drm] *ERROR* mismatch in WM pipe A plane 2 level 1 (expected e=0 b=0 l=0, got e=0 b=7 l=1) [ 118.257706] i915 :00:02.0: [drm] *ERROR* mismatch in WM pipe A plane 2 level 2 (expected e=0 b=0 l=0, got e=0 b=7 l=1) [ 118.257714] i915 :00:02.0: [drm] *ERROR* mismatch in WM pipe A plane 2 level 3 (expected e=0 b=0 l=0, got e=0 b=7 l=1) [ 118.257721] i915 :00:02.0: [drm] *ERROR* mismatch in WM pipe A plane 2 level 4 (expected e=0 b=0 l=0, got e=0 b=7 l=1) [ 118.257729] i915 :00:02.0: [drm] *ERROR* mismatch in WM pipe A plane 2 level 5 (expected e=0 b=0 l=0, got e=0 b=7 l=1) [ 118.257737] i915 :00:02.0: [drm] *ERROR* mismatch in WM pipe A plane 2 level 6 (expected e=0 b=0 l=0, got e=0 b=7 l=1) [ 118.257745] i915 :00:02.0: [drm] *ERROR* mismatch in trans WM pipe A plane 2 (expected e=0 b=0 l=0, got e=0 b=7 l=1) [ 118.257753] i915 :00:02.0: [drm] *ERROR* mismatch in SAGV trans WM pipe A plane 2 (expected e=0 b=0 l=0, got e=0 b=7 l=1) [ 118.257761] i915 :00:02.0: [drm] *ERROR* mismatch in WM pipe A plane 3 level 0 (expected e=0 b=0 l=0, got e=0 b=7 l=1) [ 118.257769] i915 :00:02.0: [drm] *ERROR* mismatch in WM pipe A plane 3 level 1 (expected e=0 b=0 l=0, got e=0 b=7 l=1) [ 118.257776] i915 :00:02.0: [drm] *ERROR* mismatch in WM pipe A plane 3 level 2 (expected e=0 b=0 l=0, got e=0 b=7 l=1) [ 118.257784] i915 :00:02.0: [drm] *ERROR* mismatch in WM pipe A plane 3 level 3 (expected e=0 b=0 l=0, got e=0 b=7 l=1) [ 118.257792] i915 :00:02.0: [drm] *ERROR* mismatch in WM pipe A plane 3 level 4 (expected e=0 b=0 l=0, got e=0 b=7 l=1) [ 118.257800] i915 :00:02.0: [drm] *ERROR* mismatch in WM pipe A plane 3 level 5 (expected e=0 b=0 l=0, got e=0 b=7 l=1) [ 118.257807] i915 :00:02.0: [drm] *ERROR* mismatch in WM pipe A plane 3 level 6 (expected e=0 b=0 l=0, got e=0 b=7 l=1) [ 118.257815] i915 :00:02.0: [drm] *ERROR* mismatch in trans WM pipe A plane 3 (expected e=0 b=0 l=0, got e=0 b=7 l=1) [ 118.257823] i915 :00:02.0: [drm] *ERROR* mismatch in SAGV trans WM pipe A plane 3 (expected e=0 b=0 l=0, got e=0 b=7 l=1) [ 118.257920] i915 :00:02.0: [drm] *ERROR* mismatch in WM pipe A plane 4 level 0 (expected e=0 b=0 l=0, got e=0 b=7 l=1) [ 118.257929] i915 :00:02.0: [drm] *ERROR* mismatch in WM pipe A plane 4 level 1 (expected e=0 b=0 l=0, got e=0 b=7 l=1) [ 118.257939] i915 :00:02.0: [drm] *ERROR* mismatch in WM pipe A plane 4 level 2 (expected e=0 b=0 l=0, got e=0 b=7 l=1) [ 118.257949] i915 :00:02.0: [drm] *ERROR* mismatch in WM pipe A plane 4 level 3 (expected e=0 b=0 l=0, got e=0 b=7 l=1) [ 118.257956] i915 :00:02.0: [drm] *ERROR* mismatch in WM pipe A plane 4 level 4 (expected e=0 b=0 l=0, got e=0 b=7 l=1) [ 118.257965] i915 :00:02.0: [drm] *ERROR* mismatch in WM pipe A plane 4 level 5 (expected e=0 b=0 l=0, got e=0 b=7 l=1) [ 118.257975] i915 :00:02.0: [drm] *ERROR* mismatch in WM pipe A plane 4 level 6 (expected e=0 b=0 l=0, got e=0 b=7 l=1) [ 118.257984] i915
Re: [Intel-gfx] [PATCH v2] drm/vblank: Do not store a new vblank timestamp in drm_vblank_restore()
On Thu, Feb 18, 2021 at 06:03:05PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > drm_vblank_restore() exists because certain power saving states > can clobber the hardware frame counter. The way it does this is > by guesstimating how many frames were missed purely based on > the difference between the last stored timestamp vs. a newly > sampled timestamp. > > If we should call this function before a full frame has > elapsed since we sampled the last timestamp we would end up > with a possibly slightly different timestamp value for the > same frame. Currently we will happily overwrite the already > stored timestamp for the frame with the new value. This > could cause userspace to observe two different timestamps > for the same frame (and the timestamp could even go > backwards depending on how much error we introduce when > correcting the timestamp based on the scanout position). > > To avoid that let's not update the stored timestamp at all, > and instead we just fix up the last recorded hw vblank counter > value such that the already stored timestamp/seq number will > match. Thus the next time a vblank irq happens it will calculate > the correct diff between the current and stored hw vblank counter > values. > > Sidenote: Another possible idea that came to mind would be to > do this correction only if the power really was removed since > the last time we sampled the hw frame counter. But to do that > we would need a robust way to detect when it has occurred. Some > possibilities could involve some kind of hardare power well > transition counter, or potentially we could store a magic value > in a scratch register that lives in the same power well. But > I'm not sure either of those exist, so would need an actual > investigation to find out. All of that is very hardware specific > of course, so would have to be done in the driver code. Forgot to mention that I wasn't able to test this with PSR since HSW+PSR1 is bork, but I did test it a bit w/o PSR by artificially adding arbitrary offsets to the reported hw frame counter value. The behaviour seemed sane enough at least. > > Cc: Dhinakaran Pandiyan > Cc: Rodrigo Vivi > Cc: Daniel Vetter > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/drm_vblank.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c > index 2bd989688eae..3417e1ac7918 100644 > --- a/drivers/gpu/drm/drm_vblank.c > +++ b/drivers/gpu/drm/drm_vblank.c > @@ -1478,6 +1478,7 @@ static void drm_vblank_restore(struct drm_device *dev, > unsigned int pipe) > u64 diff_ns; > u32 cur_vblank, diff = 1; > int count = DRM_TIMESTAMP_MAXRETRIES; > + u32 max_vblank_count = drm_max_vblank_count(dev, pipe); > > if (drm_WARN_ON(dev, pipe >= dev->num_crtcs)) > return; > @@ -1504,7 +1505,7 @@ static void drm_vblank_restore(struct drm_device *dev, > unsigned int pipe) > drm_dbg_vbl(dev, > "missed %d vblanks in %lld ns, frame duration=%d ns, > hw_diff=%d\n", > diff, diff_ns, framedur_ns, cur_vblank - vblank->last); > - store_vblank(dev, pipe, diff, t_vblank, cur_vblank); > + vblank->last = (cur_vblank - diff) & max_vblank_count; > } > > /** > -- > 2.26.2 -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/vblank: Do not store a new vblank timestamp in drm_vblank_restore()
From: Ville Syrjälä drm_vblank_restore() exists because certain power saving states can clobber the hardware frame counter. The way it does this is by guesstimating how many frames were missed purely based on the difference between the last stored timestamp vs. a newly sampled timestamp. If we should call this function before a full frame has elapsed since we sampled the last timestamp we would end up with a possibly slightly different timestamp value for the same frame. Currently we will happily overwrite the already stored timestamp for the frame with the new value. This could cause userspace to observe two different timestamps for the same frame (and the timestamp could even go backwards depending on how much error we introduce when correcting the timestamp based on the scanout position). To avoid that let's not update the stored timestamp at all, and instead we just fix up the last recorded hw vblank counter value such that the already stored timestamp/seq number will match. Thus the next time a vblank irq happens it will calculate the correct diff between the current and stored hw vblank counter values. Sidenote: Another possible idea that came to mind would be to do this correction only if the power really was removed since the last time we sampled the hw frame counter. But to do that we would need a robust way to detect when it has occurred. Some possibilities could involve some kind of hardare power well transition counter, or potentially we could store a magic value in a scratch register that lives in the same power well. But I'm not sure either of those exist, so would need an actual investigation to find out. All of that is very hardware specific of course, so would have to be done in the driver code. Cc: Dhinakaran Pandiyan Cc: Rodrigo Vivi Cc: Daniel Vetter Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_vblank.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c index 2bd989688eae..3417e1ac7918 100644 --- a/drivers/gpu/drm/drm_vblank.c +++ b/drivers/gpu/drm/drm_vblank.c @@ -1478,6 +1478,7 @@ static void drm_vblank_restore(struct drm_device *dev, unsigned int pipe) u64 diff_ns; u32 cur_vblank, diff = 1; int count = DRM_TIMESTAMP_MAXRETRIES; + u32 max_vblank_count = drm_max_vblank_count(dev, pipe); if (drm_WARN_ON(dev, pipe >= dev->num_crtcs)) return; @@ -1504,7 +1505,7 @@ static void drm_vblank_restore(struct drm_device *dev, unsigned int pipe) drm_dbg_vbl(dev, "missed %d vblanks in %lld ns, frame duration=%d ns, hw_diff=%d\n", diff, diff_ns, framedur_ns, cur_vblank - vblank->last); - store_vblank(dev, pipe, diff, t_vblank, cur_vblank); + vblank->last = (cur_vblank - diff) & max_vblank_count; } /** -- 2.26.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Issue with cec_register_adapter calling request_module() from an async context when called from intel_dp_detect
Hi,
On 2/17/21 5:29 PM, Hans Verkuil wrote:
> On 17/02/2021 16:11, Sean Young wrote:
>> Hi,
>>
>> On Wed, Feb 17, 2021 at 04:04:11PM +0100, Hans de Goede wrote:
>>> On 2/17/21 3:32 PM, Sean Young wrote:
On Wed, Feb 17, 2021 at 01:41:46PM +0100, Hans Verkuil wrote:
> Hi Hans,
>
> On 17/02/2021 13:24, Hans de Goede wrote:
>>
>>
>> Hi Hans,
>>
>> Fedora has a (opt-in) system to automatically collect backtraces from
>> software
>> crashing on users systems.
>>
>> This includes collecting kernel backtraces (including once triggered by
>> WARN macros) while looking a the top 10 of the most reported backtrace
>> during the
>> last 2 weeks report from ABRT:
>> https://retrace.fedoraproject.org/faf/problems/
>>
>> I noticed the following backtrace:
>> https://retrace.fedoraproject.org/faf/problems/8150/
>> which has been reported 17 times by Fedora users who have opted-in
>> during the
>> last 14 days.
>>
>> The issue here is that cec_register_adapter ends up calling
>> request_module()
>> from an async context, triggering this warn in kernel/kmod.c
>> __request_module():
>>
>> /*
>> * We don't allow synchronous module loading from async. Module
>> * init may invoke async_synchronize_full() which will end up
>> * waiting for this task which already is waiting for the module
>> * loading to complete, leading to a deadlock.
>> */
>> WARN_ON_ONCE(wait && current_is_async());
>>
>> The call-path leading to this goes like this:
>>
>> ? kvasprintf+0x6d/0xa0
>> ? kobject_set_name_vargs+0x6f/0x90
>> rc_map_get+0x30/0x60
>
> It's not CEC, it is rc_map_get that calls request_module() for rc-cec.ko.
>
> I've added Sean Young to the CC list.
>
> Sean, is it possible to treat rc-cec as a built-in if MEDIA_CEC_RC is set?
>
> I think this issue is very specific to CEC. I would not expect to see this
> with any other rc keymap.
So CEC creates an RC device with a keymap (cec keymap, of course) and then
the keymap needs to be loaded. We certainly don't want all keymaps as
builtins, that would be a waste.
The cec keymap is scanned once to build a map from cec codes to linux
keycodes; making it builtin is not ideal, and makes the build system a
bit messy.
I don't think we can load the keymap later, user space may start remapping
the keymap from udev.
Possibly we could create the cec or rc device later but this could be a bit
messy.
Could CEC specify:
#if IS_ENABLED(CONFIG_MEDIA_CEC_RC)
MODULE_SOFTDEP("rc-cec")
#endif
>>>
>>> That would need to be:
>>>
>>> MODULE_SOFTDEP("pre: rc-cec")
>>>
>>> I see that the drm_kms_helper and i915 drivers both depend on the cec
>>> module already,
>>> so yes if that module will request for rc-cec to be loaded before it is
>>> loaded
>>> (and thus before i915 is loaded) then that should work around this.
>>>
>>> Assuming the user is using a module-loader which honors the softdep...
>>>
>>> Also this assumes that rc_map_get is smart enough to not call
>>> request_module()
>>> if the module is already loaded, is that the case ?
>>
>> Yes, see rc_map_get().
>
> I tried this. It works if CONFIG_RC_CORE is set to m, but setting it to
> y resulted in the same problem. It looks like MODULE_SOFTDEP only works if
> rc_main
> is a module as well.
Yeah that is a known limit of module softdeps, they only work inside modules ...
Still, assuming there is no easy other fix, we could still use this somehow.
I do see that at least Fedora actually has CONFIG_RC_CORE=y for some reason.
I guess we could maybe add the softdep to the CONFIG_RC_MAP module or
maybe to the module which contains the code enabled by CONFIG_DRM_DP_CEC ?
At least Fedora has all drm stuff as modules and also has CONFIG_RC_MAP=m,
I know this is not a real fix but a workaround to get rid of 170,000
backtraces / 14 days being reported by (opted-in) systems running the
Fedora generic kernel config would be welcome regardless of it being the
"perfect" fix.
Regards,
Hans
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC v4 10/11] drm/dp: Extract i915's eDP backlight code into DRM helpers
On Thu, Feb 18, 2021 at 10:35:05AM +0200, Jani Nikula wrote: > On Fri, 12 Feb 2021, Lyude Paul wrote: > > I think it wouldn't be a bad idea to just address this with a followup > > series > > instead and use the old DRM_DEBUG_* macros in the mean time. > > aux->dev is there, could also use dev_dbg et al. in the mean time. They > handle NULL dev gracefully too if the driver didn't set that. Last I looked aux->dev was random. Some drivers point it at the connector vs. some at the the pci/platform device. -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [5.10.y regression] i915 clear-residuals mitigation is causing gfx issues
Hi,
On 2/14/21 5:00 PM, Hans de Goede wrote:
> Hi,
>
> On 2/11/21 1:26 PM, Hans de Goede wrote:
>> Hi,
>>
>> On 2/11/21 11:49 AM, Chris Wilson wrote:
> Started looking for scratch page overwrites, and found this little gem:
> https://patchwork.freedesktop.org/patch/420436/?series=86947=1
>
> Looks promising wrt the cause of overwriting random addresses -- and
> I hope that is the explanation for the glitches/hangs. I have a hsw gt2
> with gnome shell, piglit is happy, but I suspect it is all due to
> placement and so will only occur at random.
If you can give me a list of commits to cherry-pick then I can prepare
a Fedora 5.10.y kernel which those added for the group of Fedora users
who are hitting this to test.
>>>
>>> e627d5923cae ("drm/i915/gt: One more flush for Baytrail clear residuals")
>>> d30bbd62b1bf ("drm/i915/gt: Flush before changing register state")
>>> 1914911f4aa0 ("drm/i915/gt: Correct surface base address for renderclear")
>>
>> Thanks, the test-kernel is building now. I will let you know when I have
>> heard back from the Fedora users (this will likely take 1-2 days).
>
> I've heard back from 2 of the reporters who were seeing issues with 5.10.9+
>
> And I'm happy to report 5.10.15 + the 3 commits mentioned above cherry-picked
> on top fixes the graphics glitches for them.
>
> So if we can get these 3 commits into 5.10.y and 5.11.y then this should be
> resolved.
Unfortunately I just got a report that 5.10.15 + the 3 extra fixes mentioned
above is still causing issues for one user with a
"thinkpad x230 with i5-3320M (HD Graphics 4000)"
The user descibes the problem as: "still have some minor black squares popping
up while scrolling on Firefox."
I've asked this user to test 5.10.14 + the 3 reverts mentioned earlier in the
thread and that kernel does not have this issue.
Chris, any ideas / more fixes to cherry pick for testing ?
Regards,
Hans
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/vbt: update DP max link rate table (rev6)
== Series Details == Series: drm/i915/vbt: update DP max link rate table (rev6) URL : https://patchwork.freedesktop.org/series/86539/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9783_full -> Patchwork_19700_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_19700_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19700_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_19700_full: ### IGT changes ### Possible regressions * igt@i915_selftest@live@memory_region: - shard-skl: NOTRUN -> [INCOMPLETE][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19700/shard-skl6/igt@i915_selftest@live@memory_region.html Known issues Here are the changes found in Patchwork_19700_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-kbl: NOTRUN -> [DMESG-WARN][2] ([i915#3002]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19700/shard-kbl1/igt@gem_cre...@create-massive.html * igt@gem_ctx_persistence@engines-hang: - shard-snb: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19700/shard-snb6/igt@gem_ctx_persiste...@engines-hang.html * igt@gem_eio@unwedge-stress: - shard-iclb: [PASS][4] -> [TIMEOUT][5] ([i915#1037] / [i915#2481]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9783/shard-iclb7/igt@gem_...@unwedge-stress.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19700/shard-iclb5/igt@gem_...@unwedge-stress.html * igt@gem_exec_balancer@hang: - shard-iclb: [PASS][6] -> [INCOMPLETE][7] ([i915#1895] / [i915#2295] / [i915#3031]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9783/shard-iclb8/igt@gem_exec_balan...@hang.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19700/shard-iclb1/igt@gem_exec_balan...@hang.html * igt@gem_exec_fair@basic-deadline: - shard-kbl: [PASS][8] -> [FAIL][9] ([i915#2846]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9783/shard-kbl4/igt@gem_exec_f...@basic-deadline.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19700/shard-kbl6/igt@gem_exec_f...@basic-deadline.html - shard-glk: NOTRUN -> [FAIL][10] ([i915#2846]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19700/shard-glk6/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-tglb: [PASS][11] -> [FAIL][12] ([i915#2842]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9783/shard-tglb1/igt@gem_exec_fair@basic-none-sh...@rcs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19700/shard-tglb7/igt@gem_exec_fair@basic-none-sh...@rcs0.html - shard-glk: [PASS][13] -> [FAIL][14] ([i915#2842]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9783/shard-glk5/igt@gem_exec_fair@basic-none-sh...@rcs0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19700/shard-glk8/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-none@vcs0: - shard-kbl: [PASS][15] -> [FAIL][16] ([i915#2842]) +4 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9783/shard-kbl1/igt@gem_exec_fair@basic-n...@vcs0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19700/shard-kbl2/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_exec_fair@basic-none@vcs1: - shard-iclb: NOTRUN -> [FAIL][17] ([i915#2842]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19700/shard-iclb4/igt@gem_exec_fair@basic-n...@vcs1.html * igt@gem_exec_reloc@basic-parallel: - shard-kbl: NOTRUN -> [TIMEOUT][18] ([i915#1729]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19700/shard-kbl7/igt@gem_exec_re...@basic-parallel.html - shard-apl: NOTRUN -> [TIMEOUT][19] ([i915#1729]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19700/shard-apl3/igt@gem_exec_re...@basic-parallel.html * igt@gem_exec_reloc@basic-wide-active@bcs0: - shard-apl: NOTRUN -> [FAIL][20] ([i915#2389]) +3 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19700/shard-apl1/igt@gem_exec_reloc@basic-wide-act...@bcs0.html * igt@gem_exec_reloc@basic-wide-active@vcs1: - shard-iclb: NOTRUN -> [FAIL][21] ([i915#2389]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19700/shard-iclb1/igt@gem_exec_reloc@basic-wide-act...@vcs1.html *
Re: [Intel-gfx] [PATCH] drm/i915: Nuke INTEL_OUTPUT_FORMAT_INVALID
On Thu, 2021-02-18 at 00:10 +0200, Ville Syrjälä wrote:
> On Wed, Feb 17, 2021 at 04:37:20PM +, Souza, Jose wrote:
> > On Fri, 2021-02-05 at 22:23 +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > We tend to use output_format!=RGB as a shorthand for YCbCr, but
> > > this fails if we have a disabled crtc where output_format==INVALID.
> > > We're now getting some fail from intel_color_check() when we have:
> > > hw.enable==false
> > > hw.ctm!=NULL
> > > output_format==INVALID
> > >
> > > Let's avoid that by throwing INTEL_OUTPUT_FORMAT_INVALID to the
> > > dumpster, and thus everything defaults to RGB when the crtc
> > > is disabled.
> > >
> > > This does beg the deeper question of how much of the state
> > > should we in fact be validating when hw/uapi.enable==false.
> > > And should we even be doing the uapi->hw copy when
> > > uapi.enable==false? So far I've not been able to come up with
> > > satisfactory answers for myself, so I'm putting it off for the
> > > moment.
> > >
> > > Cc: Lee Shawn C
> > > Fixes: 0aa5c3835c8a ("drm/i915: support two CSC module on gen11 and
> > > later")
> > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2964
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/i915/display/intel_crtc.c | 1 -
> > > drivers/gpu/drm/i915/display/intel_display.c | 3 +--
> > > drivers/gpu/drm/i915/display/intel_display_types.h | 1 -
> > > 3 files changed, 1 insertion(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
> > > b/drivers/gpu/drm/i915/display/intel_crtc.c
> > > index 57b0a3ebe908..8e77ca7ddf11 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> > > @@ -109,7 +109,6 @@ void intel_crtc_state_reset(struct intel_crtc_state
> > > *crtc_state,
>
> void intel_crtc_state_reset(struct intel_crtc_state *crtc_state,
> struct intel_crtc *crtc)
> {
> memset(crtc_state, 0, sizeof(*crtc_state));
> ...
>
> > > crtc_state->cpu_transcoder = INVALID_TRANSCODER;
> > > crtc_state->master_transcoder = INVALID_TRANSCODER;
> > > crtc_state->hsw_workaround_pipe = INVALID_PIPE;
> > > - crtc_state->output_format = INTEL_OUTPUT_FORMAT_INVALID;
> >
> > Missing set output_format to INTEL_OUTPUT_FORMAT_RGB, kmalloc() don't set
> > memory allocated to zero and INTEL_OUTPUT_FORMAT_INVALID was the index 0 and
> > we were setting it during intel_crtc_state_reset() so we should now set it
> > to INTEL_OUTPUT_FORMAT_RGB.
> > https://www.kernel.org/doc/htmldocs/kernel-api/mm.html
>
> ie. we zero out the whole thing. The reason why the explicit assignment
> was here I suppose is that I had assumed INTEL_OUTPUT_FORMAT_INVALID==-1,
> which is the case for INVALID_TRANSCODER/PIPE/etc.
Ah okay, missed the memset().
Reviewed-by: José Roberto de Souza
>
> >
> > With that fixed:
> >
> > Reviewed-by: José Roberto de Souza
> >
> > > crtc_state->scaler_state.scaler_id = -1;
> > > crtc_state->mst_master_transcoder = INVALID_TRANSCODER;
> > > }
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > index 92c14f3f0abf..46d0093187f8 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > @@ -10220,7 +10220,6 @@ static void snprintf_output_types(char *buf,
> > > size_t len,
> > > }
> > >
> > >
> > >
> > >
> > > static const char * const output_format_str[] = {
> > > - [INTEL_OUTPUT_FORMAT_INVALID] = "Invalid",
> > > [INTEL_OUTPUT_FORMAT_RGB] = "RGB",
> > > [INTEL_OUTPUT_FORMAT_YCBCR420] = "YCBCR4:2:0",
> > > [INTEL_OUTPUT_FORMAT_YCBCR444] = "YCBCR4:4:4",
> > > @@ -10229,7 +10228,7 @@ static const char * const output_format_str[] = {
> > > static const char *output_formats(enum intel_output_format format)
> > > {
> > > if (format >= ARRAY_SIZE(output_format_str))
> > > - format = INTEL_OUTPUT_FORMAT_INVALID;
> > > + return "invalid";
> > > return output_format_str[format];
> > > }
> > >
> > >
> > >
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > index 307ff4b771f4..b3ac39fea6f0 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > @@ -830,7 +830,6 @@ struct intel_crtc_wm_state {
> > > };
> > >
> > >
> > >
> > >
> > > enum intel_output_format {
> > > - INTEL_OUTPUT_FORMAT_INVALID,
> > > INTEL_OUTPUT_FORMAT_RGB,
> > > INTEL_OUTPUT_FORMAT_YCBCR420,
> > > INTEL_OUTPUT_FORMAT_YCBCR444,
> >
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915/vbt: update DP max link rate table
On Wed, Feb 17, 2021 at 3:45 p.m., Ville Syrjälä wrote:
>On Wed, Feb 17, 2021 at 11:39:35PM +0800, Lee Shawn C wrote:
>> According to Bspec #20124, max link rate table for DP was updated at
>> BDB version 230. Max link rate can support upto UHBR.
>>
>> After migrate to BDB v230, the definition for LBR, HBR2 and HBR3 were
>> changed. For backward compatibility. If BDB version was from 216 to
>> 229. Driver have to follow original rule to configure DP max link rate
>> value from VBT.
>>
>> v2: split the mapping table to two for old and new BDB definition.
>> v3: return link rate instead of assigning it.
>>
>> Cc: Ville Syrjala
>> Cc: Imre Deak
>> Cc: Jani Nikula
>> Cc: Cooper Chiou
>> Cc: William Tseng
>> Signed-off-by: Lee Shawn C
>> ---
>> drivers/gpu/drm/i915/display/intel_bios.c | 78 +++
>> drivers/gpu/drm/i915/display/intel_vbt_defs.h | 23 --
>> 2 files changed, 80 insertions(+), 21 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
>> b/drivers/gpu/drm/i915/display/intel_bios.c
>> index 7902d4c2673e..d8305c351b77 100644
>> --- a/drivers/gpu/drm/i915/display/intel_bios.c
>> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
>> @@ -1759,6 +1759,64 @@ static enum port dvo_port_to_port(struct
>> drm_i915_private *dev_priv,
>>dvo_port);
>> }
>>
>> +static int parse_bdb_230_dp_max_link_rate(const int
>> +vbt_max_link_rate) {
>> +int link_rate;
>
>That variable is rather pointless...
>
>> +
>> +switch (vbt_max_link_rate) {
>> +case BDB_230_VBT_DP_MAX_LINK_RATE_UHBR20:
>> +link_rate = 200;
>> +break;
>
>... when you can just 'return ' here directly.
>Would reduce the noise a bit as well since the break statements would vanish.
>
Update patch v4 and just return the value as you mentioned.
Please help to review again.
BTW, I'm sorry I press "test again" button two times and waste test machine
resource.
Best regards,
Shawn
>> +case BDB_230_VBT_DP_MAX_LINK_RATE_UHBR13P5:
>> +link_rate = 135;
>> +break;
>> +case BDB_230_VBT_DP_MAX_LINK_RATE_UHBR10:
>> +link_rate = 100;
>> +break;
>> +case BDB_230_VBT_DP_MAX_LINK_RATE_HBR3:
>> +link_rate = 81;
>> +break;
>> +case BDB_230_VBT_DP_MAX_LINK_RATE_HBR2:
>> +link_rate = 54;
>> +break;
>> +case BDB_230_VBT_DP_MAX_LINK_RATE_HBR:
>> +link_rate = 27;
>> +break;
>> +case BDB_230_VBT_DP_MAX_LINK_RATE_LBR:
>> +link_rate = 162000;
>> +break;
>> +case BDB_230_VBT_DP_MAX_LINK_RATE_DEF:
>> +default:
>> +link_rate = 0;
>> +break;
>> +}
>> +
>> +return link_rate;
>> +}
>> +
>> +static int parse_bdb_216_dp_max_link_rate(const int
>> +vbt_max_link_rate) {
>> +int link_rate;
>
>Same here.
>
>With that changed this is
>Reviewed-by: Ville Syrjälä
>
>> +
>> +switch (vbt_max_link_rate) {
>> +default:
>> +case BDB_216_VBT_DP_MAX_LINK_RATE_HBR3:
>> +link_rate = 81;
>> +break;
>> +case BDB_216_VBT_DP_MAX_LINK_RATE_HBR2:
>> +link_rate = 54;
>> +break;
>> +case BDB_216_VBT_DP_MAX_LINK_RATE_HBR:
>> +link_rate = 27;
>> +break;
>> +case BDB_216_VBT_DP_MAX_LINK_RATE_LBR:
>> +link_rate = 162000;
>> +break;
>> +}
>> +
>> +return link_rate;
>> +}
>> +
>> static void parse_ddi_port(struct drm_i915_private *dev_priv,
>> struct display_device_data *devdata,
>> u8 bdb_version)
>> @@ -1884,21 +1942,11 @@ static void parse_ddi_port(struct
>> drm_i915_private *dev_priv,
>>
>> /* DP max link rate for CNL+ */
>> if (bdb_version >= 216) {
>> -switch (child->dp_max_link_rate) {
>> -default:
>> -case VBT_DP_MAX_LINK_RATE_HBR3:
>> -info->dp_max_link_rate = 81;
>> -break;
>> -case VBT_DP_MAX_LINK_RATE_HBR2:
>> -info->dp_max_link_rate = 54;
>> -break;
>> -case VBT_DP_MAX_LINK_RATE_HBR:
>> -info->dp_max_link_rate = 27;
>> -break;
>> -case VBT_DP_MAX_LINK_RATE_LBR:
>> -info->dp_max_link_rate = 162000;
>> -break;
>> -}
>> +if (bdb_version >= 230)
>> +info->dp_max_link_rate =
>> parse_bdb_230_dp_max_link_rate(child->dp_max_link_rate);
>> +else
>> +info->dp_max_link_rate =
>> +parse_bdb_216_dp_max_link_rate(child->dp_max_link_rate);
>> +
>> drm_dbg_kms(_priv->drm,
>> "Port %c VBT DP max link rate: %d\n",
>> port_name(port), info->dp_max_link_rate); diff
>> --git
>>
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/vbt: update DP max link rate table (rev6)
== Series Details ==
Series: drm/i915/vbt: update DP max link rate table (rev6)
URL : https://patchwork.freedesktop.org/series/86539/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9783 -> Patchwork_19700
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19700/index.html
Known issues
Here are the changes found in Patchwork_19700 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@gt_lrc:
- fi-tgl-y: NOTRUN -> [DMESG-FAIL][1] ([i915#2373])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19700/fi-tgl-y/igt@i915_selftest@live@gt_lrc.html
* igt@i915_selftest@live@gt_pm:
- fi-tgl-y: NOTRUN -> [DMESG-FAIL][2] ([i915#1759])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19700/fi-tgl-y/igt@i915_selftest@live@gt_pm.html
* igt@kms_chamelium@vga-edid-read:
- fi-tgl-y: NOTRUN -> [SKIP][3] ([fdo#111827]) +8 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19700/fi-tgl-y/igt@kms_chamel...@vga-edid-read.html
* igt@kms_force_connector_basic@force-load-detect:
- fi-tgl-y: NOTRUN -> [SKIP][4] ([fdo#109285])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19700/fi-tgl-y/igt@kms_force_connector_ba...@force-load-detect.html
* igt@prime_self_import@basic-with_one_bo_two_files:
- fi-tgl-y: NOTRUN -> [DMESG-WARN][5] ([i915#402]) +1 similar
issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19700/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html
Possible fixes
* igt@i915_selftest@live@blt:
- fi-snb-2520m: [DMESG-FAIL][6] -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9783/fi-snb-2520m/igt@i915_selftest@l...@blt.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19700/fi-snb-2520m/igt@i915_selftest@l...@blt.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1759]: https://gitlab.freedesktop.org/drm/intel/issues/1759
[i915#2283]: https://gitlab.freedesktop.org/drm/intel/issues/2283
[i915#2373]: https://gitlab.freedesktop.org/drm/intel/issues/2373
[i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
[i915#3004]: https://gitlab.freedesktop.org/drm/intel/issues/3004
[i915#3005]: https://gitlab.freedesktop.org/drm/intel/issues/3005
[i915#3011]: https://gitlab.freedesktop.org/drm/intel/issues/3011
[i915#3012]: https://gitlab.freedesktop.org/drm/intel/issues/3012
[i915#3013]: https://gitlab.freedesktop.org/drm/intel/issues/3013
[i915#3014]: https://gitlab.freedesktop.org/drm/intel/issues/3014
[i915#3015]: https://gitlab.freedesktop.org/drm/intel/issues/3015
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533
Participating hosts (42 -> 40)
--
Additional (2): fi-tgl-y fi-hsw-gt1
Missing(4): fi-ilk-m540 fi-bsw-cyan fi-bdw-samus fi-hsw-4200u
Build changes
-
* Linux: CI_DRM_9783 -> Patchwork_19700
CI-20190529: 20190529
CI_DRM_9783: 498a1b2bfd0ecf4401c2f653a82e9ae2c80c9145 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6005: b69a3c463f0aec46b19c14ac24351d292cb11c08 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_19700: fa8c00f1e8a25472372da9c784892698352367ee @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
fa8c00f1e8a2 drm/i915/vbt: update DP max link rate table
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19700/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Issue with cec_register_adapter calling request_module() from an async context when called from intel_dp_detect
Hi,
On Wed, Feb 17, 2021 at 05:29:46PM +0100, Hans Verkuil wrote:
> On 17/02/2021 16:11, Sean Young wrote:
> > On Wed, Feb 17, 2021 at 04:04:11PM +0100, Hans de Goede wrote:
> >> On 2/17/21 3:32 PM, Sean Young wrote:
> >>> On Wed, Feb 17, 2021 at 01:41:46PM +0100, Hans Verkuil wrote:
> Hi Hans,
>
> On 17/02/2021 13:24, Hans de Goede wrote:
> >
> >
> > Hi Hans,
> >
> > Fedora has a (opt-in) system to automatically collect backtraces from
> > software
> > crashing on users systems.
> >
> > This includes collecting kernel backtraces (including once triggered by
> > WARN macros) while looking a the top 10 of the most reported backtrace
> > during the
> > last 2 weeks report from ABRT:
> > https://retrace.fedoraproject.org/faf/problems/
> >
> > I noticed the following backtrace:
> > https://retrace.fedoraproject.org/faf/problems/8150/
> > which has been reported 17 times by Fedora users who have opted-in
> > during the
> > last 14 days.
> >
> > The issue here is that cec_register_adapter ends up calling
> > request_module()
> > from an async context, triggering this warn in kernel/kmod.c
> > __request_module():
> >
> > /*
> > * We don't allow synchronous module loading from async. Module
> > * init may invoke async_synchronize_full() which will end up
> > * waiting for this task which already is waiting for the module
> > * loading to complete, leading to a deadlock.
> > */
> > WARN_ON_ONCE(wait && current_is_async());
> >
> > The call-path leading to this goes like this:
> >
> > ? kvasprintf+0x6d/0xa0
> > ? kobject_set_name_vargs+0x6f/0x90
> > rc_map_get+0x30/0x60
>
> It's not CEC, it is rc_map_get that calls request_module() for rc-cec.ko.
>
> I've added Sean Young to the CC list.
>
> Sean, is it possible to treat rc-cec as a built-in if MEDIA_CEC_RC is
> set?
>
> I think this issue is very specific to CEC. I would not expect to see
> this
> with any other rc keymap.
> >>>
> >>> So CEC creates an RC device with a keymap (cec keymap, of course) and then
> >>> the keymap needs to be loaded. We certainly don't want all keymaps as
> >>> builtins, that would be a waste.
> >>>
> >>> The cec keymap is scanned once to build a map from cec codes to linux
> >>> keycodes; making it builtin is not ideal, and makes the build system a
> >>> bit messy.
> >>>
> >>> I don't think we can load the keymap later, user space may start remapping
> >>> the keymap from udev.
> >>>
> >>> Possibly we could create the cec or rc device later but this could be a
> >>> bit
> >>> messy.
> >>>
> >>> Could CEC specify:
> >>>
> >>> #if IS_ENABLED(CONFIG_MEDIA_CEC_RC)
> >>> MODULE_SOFTDEP("rc-cec")
> >>> #endif
> >>
> >> That would need to be:
> >>
> >> MODULE_SOFTDEP("pre: rc-cec")
> >>
> >> I see that the drm_kms_helper and i915 drivers both depend on the cec
> >> module already,
> >> so yes if that module will request for rc-cec to be loaded before it is
> >> loaded
> >> (and thus before i915 is loaded) then that should work around this.
> >>
> >> Assuming the user is using a module-loader which honors the softdep...
> >>
> >> Also this assumes that rc_map_get is smart enough to not call
> >> request_module()
> >> if the module is already loaded, is that the case ?
> >
> > Yes, see rc_map_get().
>
> I tried this. It works if CONFIG_RC_CORE is set to m, but setting it to
> y resulted in the same problem. It looks like MODULE_SOFTDEP only works if
> rc_main
> is a module as well.
Hmm, I'm not quite sure what is happening here. How can I reproduce this
issue locally?
Sean
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Issue with cec_register_adapter calling request_module() from an async context when called from intel_dp_detect
Hi,
On Wed, Feb 17, 2021 at 04:04:11PM +0100, Hans de Goede wrote:
> On 2/17/21 3:32 PM, Sean Young wrote:
> > On Wed, Feb 17, 2021 at 01:41:46PM +0100, Hans Verkuil wrote:
> >> Hi Hans,
> >>
> >> On 17/02/2021 13:24, Hans de Goede wrote:
> >>>
> >>>
> >>> Hi Hans,
> >>>
> >>> Fedora has a (opt-in) system to automatically collect backtraces from
> >>> software
> >>> crashing on users systems.
> >>>
> >>> This includes collecting kernel backtraces (including once triggered by
> >>> WARN macros) while looking a the top 10 of the most reported backtrace
> >>> during the
> >>> last 2 weeks report from ABRT:
> >>> https://retrace.fedoraproject.org/faf/problems/
> >>>
> >>> I noticed the following backtrace:
> >>> https://retrace.fedoraproject.org/faf/problems/8150/
> >>> which has been reported 17 times by Fedora users who have opted-in
> >>> during the
> >>> last 14 days.
> >>>
> >>> The issue here is that cec_register_adapter ends up calling
> >>> request_module()
> >>> from an async context, triggering this warn in kernel/kmod.c
> >>> __request_module():
> >>>
> >>> /*
> >>> * We don't allow synchronous module loading from async. Module
> >>> * init may invoke async_synchronize_full() which will end up
> >>> * waiting for this task which already is waiting for the module
> >>> * loading to complete, leading to a deadlock.
> >>> */
> >>> WARN_ON_ONCE(wait && current_is_async());
> >>>
> >>> The call-path leading to this goes like this:
> >>>
> >>> ? kvasprintf+0x6d/0xa0
> >>> ? kobject_set_name_vargs+0x6f/0x90
> >>> rc_map_get+0x30/0x60
> >>
> >> It's not CEC, it is rc_map_get that calls request_module() for rc-cec.ko.
> >>
> >> I've added Sean Young to the CC list.
> >>
> >> Sean, is it possible to treat rc-cec as a built-in if MEDIA_CEC_RC is set?
> >>
> >> I think this issue is very specific to CEC. I would not expect to see this
> >> with any other rc keymap.
> >
> > So CEC creates an RC device with a keymap (cec keymap, of course) and then
> > the keymap needs to be loaded. We certainly don't want all keymaps as
> > builtins, that would be a waste.
> >
> > The cec keymap is scanned once to build a map from cec codes to linux
> > keycodes; making it builtin is not ideal, and makes the build system a
> > bit messy.
> >
> > I don't think we can load the keymap later, user space may start remapping
> > the keymap from udev.
> >
> > Possibly we could create the cec or rc device later but this could be a bit
> > messy.
> >
> > Could CEC specify:
> >
> > #if IS_ENABLED(CONFIG_MEDIA_CEC_RC)
> > MODULE_SOFTDEP("rc-cec")
> > #endif
>
> That would need to be:
>
> MODULE_SOFTDEP("pre: rc-cec")
>
> I see that the drm_kms_helper and i915 drivers both depend on the cec module
> already,
> so yes if that module will request for rc-cec to be loaded before it is loaded
> (and thus before i915 is loaded) then that should work around this.
>
> Assuming the user is using a module-loader which honors the softdep...
>
> Also this assumes that rc_map_get is smart enough to not call request_module()
> if the module is already loaded, is that the case ?
Yes, see rc_map_get().
Thanks,
Sean
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Issue with cec_register_adapter calling request_module() from an async context when called from intel_dp_detect
On Wed, Feb 17, 2021 at 01:41:46PM +0100, Hans Verkuil wrote:
> Hi Hans,
>
> On 17/02/2021 13:24, Hans de Goede wrote:
> >
> >
> > Hi Hans,
> >
> > Fedora has a (opt-in) system to automatically collect backtraces from
> > software
> > crashing on users systems.
> >
> > This includes collecting kernel backtraces (including once triggered by
> > WARN macros) while looking a the top 10 of the most reported backtrace
> > during the
> > last 2 weeks report from ABRT:
> > https://retrace.fedoraproject.org/faf/problems/
> >
> > I noticed the following backtrace:
> > https://retrace.fedoraproject.org/faf/problems/8150/
> > which has been reported 17 times by Fedora users who have opted-in
> > during the
> > last 14 days.
> >
> > The issue here is that cec_register_adapter ends up calling request_module()
> > from an async context, triggering this warn in kernel/kmod.c
> > __request_module():
> >
> > /*
> > * We don't allow synchronous module loading from async. Module
> > * init may invoke async_synchronize_full() which will end up
> > * waiting for this task which already is waiting for the module
> > * loading to complete, leading to a deadlock.
> > */
> > WARN_ON_ONCE(wait && current_is_async());
> >
> > The call-path leading to this goes like this:
> >
> > ? kvasprintf+0x6d/0xa0
> > ? kobject_set_name_vargs+0x6f/0x90
> > rc_map_get+0x30/0x60
>
> It's not CEC, it is rc_map_get that calls request_module() for rc-cec.ko.
>
> I've added Sean Young to the CC list.
>
> Sean, is it possible to treat rc-cec as a built-in if MEDIA_CEC_RC is set?
>
> I think this issue is very specific to CEC. I would not expect to see this
> with any other rc keymap.
So CEC creates an RC device with a keymap (cec keymap, of course) and then
the keymap needs to be loaded. We certainly don't want all keymaps as
builtins, that would be a waste.
The cec keymap is scanned once to build a map from cec codes to linux
keycodes; making it builtin is not ideal, and makes the build system a
bit messy.
I don't think we can load the keymap later, user space may start remapping
the keymap from udev.
Possibly we could create the cec or rc device later but this could be a bit
messy.
Could CEC specify:
#if IS_ENABLED(CONFIG_MEDIA_CEC_RC)
MODULE_SOFTDEP("rc-cec")
#endif
?
Sean
>
> Regards,
>
> Hans
>
> > rc_register_device+0x108/0x510
> > cec_register_adapter+0x5c/0x280 [cec]
> > drm_dp_cec_set_edid+0x11e/0x178 [drm_kms_helper]
> > intel_dp_set_edid+0x8d/0xc0 [i915]
> > intel_dp_detect+0x188/0x5c0 [i915]
> > drm_helper_probe_single_connector_modes+0xc2/0x6d0 [drm_kms_helper]
> > ? krealloc+0x7b/0xb0
> > drm_client_modeset_probe+0x25b/0x1320 [drm]
> > ? kfree+0x1ea/0x200
> > ? sched_clock+0x5/0x10
> > ? sched_clock_cpu+0xc/0xa0
> > __drm_fb_helper_initial_config_and_unlock+0x37/0x470 [drm_kms_helper]
> > ? _cond_resched+0x16/0x40
> > intel_fbdev_initial_config+0x14/0x30 [i915]
> > async_run_entry_fn+0x39/0x160
> >
> > So 2 questions:
> >
> > 1. Can we get this fixed please ?
> >Related to this, what happens if we make this an async modprobe
> >(when running from async context) is that a problem, or is it fine
> >if the rc_map module gets loaded later ?
> >
> > 2. If the answer to 1. is "tricky", "maybe" or some such then can we
> > look into a workaround here ? E.g. do we know in advance which module
> > is going to be requested (1), or does that depend on the EDID data ?
> >
> > Regards,
> >
> > Hans
> >
> >
> > 1) And can we thus do tricks with a softdep on it ?
> >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/vbt: update DP max link rate table (rev6)
== Series Details == Series: drm/i915/vbt: update DP max link rate table (rev6) URL : https://patchwork.freedesktop.org/series/86539/ State : warning == Summary == $ dim checkpatch origin/drm-tip fa8c00f1e8a2 drm/i915/vbt: update DP max link rate table -:94: WARNING:LONG_LINE: line length of 105 exceeds 100 columns #94: FILE: drivers/gpu/drm/i915/display/intel_bios.c:1926: + info->dp_max_link_rate = parse_bdb_230_dp_max_link_rate(child->dp_max_link_rate); -:96: WARNING:LONG_LINE: line length of 105 exceeds 100 columns #96: FILE: drivers/gpu/drm/i915/display/intel_bios.c:1928: + info->dp_max_link_rate = parse_bdb_216_dp_max_link_rate(child->dp_max_link_rate); total: 0 errors, 2 warnings, 0 checks, 105 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 3/9] drm/i915/spi: add driver for on-die spi device
> > On Wed, Feb 17, 2021 at 08:58:12PM +, Winkler, Tomas wrote: > >> > >> On Tue, 16 Feb 2021, Tomas Winkler wrote: > >> > Add the platform driver for i915 on-die spi device, exposed via mfd > >> > framework. > >> > > >> > Cc: Rodrigo Vivi > >> > Cc: Lucas De Marchi > >> > Signed-off-by: Tomas Winkler > >> > --- > >> > drivers/gpu/drm/i915/Kconfig | 2 + > >> > drivers/gpu/drm/i915/Makefile| 3 + > >> > drivers/gpu/drm/i915/spi/intel_spi_drv.c | 116 > >> > +++ > >> > 3 files changed, 121 insertions(+) create mode 100644 > >> > drivers/gpu/drm/i915/spi/intel_spi_drv.c > >> > > >> > diff --git a/drivers/gpu/drm/i915/Kconfig > >> > b/drivers/gpu/drm/i915/Kconfig index abcaa8da45ac..13c870e5878e > >> > 100644 > >> > --- a/drivers/gpu/drm/i915/Kconfig > >> > +++ b/drivers/gpu/drm/i915/Kconfig > >> > @@ -27,6 +27,8 @@ config DRM_I915 > >> > select CEC_CORE if CEC_NOTIFIER > >> > select VMAP_PFN > >> > select MFD_CORE > >> > +select MTD > >> > >> Selecting MTD does not seem to be a popular thing to do, which is > >> usually a clue it's probably the wrong thing to do. > >Depends, if it is not selected you'll end with wrongly configured system. > > no. I believe the idea is that having a CONFIG_I915_SPI, you could do > > depends on MTD > > like the other drivers doing similar thing: > > git grep MTD -- ':(exclude)drivers/mtd' ':(exclude)arch/' '*Kconfig' MTD is usually used on embedded systems rather than on general distros, i915_spi and actually a bit redefines its usage so w/o forceful select, it won't be enabled. > > Lucas De Marchi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 3/9] drm/i915/spi: add driver for on-die spi device
On Wed, Feb 17, 2021 at 08:58:12PM +, Winkler, Tomas wrote: On Tue, 16 Feb 2021, Tomas Winkler wrote: > Add the platform driver for i915 on-die spi device, exposed via mfd > framework. > > Cc: Rodrigo Vivi > Cc: Lucas De Marchi > Signed-off-by: Tomas Winkler > --- > drivers/gpu/drm/i915/Kconfig | 2 + > drivers/gpu/drm/i915/Makefile| 3 + > drivers/gpu/drm/i915/spi/intel_spi_drv.c | 116 > +++ > 3 files changed, 121 insertions(+) > create mode 100644 drivers/gpu/drm/i915/spi/intel_spi_drv.c > > diff --git a/drivers/gpu/drm/i915/Kconfig > b/drivers/gpu/drm/i915/Kconfig index abcaa8da45ac..13c870e5878e 100644 > --- a/drivers/gpu/drm/i915/Kconfig > +++ b/drivers/gpu/drm/i915/Kconfig > @@ -27,6 +27,8 @@ config DRM_I915 >select CEC_CORE if CEC_NOTIFIER >select VMAP_PFN >select MFD_CORE > + select MTD Selecting MTD does not seem to be a popular thing to do, which is usually a clue it's probably the wrong thing to do. Depends, if it is not selected you'll end with wrongly configured system. no. I believe the idea is that having a CONFIG_I915_SPI, you could do depends on MTD like the other drivers doing similar thing: git grep MTD -- ':(exclude)drivers/mtd' ':(exclude)arch/' '*Kconfig' Lucas De Marchi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/vbt: update DP max link rate table (rev4)
== Series Details == Series: drm/i915/vbt: update DP max link rate table (rev4) URL : https://patchwork.freedesktop.org/series/86539/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9783_full -> Patchwork_19699_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_19699_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19699_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_19699_full: ### IGT changes ### Possible regressions * igt@i915_selftest@live@reset: - shard-skl: NOTRUN -> [INCOMPLETE][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19699/shard-skl5/igt@i915_selftest@l...@reset.html Known issues Here are the changes found in Patchwork_19699_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@engines-hang: - shard-hsw: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#1099]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19699/shard-hsw7/igt@gem_ctx_persiste...@engines-hang.html * igt@gem_ctx_persistence@engines-mixed-process: - shard-snb: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) +3 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19699/shard-snb5/igt@gem_ctx_persiste...@engines-mixed-process.html * igt@gem_exec_balancer@hang: - shard-iclb: [PASS][4] -> [INCOMPLETE][5] ([i915#1895] / [i915#2295]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9783/shard-iclb8/igt@gem_exec_balan...@hang.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19699/shard-iclb2/igt@gem_exec_balan...@hang.html * igt@gem_exec_fair@basic-deadline: - shard-glk: NOTRUN -> [FAIL][6] ([i915#2846]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19699/shard-glk9/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-glk: [PASS][7] -> [FAIL][8] ([i915#2842]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9783/shard-glk5/igt@gem_exec_fair@basic-none-sh...@rcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19699/shard-glk2/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-none-solo@rcs0: - shard-kbl: NOTRUN -> [FAIL][9] ([i915#2842]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19699/shard-kbl2/igt@gem_exec_fair@basic-none-s...@rcs0.html * igt@gem_exec_fair@basic-none@vecs0: - shard-kbl: [PASS][10] -> [FAIL][11] ([i915#2842]) +1 similar issue [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9783/shard-kbl1/igt@gem_exec_fair@basic-n...@vecs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19699/shard-kbl7/igt@gem_exec_fair@basic-n...@vecs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-iclb: NOTRUN -> [FAIL][12] ([i915#2842]) +1 similar issue [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19699/shard-iclb4/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_exec_reloc@basic-many-active@rcs0: - shard-snb: NOTRUN -> [FAIL][13] ([i915#2389]) +2 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19699/shard-snb5/igt@gem_exec_reloc@basic-many-act...@rcs0.html * igt@gem_exec_reloc@basic-parallel: - shard-kbl: NOTRUN -> [TIMEOUT][14] ([i915#1729]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19699/shard-kbl6/igt@gem_exec_re...@basic-parallel.html - shard-apl: NOTRUN -> [TIMEOUT][15] ([i915#1729]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19699/shard-apl8/igt@gem_exec_re...@basic-parallel.html * igt@gem_exec_reloc@basic-wide-active@bcs0: - shard-apl: NOTRUN -> [FAIL][16] ([i915#2389]) +3 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19699/shard-apl1/igt@gem_exec_reloc@basic-wide-act...@bcs0.html * igt@gem_exec_schedule@u-fairslice@bcs0: - shard-tglb: [PASS][17] -> [DMESG-WARN][18] ([i915#2803]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9783/shard-tglb2/igt@gem_exec_schedule@u-fairsl...@bcs0.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19699/shard-tglb8/igt@gem_exec_schedule@u-fairsl...@bcs0.html * igt@gem_exec_schedule@u-fairslice@rcs0: - shard-apl: NOTRUN -> [DMESG-WARN][19] ([i915#1610]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19699/shard-apl8/igt@gem_exec_schedule@u-fairsl...@rcs0.html - shard-skl: [PASS][20] -> [DMESG-WARN][21] ([i915#1610] /
Re: [Intel-gfx] Issue with cec_register_adapter calling request_module() from an async context when called from intel_dp_detect
On 18/02/2021 09:52, Sean Young wrote:
> Hi,
>
> On Wed, Feb 17, 2021 at 05:29:46PM +0100, Hans Verkuil wrote:
>> On 17/02/2021 16:11, Sean Young wrote:
>>> On Wed, Feb 17, 2021 at 04:04:11PM +0100, Hans de Goede wrote:
On 2/17/21 3:32 PM, Sean Young wrote:
> On Wed, Feb 17, 2021 at 01:41:46PM +0100, Hans Verkuil wrote:
>> Hi Hans,
>>
>> On 17/02/2021 13:24, Hans de Goede wrote:
>>>
>>>
>>> Hi Hans,
>>>
>>> Fedora has a (opt-in) system to automatically collect backtraces from
>>> software
>>> crashing on users systems.
>>>
>>> This includes collecting kernel backtraces (including once triggered by
>>> WARN macros) while looking a the top 10 of the most reported backtrace
>>> during the
>>> last 2 weeks report from ABRT:
>>> https://retrace.fedoraproject.org/faf/problems/
>>>
>>> I noticed the following backtrace:
>>> https://retrace.fedoraproject.org/faf/problems/8150/
>>> which has been reported 17 times by Fedora users who have opted-in
>>> during the
>>> last 14 days.
>>>
>>> The issue here is that cec_register_adapter ends up calling
>>> request_module()
>>> from an async context, triggering this warn in kernel/kmod.c
>>> __request_module():
>>>
>>> /*
>>> * We don't allow synchronous module loading from async. Module
>>> * init may invoke async_synchronize_full() which will end up
>>> * waiting for this task which already is waiting for the module
>>> * loading to complete, leading to a deadlock.
>>> */
>>> WARN_ON_ONCE(wait && current_is_async());
>>>
>>> The call-path leading to this goes like this:
>>>
>>> ? kvasprintf+0x6d/0xa0
>>> ? kobject_set_name_vargs+0x6f/0x90
>>> rc_map_get+0x30/0x60
>>
>> It's not CEC, it is rc_map_get that calls request_module() for rc-cec.ko.
>>
>> I've added Sean Young to the CC list.
>>
>> Sean, is it possible to treat rc-cec as a built-in if MEDIA_CEC_RC is
>> set?
>>
>> I think this issue is very specific to CEC. I would not expect to see
>> this
>> with any other rc keymap.
>
> So CEC creates an RC device with a keymap (cec keymap, of course) and then
> the keymap needs to be loaded. We certainly don't want all keymaps as
> builtins, that would be a waste.
>
> The cec keymap is scanned once to build a map from cec codes to linux
> keycodes; making it builtin is not ideal, and makes the build system a
> bit messy.
>
> I don't think we can load the keymap later, user space may start remapping
> the keymap from udev.
>
> Possibly we could create the cec or rc device later but this could be a
> bit
> messy.
>
> Could CEC specify:
>
> #if IS_ENABLED(CONFIG_MEDIA_CEC_RC)
> MODULE_SOFTDEP("rc-cec")
> #endif
That would need to be:
MODULE_SOFTDEP("pre: rc-cec")
I see that the drm_kms_helper and i915 drivers both depend on the cec
module already,
so yes if that module will request for rc-cec to be loaded before it is
loaded
(and thus before i915 is loaded) then that should work around this.
Assuming the user is using a module-loader which honors the softdep...
Also this assumes that rc_map_get is smart enough to not call
request_module()
if the module is already loaded, is that the case ?
>>>
>>> Yes, see rc_map_get().
>>
>> I tried this. It works if CONFIG_RC_CORE is set to m, but setting it to
>> y resulted in the same problem. It looks like MODULE_SOFTDEP only works if
>> rc_main
>> is a module as well.
>
> Hmm, I'm not quite sure what is happening here. How can I reproduce this
> issue locally?
You need the right hardware for this, I'm afraid: this issue happens if you have
a DisplayPort-to-HDMI adapter that supports CEC and CONFIG_DRM_DP_CEC is set to
y.
In my case I have an Intel NUC with a USB-C to HDMI adapter from Club 3D
(CAC-2504).
I can easily test patches for you.
Regards,
Hans
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC v4 10/11] drm/dp: Extract i915's eDP backlight code into DRM helpers
On Fri, 12 Feb 2021, Lyude Paul wrote: > I think it wouldn't be a bad idea to just address this with a followup series > instead and use the old DRM_DEBUG_* macros in the mean time. aux->dev is there, could also use dev_dbg et al. in the mean time. They handle NULL dev gracefully too if the driver didn't set that. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
