The following is a copy an issue I posted to drm/i915 gitlab [1] two
months ago. I repost it to the mailing lists in hope that it will help
the right people pay attention to it.
After kernel upgrade from 6.2.13 to 6.3 HDMI connector detection is
broken for me. Issue is 100% reproducible:
1. Start system as usual with HDMI connected.
2. Disconnect HDMI
3. Connect HDMI back
4. Get "no signal" on display, connector status in sysfs is disconnected
Curiously, running xrandr over ssh like
ssh qnap251.local env DISPLAY=:0 xrandr
makes display come back. drm-tip tip is affected as well (last test
2023-08-02).
Bisecting points at a4e771729a51 ("drm/probe_helper: sort out poll_running vs poll_enabled").
Reverting that commit on top of 6.3 fixes the issue for me.
System information:
* System architecture: x86_64
* Kernel version: 6.3.arch1
* Linux distribution: Arch Linux
* Machine: QNAP TS-251A, CPU: Intel(R) Celeron(R) CPU N3060 @ 1.60GHz
* Display connector: single HDMI display
* dmesg with debug information (captured on drm-tip, following above 4 steps): [2]
* xrandr output:
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 16384 x 16384
DP-1 disconnected (normal left inverted right x axis y axis)
HDMI-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 708mm x 398mm
1920x1080 60.00*+ 50.00 59.94 30.00 25.00 24.00 29.97 23.98
1920x1080i 60.00 50.00 59.94
1360x768 59.80
1280x768 60.35
1280x720 60.00 50.00 59.94
1024x768 75.03 70.07 60.00
832x624 74.55
800x600 75.00 60.32
720x576 50.00
720x480 60.00 59.94
640x480 75.00 60.00 59.94
720x400 70.08
DP-2 disconnected (normal left inverted right x axis y axis)
HDMI-2 disconnected (normal left inverted right x axis y axis)```
I'm willing to provide additional information and/or test fixes.
[1] https://gitlab.freedesktop.org/drm/intel/-/issues/8451
[2] https://gitlab.freedesktop.org/drm/intel/uploads/fda7aff0b13ef20962856c2c7be51544/dmesg.txt
#regzbot introduced: a4e771729a51
--
Best regards,
Mikhail Rudenko
[CCing the i915 maintainers and the dri maintainers]
Hi, Thorsten here, the Linux kernel's regression tracker.
On 10.08.23 21:33, Mikhail Rudenko wrote:
> The following is a copy an issue I posted to drm/i915 gitlab [1] two
> months ago. I repost it to the mailing lists in hope that it will help
> the right people pay attention to it.
Thx for your report. Wonder why Dmitry (who authored a4e771729a51) or
Thomas (who committed it) it didn't look into this, but maybe the i915
devs didn't forward the report to them.
Let's see if these mails help. Just wondering: does reverting
a4e771729a51 from 6.5-rc5 or drm-tip help as well?
BTW, there was an earlier report about a problem with a4e771729a51 that
afaics was never addressed, but it might be unrelated.
https://lore.kernel.org/all/[email protected]/
Ciao, Thorsten
> After kernel upgrade from 6.2.13 to 6.3 HDMI connector detection is
> broken for me. Issue is 100% reproducible:
>
> 1. Start system as usual with HDMI connected.
> 2. Disconnect HDMI
> 3. Connect HDMI back
> 4. Get "no signal" on display, connector status in sysfs is disconnected
>
> Curiously, running xrandr over ssh like
>
> ssh qnap251.local env DISPLAY=:0 xrandr
>
> makes display come back. drm-tip tip is affected as well (last test
> 2023-08-02).
>
> Bisecting points at a4e771729a51 ("drm/probe_helper: sort out poll_running vs poll_enabled").
> Reverting that commit on top of 6.3 fixes the issue for me.
>
> System information:
> * System architecture: x86_64
> * Kernel version: 6.3.arch1
> * Linux distribution: Arch Linux
> * Machine: QNAP TS-251A, CPU: Intel(R) Celeron(R) CPU N3060 @ 1.60GHz
> * Display connector: single HDMI display
> * dmesg with debug information (captured on drm-tip, following above 4 steps): [2]
> * xrandr output:
>
> Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 16384 x 16384
> DP-1 disconnected (normal left inverted right x axis y axis)
> HDMI-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 708mm x 398mm
> 1920x1080 60.00*+ 50.00 59.94 30.00 25.00 24.00 29.97 23.98
> 1920x1080i 60.00 50.00 59.94
> 1360x768 59.80
> 1280x768 60.35
> 1280x720 60.00 50.00 59.94
> 1024x768 75.03 70.07 60.00
> 832x624 74.55
> 800x600 75.00 60.32
> 720x576 50.00
> 720x480 60.00 59.94
> 640x480 75.00 60.00 59.94
> 720x400 70.08
> DP-2 disconnected (normal left inverted right x axis y axis)
> HDMI-2 disconnected (normal left inverted right x axis y axis)```
>
> I'm willing to provide additional information and/or test fixes.
>
> [1] https://gitlab.freedesktop.org/drm/intel/-/issues/8451
> [2] https://gitlab.freedesktop.org/drm/intel/uploads/fda7aff0b13ef20962856c2c7be51544/dmesg.txt
>
> #regzbot introduced: a4e771729a51
>
> --
> Best regards,
> Mikhail Rudenko
On Fri, 11 Aug 2023, Thorsten Leemhuis <[email protected]> wrote:
> [CCing the i915 maintainers and the dri maintainers]
>
> Hi, Thorsten here, the Linux kernel's regression tracker.
>
> On 10.08.23 21:33, Mikhail Rudenko wrote:
>> The following is a copy an issue I posted to drm/i915 gitlab [1] two
>> months ago. I repost it to the mailing lists in hope that it will help
>> the right people pay attention to it.
>
> Thx for your report. Wonder why Dmitry (who authored a4e771729a51) or
> Thomas (who committed it) it didn't look into this, but maybe the i915
> devs didn't forward the report to them.
It was [1], but never followed up on, and fell between the cracks. :(
BR,
Jani.
[1] https://lore.kernel.org/r/[email protected]
> Let's see if these mails help. Just wondering: does reverting
> a4e771729a51 from 6.5-rc5 or drm-tip help as well?
>
> BTW, there was an earlier report about a problem with a4e771729a51 that
> afaics was never addressed, but it might be unrelated.
>
> https://lore.kernel.org/all/[email protected]/
>
> Ciao, Thorsten
>
>> After kernel upgrade from 6.2.13 to 6.3 HDMI connector detection is
>> broken for me. Issue is 100% reproducible:
>>
>> 1. Start system as usual with HDMI connected.
>> 2. Disconnect HDMI
>> 3. Connect HDMI back
>> 4. Get "no signal" on display, connector status in sysfs is disconnected
>>
>> Curiously, running xrandr over ssh like
>>
>> ssh qnap251.local env DISPLAY=:0 xrandr
>>
>> makes display come back. drm-tip tip is affected as well (last test
>> 2023-08-02).
>>
>> Bisecting points at a4e771729a51 ("drm/probe_helper: sort out poll_running vs poll_enabled").
>> Reverting that commit on top of 6.3 fixes the issue for me.
>>
>> System information:
>> * System architecture: x86_64
>> * Kernel version: 6.3.arch1
>> * Linux distribution: Arch Linux
>> * Machine: QNAP TS-251A, CPU: Intel(R) Celeron(R) CPU N3060 @ 1.60GHz
>> * Display connector: single HDMI display
>> * dmesg with debug information (captured on drm-tip, following above 4 steps): [2]
>> * xrandr output:
>>
>> Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 16384 x 16384
>> DP-1 disconnected (normal left inverted right x axis y axis)
>> HDMI-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 708mm x 398mm
>> 1920x1080 60.00*+ 50.00 59.94 30.00 25.00 24.00 29.97 23.98
>> 1920x1080i 60.00 50.00 59.94
>> 1360x768 59.80
>> 1280x768 60.35
>> 1280x720 60.00 50.00 59.94
>> 1024x768 75.03 70.07 60.00
>> 832x624 74.55
>> 800x600 75.00 60.32
>> 720x576 50.00
>> 720x480 60.00 59.94
>> 640x480 75.00 60.00 59.94
>> 720x400 70.08
>> DP-2 disconnected (normal left inverted right x axis y axis)
>> HDMI-2 disconnected (normal left inverted right x axis y axis)```
>>
>> I'm willing to provide additional information and/or test fixes.
>>
>> [1] https://gitlab.freedesktop.org/drm/intel/-/issues/8451
>> [2] https://gitlab.freedesktop.org/drm/intel/uploads/fda7aff0b13ef20962856c2c7be51544/dmesg.txt
>>
>> #regzbot introduced: a4e771729a51
>>
>> --
>> Best regards,
>> Mikhail Rudenko
--
Jani Nikula, Intel Open Source Graphics Center
Hi, Thorsten!
On 2023-08-11 at 08:45 +02, Thorsten Leemhuis <[email protected]> wrote:
> [CCing the i915 maintainers and the dri maintainers]
>
> Hi, Thorsten here, the Linux kernel's regression tracker.
>
> On 10.08.23 21:33, Mikhail Rudenko wrote:
>> The following is a copy an issue I posted to drm/i915 gitlab [1] two
>> months ago. I repost it to the mailing lists in hope that it will help
>> the right people pay attention to it.
>
> Thx for your report. Wonder why Dmitry (who authored a4e771729a51) or
> Thomas (who committed it) it didn't look into this, but maybe the i915
> devs didn't forward the report to them.
>
> Let's see if these mails help. Just wondering: does reverting
> a4e771729a51 from 6.5-rc5 or drm-tip help as well?
I've redone my tests with 6.5-rc5, and here are the results:
(1) 6.5-rc5 -> still affected
(2) 6.5-rc5 + revert a4e771729a51 -> not affected
(3) 6.5-rc5 + two patches [1][2] suggested on i915 gitlab by @ideak -> not affected (!)
Should we somehow tell regzbot about (3)?
> BTW, there was an earlier report about a problem with a4e771729a51 that
> afaics was never addressed, but it might be unrelated.
>
> https://lore.kernel.org/all/[email protected]/
>
> Ciao, Thorsten
[1] https://patchwork.freedesktop.org/patch/548590/?series=121050&rev=1
[2] https://patchwork.freedesktop.org/patch/548591/?series=121050&rev=1
--
Best regards,
Mikhail Rudenko
On 11.08.23 20:10, Mikhail Rudenko wrote:
> On 2023-08-11 at 08:45 +02, Thorsten Leemhuis <[email protected]> wrote:
>> On 10.08.23 21:33, Mikhail Rudenko wrote:
>>> The following is a copy an issue I posted to drm/i915 gitlab [1] two
>>> months ago. I repost it to the mailing lists in hope that it will help
>>> the right people pay attention to it.
>>
>> Thx for your report. Wonder why Dmitry (who authored a4e771729a51) or
>> Thomas (who committed it) it didn't look into this, but maybe the i915
>> devs didn't forward the report to them.
For the record: they did, and Jani mentioned already. Sorry, should have
phrased this differently.
>> Let's see if these mails help. Just wondering: does reverting
>> a4e771729a51 from 6.5-rc5 or drm-tip help as well?
>
> I've redone my tests with 6.5-rc5, and here are the results:
> (1) 6.5-rc5 -> still affected
> (2) 6.5-rc5 + revert a4e771729a51 -> not affected
> (3) 6.5-rc5 + two patches [1][2] suggested on i915 gitlab by @ideak -> not affected (!)
>
> Should we somehow tell regzbot about (3)?
That's good to know, thx. But the more important things are:
* When will those be merged? They are not yet in next yet afaics, so it
might take some time to mainline them, especially at this point of the
devel cycle. Imre, could you try to prod the right people so that these
are ideally upstreamed rather sooner than later, as they fix a regression?
* They if possible ideally should be tagged for backporting to 6.4, as
this is a regression from the 6.3 cycle.
But yes, let's tell regzbot that fixes are available, too:
#regzbot fix: drm/i915: Fix HPD polling, reenabling the output poll work
as needed
(for the record: that's the second of two patches apparently needed)
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.
>> BTW, there was an earlier report about a problem with a4e771729a51 that
>> afaics was never addressed, but it might be unrelated.
>> https://lore.kernel.org/all/[email protected]/
> [1] https://patchwork.freedesktop.org/patch/548590/?series=121050&rev=1
> [2] https://patchwork.freedesktop.org/patch/548591/?series=121050&rev=1
On Sun, Aug 13, 2023 at 03:41:30PM +0200, Linux regression tracking (Thorsten Leemhuis) wrote:
Hi,
> On 11.08.23 20:10, Mikhail Rudenko wrote:
> > On 2023-08-11 at 08:45 +02, Thorsten Leemhuis <[email protected]> wrote:
> >> On 10.08.23 21:33, Mikhail Rudenko wrote:
> >>> The following is a copy an issue I posted to drm/i915 gitlab [1] two
> >>> months ago. I repost it to the mailing lists in hope that it will help
> >>> the right people pay attention to it.
> >>
> >> Thx for your report. Wonder why Dmitry (who authored a4e771729a51) or
> >> Thomas (who committed it) it didn't look into this, but maybe the i915
> >> devs didn't forward the report to them.
>
> For the record: they did, and Jani mentioned already. Sorry, should have
> phrased this differently.
>
> >> Let's see if these mails help. Just wondering: does reverting
> >> a4e771729a51 from 6.5-rc5 or drm-tip help as well?
> >
> > I've redone my tests with 6.5-rc5, and here are the results:
> > (1) 6.5-rc5 -> still affected
> > (2) 6.5-rc5 + revert a4e771729a51 -> not affected
> > (3) 6.5-rc5 + two patches [1][2] suggested on i915 gitlab by @ideak -> not affected (!)
> >
> > Should we somehow tell regzbot about (3)?
>
> That's good to know, thx. But the more important things are:
>
> * When will those be merged? They are not yet in next yet afaics, so it
> might take some time to mainline them, especially at this point of the
> devel cycle. Imre, could you try to prod the right people so that these
> are ideally upstreamed rather sooner than later, as they fix a regression?
I think the patches ([1] and [2]) could be merged via the drm-intel-next
(drm-intel-fixes) tree Cc'ing also stable. Jani, is this ok?
> * They if possible ideally should be tagged for backporting to 6.4, as
> this is a regression from the 6.3 cycle.
>
> But yes, let's tell regzbot that fixes are available, too:
>
> #regzbot fix: drm/i915: Fix HPD polling, reenabling the output poll work
> as needed
>
> (for the record: that's the second of two patches apparently needed)
>
> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> --
> Everything you wanna know about Linux kernel regression tracking:
> https://linux-regtracking.leemhuis.info/about/#tldr
> If I did something stupid, please tell me, as explained on that page.
>
> >> BTW, there was an earlier report about a problem with a4e771729a51 that
> >> afaics was never addressed, but it might be unrelated.
> >> https://lore.kernel.org/all/[email protected]/
> > [1] https://patchwork.freedesktop.org/patch/548590/?series=121050&rev=1
> > [2] https://patchwork.freedesktop.org/patch/548591/?series=121050&rev=1
>
On Tue, Aug 15, 2023 at 11:12:46AM +0300, Jani Nikula wrote:
> On Mon, 14 Aug 2023, Imre Deak <[email protected]> wrote:
> > On Sun, Aug 13, 2023 at 03:41:30PM +0200, Linux regression tracking (Thorsten Leemhuis) wrote:
> > Hi,
> >
> >> On 11.08.23 20:10, Mikhail Rudenko wrote:
> >> > On 2023-08-11 at 08:45 +02, Thorsten Leemhuis <[email protected]> wrote:
> >> >> On 10.08.23 21:33, Mikhail Rudenko wrote:
> >> >>> The following is a copy an issue I posted to drm/i915 gitlab [1] two
> >> >>> months ago. I repost it to the mailing lists in hope that it will help
> >> >>> the right people pay attention to it.
> >> >>
> >> >> Thx for your report. Wonder why Dmitry (who authored a4e771729a51) or
> >> >> Thomas (who committed it) it didn't look into this, but maybe the i915
> >> >> devs didn't forward the report to them.
> >>
> >> For the record: they did, and Jani mentioned already. Sorry, should have
> >> phrased this differently.
> >>
> >> >> Let's see if these mails help. Just wondering: does reverting
> >> >> a4e771729a51 from 6.5-rc5 or drm-tip help as well?
> >> >
> >> > I've redone my tests with 6.5-rc5, and here are the results:
> >> > (1) 6.5-rc5 -> still affected
> >> > (2) 6.5-rc5 + revert a4e771729a51 -> not affected
> >> > (3) 6.5-rc5 + two patches [1][2] suggested on i915 gitlab by @ideak -> not affected (!)
> >> >
> >> > Should we somehow tell regzbot about (3)?
> >>
> >> That's good to know, thx. But the more important things are:
> >>
> >> * When will those be merged? They are not yet in next yet afaics, so it
> >> might take some time to mainline them, especially at this point of the
> >> devel cycle. Imre, could you try to prod the right people so that these
> >> are ideally upstreamed rather sooner than later, as they fix a regression?
> >
> > I think the patches ([1] and [2]) could be merged via the drm-intel-next
> > (drm-intel-fixes) tree Cc'ing also stable. Jani, is this ok?
>
> It's fine by me, but need drm-misc maintainer ack to merge [1] via
> drm-intel.
That's fine for me
Maxime