On a kefka board (braswell) this happens every time I run it.

I tried setting CONFIG_X86_TSC=n, but it turns out it's implied by having an x86_64 processor.

We can try setting clocksource on the kernel command line, but I think there are kernel pieces that will always use tsc when it's available. We might be better off seeing what we're doing wrong with it.

 Issue 884911  has been merged into this issue.

Assigning to myself while we wait for mutexlox@ (who will be working on it) to get a chromium.org account.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/tast-tests/+/2f05c69330879c875332b1b816dc0125251a4835

commit 2f05c69330879c875332b1b816dc0125251a4835
Author: Jeffrey Kardatzke <jkardatzke@google.com>
Date: Sat Sep 29 07:27:31 2018

tast-tests: Fix localhost prompt checking in StartCrosvm

Previously this test worked because the VM was logging out a line from
the kernel after the bash prompt was shown, which then caused a line
terminator to come through stdout. There was a kernel change which made
that line come earlier, so we are not seeing the line terminator on
stdout after the 'localhost #' prompt like we used to. This fixes that
problem by scanning for bytes from stdout rather than lines.

BUG= chromium:878908 
TEST=tast run vm.StartCrosvm

Change-Id: I3aebffe588a0c9a6ae9f012e9d74877cb1833455
Reviewed-on: https://chromium-review.googlesource.com/1249764
Commit-Ready: Jeffrey Kardatzke <jkardatzke@google.com>
Tested-by: Jeffrey Kardatzke <jkardatzke@google.com>
Reviewed-by: Dan Erat <derat@chromium.org>

[modify] https://crrev.com/2f05c69330879c875332b1b816dc0125251a4835/src/chromiumos/tast/local/bundles/cros/vm/start_crosvm.go

The above fix I did causes the test to pass now...but the underlying TSC issue is still there (it was causing the test to fail because it was flakey).

I believe that the root cause of this bug is a partially-applied patchset: https://lore.kernel.org/lkml/20180719205545.16512-12-pasha.tatashin@oracle.com/T/#m6f1410941dcc6efb59be58d06f9e1fffb4a21d54

Specifically, we have applied 8 / 26 commits from that patch applied in third_party/kernel/v4.14. The patchset is rather large:
  33 files changed, 439 insertions(+), 447 deletions(-)
and does not merge cleanly.  (For example, one of the early patches in that set comes after https://github.com/torvalds/linux/commit/819aeee065e5d1b417ecd633897427c89f3253ec, and trying to apply the patchset without 819aeee causes non-trivial merge conflicts.)

Note that I'm not positive that applying the patchset I linked earlier will fix the problem -- I haven't successfully applied it to test yet.

As I see it, we have a few options:

1) Apply the patchset, manually resolving merge conflicts and applying older patches as needed. This could easily take weeks, and would be very error-prone.
2) Upgrade to a newer kernel version (e.g. 4.18). While not LTS, a later kernel version would have more of the patches we need. However, I'm not sure how much work it is to do a kernel upgrade. How far does our tree diverge from upstream?
3) Wait for version 4.19. It's not released yet, but should be soon for some value of "soon".

Does anyone have thoughts on these options?

we only need this in the VM kernel right ?

if we can't find something small to resolve it, waiting for 4.19 is prob our best bet imo.  applying the patches would affect our host kernels too which might be dicey.

We should only need it in the guest.

One downside of waiting that I didn't mention is that it is somewhat likely that this bug is causing user-noticeable issues ( https://crbug.com/891024  and  https://crbug.com/823406 ).

can we workaround it on the host side ?  have cicerone or something listen to the resume event and then have it force the time to change in the VMs ?  not sure if that's something kvm offers.

Can we try a 4.19-rcX build to see if that really fixes it?

Good idea. Are there any critical kernel patches in our 4.14 that aren't in the latest 4.19-rcX?

Indeed, it seems to be fixed in next/chromeos-next (I can no longer see the warning).

We've got an official 4.19 branch now, smbarber is working to get the VMs updated.

Dylan, smbarber: have you been able to confirm that the TSC warnings don't happen in the 4.19 branch? (Just confirming that they start up with the tast test isn't enough; that was only failing due to a test infrastructure issue)

What milestone are we targeting for 4.19 kernel?

assign to smbarber to confirm.

I haven't seen this since we switched to 4.19, on M72.

Excellent! Thanks :-)