linux-kernel - Re: Performance/resume issues on Toshiba NB305

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]

Date:	Mon, 28 Feb 2011 09:10:08 -0600
From:	Seth Forshee <seth.forshee@...onical.com>
To:	Burt Triplett <burt@...triplett.org>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Arjan van de Ven <arjan@...radead.org>,
	Venkatesh Pallipadi <venki@...gle.com>,
	Len Brown <lenb@...nel.org>
Subject: Re: Performance/resume issues on Toshiba NB305

On Sun, Feb 27, 2011 at 12:17:29PM -0800, Burt Triplett wrote:
> >The new release detects the Atom processor okay, but in bits-327 the
> >system resets during the SMI frequency/latency test, whereas it didn't
> >with bits-316.
> 
> The SMI Frequency and Latency test should be fixed in bits-329.

Yes, it's fixed now, thanks.

> To get more information on how the MSRs differ between CPUs, you can
> turn on verbose mode.  Go to the GRUB command line by hitting 'c',
> and enter "test_options -v 2".  Then hit Esc to go back to the menu,
> and re-run the MSR consistency check.  It will now show you the
> value of the MSR on each CPU.
> 
> MSR 0x1a0 is IA32_MISC_ENABLE, and generally any inconsistency in
> that MSR represents a BIOS bug: it didn't enable features
> identically on all CPUs.  Once you see which bits differ, you can
> look at the Intel Software Developer's Manual (specifically volume
> 3B) to find out what those bits mean and which specific features the
> BIOS inconsistently enabled.

 (MSR 0x1a0 consistent) FAIL (2 different values)
 1 CPUs 0x0000000364950089: 0x0
 1 CPUs 0x0000000364950081: 0x1

 Bit 3: Automatic Thermal Control Circuit Enable

I'm not sure of the impact of this, since there's really only one core
in the CPU. One of the others differs has bit 3 inconsistent as well. On
the third bit 3 is the same but bit 0 (fast-strings enable) is
inconsistent.

The three machines have further differences in this MSR, but all in bits
documented as being reserved.

> MSR 0x199 is IA32_PERF_CTL.  A difference in that MSR usually means
> the BIOS left CPUs in different P-states when booting, which it
> really shouldn't do.  Again, you can decode the result with the
> Intel SDM.

 (MSR 0x199 consistent): FAIL (2 different values)
 1 CPUs 0x0000000000000a1f: 0x0
 1 CPUs 0x0000000000000613: 0x1

So yes, the cores are in different P-states. The results from the other
machines are similar, but the values for CPU1 are slightly different for
each machine. CPU1 has the same value on all three machines.

> Looking into MSR 0x39.

Yeah, this one isn't in the SDM at all. Here are the values I got:

 (MSR 0x39 consistent): FAIL (2 different values)
 1 CPUs 0x0000000000000000: 0x0
 1 CPUs 0x0000000000000001: 0x1

Values are identical for all three machines.

I'm not really getting the idea that any of these is contributing to the
problems I'm seeing with this machine though.

Thanks,
Seth

--
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/