All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: "Michał Grzelak" <michal.grzelak@intel.com>
Cc: Oliver Sang <oliver.sang@intel.com>,
	lkp@intel.com, intel-gfx@lists.freedesktop.org,
	Jani Nikula <jani.nikula@linux.intel.com>,
	oe-lkp@lists.linux.dev, intel-xe@lists.freedesktop.org,
	ltp@lists.linux.it, linux-integrity@vger.kernel.org,
	Mimi Zohar <zohar@linux.ibm.com>
Subject: Re: [LTP] [PATCH v1 15/16] drm/i915/bios: search for VBT #57 by default
Date: Fri, 17 Apr 2026 19:11:04 +0200	[thread overview]
Message-ID: <20260417171104.GB426937@pevik> (raw)
In-Reply-To: <2df6f595-da57-0668-951c-657c5c876333@intel.com>

Hi Michał, all,

> Hi Petr & Oliver,

> > in our tests, it's quite persistent and clean on parent:

> I haven't reproduced it myself, but this issue seems somewhat related
> with issue observed earlier by CI [1]. I would expect it to not be a
> random glitch but a true bug related to the series.

> In previous versions of the series, during parsing there was a
> unfortunate snippet of:

> +	const u32 *tables = block->tables;
> +	size_t offset = 0;
> +	size_t row_width;
> +	const u32 *vals;
> +
> +	row_width = block->num_columns * sizeof(*tables);
> +
> +	for (int idx = 0; idx < block->num_tables; idx++) {
> +		for (int row = 0; row < num_rows; row++) {
> +			vals = &tables[offset];
> [...]
> +			offset += row_width;
> +		}
> +	}

> Which caused hopping by 4 times more bytes than it should, because the
> sizeof() wasn't meant to be there. Since parsing takes place at module
> load, looks like it could be the issue. This seems especially convincing
> given that report is from parse_vswing_preemph_snps(). I have to also
> admit that it would be consistent with review comment from Sashiko [2].

> Lastly, sadly due to poorly split commits, 15th patch from v1 turned on
> whole VBT #57 searching. This probably caused bisect to point at 15th
> patch instead of pointing at patch adding parsing code, which would
> clearly show that patch/es introduce/s the bug.

> Anyways, now the bug should be fixed in v2 [3].

Michał, thanks a lot for pointing pointing this out.

Kind regards,
Petr

> [1] https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164196v1/fi-hsw-4770/dmesg0.txt
> [2] https://sashiko.dev/#/patchset/20260331183332.1773886-1-michal.grzelak%40intel.com?part=5
> [3] https://lore.kernel.org/intel-gfx/20260415234639.3577774-21-michal.grzelak@intel.com/

> BR,
> Michał

WARNING: multiple messages have this Message-ID (diff)
From: Petr Vorel <pvorel@suse.cz>
To: "Michał Grzelak" <michal.grzelak@intel.com>
Cc: lkp@intel.com, intel-gfx@lists.freedesktop.org,
	Jani Nikula <jani.nikula@linux.intel.com>,
	Oliver Sang <oliver.sang@intel.com>,
	oe-lkp@lists.linux.dev, linux-integrity@vger.kernel.org,
	intel-xe@lists.freedesktop.org, ltp@lists.linux.it
Subject: Re: [LTP] [PATCH v1 15/16] drm/i915/bios: search for VBT #57 by default
Date: Fri, 17 Apr 2026 19:11:04 +0200	[thread overview]
Message-ID: <20260417171104.GB426937@pevik> (raw)
In-Reply-To: <2df6f595-da57-0668-951c-657c5c876333@intel.com>

Hi Michał, all,

> Hi Petr & Oliver,

> > in our tests, it's quite persistent and clean on parent:

> I haven't reproduced it myself, but this issue seems somewhat related
> with issue observed earlier by CI [1]. I would expect it to not be a
> random glitch but a true bug related to the series.

> In previous versions of the series, during parsing there was a
> unfortunate snippet of:

> +	const u32 *tables = block->tables;
> +	size_t offset = 0;
> +	size_t row_width;
> +	const u32 *vals;
> +
> +	row_width = block->num_columns * sizeof(*tables);
> +
> +	for (int idx = 0; idx < block->num_tables; idx++) {
> +		for (int row = 0; row < num_rows; row++) {
> +			vals = &tables[offset];
> [...]
> +			offset += row_width;
> +		}
> +	}

> Which caused hopping by 4 times more bytes than it should, because the
> sizeof() wasn't meant to be there. Since parsing takes place at module
> load, looks like it could be the issue. This seems especially convincing
> given that report is from parse_vswing_preemph_snps(). I have to also
> admit that it would be consistent with review comment from Sashiko [2].

> Lastly, sadly due to poorly split commits, 15th patch from v1 turned on
> whole VBT #57 searching. This probably caused bisect to point at 15th
> patch instead of pointing at patch adding parsing code, which would
> clearly show that patch/es introduce/s the bug.

> Anyways, now the bug should be fixed in v2 [3].

Michał, thanks a lot for pointing pointing this out.

Kind regards,
Petr

> [1] https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164196v1/fi-hsw-4770/dmesg0.txt
> [2] https://sashiko.dev/#/patchset/20260331183332.1773886-1-michal.grzelak%40intel.com?part=5
> [3] https://lore.kernel.org/intel-gfx/20260415234639.3577774-21-michal.grzelak@intel.com/

> BR,
> Michał

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

  reply	other threads:[~2026-04-17 17:11 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-31 18:33 [PATCH v1 00/16] VS/PE Override support Michał Grzelak
2026-03-31 18:33 ` [PATCH v1 01/16] drm/i915/lt: align xe3plpd with VS/PE Override layout Michał Grzelak
2026-03-31 18:33 ` [PATCH v1 02/16] drm/i915/buf_trans: switch from u8 to u32 Michał Grzelak
2026-03-31 18:33 ` [PATCH v1 03/16] drm/i915/buf_trans: describe VS/PE Override layout Michał Grzelak
2026-03-31 18:33 ` [PATCH v1 04/16] drm/i915/bios: prepare for parsing VBT #57 Michał Grzelak
2026-03-31 18:33 ` [PATCH v1 05/16] drm/i915/bios: parse LT's VS/PE Override Block #57 Michał Grzelak
2026-03-31 18:33 ` [PATCH v1 06/16] drm/i915/bios: parse Snps's " Michał Grzelak
2026-03-31 18:33 ` [PATCH v1 07/16] drm/i915/bios: parse EHL's " Michał Grzelak
2026-03-31 18:33 ` [PATCH v1 08/16] drm/i915/bios: support VS/PE Override per each ddi port Michał Grzelak
2026-04-03  8:39   ` kernel test robot
2026-03-31 18:33 ` [PATCH v1 09/16] drm/i915/bios: print VS/PE Override port info Michał Grzelak
2026-03-31 18:33 ` [PATCH v1 10/16] drm/i915/ddi: cache VS/PE struct pointer into intel_encoder Michał Grzelak
2026-03-31 18:33 ` [PATCH v1 11/16] drm/i915/buf_trans: override encoder->get_buf_trans when asked Michał Grzelak
2026-03-31 18:33 ` [PATCH v1 12/16] drm/i915/buf_trans: compute LT's VS/PE Override index Michał Grzelak
2026-04-01  7:16   ` kernel test robot
2026-03-31 18:33 ` [PATCH v1 13/16] drm/i915/buf_trans: compute Snps's " Michał Grzelak
2026-03-31 18:33 ` [PATCH v1 14/16] drm/i915/buf_trans: compute EHL's " Michał Grzelak
2026-03-31 18:33 ` [PATCH v1 15/16] drm/i915/bios: search for VBT #57 by default Michał Grzelak
2026-04-15  6:42   ` kernel test robot
2026-04-15  6:42     ` [LTP] " kernel test robot
2026-04-16  6:40     ` Petr Vorel
2026-04-16  6:40       ` Petr Vorel
2026-04-16  7:40       ` Oliver Sang
2026-04-16  7:40         ` Oliver Sang
2026-04-16  9:17         ` Michał Grzelak
2026-04-16  9:17           ` Michał Grzelak
2026-04-17 17:11           ` Petr Vorel [this message]
2026-04-17 17:11             ` Petr Vorel
2026-03-31 18:33 ` [PATCH v1 16/16] drm/i915/bios: remove VS/PE Override warning Michał Grzelak
2026-03-31 19:47 ` ✗ i915.CI.BAT: failure for VS/PE Override support Patchwork
2026-03-31 20:52 ` ✗ CI.checkpatch: warning " Patchwork
2026-03-31 20:53 ` ✓ CI.KUnit: success " Patchwork
2026-03-31 21:35 ` ✓ Xe.CI.BAT: " Patchwork
2026-04-01  4:45 ` ✓ Xe.CI.FULL: " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260417171104.GB426937@pevik \
    --to=pvorel@suse.cz \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=linux-integrity@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=ltp@lists.linux.it \
    --cc=michal.grzelak@intel.com \
    --cc=oe-lkp@lists.linux.dev \
    --cc=oliver.sang@intel.com \
    --cc=zohar@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.