Nouveau - Nov 2023 - [REGRESSION]: acpi/nouveau: Hardware unavailable upon resume or suspend fails

Hi Hans,

On Fri, Nov 10, 2023 at 2:19?PM Hans de Goede <hdegoede at redhat.com>
wrote:
>
> Hi All,
>
> On 11/10/23 07:09, Kai-Heng Feng wrote:
> > Hi Owen,
> >
> > On Fri, Nov 10, 2023 at 5:55?AM Owen T. Heisler <writer at
owenh.net> wrote:
> >>
> >> #regzbot introduced: 89c290ea758911e660878e26270e084d862c03b0
> >> #regzbot link:
https://gitlab.freedesktop.org/drm/nouveau/-/issues/273
> >> #regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=218124
> >
> > Thanks for the bug report. Do you prefer to continue the discussion
> > here, on gitlab or on bugzilla?
>
> Owen, as Kai-Heng said thank you for reporting this.
>
> >> ## Reproducing
> >>
> >> 1. Boot system to framebuffer console.
> >> 2. Run `systemctl suspend`. If undocked without secondary display,
> >> suspend fails. If docked with secondary display, suspend succeeds.
> >> 3. Resume from suspend if applicable.
> >> 4. System is now in a broken state.
> >
> > So I guess we need to put those devices to ACPI D3 for suspend.
Let's
> > discuss this on your preferred platform.
>
> Ok, so I was already sort of afraid we might see something like this
> happening because of:
>
>
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=89c290ea758911e660878e26270e084d862c03b0
>
> As I mentioned during the review of that, it might be better to
> not touch the video-card ACPI power-state at all and instead
> only do acpi_device_fix_up_power() on the child devices.
Or the child devices need to be put to D3 during suspend.
>
> Owen, attached are 2 patches which implement only
> calling acpi_device_fix_up_power() on the child devices,
> can you build a v6.6 kernel with these 2 patches added
> on top please and see if that fixes things ?
>
> Kai-Heng can you test that the issue on the HP ZBook Fury 16 G10
> is still resolved after applying these patches ?
Yes. Thanks for the patch.

If this patch also fixes Owen's issue, then
Tested-by: Kai-Heng Feng <kai.heng.feng at canonical.com>

>
> Regards,
>
> Hans
>

Hi everyone,

On 11/10/23 06:52, Kai-Heng Feng wrote:
> On Fri, Nov 10, 2023 at 2:19?PM Hans de Goede <hdegoede at
redhat.com> wrote:
>> On 11/10/23 07:09, Kai-Heng Feng wrote:
>>> On Fri, Nov 10, 2023 at 5:55?AM Owen T. Heisler <writer at
owenh.net> wrote:
>>>> #regzbot introduced: 89c290ea758911e660878e26270e084d862c03b0
>>>> #regzbot link:
https://gitlab.freedesktop.org/drm/nouveau/-/issues/273
>>>> #regzbot link:
https://bugzilla.kernel.org/show_bug.cgi?id=218124
>>>
>>> Thanks for the bug report. Do you prefer to continue the discussion
>>> here, on gitlab or on bugzilla?
Kai-Heng, you're welcome and thank you too. By email is fine with me.
>> Owen, as Kai-Heng said thank you for reporting this.
Hans, you're welcome, and thanks for your help too.
>>>> ## Reproducing
>>>>
>>>> 1. Boot system to framebuffer console.
>>>> 2. Run `systemctl suspend`. If undocked without secondary
display,
>>>> suspend fails. If docked with secondary display, suspend
succeeds.
>>>> 3. Resume from suspend if applicable.
>>>> 4. System is now in a broken state.
>>>
>>> So I guess we need to put those devices to ACPI D3 for suspend.
Let's
>>> discuss this on your preferred platform.
>>
>> Ok, so I was already sort of afraid we might see something like this
>> happening because of:
>>
>>
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=89c290ea758911e660878e26270e084d862c03b0
>>
>> As I mentioned during the review of that, it might be better to
>> not touch the video-card ACPI power-state at all and instead
>> only do acpi_device_fix_up_power() on the child devices.
> 
> Or the child devices need to be put to D3 during suspend.
> 
>> Owen, attached are 2 patches which implement only
>> calling acpi_device_fix_up_power() on the child devices,
>> can you build a v6.6 kernel with these 2 patches added
>> on top please and see if that fixes things ?
Yes, with those patches v6.6 suspend works normally. That's great, thanks!

I tested with v6.6 with the 2 patches at 
<https://lore.kernel.org/regressions/a592ce0c-64f0-477d-80fa-8f5a52ba29ea at
redhat.com/>
using 
<https://gitlab.freedesktop.org/drm/nouveau/uploads/788d7faf22ba2884dcc09d7be931e813/v6.6-config1>.
I tested both docked and un-docked, just in case.

Tested-by: Owen T. Heisler <writer at owenh.net>
>> Kai-Heng can you test that the issue on the HP ZBook Fury 16 G10
>> is still resolved after applying these patches ?
> 
> Yes. Thanks for the patch.
> 
> If this patch also fixes Owen's issue, then
> Tested-by: Kai-Heng Feng <kai.heng.feng at canonical.com
Please let me know if anything else is needed from me.

Many thanks,
Owen

Hi,

On 11/10/23 17:58, Owen T. Heisler wrote:
> Hi everyone,
> 
> On 11/10/23 06:52, Kai-Heng Feng wrote:
>> On Fri, Nov 10, 2023 at 2:19?PM Hans de Goede <hdegoede at
redhat.com> wrote:
>>> On 11/10/23 07:09, Kai-Heng Feng wrote:
>>>> On Fri, Nov 10, 2023 at 5:55?AM Owen T. Heisler <writer at
owenh.net> wrote:
>>>>> #regzbot introduced:
89c290ea758911e660878e26270e084d862c03b0
>>>>> #regzbot link:
https://gitlab.freedesktop.org/drm/nouveau/-/issues/273
>>>>> #regzbot link:
https://bugzilla.kernel.org/show_bug.cgi?id=218124
>>>>
>>>> Thanks for the bug report. Do you prefer to continue the
discussion
>>>> here, on gitlab or on bugzilla?
> 
> Kai-Heng, you're welcome and thank you too. By email is fine with me.
> 
>>> Owen, as Kai-Heng said thank you for reporting this.
> 
> Hans, you're welcome, and thanks for your help too.
> 
>>>>> ## Reproducing
>>>>>
>>>>> 1. Boot system to framebuffer console.
>>>>> 2. Run `systemctl suspend`. If undocked without secondary
display,
>>>>> suspend fails. If docked with secondary display, suspend
succeeds.
>>>>> 3. Resume from suspend if applicable.
>>>>> 4. System is now in a broken state.
>>>>
>>>> So I guess we need to put those devices to ACPI D3 for suspend.
Let's
>>>> discuss this on your preferred platform.
>>>
>>> Ok, so I was already sort of afraid we might see something like
this
>>> happening because of:
>>>
>>>
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=89c290ea758911e660878e26270e084d862c03b0
>>>
>>> As I mentioned during the review of that, it might be better to
>>> not touch the video-card ACPI power-state at all and instead
>>> only do acpi_device_fix_up_power() on the child devices.
>>
>> Or the child devices need to be put to D3 during suspend.
>>
>>> Owen, attached are 2 patches which implement only
>>> calling acpi_device_fix_up_power() on the child devices,
>>> can you build a v6.6 kernel with these 2 patches added
>>> on top please and see if that fixes things ?
> 
> Yes, with those patches v6.6 suspend works normally. That's great,
thanks!
> 
> I tested with v6.6 with the 2 patches at
<https://lore.kernel.org/regressions/a592ce0c-64f0-477d-80fa-8f5a52ba29ea at
redhat.com/> using
<https://gitlab.freedesktop.org/drm/nouveau/uploads/788d7faf22ba2884dcc09d7be931e813/v6.6-config1>.
I tested both docked and un-docked, just in case.
> 
> Tested-by: Owen T. Heisler <writer at owenh.net>
> 
>>> Kai-Heng can you test that the issue on the HP ZBook Fury 16 G10
>>> is still resolved after applying these patches ?
>>
>> Yes. Thanks for the patch.
>>
>> If this patch also fixes Owen's issue, then
>> Tested-by: Kai-Heng Feng <kai.heng.feng at canonical.com
Owen, Kai-Heng thank you for testing. I've submitted these patches
to Rafael (the ACPI maintainer) now (with you on the Cc).
Hopefully they will get merged soon.

Regards,

Hans