From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-139-mta243.mxyeet.net (mail-139-mta243.mxyeet.net [23.172.139.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2E1751FDA61 for ; Sat, 4 Jul 2026 09:52:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=23.172.139.243 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783158724; cv=none; b=AoHWoFyMA3mvpV3BtmCrYE0/lh66NORQP06UwTK/HoN2OZAMPSM0ro02Eged1oHNtLHTsaUu2OXMCkYwy6zxnQIRNVsPjk9dRH1MFEVjENIL6j+ojfpdVH96tpqLRUDjaQlBxp/F1PNTLXh7HTKlhXk+1hK/i7iWM/CbO67KC1I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783158724; c=relaxed/simple; bh=E6DAj/PvkQ2VmlL22CjNpv2GKGqX2tXizxAP/LtmzjY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=SuRoreC5ml4J42ZUcyen8dV5VycK/6gCCvcZCrhqaTmJWDP/zBwd7y5kBQbz8k5Th/6OaDj3b7zNprvOp9y3/AMEzlsYxr3uONxRObWVdLn71IFiIv2wNj3SFDG+wKD71e2Ve0E4pB2EjKdxD/WGkqIxP4VqXBe7GyIiD1E0Z8Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=evalyngoemer.com; spf=pass smtp.mailfrom=evalyngoemer.com; dkim=pass (2048-bit key) header.d=evalyngoemer.com header.i=@evalyngoemer.com header.b=AbQ6XACh; arc=none smtp.client-ip=23.172.139.243 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=evalyngoemer.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=evalyngoemer.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=evalyngoemer.com header.i=@evalyngoemer.com header.b="AbQ6XACh" Received: from us1.workspace.org ([162.244.93.81] us1.workspace.org) (Authenticated sender: smartermail.us1@mxyeet.net) by mail-139-mta243.mxyeet.net (MailFilter Outbound) with ESMTPSA id 19f2c8601f0000d9a4.009 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Sat, 04 Jul 2026 09:46:47 +0000 DKIM-Signature: v=1; a=rsa-sha256; d=evalyngoemer.com; s=cx8DDCB0BEEEDC8F5; c=relaxed/relaxed; t=1783158407; h=from:to:cc:subject:date:message-id:in-reply-to:references:mime-version; bh=E6DAj/PvkQ2VmlL22CjNpv2GKGqX2tXizxAP/LtmzjY=; b=AbQ6XAChsv0n9n1F1+rlMhqNwkAlxC261hfumeicZ82LKBew/KVEPTF1oPTLmhmlb4Qsb75DLY+ a4PeWbe8Z28S2taDhuZFjV8KDxlpqlXzKito7sYeIq99aWkEQOoXmTqpT1Kp5+Vu+6b1/HrcCnG0B mCuKwr6Jxrr0seChBADYO9ctktDcDGxY8zE9lkTlR2Cu6nvHElTbBfE5LQoabA8oi1crIfTvigCQe 1P/5lWFFXvbrDWiY3nxaiPIt+KQ7xTlnOitfekUXkCS+oNGK+xZErzW8j8np94CywpEl+KI2dU/Bd 3JO4Fd7woj9pjR+oNQbBICZhccZ+3LrZCEDA== From: Evalyn Goemer To: ludloff@gmail.com Cc: linux-kernel@vger.kernel.org, tglx@kernel.org, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, joe@perches.com, Andrew Cooper Subject: Re: [PATCH] platform/x86: handle Intel CPUs falsely reporting as GenuineIotel Date: Sat, 04 Jul 2026 05:46:38 -0400 Message-ID: In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Saturday, July 4, 2026 4:22:40=E2=80=AFAM Eastern Daylight Time Christia= n Ludloff=20 wrote: > > This issue can be found as existing here: > > https://github.com/InstLatx64/InstLatx64/blob/master/GenuineIotel/Genui= neI > > otel00306C3_Haswell_CPUID5.txt > > https://web.archive.org/web/20150818115122/http://store.steampowered.co= m/ > > hwsurvey/processormfg > To help put this into perspective... >=20 > The InstLatx64 dump remains the *sole* full ("canonical") report. > The additional two known *partial* reports (SNB and IVB) are here: > https://web.archive.org/web/20251105144105/https://valid.x86.fr/kjm24i > https://web.archive.org/web/20250221003721/https://valid.x86.fr/5f6gzf >=20 > It is possible that the reports were tampered with by humans. I would hope this is not the case since this is seemingly somewhat parroted= =20 around in many places and seemingly the same string comes up dating back to= =20 2015. I have contacted the person behind the InstLatx64 dump to see if they have = any=20 more info to see if I can help find more information on this specific case = and=20 maybe see if others have the same thing coming up or can reproduce it. I also have a friend testing out a bunch of similar chips as well to see if= =20 the issue can be reproduced on similar hardware. > It is possible that the reports are the result of bad DRAM memory (RAM). > It is possible that the reports are the result of bad SRAM memory (CPU). If it was DRAM/SRAM errors wouldn't they be somewhat less consistent? But y= eah=20 this is another thing that could be happening. But bad memory would probabl= y=20 come with other more severe effects than a single bit in the vendor ID? I would think it would prevent the dump from working too at least from my=20 experiences with bad memory. >=20 > Treating GenuineIotel like GenuineIntel is one choice. > Treating GenuineIotel like a rare find is another choice. This may not be the best way to handle it but I'm not sure what would be th= e=20 best. I did the patch this way since this is the only reported thing I was= =20 able to find for broken CPUID vendor strings for Intel. > Treating GenuineIotel like potentially broken HW seems most logical. How should something like this be detected and what actions should be taken= =20 when this issue is found. Though that should potentially wait until more=20 information on this issue can be found and what side effects it comes with. David Laight in the thread also mentioned it could be a BIOS issue causing= =20 this which could be some other specific issue that could be detected=20 explicitly? >=20 > There have been other similar outliers. Is there anything that's been seen to be this close on actual genuine chips= ?=20 Nothing like that sadly came up when I was researching this issue. >=20 > In my collection I got a 486 chip (fake-)marked Intel but reporting UMC. >=20 > At the other end of the spectrum, there were CPU models for which the > microcode patch match registers were not up to spec =E2=80=93 as a result= they > exhibited all kinds of undesired behavior, and had to be screened out... >=20 > -- > C.