* Russell King - ARM Linux <linux@xxxxxxxxxxxxxxx> [171103 10:45]:
> I don't know if this is covered in your pull request, but since 31st
> October, the SDP4430 no longer recovers from a hibernation attempt.
> (as found by my nightly tests).
No I was not aware of any -rc series regressions, thanks for letting
me know.
> 4.14-rc6+ plus my tree plus arm-soc/for-next branch worked fine:
>
> root@omap-4430sdp:~# if [ -f /sys/power/disk ]; then echo reboot > /sys/power/disk; echo disk > /sys/power/state; fi
> PM: hibernation entry
> PM: Syncing filesystems ...
> PM: done.
> Freezing user space processes ... (elapsed 0.022 seconds) done.
> OOM killer disabled.
> PM: Basic memory bitmaps created
> PM: Preallocating image memory... done (allocated 13293 pages)
> PM: Allocated 53172 kbytes in 0.17 seconds (312.77 MB/s)
> Freezing remaining freezable tasks ... (elapsed 0.016 seconds) done.
> Suspending console(s) (use no_console_suspend to debug)
> omap_hwmod: gpio2: _wait_target_disable failed
> Disabling non-boot CPUs ...
> PM: Creating hibernation image:
> PM: Need to copy 13028 pages
> PM: Normal pages needed: 9836 + 1024, available pages: 53639
> PM: Hibernation image created (13028 pages copied)
> Enabling non-boot CPUs ...
> CPU1 is up
> PM: Cannot find swap device, try swapon -a.
> PM: Cannot get swap writer
> PM: Basic memory bitmaps freed
> OOM killer enabled.
> Restarting tasks ... done.
> PM: hibernation exit
> root@omap-4430sdp:~#
>
> The above is an example of success - it's intentional that there's no
> swap, which prevents the system entering hibernation. The purpose of
> this test is to exercise the PM and CPU hotplug paths.
>
> 4.14-rc7+ plus my tree plus arm-soc/for-next now fails:
>
> root@omap-4430sdp:~# if [ -f /sys/power/disk ]; then echo reboot > /sys/power/disk; echo disk > /sys/power/state; fi
> PM: hibernation entry
> PM: Syncing filesystems ...
> PM: done.
> Freezing user space processes ... (elapsed 0.022 seconds) done.
> OOM killer disabled.
> PM: Basic memory bitmaps created
> PM: Preallocating image memory... done (allocated 13200 pages)
> PM: Allocated 52800 kbytes in 0.17 seconds (310.58 MB/s)
> Freezing remaining freezable tasks ... (elapsed 0.015 seconds) done.
> Suspending console(s) (use no_console_suspend to debug)
>
> From what I can see, there's no change in arm-soc/for-next across that
> period - the same SHA1 hash was merged for the build tree update
> on the 27th October as was used on the 30th October.
>
> There's no change (apart from the SHA hashes, the diff between them is
> empty) in the branch I merged between those two dates either for my
> tree. The SHA hash change was due to squashing some MPS3 changes to
> fix a build error for the recently added mps3 build target in the
> builder.
>
> The material difference is Linus' tip, which changed from f34157878d3b
> ("Merge tag 'nfs-for-4.14-4' of git://git.linux-nfs.org/projects/trondmy/linux-nfs")
> to 0b07194bb55e ("Linux 4.14-rc7").
>
> In the diffstat between the two build trees (post merge), I don't see
> anything in arch/arm that could account for it. I do see some power
> changes:
>
> drivers/base/power/domain_governor.c | 53 +--
> drivers/base/power/qos.c | 2 +-
> drivers/base/power/runtime.c | 2 +-
> drivers/base/power/sysfs.c | 25 +-
>
> but nothing in tty or serial. These power changes look like QoS
> changes, which probably aren't related.
>
> Just to make sure, I've diffed the build tree SHAs and the change in
> Linus' tip, and the two diffs match apart from a couple of SHA blob
> hashes on a couple of files (EFI stub and MAINTAINERS).
Initiating git bisect sequence.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
