uptime ; cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor | uniq ; lscpu | grep MHz 12:31:54 up 0:35, 4 users, load average: 0.56, 0.57, 0.50

http://bugzilla.opensuse.org/show_bug.cgi?id=1185513 http://bugzilla.opensuse.org/show_bug.cgi?id=1185513#c1 --- Comment #1 from Anthony Agelastos --- It also seems as if my CPU is running hotter than normal. {{{ powersave CPU MHz: 3700.000 CPU max MHz: 4700.0000 CPU min MHz: 800.0000 }}} If I repeat that in quick succession, I will see it dip below the 3.7 GHz, however it is staying here far more often than it dips and my machine has been up for 35+ minutes and I am not running anything. I have another openSUSE Tumbleweed machine that was also recently updated. It does not have the errors mentioned in this ticket and it has the following look (which looks about right with the frequency straddling the minimum). Thoughts? {{{

uptime ; cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor | uniq ; lscpu | grep MHz 12:34:52 up 3:38, 1 user, load average: 0.80, 0.87, 0.90 schedutil CPU MHz: 1400.000 CPU max MHz: 4000.0000 CPU min MHz: 1400.0000 }}}

-- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1185513 http://bugzilla.opensuse.org/show_bug.cgi?id=1185513#c3 --- Comment #3 from Anthony Agelastos --- (In reply to Anthony Agelastos from comment #1)

It also seems as if my CPU is running hotter than normal.

...

uptime ; cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor | uniq ; lscpu | grep MHz 12:31:54 up 0:35, 4 users, load average: 0.56, 0.57, 0.50

{{{ powersave CPU MHz: 3700.000 CPU max MHz: 4700.0000 CPU min MHz: 800.0000 }}}

If I repeat that in quick succession, I will see it dip below the 3.7 GHz, however it is staying here far more often than it dips and my machine has been up for 35+ minutes and I am not running anything. I have another openSUSE Tumbleweed machine that was also recently updated. It does not have the errors mentioned in this ticket and it has the following look (which looks about right with the frequency straddling the minimum). Thoughts?

{{{

...

uptime ; cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor | uniq ; lscpu | grep MHz 12:34:52 up 3:38, 1 user, load average: 0.80, 0.87, 0.90 schedutil CPU MHz: 1400.000 CPU max MHz: 4000.0000 CPU min MHz: 1400.0000 }}}

I believe I am mistaken about this. I used snapshots to go back to 5.11 and it is also running a 3.7 GHz rather than 800 MHz. I could've sworn it used to default to the latter more often than the former when it wasn't taxed. -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1185513 http://bugzilla.opensuse.org/show_bug.cgi?id=1185513#c9 --- Comment #9 from Hans de Jong --- Created attachment 848991 --> http://bugzilla.opensuse.org/attachment.cgi?id=848991&action=edit acpidump -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1185513 http://bugzilla.opensuse.org/show_bug.cgi?id=1185513#c11 --- Comment #11 from Anthony Agelastos --- Created attachment 849003 --> http://bugzilla.opensuse.org/attachment.cgi?id=849003&action=edit Anthony Agelastos' acpidump.raw This is my output from `acpidump`. Please note that I am booted into a snapshot from 5.11 right before 5.12 was released. If I need to run this from 5.12, then please let me know. -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1185513 http://bugzilla.opensuse.org/show_bug.cgi?id=1185513#c13 --- Comment #13 from Anthony Agelastos --- (In reply to Joey Lee from comment #7)

(In reply to Anthony Agelastos from comment #0)

...

I recently updated to the 5.12.0-1-default kernel with openSUSE Tumbleweed and now I see the following messages during boot. These were not there before.

On the other hand, do you mean that this messages did not show in v5.11 kernel?

Thanks

These messages do not show up in the v5.11 kernel. I am booted into a 5.11 snapshot with the following kernel and it does not have these errors. $ uname -a Linux babeltumble 5.11.16-1-default #1 SMP Thu Apr 22 10:30:16 UTC 2021 (e06d321) x86_64 x86_64 x86_64 GNU/Linux -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1185513 http://bugzilla.opensuse.org/show_bug.cgi?id=1185513#c18 --- Comment #18 from Anthony Agelastos --- (In reply to Joey Lee from comment #15)

The real strange thing is in Anthony's ACPI tables. ACPI tables of his machine has _CPC method in processor 0 in ssdt15:

Scope (\_PR.PR00) { Method (_CPC, 0, NotSerialized) // _CPC: Continuous Performance Control { If ((\_PR.CFGD & 0x01000000)) { Return (CPOC) /* External reference */ } Else { Return (CPC2) /* External reference */ } } }

It looks no problem, then I used two version ACPICA to verify the execution of \_PR.PR01._CPC. I can _NOT_ reproduce AE_NOT_FOUND error. The execution of \_PR.PR01._CPC is success:

- execute \_PR.PR01._CPC Evaluating \_PR.PR01._CPC Evaluation of \_PR.PR01._CPC returned object 0x18d6a90, external buffer length 3A8 [Package] Contains 21 Elements: [Integer] = 0000000000000015 ...

Both of two version ACPICA (version 20210105 for v5.12 kernel and version 20201113 for v5.11 kernel) are success.

Hi Anthony,

Could you please confirm that you still see the AE_NOT_FOUND parsing error on _CPC with v5.12 kernel? Could you please help to attach dmesg log on bugzilla?

Thanks

Hello Joey: I updated from openSUSE Tumbleweed 20210427-0 -> 20210502-0 where the former had 5.11 (5.11.16-1-default) and the new one 5.12 (5.12.0-2-default). The errors persist. I attached a tarball that contains acpidump and dmesg info from when I was in 5.11 and 5.12 to be compared. This was a fresh acpidump on 5.11 in case that helps. Thank you for your help with this ticket; your responses are very much appreciated. -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1185513 http://bugzilla.opensuse.org/show_bug.cgi?id=1185513#c25 --- Comment #25 from Anthony Agelastos --- (In reply to Joey Lee from comment #22)

Hi Anthony,

Could you please help to add the following kernel parameter and reboot for capturing more acpi debug log?

log_buf_len=10M acpi.debug_layer=0x20000010 acpi.debug_level=0x0000021f

It will dump many acpi debug log to dmesg. Please help to attach it on bugzilla. It may causes a long boot time. Please try to wait it. If the log is really too many, then I will try other way.

Thanks

Greetings: I think I was able to do what you wanted. I don't often add kernel parameters so I edited the GRUB entry and then booted it. The following may indicate I did it correctly (or not). I will attach the updated `dmesg` shortly. Thank you for your help with this. If you need me to do it a different way, then please let me know how. {{{

cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-5.12.0-2-default root=UUID=78e7058a-1a03-4d45-9981-15adfad3c601 splash=silent mitigations=auto quiet log_buf_len=10M acpi.debug_layer=0x20000010 acpi.debug_level=0x0000021f }}}

-- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1185513 http://bugzilla.opensuse.org/show_bug.cgi?id=1185513#c27 --- Comment #27 from Anthony Agelastos --- (In reply to Frank Kr�ger from comment #23)

This is just a guess, it might be that the above-mentioned issue was introduced with kernel 5.12.rc6 and commit b3041510f0fca598e0311a9df82337f811799d6b:

<snip> --

Does kernel 5.12.3 from kernel:stable still show these messages?

I just updated to 5.12.3-1-default through the normal means and the messages are still present. -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1185513 http://bugzilla.opensuse.org/show_bug.cgi?id=1185513#c29 --- Comment #29 from Frank Kr�ger --- JFYI: Others are also affected, even with kernel version 5.12.4: https://bugzilla.kernel.org/show_bug.cgi?id=213023 -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1185513 http://bugzilla.opensuse.org/show_bug.cgi?id=1185513#c35 --- Comment #35 from Joey Lee --- (In reply to Anthony Agelastos from comment #34)

(In reply to Joey Lee from comment #32)

...

Hi Anthony,

I have attached updated DSDT and SSDT11 tables. Could you please help to do the following steps for debugging? I have added some debug log to the above two tables.

- Put updated tables to new initrd:

mkdir -p kernel/firmware/acpi cp dsdt.aml kernel/firmware/acpi cp ssdt11.aml kernel/firmware/acpi find kernel | cpio -H newc --create > /boot/instrumented_initrd-5.12.0-2-default cat /boot/initrd-4.12.14-94.41-default

...

...

/boot/instrumented_initrd-5.12.0-2-default

- Modify /boot/grub2/grub.cfg

Add the following kernel parameters (please remove old): acpi.debug_level=0x2 acpi.debug_layer=0xFFFFFFFF

Change the booting initrd: < initrdefi /boot/initrd-5.12.0-2-default change to

...

initrdefi /boot/instrumented_initrd-5.12.0-2-default

Then please reboot and capture dmesg log. You should see some "[ACPI Debug]" log in dmesg. Please attach dmesg log on bugzilla.

Thanks!

I currently am running a different kernel than what you're showing (see below). Do I modify your instructions for the 5.12.3-1-default kernel? Thank you for your clarification and wonderful help with this ticket.

...

cat /etc/os-release | grep VERSION_ID VERSION_ID="20210515" uname -r 5.12.3-1-default

Yes, you can modify my command to use "5.12.3-1-default". e.g. /boot/initrd-5.12.3-1-default Please still keep the original initrd file in /boot folder in case my modified tables has problem because I do not have machine to test it. If the instrumented_initrd-5.12.0-2-default has problem that it causes booting failed. Then you just need to use grub2 UI to modify initrd back to original initrd-5.12.3-1-default for booting. Thanks -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1185513 http://bugzilla.opensuse.org/show_bug.cgi?id=1185513#c37 --- Comment #37 from Anthony Agelastos --- (In reply to Joey Lee from comment #35)

(In reply to Anthony Agelastos from comment #34)

...

(In reply to Joey Lee from comment #32)

...

Hi Anthony,

I have attached updated DSDT and SSDT11 tables. Could you please help to do the following steps for debugging? I have added some debug log to the above two tables.

- Put updated tables to new initrd:

mkdir -p kernel/firmware/acpi cp dsdt.aml kernel/firmware/acpi cp ssdt11.aml kernel/firmware/acpi find kernel | cpio -H newc --create > /boot/instrumented_initrd-5.12.0-2-default cat /boot/initrd-4.12.14-94.41-default

...

...

/boot/instrumented_initrd-5.12.0-2-default

- Modify /boot/grub2/grub.cfg

Add the following kernel parameters (please remove old): acpi.debug_level=0x2 acpi.debug_layer=0xFFFFFFFF

Change the booting initrd: < initrdefi /boot/initrd-5.12.0-2-default change to

...

initrdefi /boot/instrumented_initrd-5.12.0-2-default

Then please reboot and capture dmesg log. You should see some "[ACPI Debug]" log in dmesg. Please attach dmesg log on bugzilla.

Thanks!

I currently am running a different kernel than what you're showing (see below). Do I modify your instructions for the 5.12.3-1-default kernel? Thank you for your clarification and wonderful help with this ticket.

...

cat /etc/os-release | grep VERSION_ID VERSION_ID="20210515" uname -r 5.12.3-1-default

Yes, you can modify my command to use "5.12.3-1-default". e.g. /boot/initrd-5.12.3-1-default

Please still keep the original initrd file in /boot folder in case my modified tables has problem because I do not have machine to test it. If the instrumented_initrd-5.12.0-2-default has problem that it causes booting failed. Then you just need to use grub2 UI to modify initrd back to original initrd-5.12.3-1-default for booting.

Thanks

Greetings: I added the dmesg output within comment#36. Note that I made some mods to your commands (e.g., I changed `cat /boot/initrd-4.12.14-94.41-default

...

/boot/instrumented_initrd-5.12.3-1-default` to `cat /boot/initrd-5.12.3-1 /boot/instrumented_initrd-5.12.3-1-default`) The debug statements you mention are below. Please let me know if you have any questions, comments, or concerns.

{{{

dmesg | grep 'ACPI Debug' [ 0.170352] ACPI Debug: "_PR.PR00._OSC" [ 0.170730] ACPI Debug: "Method (GCAP, 1, Serialized)" [ 0.171927] ACPI Debug: "If ((OSYS >= 0x07DF))" [ 0.171953] ACPI Debug: "If (((CFGD & 0x00400000) && !(SDTL & 0x40)))" [ 0.172999] ACPI Debug: "_PR.PR00._PDC" [ 0.173091] ACPI Debug: "Method (GCAP, 1, Serialized)" [ 0.174092] ACPI Debug: "If ((OSYS >= 0x07DF))" [ 0.174116] ACPI Debug: "If (((CFGD & 0x00400000) && !(SDTL & 0x40)))" }}}

Kind regards, Anthony -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1185513 http://bugzilla.opensuse.org/show_bug.cgi?id=1185513#c39 --- Comment #39 from Joey Lee --- Hi Anthony, Thanks for your debug log. (In reply to Anthony Agelastos from comment #37) [...snip]

mention are below. Please let me know if you have any questions, comments, or concerns.

{{{

...

dmesg | grep 'ACPI Debug' [ 0.170352] ACPI Debug: "_PR.PR00._OSC" [ 0.170730] ACPI Debug: "Method (GCAP, 1, Serialized)" [ 0.171927] ACPI Debug: "If ((OSYS >= 0x07DF))" [ 0.171953] ACPI Debug: "If (((CFGD & 0x00400000) && !(SDTL & 0x40)))" [ 0.172999] ACPI Debug: "_PR.PR00._PDC" [ 0.173091] ACPI Debug: "Method (GCAP, 1, Serialized)" [ 0.174092] ACPI Debug: "If ((OSYS >= 0x07DF))" [ 0.174116] ACPI Debug: "If (((CFGD & 0x00400000) && !(SDTL & 0x40)))" }}}

The "If ((\_SB.OSCP & 0x40))" debug log did not be printed out. It confirmed that the CPPC 2 Support _OSC Capabilities did not be set. The _SB._OSC is the only method to set OSCP. I have add debug log to dsdt table, but I attached a wrong AML code on comment#30. Hi Anthony, I have attached a new dsdt-new.aml table on comment#38. Could you please help to put it to initrd and test it? I have add more debug log to dsdt. Please use the dsdt-new.aml with ssdt11.sml for testing. And please attach dmesg log. Thanks a lot! Joey Lee -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1185513 http://bugzilla.opensuse.org/show_bug.cgi?id=1185513#c41 --- Comment #41 from Anthony Agelastos --- (In reply to Joey Lee from comment #39)

Hi Anthony,

Thanks for your debug log.

(In reply to Anthony Agelastos from comment #37) [...snip]

...

mention are below. Please let me know if you have any questions, comments, or concerns.

{{{

...

dmesg | grep 'ACPI Debug' [ 0.170352] ACPI Debug: "_PR.PR00._OSC" [ 0.170730] ACPI Debug: "Method (GCAP, 1, Serialized)" [ 0.171927] ACPI Debug: "If ((OSYS >= 0x07DF))" [ 0.171953] ACPI Debug: "If (((CFGD & 0x00400000) && !(SDTL & 0x40)))" [ 0.172999] ACPI Debug: "_PR.PR00._PDC" [ 0.173091] ACPI Debug: "Method (GCAP, 1, Serialized)" [ 0.174092] ACPI Debug: "If ((OSYS >= 0x07DF))" [ 0.174116] ACPI Debug: "If (((CFGD & 0x00400000) && !(SDTL & 0x40)))" }}}

The "If ((\_SB.OSCP & 0x40))" debug log did not be printed out. It confirmed that the CPPC 2 Support _OSC Capabilities did not be set.

The _SB._OSC is the only method to set OSCP. I have add debug log to dsdt table, but I attached a wrong AML code on comment#30.

Hi Anthony,

I have attached a new dsdt-new.aml table on comment#38. Could you please help to put it to initrd and test it? I have add more debug log to dsdt. Please use the dsdt-new.aml with ssdt11.sml for testing. And please attach dmesg log.

Thanks a lot! Joey Lee

Hello Joey: I have repeated the steps with your updated AML file (note I am on kernel 5.12.4-1-default right now). I attached the file within comment#40. The quick `grep` of output is below. Please let me know if you need anything further. {{{

dmesg | grep 'ACPI Debug' [ 0.171855] ACPI Debug: "_PR.PR00._OSC" [ 0.172231] ACPI Debug: "Method (GCAP, 1, Serialized)" [ 0.173426] ACPI Debug: "If ((OSYS >= 0x07DF))" [ 0.173452] ACPI Debug: "If (((CFGD & 0x00400000) && !(SDTL & 0x40)))" [ 0.174382] ACPI Debug: "_SB._OSC" [ 0.174401] ACPI Debug: "If ((Arg0 == ToUUID (0811b06e-4a27-44f9-8d60-3cbbc22e7b48)" [ 0.174406] ACPI Debug: "If ((Arg1 == One))" [ 0.174415] ACPI Debug: "If (OSCP & 0x40)" [ 0.174461] ACPI Debug: "_SB._OSC" [ 0.174478] ACPI Debug: "If ((Arg0 == ToUUID (0811b06e-4a27-44f9-8d60-3cbbc22e7b48)" [ 0.174483] ACPI Debug: "If ((Arg1 == One))" [ 0.174520] ACPI Debug: "_PR.PR00._PDC" [ 0.174609] ACPI Debug: "Method (GCAP, 1, Serialized)" [ 0.175617] ACPI Debug: "If ((OSYS >= 0x07DF))" [ 0.175641] ACPI Debug: "If (((CFGD & 0x00400000) && !(SDTL & 0x40)))" }}}

Kind regards, Anthony -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1185513 http://bugzilla.opensuse.org/show_bug.cgi?id=1185513#c47 --- Comment #47 from Anthony Agelastos --- (In reply to Anthony Agelastos from comment #46)

(In reply to Joey Lee from comment #45)

...

Hi Anthony and anyone's system has the same symptom:

I have reverted the 719e1f561afbe patch and built a kernel rpm in my home branch on OBS. Could you please try it?

https://build.opensuse.org/package/binaries/home:joeyli:branches:openSUSE: Factory:bsc1185513/kernel-default/standard

Please install this kernel rpm but still keep the old kernel in case there have any unknown problem.

And, please note that this is not a real solution. I will raise this issue on upstream after we confirmed that the 719e1f561afbe patch is root cause. Reverting 719e1f561afbe patch will cause that we may lost some USB4 functions.

On the other hand, kernel upstream may treats this problem as a firmware issue. We didn't see this ACPI error message that's because v5.11 kernel doesn't follow ACPI spec's recommended behavior.

Hello Joey:

Thank you for your help with this. I'm glad you were able to drill down to the root cause. Could you (or anyone familiar with this) walk me through the steps for how to install your kernel to test and then to revert the changes afterwards? One method could be manual whilst another could leverage Snapper and do it through snapshots. I am new enough to openSUSE that I don't have enough experience with either of those methods to know precisely how to. So, any guidance would be appreciated. Thank you for your help with this.

Kind regards, Anthony

Hello Joey: Also, do you have an idea as to what functionality is impacted with these errors I'm getting? If upstream decides it's a bug in my firmware and that they don't want to change anything, then I need to start evaluating my options. One option is that I can update my firmware to see if that fixes the problem (but I updated firmware on a laptop before and afterwards Linux was unable to access the hard drive thanks to changes in firmware which I could not roll back so I am very hesitant to update firmware in general). However, if these ACPI errors aren't really impacting anything (i.e., if they're cosmetic), then I can also just ignore them. So, any guidance you have regarding what is not working would help me make this decision (assuming the upstream doesn't address this issue... if they do address the issue then this is moot). Thank you for any clarification you can provide here. Kind regards, Anthony Kind regards, Anthony -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1185513 http://bugzilla.opensuse.org/show_bug.cgi?id=1185513#c50 --- Comment #50 from Anthony Agelastos --- (In reply to Joey Lee from comment #48)

(In reply to Anthony Agelastos from comment #46)

...

(In reply to Joey Lee from comment #45)

...

Hi Anthony and anyone's system has the same symptom:

I have reverted the 719e1f561afbe patch and built a kernel rpm in my home branch on OBS. Could you please try it?

https://build.opensuse.org/package/binaries/home:joeyli:branches:openSUSE: Factory:bsc1185513/kernel-default/standard

Please install this kernel rpm but still keep the old kernel in case there have any unknown problem.

And, please note that this is not a real solution. I will raise this issue on upstream after we confirmed that the 719e1f561afbe patch is root cause. Reverting 719e1f561afbe patch will cause that we may lost some USB4 functions.

On the other hand, kernel upstream may treats this problem as a firmware issue. We didn't see this ACPI error message that's because v5.11 kernel doesn't follow ACPI spec's recommended behavior.

Hello Joey:

Thank you for your help with this. I'm glad you were able to drill down to the root cause. Could you (or anyone familiar with this) walk me through the steps for how to install your kernel to test and then to revert the changes afterwards? One method could be manual whilst another could leverage Snapper and do it through snapshots. I am new enough to openSUSE that I don't have enough experience with either of those methods to know precisely how to. So, any guidance would be appreciated. Thank you for your help with this.

Normally I just download the kernel-default RPM and use 'rpm -ivh' command to install it on my machine. e.g.

# rpm -ivh kernel-default-5.12.6-1.1.g15ed7b8.x86_64.rpm

Then reboot system, you should see a boot item on grub2 menu. e.g.

openSUSE Tumbleweed, with Linux 5.12.6-1.g15ed7b8-default

Then select it for booting test.

Let's test and confirm the 719e1f561afbe patch is the root cause. Then we ping upstream experts.

Greetings: I installed the kernel and attached its dmesg output to this ticket. I was not able to boot the system graphically (it stopped at the console login). I didn't see any of the errors we saw before (but please double check me). This seems to indicate that you have correctly identified the problem. Please let me know if you have any questions, comments, or concerns. Additionally, please let me know how to proceed once you discuss things with upstream. Thank you for your help with this. Kind regards, Anthony -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1185513 http://bugzilla.opensuse.org/show_bug.cgi?id=1185513#c63 --- Comment #63 from Anthony Agelastos --- (In reply to Joey Lee from comment #61)

(In reply to Joey Lee from comment #60)

...

(In reply to Hendrik Woltersdorf from comment #57)

...

I installed kernel 5.12.9-1.g7c88540-default on top of Tumbleweed version 20210606 and the issue is NOT gone. The error messages are still there.

(In reply to Anthony Agelastos from comment #59)

...

(In reply to Hendrik Woltersdorf from comment #57)

...

I installed kernel 5.12.9-1.g7c88540-default on top of Tumbleweed version 20210606 and the issue is NOT gone. The error messages are still there.

I, too, installed this kernel atop 20210606 and the issue remained as well.

Thanks for your testing to confirm that Hans's patch doesn't work for our issue.

Mika Westerberg sent a new patch on upstream:

ACPI: Pass the same capabilities to the _OSC regardless of the query flag https://patchwork.kernel.org/project/linux-acpi/patch/20210608163810.18071-1... mika.westerberg@linux.intel.com/

Then Hans modified Mika's patch and put to as Frank mentioned:

https://bugzilla.kernel.org/attachment.cgi?id=297241&action=diff

I will backport the patch to openSUSE TW kernel and generate a new kernel RPM for testing.

I have backported Hans's new patch for testing:

https://build.opensuse.org/package/binaries/home:joeyli:branches:openSUSE: Factory:bsc1185513/kernel-default/standard

Hi Anthony,

Could you please help to test again?

Thanks

The errors were not present. It looks like this patch worked. Does it seem like they are going to put it in the upstream kernel? -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1185513 http://bugzilla.opensuse.org/show_bug.cgi?id=1185513#c70 --- Comment #70 from Anthony Agelastos --- (In reply to Joey Lee from comment #69)

Patch 159d8c274fd be merged to openSUSE kernel stable branch for openSUSE TW.

Set this issue to fixed.

THANK YOU EVERYONE for your hard work on this ticket; it is much appreciated! I look forward to the upcoming update that resolves this. When >=5.12.11 is installed, if the errors persist I will come back to this ticket. If there is no reply, then please assume this works for me. Thanks again! -- You are receiving this mail because: You are the assignee for the bug.