From: Jani Nikula <jani.nikula@linux.intel.com>
To: Hans de Goede <hdegoede@redhat.com>,
intel-gfx <intel-gfx@lists.freedesktop.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"Thorsten Leemhuis (regressions address)"
<regressions@leemhuis.info>
Subject: Re: [Intel-gfx] alderlake crashes (random memory corruption?) with 6.0 i915 / ucode related
Date: Mon, 17 Oct 2022 14:40:17 +0300 [thread overview]
Message-ID: <877d0yk7a6.fsf@intel.com> (raw)
In-Reply-To: <717fb4ab-5225-884f-37f9-2032c265824e@redhat.com>
On Mon, 17 Oct 2022, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 10/17/22 10:39, Jani Nikula wrote:
>> On Mon, 17 Oct 2022, Jani Nikula <jani.nikula@linux.intel.com> wrote:
>>> On Thu, 13 Oct 2022, Hans de Goede <hdegoede@redhat.com> wrote:
>>>> With 6.0 the following WARN triggers:
>>>> drivers/gpu/drm/i915/display/intel_bios.c:477:
>>>>
>>>> drm_WARN(&i915->drm, min_size == 0,
>>>> "Block %d min_size is zero\n", section_id);
>>>
>>> What's the value of section_id that gets printed?
>>
>> I'm guessing this is [1] fixed by commit d3a7051841f0 ("drm/i915/bios:
>> Use hardcoded fp_timing size for generating LFP data pointers") in
>> v6.1-rc1.
>>
>> I don't think this is the root cause for your issues, but I wonder if
>> you could try v6.1-rc1 or drm-tip and see if we've fixed the other stuff
>> already too?
>
> 6.1-rc1 indeed does not trigger the drm_WARN and for now (couple of
> reboots, running for 5 minutes now) it seems stable. 6.0.0 usually
> crashed during boot (but not always).
>
> Do you think it would be worthwhile to try 6.0.0 with d3a7051841f0 ?
My guess is that d3a7051841f0 is a red herring. Sure, it's a warning
splat that would be nice to get fixed in v6.0, but I doubt it has
relevance to the problems you're seeing.
Cc: Ville, your thoughts?
> Any other commits which I can try before I go down the bisect route ?
Seems pretty vague I'm afraid. I know it's painful, but likely bisect is
the fastest way to pinpoint the issue and get at the root cause.
Also, filing a bug at [1] would help us get more attention.
BR,
Jani.
[1] https://gitlab.freedesktop.org/drm/intel/issues/new
>
> (I'm assuming this will also affect other users, so we really need
> to fix this for 6.0.x before it starts hitting Arch + Fedora users)
>
> Regards,
>
> Hans
>
>
>
>> [1] https://gitlab.freedesktop.org/drm/intel/-/issues/6592
>
--
Jani Nikula, Intel Open Source Graphics Center
WARNING: multiple messages have this Message-ID (diff)
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Hans de Goede <hdegoede@redhat.com>,
intel-gfx <intel-gfx@lists.freedesktop.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"Thorsten Leemhuis (regressions address)"
<regressions@leemhuis.info>
Cc: ville.syrjala@linux.intel.com
Subject: Re: [Intel-gfx] alderlake crashes (random memory corruption?) with 6.0 i915 / ucode related
Date: Mon, 17 Oct 2022 14:40:17 +0300 [thread overview]
Message-ID: <877d0yk7a6.fsf@intel.com> (raw)
In-Reply-To: <717fb4ab-5225-884f-37f9-2032c265824e@redhat.com>
On Mon, 17 Oct 2022, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 10/17/22 10:39, Jani Nikula wrote:
>> On Mon, 17 Oct 2022, Jani Nikula <jani.nikula@linux.intel.com> wrote:
>>> On Thu, 13 Oct 2022, Hans de Goede <hdegoede@redhat.com> wrote:
>>>> With 6.0 the following WARN triggers:
>>>> drivers/gpu/drm/i915/display/intel_bios.c:477:
>>>>
>>>> drm_WARN(&i915->drm, min_size == 0,
>>>> "Block %d min_size is zero\n", section_id);
>>>
>>> What's the value of section_id that gets printed?
>>
>> I'm guessing this is [1] fixed by commit d3a7051841f0 ("drm/i915/bios:
>> Use hardcoded fp_timing size for generating LFP data pointers") in
>> v6.1-rc1.
>>
>> I don't think this is the root cause for your issues, but I wonder if
>> you could try v6.1-rc1 or drm-tip and see if we've fixed the other stuff
>> already too?
>
> 6.1-rc1 indeed does not trigger the drm_WARN and for now (couple of
> reboots, running for 5 minutes now) it seems stable. 6.0.0 usually
> crashed during boot (but not always).
>
> Do you think it would be worthwhile to try 6.0.0 with d3a7051841f0 ?
My guess is that d3a7051841f0 is a red herring. Sure, it's a warning
splat that would be nice to get fixed in v6.0, but I doubt it has
relevance to the problems you're seeing.
Cc: Ville, your thoughts?
> Any other commits which I can try before I go down the bisect route ?
Seems pretty vague I'm afraid. I know it's painful, but likely bisect is
the fastest way to pinpoint the issue and get at the root cause.
Also, filing a bug at [1] would help us get more attention.
BR,
Jani.
[1] https://gitlab.freedesktop.org/drm/intel/issues/new
>
> (I'm assuming this will also affect other users, so we really need
> to fix this for 6.0.x before it starts hitting Arch + Fedora users)
>
> Regards,
>
> Hans
>
>
>
>> [1] https://gitlab.freedesktop.org/drm/intel/-/issues/6592
>
--
Jani Nikula, Intel Open Source Graphics Center
next prev parent reply other threads:[~2022-10-17 11:40 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-13 20:33 [Intel-gfx] alderlake crashes (random memory corruption?) with 6.0 i915 / ucode related Hans de Goede
2022-10-13 20:33 ` Hans de Goede
2022-10-15 14:25 ` [Intel-gfx] " Hans de Goede
2022-10-15 14:25 ` Hans de Goede
2022-10-17 8:17 ` [Intel-gfx] " Tvrtko Ursulin
2022-10-17 8:17 ` Tvrtko Ursulin
2022-10-17 8:30 ` Jani Nikula
2022-10-17 8:32 ` Hans de Goede
2022-10-17 8:39 ` Jani Nikula
2022-10-17 10:48 ` Hans de Goede
2022-10-17 11:19 ` Thorsten Leemhuis
2022-10-17 13:14 ` Hans de Goede
2022-10-17 13:35 ` Jani Nikula
2022-10-17 14:32 ` Hans de Goede
2022-10-18 10:32 ` Ville Syrjälä
2022-10-18 10:32 ` Ville Syrjälä
2022-10-17 11:40 ` Jani Nikula [this message]
2022-10-17 11:40 ` Jani Nikula
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=877d0yk7a6.fsf@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=hdegoede@redhat.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=regressions@leemhuis.info \
/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.