Public bug reported: lscpu behaves differently when run sudo vs non-sudo on AMD architectures.
On sudo runs, it adds a BIOS model name and BIOS CPU family which it does not add for the latter. However since this parsing from the DMI is primarily catered to aarch64, for AMD platform the BIOS model name is printed out as follows "AMD XXX Processor *Unknown* CPU @ X.XGHz" due to the part number is not populated on the platform. The issue boils down to an unconditional call to arm_decode() which attempts to read the DMI path and populate the processor information such as processor version and part number which is set to Unknown on AMD CPUs. 81d6de9 (lscpu: remove the old code) changed the DMI path from /sys/firmware/dmi/entries/4-0/raw (non-existent) to /sys/firmware/dmi/tables/dmi (existent) which has brought this latent issue to light as DMI was starting to be parsed incorrectly. Therefore, do not perform aarch64 parsing for other architectures. https://github.com/util-linux/util- linux/commit/50a3efab6d126b28fcdcc28f1a0cd5cd596ae357 ** Affects: linux (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2077464 Title: lscpu: Skip aarch64 decode path for rest of the architectures Status in linux package in Ubuntu: New Bug description: lscpu behaves differently when run sudo vs non-sudo on AMD architectures. On sudo runs, it adds a BIOS model name and BIOS CPU family which it does not add for the latter. However since this parsing from the DMI is primarily catered to aarch64, for AMD platform the BIOS model name is printed out as follows "AMD XXX Processor *Unknown* CPU @ X.XGHz" due to the part number is not populated on the platform. The issue boils down to an unconditional call to arm_decode() which attempts to read the DMI path and populate the processor information such as processor version and part number which is set to Unknown on AMD CPUs. 81d6de9 (lscpu: remove the old code) changed the DMI path from /sys/firmware/dmi/entries/4-0/raw (non-existent) to /sys/firmware/dmi/tables/dmi (existent) which has brought this latent issue to light as DMI was starting to be parsed incorrectly. Therefore, do not perform aarch64 parsing for other architectures. https://github.com/util-linux/util- linux/commit/50a3efab6d126b28fcdcc28f1a0cd5cd596ae357 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2077464/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
