Bug 114741
Summary: | ubsan: "-1364598267798016 * 25600 cannot be represented" in drivers/cpufreq/intel_pstate.c:874:11 | ||
---|---|---|---|
Product: | Platform Specific/Hardware | Reporter: | Peter Gerber (peter) |
Component: | IA-64 | Assignee: | platform_ia-64 |
Status: | NEW --- | ||
Severity: | normal | CC: | dsmythies |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 4.5.0 | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: | Trace example of MSR's reset after suspend |
Description
Peter Gerber
2016-03-15 20:38:14 UTC
I am having trouble to correlate your line 874 of the intel_pstate.c driver with any version I can extract from git. Could you please post the code fragment from that area, so that I can correlate it with some version of the intel_pstate.c driver that I have. I believe the issue to be that the aperf, mperf, and tsc MSR's get reset during a suspend / resume cycle, and so the first sample to sample difference calculation after resume becomes ridiculous. While I have seen this issue before, I have never complained about it. Does the issue still occur with kernel 4.7-rc4? I think, but am not sure yet, that you will want to change the bug report "Product" to "Power Management" and the "Component" to "intel_pstate". I stumbled across this by accident, while searching for bugs with the keyword intel_pstate. Created attachment 220831 [details]
Trace example of MSR's reset after suspend
On kernel 4.7-rc4, I ran a trace, however trace messes up through a suspend/resume and only data for CPU 0 was acquired after the first suspend.
3 suspend / resumes were done. Observe the extreme numbers for aperf, mperf, and tsc on the first sample during resume. The reason, I have never complained about this before, it that there I never observed any bad side effect as a result.
Note: the trace post processing tools print the numbers as %u, or unsigned.
|