~kamalmostafa/ubuntu/+source/linux-aws/+git/cosmic:hibernate-master

Last commit made on 2019-04-03
Get this branch:
git clone -b hibernate-master https://git.launchpad.net/~kamalmostafa/ubuntu/+source/linux-aws/+git/cosmic
Only Kamal Mostafa can upload to this branch. If you are Kamal Mostafa please log in for upload directions.

Branch merges

Branch information

Name:
hibernate-master
Repository:
lp:~kamalmostafa/ubuntu/+source/linux-aws/+git/cosmic

Recent commits

b697f20... by Frank van der Linden <email address hidden>

UBUNTU SAUCE [aws]: xen: Only restore the ACPI SCI interrupt in xen_restore_pirqs.

Restoring all PIRQs, which is the right thing to do, was causing problems
on larger instances. This is a horrible workaround until this issue is fully
understood.

Signed-off-by: Frank van der Linden <email address hidden>
Reviewed-by: Alakesh Haloi <email address hidden>
Reviewed-by: Anchal Agarwal <email address hidden>
Reviewed-by: Qian Lu <email address hidden>
Signed-off-by: Kamal Mostafa <email address hidden>

93cf1d7... by Frank van der Linden <email address hidden>

UBUNTU SAUCE [aws]: xen: restore pirqs on resume from hibernation.

The hibernation code unlinks event channels from these (legacy) IRQs, so they
must be reinitialized on wakeup, much like in the Xen suspend/resume case.

Signed-off-by: Frank van der Linden <email address hidden>
Reviewed-by: Cristian Gafton <email address hidden>
Reviewed-by: Anchal Agarwal <email address hidden>
Reviewed-by: Alakesh Haloi <email address hidden>

CR: https://code.amazon.com/reviews/CR-3702953/
Signed-off-by: Kamal Mostafa <email address hidden>

50f4806... by Anchal Agarwal <email address hidden>

UBUNTU SAUCE [aws]: ACPICA: Enable sleep button on ACPI legacy wake

Currently we do not see sleep_enable bit set after guest resumes from
hibernation. Hibernation is triggered in guest on receiving a sleep
trigger from the hypervisor(S4 state). We see that power button is enabled
on wake up however sleep button isn't. This causes 2nd sleep trigger to fail
since PMEN register does not have bit 9 set in its register on resume which
is expected by hypervisor to be set before it can send an SCI interrupt to
the guest.
Expected PMEN=0x320 on fresh boot however, after resume PMEN=0x120

Signed-off-by: Anchal Agarwal <email address hidden>
Reviewed-by: Balbir Singh <email address hidden>
Reviewed-by: Frank van der Linden <email address hidden>

CR: https://code.amazon.com/reviews/CR-3704872
Signed-off-by: Kamal Mostafa <email address hidden>

bbf2029... by Eduardo Valentin <email address hidden>

UBUNTU SAUCE [aws]: block: xen-blkfront: consider new dom0 features on restore

On regular start, the instance will perform a regular boot, in which rootfs
is mounted accordingly to the xen-blkback features (in particular
feature-barrier and feature-flush-cache). That will setup the journal
accordingly to the provided features on SB.
On a start from hibernation, the instance boots, detects that a hibernation
image is present, push the image to memory and jumps back where it was. There
is no regular mount of the rootfs, it uses the data structures already in
the previous saved memory image.
Now, When the instance hibernates, it may move from its original dom0 to a new dom0
when it is restarted.
So, given the above, if the xen-blkback features change then the guest
can be in trouble. And I see the original assumption was that the
dom0 environment would be preserved. I did a couple of experiments,
and I confirm that these particular features change quite a lot across
hibernation attempts:
[ 2343.157903] blkfront: xvda: barrier or flush: disabled; persistent grants: disabled; indirect descriptors: enabled;
[ 2444.712339] blkfront: xvda: barrier or flush: disabled; persistent grants: disabled; indirect descriptors: enabled;
[ 2537.105884] blkfront: xvda: flush diskcache: enabled; persistent grants: disabled; indirect descriptors: enabled;
[ 2636.641298] blkfront: xvda: barrier or flush: disabled; persistent grants: disabled; indirect descriptors: enabled;
[ 2729.868349] blkfront: xvda: flush diskcache: enabled; persistent grants: disabled; indirect descriptors: enabled;
[ 2827.118979] blkfront: xvda: flush diskcache: enabled; persistent grants: disabled; indirect descriptors: enabled;
[ 2924.812599] blkfront: xvda: flush diskcache: enabled; persistent grants: disabled; indirect descriptors: enabled;
[ 3018.063399] blkfront: xvda: flush diskcache: enabled; persistent grants: disabled; indirect descriptors: enabled;
[ 3116.685040] blkfront: xvda: flush diskcache: enabled; persistent grants: disabled; indirect descriptors: enabled;
[ 3209.164475] blkfront: xvda: barrier or flush: disabled; persistent grants: disabled; indirect descriptors: enabled;
[ 3317.981362] blkfront: xvda: barrier or flush: disabled; persistent grants: disabled; indirect descriptors: enabled;
[ 3415.939725] blkfront: xvda: flush diskcache: enabled; persistent grants: disabled; indirect descriptors: enabled;
[ 3514.202478] blkfront: xvda: barrier or flush: disabled; persistent grants: disabled; indirect descriptors: enabled;
[ 3619.355791] blkfront: xvda: barrier or flush: disabled; persistent grants: disabled; indirect descriptors: enabled;

Now, considering the above, this patch fixes the following scenario:
a. Instance boots and sets up bio queue on a dom0 A with softbarrier supported.
b. hibernates
c. When asked to restore, the instance is back on dom0 B with unsupported
softbarrier.
d. Restoration goes well until next journal commit is issued. Remember that
it is still using the previous image rootfs data structures, therefore
is gonna request a softbarrier.
e. The bio will error out and throw a "operation not supported" message
and cause the journal to fail, and it will decide to remount
the rootfs as RO.
[ 1138.909290] print_req_error: operation not supported error, dev xvda, sector 4470400, flags 6008
[ 1139.025685] Aborting journal on device xvda1-8.
[ 1139.029758] print_req_error: operation not supported error, dev xvda, sector 4460544, flags 26008
[ 1139.326119] Buffer I/O error on dev xvda1, logical block 0, lost sync page write
[ 1139.331398] EXT4-fs error (device xvda1): ext4_journal_check_start:61: Detected aborted journal
[ 1139.337296] EXT4-fs (xvda1): Remounting filesystem read-only
[ 1139.341006] EXT4-fs (xvda1): previous I/O error to superblock detected
[ 1139.345704] print_req_error: operation not supported error, dev xvda, sector 4096, flags 26008

The fix is essentially to read xenbus to query the new xen
blkback capabilities and update them into the request queue.

Reviewed-by: Balbir Singh <email address hidden>
Reviewed-by: Vallish Vaidyeshwara <email address hidden>
Signed-off-by: Eduardo Valentin <email address hidden>
Signed-off-by: Kamal Mostafa <email address hidden>

513d707... by Kamal Mostafa

UBUNTU: [config] AWS: ib_uverbs.ko, ib_umad.ko moved to linux-modules package

BugLink: https://bugs.launchpad.net/bugs/1822692

Signed-off-by: Kamal Mostafa <email address hidden>

6cc5046... by Khaled El Mously

UBUNTU: Ubuntu-aws-4.18.0-1013.15

Signed-off-by: Khalid Elmously <email address hidden>

466c2eb... by Khaled El Mously

UBUNTU: link-to-tracker: update tracking bug

BugLink: https://bugs.launchpad.net/bugs/1822788
Signed-off-by: Khalid Elmously <email address hidden>

11f3f70... by Khaled El Mously

UBUNTU: Start new release

Ignore: yes
Signed-off-by: Khalid Elmously <email address hidden>

6dfa78e... by Kleber Sacilotto de Souza

UBUNTU: Ubuntu-aws-4.18.0-1012.14

Signed-off-by: Kleber Sacilotto de Souza <email address hidden>

ac09fc6... by Kleber Sacilotto de Souza

UBUNTU: link-to-tracker: update tracking bug

BugLink: https://bugs.launchpad.net/bugs/1819614
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>