On 9/3/25 7:21 AM, Przemysław Kopa wrote:
On 9/3/25 05:35, Mario Limonciello wrote:
Given it's not a 100% reproduce for you, how did you confirm this
commit is causing the issue? Some sort of sampling of X cycles at
each bisect point?
Yes, I've tried a couple of times to trigger this issue on each
bisection point (by doing suspend -> resume cycle), and if I wasn't able
to trigger it, I've assumed it's good and moved on. I think I got the
right commit in the end, since now I have two kernels that are a single
commit apart (50e0bae34fa6), and I am able to trigger the issue when
running kernel with 50e0bae34fa6 applied, but am not able to trigger it
when running kernel without 50e0bae34fa6 (and I tried a lot ;).
Could you capture a dmesg log where /sys/power/pm_debug_messages is
set both from a good case and from a bad case so we can compare?
I'm attaching two dmesg dumps, running 6.17-rc4, fresh boot with a
single suspend -> resume cycle within each file.
'dmesg_dp_audio_good.txt' - sound is fine after resume
'dmesg_dp_audio_bad.txt' - no sound after resume
I compared the two of them.
There are different problems you have with USB during recovery in the
bad, but I don't think that's relevant.
The only thing different from a display perspective is a slight
difference to the timing.
Can you repeat once more with /sys/power/pm_debug_messages and
/sys/power/pm_print_times set for good and bad? I want to make sure the
device suspend order is identical.
Also; does playing audio leading up to the suspend cycle influence
anything (both on good and bad kernel)?
