retitle 736892 kernel: does not log when it skips an already up-do-date cpu severity 736892 minor tags 736892 upstream wontfix thanks
On Tue, 28 Jan 2014, Stephen Powell wrote: > On Tue, 28 Jan 2014 06:23:49 -0500 (EST), Henrique de Moraes Holschuh wrote: > > Could you please send to the bug report the contents of /proc/cpuinfo on the > > kernel that is showing problems? That should help diagnosing the issue. > > I will include lines from both /var/log/dmesg and /proc/cpuinfo. > As you will see, the two sources do not agree. According to /var/log/dmesg, > only CPU 0 and CPU 2 were upgraded. But according to /proc/cpuinfo, all > four of them have been upgraded. I'm not sure which one to believe. Some processors update per core, not per hardware thread (hardware threads show up as separate "cpus" in Linux x86/x86-64). When a hardware thread is updated on these processors, it actually updates all hardware threads that share that core. The newer kernel notices this, and doesn't attempt to apply an update to a core that has been updated already. It really is updating the entire processor, you can believe /proc/cpuinfo. I will leave this bug report open as documentation, even if it really is a kernel-side issue. I will abuse the "upstream" and "wontfix" tags for this, as we don't have a "notabug" tag, unfortunately. I will also take a look kernel-side, but I have no idea how feasible would it be to provide better log messages when a "cpu" can be skipped because its core has been updated already by a previous thread in the same microcode update run. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
