Bug 156501

Created attachment 232981 [details]
acpidump

Created attachment 239241 [details]
[PATCH] ACPICA: Dispatcher: Disable infinite loop detection

Hi,

Please give this patch a try.

Thanks

Also please upload dmidecode here.

Created attachment 239341 [details]
dmidecode

Thanks,
I'll try the patch and report in a few days or when something interesting happens.

OK.
IMO, the infinite loop detection is a compromise for the current Linux ACPI entironment. It is not reasonable but is useful during the period when there are bugs/gaps not root caused. Introducing this mechanism ensures that when such bugs/gaps cause some AML synchronization failures, Linux ACPI can still run and most of other ACPI features won't be affected.

Hi,

I've been testing the patch on a single session spanning 5 days so far and haven't encountered the issue. I've monitored the output of the acpi command and suspended countless times. The logs have also stayed very quiet and haven't reported anything resembling an AML synchronization failure or any other ACPI error. It's the longest session I have had in memory so I'd say the issue is solved.

Thank you, this was driving me insane

OK, marking this as RESOLVED.
I'll discuss this with ACPI experts, see how we can have it upstreamed under the current Linux ACPI entironment.

Best regards

I've obtained some insructions.
Let me re-open this bug.

We'll about to introduce a timeout mechanism instead of this loop couting mechanism in order to break possible infinite loops.

I'll post another patch later.

Thanks
Lv

Sure, looking forward to test the patch

Hi,

Just a reminder that I'll test the patch you mentioned last month when it's ready.

Thanks

Created attachment 243041 [details]
[PATCH] ACPICA: Dispatcher: Introduce timeout mechanism for infinite loop detection

Here you are.
Please check if it is working.
I've configured the timeout value to 120seconds by default.
It cleanly applies to linux-pm/linux-next branch.

Thanks in adnvace.

Created attachment 243081 [details]
[PATCH] ACPICA: Dispatcher: Introduce timeout mechanism for infinite loop detection

I refined the patch, making it eligible for upstream.
Please test the upgraded one.

And I changed the default timeout to 30s.
If it is not suitable for your machine.
Please help to modify the value for ACPI_MAX_LOOP_TIMEOUT.

Thanks in advance.

Thanks, I am currently testing the patch.
I'll let you know if I find any issues or after a week long session without them.

Hi, 

I have tested the patch for 4 days and the logs haven't yet shown anything related to the bug. Nevertheless, out of 9 times I've suspended 2 have gone badly in a new way. Everything seemed to suspend fine except for the fans and the keyboard backlight, and later I wasn't able to resume. The logs don't show anything different from a successful suspend. I applied the patch to next-20161028 and didn't modify ACPI_MAX_LOOP_TIMEOUT.

Thanks

Can the suspend/resume issue be reproduced with attachment 239241 [details]?

No, I didn't have that issue with the previous patch. I applied that patch to 4.8-rc7 and this is also the first time I tried a kernel released after that. Should I build the latest kernel on the linux-next branch with no infinite loop detection?

I was thinking you were complaining that ktime_get() wasn't working in suspend/resume process and the patch thus need to be improved.

While now this just looks to me like that the default timeout value is not long enough (or could never be long enough).
So we should choose a longer timeout value or we shouldn't have such infinite loop detection mechanism in the upstream.

That's a non-technical issue. I'll close the bug and let the others to determine which should be in the usptream.

Thanks for the report and the test.

Best regards
Lv

One last thing. How should I find out when a fix is pushed upstream?
Thanks for your work

I'll mention the upstream commit ID here before closing the bug. :)

That's great, thank you very much!

> And I changed the default timeout to 30s.

What is the approximate _minimum_ delay that makes this system work?
eg. does 3s work?

Unclear if the issue with suspend/resume is related to this one.
Are these suspend/resume problems newly created by the test patch,
or is it possible they were present before the test patch?

Hi Len,

If by delay you mean the timeout value on the patch, I used only 30 seconds. If you mean something about the suspend/resume issue, there is no delay at resume, the laptop didn't come back from suspend 2 out of 9 times and I had to force a shutdown.

I only had this issue with this patch on kernel next-20161028. Before this, I used all ubuntu supported kernels from 3.19 until the current 4.4, mainline 4.8-rc4 until rc7 and the first patch on this thread applied to mainline 4.8-rc7. 

I might try an unpatched version of next-20161028, a different timeout value or something more specific if you think it's worthwhile.

Thanks

We changed strategy, and will track ACPICA bugs in ACPICA upstream.
Please monitor the following URL for this bug:
https://github.com/acpica/acpica/pull/185

I'll close this bug due to the strategy change.

Fine, I'll keep an eye for when it gets commited to linuxized ACPICA. Thanks for your work again.

Hi, is there any reason why this has not been solved in ACPICA upstream yet?
Thanks