| Summary: | Issues after resume when TSC timecounter selected, possibly due to CPU TSC resetting to zero | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | Gavin Atkinson <gavin> | ||||
| Component: | kern | Assignee: | freebsd-bugs (Nobody) <bugs> | ||||
| Status: | New --- | ||||||
| Severity: | Affects Only Me | ||||||
| Priority: | --- | ||||||
| Version: | CURRENT | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
Created attachment 157592 [details] 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@flex10:~ # cpucontrol -m 0x10 /dev/cpuctl0 ; cpucontrol -m 0x10 /dev/cpuctl1 MSR 0x10: 0x0000019a 0x3d2660a7 MSR 0x10: 0x0000019a 0x5f4b9d7a root@flex10:~ # zzz [wake machine up] root@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.