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: "Carlos O'Donell" <carlos at redhat dot com>
- To: Richard Henderson <rth at twiddle dot net>, Allan McRae <allan at archlinux dot org>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Thu, 06 Nov 2014 10:18:14 -0500
- Subject: Re: Discrepancy between /proc/cpuinfo and glibc are suspend
- Authentication-results: sourceware.org; auth=none
- References: <545B703B dot 8050803 at archlinux dot org> <545B8D5B dot 6020903 at twiddle dot net>
On 11/06/2014 10:01 AM, Richard Henderson wrote:
> 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.
+1.
Quite weird.
c.