[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