#regzbot introduced: 89c290ea758911e660878e26270e084d862c03b0 #regzbot link: https://gitlab.freedesktop.org/drm/nouveau/-/issues/273 #regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=218124
## 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.
## Testing
- culprit commit is 89c290ea758911e660878e26270e084d862c03b0 - v6.6 fails - v6.6 with culprit commit reverted does not fail - Compiled with https://gitlab.freedesktop.org/drm/nouveau/uploads/788d7faf22ba2884dcc09d7be931e813/v6.6-config1
## Hardware
- ThinkPad W530 2438-52U - Dock with Nvidia-connected DVI ports - Secondary display connected via DVI - Nvidia Optimus GPU switching system
```console $ lspci | grep -i vga 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) 01:00.0 VGA compatible controller: NVIDIA Corporation GK107GLM [Quadro K2000M] (rev a1) ```
## Decoded logs from v6.6
- System is not docked and fails to suspend: https://gitlab.freedesktop.org/drm/nouveau/uploads/fb8fdf5a6bed1b1491d2544ab67fa257/undocked.log - System is docked and fails after resume: https://gitlab.freedesktop.org/drm/nouveau/uploads/cb3d5ac55c01f663cd80fa000cd6a3b5/docked.log
Hi Owen,
On Fri, Nov 10, 2023 at 5:55 AM Owen T. Heisler writer@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?
## Reproducing
- Boot system to framebuffer console.
- 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.
Kai-Heng
## Testing
- culprit commit is 89c290ea758911e660878e26270e084d862c03b0
- v6.6 fails
- v6.6 with culprit commit reverted does not fail
- Compiled with
https://gitlab.freedesktop.org/drm/nouveau/uploads/788d7faf22ba2884dcc09d7be931e813/v6.6-config1
## Hardware
- ThinkPad W530 2438-52U
- Dock with Nvidia-connected DVI ports
- Secondary display connected via DVI
- Nvidia Optimus GPU switching system
$ lspci | grep -i vga 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) 01:00.0 VGA compatible controller: NVIDIA Corporation GK107GLM [Quadro K2000M] (rev a1)## Decoded logs from v6.6
- System is not docked and fails to suspend:
https://gitlab.freedesktop.org/drm/nouveau/uploads/fb8fdf5a6bed1b1491d2544ab67fa257/undocked.log
- System is docked and fails after resume:
https://gitlab.freedesktop.org/drm/nouveau/uploads/cb3d5ac55c01f663cd80fa000cd6a3b5/docked.log
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@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
- Boot system to framebuffer console.
- 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/?i...
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.
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 ?
Regards,
Hans
Hi Hans,
On Fri, Nov 10, 2023 at 2:19 PM Hans de Goede hdegoede@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@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
- Boot system to framebuffer console.
- 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/?i...
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@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@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@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
- Boot system to framebuffer console.
- 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/?i...
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@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@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@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@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@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
- Boot system to framebuffer console.
- 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/?i...
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@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@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@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
linux-stable-mirror@lists.linaro.org
-
Hans de Goede -
Kai-Heng Feng -
Owen T. Heisler