Hi there,
While testing upstream kernel on some devices, I've recently discovered that suspend was broken for "distro kernel" (not only related to fedora kernel, but also ubuntu).
I order to debug this, I was advised to use a serial console and boot with theses options: no_console_suspend=1 initcall_debug
Then using systemctl suspend outputs this report for me: https://bugzilla.redhat.com/show_bug.cgi?id=1619699 Basically, I'm running a tegra device, but a pxa driver (unrelated to the device) lead to a crash preventing suspend.
I would like others on this list to try to report such use case, I don't expect pxa_gpio to be the only driver to have issue in the fedora config. Specially as it does not have problem at boot time or shutdown so this problem might remains silent.
Please don't forget to block ARMTracker on bugzilla.redhat.com, and mention it there if you uses upstream bug tracker.
Thx for any report.
On 08/21/2018 11:40 AM, Nicolas Chauvet wrote:
Hi there,
While testing upstream kernel on some devices, I've recently discovered that suspend was broken for "distro kernel" (not only related to fedora kernel, but also ubuntu).
On the Fedora users list we have had a terrible time with suspend on F28. 4.17.3 was ok, but then broke with 4.17.4 and was not, for the most part, fixed until 4.17.11. But still even with 4.17.14 a number of us are still reporting that suspend fails the first time with the system immediately restarting and then when you unlock your system and suspend again, that 'takes'.
Some of the reported problems (by ME!) revolved around QEMU running an image.
Most logs showed hangs occurring right after NetworkManager messages (but not all that are typically seen on successful suspends).
So does not surprise me at all that we are not out of the woods here. I wonder if anyone is testing this on x86_64 systems. I don't have the wherewithall to do that.
I will put together a test on a Cubieboard2 with the Xfce desktop. But I will be waiting for an image that contains openssl 1.1.1-pre9 to put in the time. And I never really tested suspend to swap on my Cubies. It will be painful with swap on an SD card.
And I think that is part of the suspend problem. If it takes too long, some thing breaks.
I order to debug this, I was advised to use a serial console and boot with theses options: no_console_suspend=1 initcall_debug
Then using systemctl suspend outputs this report for me: https://bugzilla.redhat.com/show_bug.cgi?id=1619699 Basically, I'm running a tegra device, but a pxa driver (unrelated to the device) lead to a crash preventing suspend.
I would like others on this list to try to report such use case, I don't expect pxa_gpio to be the only driver to have issue in the fedora config. Specially as it does not have problem at boot time or shutdown so this problem might remains silent.
Please don't forget to block ARMTracker on bugzilla.redhat.com, and mention it there if you uses upstream bug tracker.
Thx for any report.
On 08/21/2018 01:27 PM, Robert Moskowitz wrote:
On 08/21/2018 11:40 AM, Nicolas Chauvet wrote:
Hi there,
While testing upstream kernel on some devices, I've recently discovered that suspend was broken for "distro kernel" (not only related to fedora kernel, but also ubuntu).
On the Fedora users list we have had a terrible time with suspend on F28. 4.17.3 was ok, but then broke with 4.17.4 and was not, for the most part, fixed until 4.17.11. But still even with 4.17.14 a number of us are still reporting that suspend fails the first time with the system immediately restarting and then when you unlock your system and suspend again, that 'takes'.
And we have been getting a weekly kernel update on F28 64 for some time now. I cannot remember another Fedora release where the kernel updates have come so frequently for so long.
Some of the reported problems (by ME!) revolved around QEMU running an image.
Most logs showed hangs occurring right after NetworkManager messages (but not all that are typically seen on successful suspends).
So does not surprise me at all that we are not out of the woods here. I wonder if anyone is testing this on x86_64 systems. I don't have the wherewithall to do that.
I will put together a test on a Cubieboard2 with the Xfce desktop. But I will be waiting for an image that contains openssl 1.1.1-pre9 to put in the time. And I never really tested suspend to swap on my Cubies. It will be painful with swap on an SD card.
And I think that is part of the suspend problem. If it takes too long, some thing breaks.
I order to debug this, I was advised to use a serial console and boot with theses options: no_console_suspend=1 initcall_debug
Then using systemctl suspend outputs this report for me: https://bugzilla.redhat.com/show_bug.cgi?id=1619699 Basically, I'm running a tegra device, but a pxa driver (unrelated to the device) lead to a crash preventing suspend.
I would like others on this list to try to report such use case, I don't expect pxa_gpio to be the only driver to have issue in the fedora config. Specially as it does not have problem at boot time or shutdown so this problem might remains silent.
Please don't forget to block ARMTracker on bugzilla.redhat.com, and mention it there if you uses upstream bug tracker.
Thx for any report.
arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org/me...
On 08/21/2018 11:40 AM, Nicolas Chauvet wrote:
Hi there,
While testing upstream kernel on some devices, I've recently discovered that suspend was broken for "distro kernel" (not only related to fedora kernel, but also ubuntu).
On the Fedora users list we have had a terrible time with suspend on F28. 4.17.3 was ok, but then broke with 4.17.4 and was not, for the most part, fixed until 4.17.11. But still even with 4.17.14 a number of us are still reporting that suspend fails the first time with the system immediately restarting and then when you unlock your system and suspend again, that 'takes'.
And we have been getting a weekly kernel update on F28 64 for some time now. I cannot remember another Fedora release where the kernel updates have come so frequently for so long.
Well there's been just one or two major vulnerabilities this year (spectre/meltdown) that have been a major reason for some of these so it's not unexpected, at least for those that vaguely sort of follow the security industry.
On 08/29/2018 08:12 AM, Peter Robinson wrote:
On 08/21/2018 11:40 AM, Nicolas Chauvet wrote:
Hi there,
While testing upstream kernel on some devices, I've recently discovered that suspend was broken for "distro kernel" (not only related to fedora kernel, but also ubuntu).
On the Fedora users list we have had a terrible time with suspend on F28. 4.17.3 was ok, but then broke with 4.17.4 and was not, for the most part, fixed until 4.17.11. But still even with 4.17.14 a number of us are still reporting that suspend fails the first time with the system immediately restarting and then when you unlock your system and suspend again, that 'takes'.
And we have been getting a weekly kernel update on F28 64 for some time now. I cannot remember another Fedora release where the kernel updates have come so frequently for so long.
Well there's been just one or two major vulnerabilities this year (spectre/meltdown) that have been a major reason for some of these so it's not unexpected, at least for those that vaguely sort of follow the security industry.
Not my area of security industry. Protocol design takes up all my cycles. But I did hear of these.
How would suspend work with no swap partition? I have to spend a little time working out how to use gparted to add a swap partition to a sata HD.
And I can't test out suspend until I get a system with Xfce running. Suspend is not interesting on a minimal image.
On Wed, Aug 29, 2018 at 1:29 PM Robert Moskowitz rgm@htt-consult.com wrote:
On 08/29/2018 08:12 AM, Peter Robinson wrote:
On 08/21/2018 11:40 AM, Nicolas Chauvet wrote:
Hi there,
While testing upstream kernel on some devices, I've recently discovered that suspend was broken for "distro kernel" (not only related to fedora kernel, but also ubuntu).
On the Fedora users list we have had a terrible time with suspend on F28. 4.17.3 was ok, but then broke with 4.17.4 and was not, for the most part, fixed until 4.17.11. But still even with 4.17.14 a number of us are still reporting that suspend fails the first time with the system immediately restarting and then when you unlock your system and suspend again, that 'takes'.
And we have been getting a weekly kernel update on F28 64 for some time now. I cannot remember another Fedora release where the kernel updates have come so frequently for so long.
Well there's been just one or two major vulnerabilities this year (spectre/meltdown) that have been a major reason for some of these so it's not unexpected, at least for those that vaguely sort of follow the security industry.
Not my area of security industry. Protocol design takes up all my cycles. But I did hear of these.
How would suspend work with no swap partition? I have to spend a little time working out how to use gparted to add a swap partition to a sata HD.
Suspend should be just fine (S3, s2idle etc) , I think you mean hibernate which writes the contents of RAM out to storage so it can turn the device off completely.
Hi Nicolas,
While testing upstream kernel on some devices, I've recently discovered that suspend was broken for "distro kernel" (not only related to fedora kernel, but also ubuntu).
TBH I'm not particular surprised to see this, I'm aware it works for some aarch64 devices but I've not had the time to focus on anything around suspend because well making/keeping things booting and the basics takes up a lot of my time.
I order to debug this, I was advised to use a serial console and boot with theses options: no_console_suspend=1 initcall_debug
This good information, would you be able to assist in documenting this in a wiki page. I've created an initial template [1] so feel free to add/adjust.
[1] https://fedoraproject.org/wiki/Architectures/ARM/Debugging
Then using systemctl suspend outputs this report for me: https://bugzilla.redhat.com/show_bug.cgi?id=1619699 Basically, I'm running a tegra device, but a pxa driver (unrelated to the device) lead to a crash preventing suspend.
Has this been reported to the pxa_gpio driver maintainer upstream? Without that the above bug report will sit until I have the time to deal with it so it's unlikely to go too far. Please feel free to cc: on emails if it will assist with accelerating fixes.
I would like others on this list to try to report such use case, I don't expect pxa_gpio to be the only driver to have issue in the fedora config. Specially as it does not have problem at boot time or shutdown so this problem might remains silent.
I'm very sure that is the case.
Please don't forget to block ARMTracker on bugzilla.redhat.com, and mention it there if you uses upstream bug tracker.
Thx for any report.
--
Nicolas (kwizart) _______________________________________________ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org/me...
2018-08-29 14:24 GMT+02:00 Peter Robinson pbrobinson@gmail.com:
Hi Nicolas,
Hi Peter,
I order to debug this, I was advised to use a serial console and boot with theses options: no_console_suspend=1 initcall_debug
This good information, would you be able to assist in documenting this in a wiki page. I've created an initial template [1] so feel free to add/adjust.
[1] https://fedoraproject.org/wiki/Architectures/ARM/Debugging
Sure, I will report in the appropriate section when possible.
Then using systemctl suspend outputs this report for me: https://bugzilla.redhat.com/show_bug.cgi?id=1619699 Basically, I'm running a tegra device, but a pxa driver (unrelated to the device) lead to a crash preventing suspend.
Has this been reported to the pxa_gpio driver maintainer upstream?
This issue has been reported on linux-gpio along with: https://bugzilla.kernel.org/show_bug.cgi?id=200905
The pxa_gpio maintainer is answering , but unfortunately the first patch he suggested doesn't seem to work.
About the ti-cpufreq patch reported at: https://bugzilla.kernel.org/show_bug.cgi?id=200875 There is a patch on the omap mailing list: https://marc.info/?l=linux-arm-kernel&m=153505207226577&w=2 This seems to work at this step.
Thx
On Wed, Aug 29, 2018 at 7:59 PM Nicolas Chauvet kwizart@gmail.com wrote:
2018-08-29 14:24 GMT+02:00 Peter Robinson pbrobinson@gmail.com:
Hi Nicolas,
Hi Peter,
I order to debug this, I was advised to use a serial console and boot with theses options: no_console_suspend=1 initcall_debug
This good information, would you be able to assist in documenting this in a wiki page. I've created an initial template [1] so feel free to add/adjust.
[1] https://fedoraproject.org/wiki/Architectures/ARM/Debugging
Sure, I will report in the appropriate section when possible.
Feel free to add sections as necessary
Then using systemctl suspend outputs this report for me: https://bugzilla.redhat.com/show_bug.cgi?id=1619699 Basically, I'm running a tegra device, but a pxa driver (unrelated to the device) lead to a crash preventing suspend.
Has this been reported to the pxa_gpio driver maintainer upstream?
This issue has been reported on linux-gpio along with: https://bugzilla.kernel.org/show_bug.cgi?id=200905
The pxa_gpio maintainer is answering , but unfortunately the first patch he suggested doesn't seem to work.
OK
About the ti-cpufreq patch reported at: https://bugzilla.kernel.org/show_bug.cgi?id=200875 There is a patch on the omap mailing list: https://marc.info/?l=linux-arm-kernel&m=153505207226577&w=2 This seems to work at this step.
I saw that. Once it gets reviewed/acked I'm happy to pull it in.
Peter
Nicolas,
I finally have an Xfce desktop. So I decided to try suspend to ram.
It did something, but then stopped. Monitor is still on, in character mode. And I realized, WHAT do I do to get the system to resume? What do I have on this SOC that will trigger the resume. I am stumped!
So I will power cycle...
[ 1422.375877] PM: Syncing filesystems ... done. [ 1427.191217] Freezing user space processes ... (elapsed 0.004 seconds) done. [ 1427.203321] OOM killer disabled. [ 1427.206678] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [ 1427.216019] Suspending console(s) (use no_console_suspend to debug)
On 08/21/2018 11:40 AM, Nicolas Chauvet wrote:
Hi there,
While testing upstream kernel on some devices, I've recently discovered that suspend was broken for "distro kernel" (not only related to fedora kernel, but also ubuntu).
I order to debug this, I was advised to use a serial console and boot with theses options: no_console_suspend=1 initcall_debug
Then using systemctl suspend outputs this report for me: https://bugzilla.redhat.com/show_bug.cgi?id=1619699 Basically, I'm running a tegra device, but a pxa driver (unrelated to the device) lead to a crash preventing suspend.
I would like others on this list to try to report such use case, I don't expect pxa_gpio to be the only driver to have issue in the fedora config. Specially as it does not have problem at boot time or shutdown so this problem might remains silent.
Please don't forget to block ARMTracker on bugzilla.redhat.com, and mention it there if you uses upstream bug tracker.
Thx for any report.
2018-09-04 20:05 GMT+02:00 Robert Moskowitz rgm@htt-consult.com:
Nicolas,
I finally have an Xfce desktop. So I decided to try suspend to ram.
It did something, but then stopped. Monitor is still on, in character mode. And I realized, WHAT do I do to get the system to resume? What do I have on this SOC that will trigger the resume. I am stumped!
So I will power cycle...
[ 1422.375877] PM: Syncing filesystems ... done. [ 1427.191217] Freezing user space processes ... (elapsed 0.004 seconds) done. [ 1427.203321] OOM killer disabled. [ 1427.206678] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [ 1427.216019] Suspending console(s) (use no_console_suspend to debug)
It depends on the device, I expect not all keys can leave suspend. On the Trimslice, I can use the power button, on AC100 any key on the keyboard. If you have an usb keyboard plugin and it didn't leave suspend, then I guess there is something missing to be hooked there.
But I would have expected crash to happen when entering suspend. Having no crash on your device is an interesting information anway. (I was also able to "not" reproduce any crash with wandboard).
Thx for your tests.
-
Nicolas Chauvet -
Peter Robinson -
Robert Moskowitz