Hi community,
Our customer have a question about i.MX6Q Android 5.1.1 BSP.
This BSP sometimes faile to resume from suspend.
Please see the detail as below.
=====
[Board]
MCIMX6Q-SDP
[BSP]
Android 5.1.1_2.1.0-ga
[Problem]
Sometimes fail to resume from suspend.
[Procedure]
1.Boot Android 5.1.1 and set the following bootargs to use serial console.
setenv bootargs console=ttymxc0,115200 init=/init video=mxcfb0:dev=ldb,bpp=32 video=mxcfb1:off video=mxcfb2:off video=mxcfb3:off vmalloc=256M androidboot.console=ttymxc0 consoleblank=0 androidboot.hardware=freescale cma=384M androidboot.selinux=disabled androidboot.dm_verity=disabled
2. Suspend Anroid with the following command.
echo mem > /sys/power/state
3. Resume with pushing power switch (SW1).
[Frequency]
Often
[log]
root@sabresd_6dq:/ # echo mem > /sys/power/state
PM: suspend entry 1970-01-01 00:42:12.771037673 UTC
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.001 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
Suspending console(s) (use no_console_suspend to debug) // Suspending Done
PM: suspend of devices complete after 66.477 msecs // Push power button to resume
PM: suspend devices took 0.070 seconds
PM: late suspend of devices complete after 0.535 msecs
PM: noirq suspend of devices complete after 0.634 msecs
Disabling non-boot CPUs ...
CPU1: shutdown
CPU2: shutdown
CPU3: shutdown
Resume caused by IRQ 103
Suspended for 0.000 seconds
Enabling non-boot CPUs ...
CPU1: Booted secondary processor
CPU1 is up
CPU2: Booted secondary processor
CPU2 is up
CPU3: Booted secondary processor
CPU3 is up
PM: noirq resume of devices complete after 0.392 msecs
PM: early resume of devices complete after 0.454 msecs
PM: resume of devices complete after 131.201 msecs
PM: resume devices took 0.140 seconds
Restarting tasks ... done.
PM: suspend exit 1970-01-01 00:42:16.162975000 UTC
root@sabresd_6dq:/ # ata1: SATA link down (SStatus 0 SControl 300)
mma enable setting inactive
PU: Power-off latency exceeded, new value 29000 ns
PM: suspend entry 1970-01-01 00:42:20.462260334 UTC
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.001 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
Suspending console(s) (use no_console_suspend to debug) // Suspend automatically again with no handling
=====
[Question]
How can I modify this resume problem?
Best Regards,
Satoshi Shimoda
Dear SergioSolis,
I tested with another SABRE-SDP, but same problem was occurred.
And tested with M6.0.1_2.1.0 BSP, but same problem was occurred.
> Can we get a log of the system?
Did you mean dmesg log as "a log of the system"?
If yes, please see the attached file.
I entered to suspend on line 656, and push power switch on line 662.
The system was woken-up on line 685, but entered to suspend again automatically on line 692.
I woke-up the system on line 693 again by pushing power switch, and execute dmesg on line 720.
For your information, I tested with SCH-27392 Rev. C4 SABRE-SDP, and another one is Rev. C2.
Best Regards,
Satoshi Shimoda
Hello Satoshi,
I am unable to duplicate using a SABRE6Q-SDB version. Sounds like something on the power rails may not be turning back on after a suspend.
Can the customer duplicate the problem under Marshmallow 6.0?
Dear Sergio,
I tested with SCH-27392 REV C4 board.
700-27392 REV C is written on the board also.
Best Regards,
Satoshi Shimoda