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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
