From: Johannes Stezenbach <hidden> Date: 2016-06-16 10:21:05
Hi,
it's not important for me but I hibernated kernel v4.5.7
and inadvertantly resumed using v4.6.2, and ISTR this
should work (confirmed by looking into git where I found
commit cc456c4e7cac3837a86aaa7ca3cb9f488d44d196).
My swap is an LVM volume inside dm-crypt, on boot the kernel read
the resume image but then immediately reset and invalidated it.
I'm using Debian sid, the initrd calls /bin/resume from
klibc-utils package.
So, should this still work? I couldn't find any
information about it.
Thanks,
Johannes
From: "Rafael J. Wysocki" <rafael@kernel.org> Date: 2016-06-16 12:11:50
On Thu, Jun 16, 2016 at 12:03 PM, Johannes Stezenbach [off-list ref] wrote:
Hi,
it's not important for me but I hibernated kernel v4.5.7
and inadvertantly resumed using v4.6.2, and ISTR this
should work (confirmed by looking into git where I found
commit cc456c4e7cac3837a86aaa7ca3cb9f488d44d196).
My swap is an LVM volume inside dm-crypt, on boot the kernel read
the resume image but then immediately reset and invalidated it.
I'm using Debian sid, the initrd calls /bin/resume from
klibc-utils package.
So, should this still work? I couldn't find any
information about it.
It should in theory, but may not in fact due to bugs discovered
recently. This patch should help:
https://patchwork.kernel.org/patch/9172981/ (it has to be applied to
both the image and boot kernels).
Thanks,
Rafael
From: Johannes Stezenbach <hidden> Date: 2016-06-16 19:06:31
On Thu, Jun 16, 2016 at 02:11:48PM +0200, Rafael J. Wysocki wrote:
On Thu, Jun 16, 2016 at 12:03 PM, Johannes Stezenbach [off-list ref] wrote:
quoted
it's not important for me but I hibernated kernel v4.5.7
and inadvertantly resumed using v4.6.2, and ISTR this
should work (confirmed by looking into git where I found
commit cc456c4e7cac3837a86aaa7ca3cb9f488d44d196).
My swap is an LVM volume inside dm-crypt, on boot the kernel read
the resume image but then immediately reset and invalidated it.
I'm using Debian sid, the initrd calls /bin/resume from
klibc-utils package.
So, should this still work? I couldn't find any
information about it.
It should in theory, but may not in fact due to bugs discovered
recently. This patch should help:
https://patchwork.kernel.org/patch/9172981/ (it has to be applied to
both the image and boot kernels).
I applied it to both the v4.5.7 and v4.6.2 kernels, booted
v4.5.7, hibernated, booted v4.6.2 to resume: still resets.
Let me know if you have something else to test.
BTW, the machine has a serial port in case you'd
like me to capture logs, but then please be specific
about the how and what so I don't waste my time.
Thanks,
Johannes
From: "Rafael J. Wysocki" <rafael@kernel.org> Date: 2016-06-16 22:00:22
On Thu, Jun 16, 2016 at 9:06 PM, Johannes Stezenbach [off-list ref] wrote:
On Thu, Jun 16, 2016 at 02:11:48PM +0200, Rafael J. Wysocki wrote:
quoted
On Thu, Jun 16, 2016 at 12:03 PM, Johannes Stezenbach [off-list ref] wrote:
quoted
it's not important for me but I hibernated kernel v4.5.7
and inadvertantly resumed using v4.6.2, and ISTR this
should work (confirmed by looking into git where I found
commit cc456c4e7cac3837a86aaa7ca3cb9f488d44d196).
My swap is an LVM volume inside dm-crypt, on boot the kernel read
the resume image but then immediately reset and invalidated it.
I'm using Debian sid, the initrd calls /bin/resume from
klibc-utils package.
So, should this still work? I couldn't find any
information about it.
It should in theory, but may not in fact due to bugs discovered
recently. This patch should help:
https://patchwork.kernel.org/patch/9172981/ (it has to be applied to
both the image and boot kernels).
I applied it to both the v4.5.7 and v4.6.2 kernels, booted
v4.5.7, hibernated, booted v4.6.2 to resume: still resets.
Well, it looks broken now, but it used to work at one point at least.
I need to investigate a bit when the time permits.
From: "Rafael J. Wysocki" <rafael@kernel.org> Date: 2016-06-17 00:53:30
On Fri, Jun 17, 2016 at 12:00 AM, Rafael J. Wysocki [off-list ref] wrote:
On Thu, Jun 16, 2016 at 9:06 PM, Johannes Stezenbach [off-list ref] wrote:
quoted
On Thu, Jun 16, 2016 at 02:11:48PM +0200, Rafael J. Wysocki wrote:
quoted
On Thu, Jun 16, 2016 at 12:03 PM, Johannes Stezenbach [off-list ref] wrote:
quoted
it's not important for me but I hibernated kernel v4.5.7
and inadvertantly resumed using v4.6.2, and ISTR this
should work (confirmed by looking into git where I found
commit cc456c4e7cac3837a86aaa7ca3cb9f488d44d196).
My swap is an LVM volume inside dm-crypt, on boot the kernel read
the resume image but then immediately reset and invalidated it.
I'm using Debian sid, the initrd calls /bin/resume from
klibc-utils package.
So, should this still work? I couldn't find any
information about it.
It should in theory, but may not in fact due to bugs discovered
recently. This patch should help:
https://patchwork.kernel.org/patch/9172981/ (it has to be applied to
both the image and boot kernels).
I applied it to both the v4.5.7 and v4.6.2 kernels, booted
v4.5.7, hibernated, booted v4.6.2 to resume: still resets.
Well, it looks broken now, but it used to work at one point at least.
I need to investigate a bit when the time permits.
So I tried 4.6.0 and 4.7-rc3, both with
https://patchwork.kernel.org/patch/9172981/ applied, and it worked for
me.
On x86-64 there's nothing fundamentally preventing a different kernel
from being used as a boot kernel for resume from hibernation (as long
as it uses the same header format as the image kernel), but
incompatibilities in device drivers are not impossible (although they
shouldn't matter in theory).
From: Johannes Stezenbach <hidden> Date: 2016-06-17 07:35:06
On Fri, Jun 17, 2016 at 02:53:28AM +0200, Rafael J. Wysocki wrote:
On Fri, Jun 17, 2016 at 12:00 AM, Rafael J. Wysocki [off-list ref] wrote:
quoted
On Thu, Jun 16, 2016 at 9:06 PM, Johannes Stezenbach [off-list ref] wrote:
quoted
On Thu, Jun 16, 2016 at 02:11:48PM +0200, Rafael J. Wysocki wrote:
quoted
On Thu, Jun 16, 2016 at 12:03 PM, Johannes Stezenbach [off-list ref] wrote:
quoted
it's not important for me but I hibernated kernel v4.5.7
and inadvertantly resumed using v4.6.2, and ISTR this
should work (confirmed by looking into git where I found
commit cc456c4e7cac3837a86aaa7ca3cb9f488d44d196).
My swap is an LVM volume inside dm-crypt, on boot the kernel read
the resume image but then immediately reset and invalidated it.
I'm using Debian sid, the initrd calls /bin/resume from
klibc-utils package.
So, should this still work? I couldn't find any
information about it.
It should in theory, but may not in fact due to bugs discovered
recently. This patch should help:
https://patchwork.kernel.org/patch/9172981/ (it has to be applied to
both the image and boot kernels).
I applied it to both the v4.5.7 and v4.6.2 kernels, booted
v4.5.7, hibernated, booted v4.6.2 to resume: still resets.
Well, it looks broken now, but it used to work at one point at least.
I need to investigate a bit when the time permits.
So I tried 4.6.0 and 4.7-rc3, both with
https://patchwork.kernel.org/patch/9172981/ applied, and it worked for
me.
On x86-64 there's nothing fundamentally preventing a different kernel
from being used as a boot kernel for resume from hibernation (as long
as it uses the same header format as the image kernel), but
incompatibilities in device drivers are not impossible (although they
shouldn't matter in theory).
OK, knowing it should work is enough since the use case
is not relly important for me.
Thanks,
Johannes