linux-kernel - Re: CPU hyperthreading turned on after soft power-cycle

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4EC43DF7.4010902@atlas.cz>
Date:	Wed, 16 Nov 2011 23:49:27 +0100
From:	Clarinet <clarinet@...as.cz>
To:	647095@...s.debian.org
CC:	Jonathan Nieder <jrnieder@...il.com>,
	Ben Hutchings <ben@...adent.org.uk>,
	LKML <linux-kernel@...r.kernel.org>, x86@...nel.org,
	john.stultz@...aro.org
Subject: Re: CPU hyperthreading turned on after soft power-cycle

Hi all,

>> 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.
>
> I have been able to narrow the interval manually a little bit from the
> "top" (the bad side) and I will go on from the bottom now. However,
> there seems to be a large area where kernels are unbootable for me -
> they mostly stop when init is called and I do not know why.

Finally! After another 50+ compilations a have it! It took some time as 
first I had to find a reason why some revisions did not boot (almost 2/3 
were unbootable and the first bad commit was among them). Having this 
solved I have been able to bisect without "skipping". The result is 
surprising (at least for me) - believe it or not, the first bad commit 
is 6610e089 "RTC: Rework RTC code to use timerqueue for events" from 
John Stultz (I am sending him a copy of this message).

I would never expect this would be a problem, but my understanding of 
this commit is very limited, so I am certainly missing the point. 
However, I have tried to compile 2.6.38 (which was "bad") with "Real 
Time Clock" configuration option turned off and it behaves "normally" 
then (= is "good").

Can you please comment this result? What does it mean? Any idea what is 
"wrong" there?

Best regards,

Jiri Polach

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/