This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Discrepancy between /proc/cpuinfo and glibc are suspend
- From: Richard Henderson <rth at twiddle dot net>
- To: Allan McRae <allan at archlinux dot org>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Thu, 06 Nov 2014 16:01:47 +0100
- Subject: Re: Discrepancy between /proc/cpuinfo and glibc are suspend
- Authentication-results: sourceware.org; auth=none
- References: <545B703B dot 8050803 at archlinux dot org>
On 11/06/2014 01:57 PM, Allan McRae wrote:
> Hi all,
>
> I am wondering if anyone can shed insight onto my problem...
>
> We load Intel microcode early in boot and it successfully disables HLE.
> However, after resume from suspend, glibc tries using HLE again.
> /proc/cpuinfo reports no HLE before and after suspend, so there seems to
> be a disagreement between that and glibc. We also have a user report
> that the cpuid software (I am not familiar with it) reports no HLE
> before suspend by reports 1/4 cpu with HLE support after suspend.
>
> I am not sure if this is a glibc issue at all, although the dependency
> between what glibc detects as enabled and /proc/cpuinfo is troubling,
> particularly as glibc is wrong.
Not a glibc problem.
/proc/cpuinfo includes stuff that the kernel cached at some point.
cpuid and glibc both use the cpuid instruction, and so reports what the
current cpu actually has enabled. If cpuid says that HLE is enabled,
then it really is enabled.
How a microcode update could get lost, I've no idea, since I don't
know how that interacts with cpus that the kernel decides to power
down. But I can't imagine except that this is a kernel bug.
r~