[Bug 200748] Issues after resume when TSC timecounter selected, possibly due to CPU TSC resetting to zero

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Wed Jun 10 01:09:43 UTC 2015


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200748

            Bug ID: 200748
           Summary: Issues after resume when TSC timecounter selected,
                    possibly due to CPU TSC resetting to zero
           Product: Base System
           Version: 11.0-CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: gavin at FreeBSD.org

Created attachment 157592
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=157592&action=edit
Verbose dmesg

I have a Lenovo Flex 10 laptop.  With kern.timecounter.hardware=TSC (the
default), on resume there are serious issues: primarily that time appears to
run very fast, the AHCI controller/drive fail to reinit correctly, etc. 
Unfortunately the video doesn't recover either (unrelated to this issue), so
it's a bit hard to establish exactly what state the machine is in at this time.

After some digging, it looks like the CPU TSC counter is reset to zero on
resume:

root at flex10:~ # cpucontrol -m 0x10 /dev/cpuctl0 ; cpucontrol -m 0x10
/dev/cpuctl1
MSR 0x10: 0x0000019a 0x3d2660a7
MSR 0x10: 0x0000019a 0x5f4b9d7a
root at flex10:~ # zzz
[wake machine up]
root at flex10:~ # cpucontrol -m 0x10 /dev/cpuctl0 ; cpucontrol -m 0x10
/dev/cpuctl1
MSR 0x10: 0x00000004 0x27c4514f
MSR 0x10: 0x00000004 0x49dcc993

I suspect (though haven't been able to prove) that this is the cause.

The CPU is an Intel N2807 ultra low power CPU.  It does have invariant P state
TSC.

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the freebsd-bugs mailing list