Messages in this thread | | | Date | Wed, 9 Nov 2011 19:52:12 -0600 | From | Jonathan Nieder <> | Subject | Re: CPU hyperthreading turned on after soft power-cycle |
| |
Hi Jiri,
Jiri Polach wrote:
> On Ben's advice I am trying to locate the commit that causes the problem to > appear more precisely using 'git bisect'. However, too many of generated > revisions are unbootable so I have to use 'bisect skip' frequently.
Ok, so I've looked over the log at <http://bugs.debian.org/647095>, and this seems totally weird. Have I described the symptoms correctly below? (Warning: I am making some guesses, especially at step 5. In case of doubt, see the bug log just mentioned.)
1. Disable SMT in the BIOS.
2. Boot a bad kernel. /proc/cpuinfo (correctly) shows one entry per core.
3. "shutdown -h now". Enter BIOS. SMT is still disabled. Don't save.
4. Boot any kernel. /proc/cpuinfo shows two entries per core.
5. "shutdown -h now". Boot any kernel. /proc/cpuinfo still shows two entries per core.
6. "shutdown -h now". Enter BIOS. SMT is still disabled. Save. Now /proc/cpuinfo will (correctly) shows one entry per core.
Reproducible for Jiri with v3.0.4.
Result of bisecting: v2.6.38-rc1 exhibits the problem. v2.6.37 and many of the topic branches merged in the 2.6.38 merge window work ok. Some other topic branches do not boot at all.
Jiri: if you have gitk installed, then "git bisect visualize" can help get a sense of what's in the middle of the regression range. "gitk --bisect --first-parent v2.6.37..v2.6.38-rc1" might be a good way to find mainline commits to test before finding a topic branch to delve into.
x86 people: do the symptoms seem familiar? Any hints for tracking it down?
Thanks and hope that helps, Jonathan
| |