intel / Intel-Linux-Processor-Microcode-Data-Files

Other
643 stars 70 forks source link

Asus Zenbook UX533FD don't boot with intel-ucode 20190312 #1

Open jledun opened 5 years ago

jledun commented 5 years ago

Hello,

I'm an ArchLinux user on Asus Zenbook laptop and my laptop can't boot with the latest intel-ucode update 20190312. I have to downgrade to 20180807.a to make it run again.

With the latest update of intel-ucode, after power on my laptop, the Asus splash screen appears then nothing else happen. I wait a few minutes then I push the power on button for 20 seconds to hard reset the laptop. After a reboot on live session, journalctl shows no entries even with the debug option in kernel command line.

It really looks like the chipset can't find any CPU.

Here are the system packages :

$ pacman -Q | grep -e linux-lts -e systemd -e intel-ucode -e iucode
intel-ucode 20180807.a-1
iucode-tool 2.3.1-2
linux-lts 4.19.37-1
linux-lts-headers 4.19.37-1
systemd 242.16-1
systemd-libs 242.16-1
systemd-sysvcompat 242.16-1

The laptop boots with systemd EFI boot :

$ cat /boot/loader/entries/arch-lts.conf 
title   Arch Linux lts
linux   /vmlinuz-linux-lts
initrd  /intel-ucode.img
initrd  /initramfs-linux-lts.img
options root=UUID=522a7ae9-8ad6-441e-85e2-baf1074be7f2  rw debug

journalctl

$ journalctl -b
-- Logs begin at Sun 2019-01-13 21:29:21 CET, end at Mon 2019-04-29 10:54:51 CEST. --
-- No entries --

CPU details (8 identical CPUs)

$ head -n26 /proc/cpuinfo 
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model       : 142
model name  : Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz
stepping    : 11
microcode   : 0x98
cpu MHz     : 800.029
cache size  : 8192 KB
physical id : 0
siblings    : 8
core id     : 0
cpu cores   : 4
apicid      : 0
initial apicid  : 0
fpu     : yes
fpu_exception   : yes
cpuid level : 22
wp      : yes
flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp flush_l1d arch_capabilities
bugs        : spectre_v1 spectre_v2 spec_store_bypass
bogomips    : 3984.00
clflush size    : 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

lspci

$ lspci 
00:00.0 Host bridge: Intel Corporation Device 3e34 (rev 0b)
00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 620 (Whiskey Lake)
00:04.0 Signal processing controller: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem (rev 0b)
00:08.0 System peripheral: Intel Corporation Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th Gen Core Processor Gaussian Mixture Model
00:12.0 Signal processing controller: Intel Corporation Cannon Point-LP Thermal Controller (rev 30)
00:14.0 USB controller: Intel Corporation Cannon Point-LP USB 3.1 xHCI Controller (rev 30)
00:14.2 RAM memory: Intel Corporation Cannon Point-LP Shared SRAM (rev 30)
00:14.3 Network controller: Intel Corporation Cannon Point-LP CNVi [Wireless-AC] (rev 30)
00:14.5 SD Host controller: Intel Corporation Device 9df5 (rev 30)
00:15.0 Serial bus controller [0c80]: Intel Corporation Cannon Point-LP Serial IO I2C Controller #0 (rev 30)
00:15.1 Serial bus controller [0c80]: Intel Corporation Cannon Point-LP Serial IO I2C Controller #1 (rev 30)
00:15.3 Serial bus controller [0c80]: Intel Corporation Device 9deb (rev 30)
00:16.0 Communication controller: Intel Corporation Cannon Point-LP MEI Controller #1 (rev 30)
00:19.0 Serial bus controller [0c80]: Intel Corporation Device 9dc5 (rev 30)
00:1c.0 PCI bridge: Intel Corporation Cannon Point-LP PCI Express Root Port #1 (rev f0)
00:1c.4 PCI bridge: Intel Corporation Cannon Point-LP PCI Express Root Port #5 (rev f0)
00:1d.0 PCI bridge: Intel Corporation Cannon Point-LP PCI Express Root Port #13 (rev f0)
00:1f.0 ISA bridge: Intel Corporation Cannon Point-LP LPC Controller (rev 30)
00:1f.3 Audio device: Intel Corporation Cannon Point-LP High Definition Audio Controller (rev 30)
00:1f.4 SMBus: Intel Corporation Cannon Point-LP SMBus Controller (rev 30)
00:1f.5 Serial bus controller [0c80]: Intel Corporation Cannon Point-LP SPI Controller (rev 30)
02:00.0 3D controller: NVIDIA Corporation GP107M [GeForce GTX 1050 Mobile] (rev ff)
03:00.0 Non-Volatile memory controller: Sandisk Corp WD Black 2018/PC SN520 NVMe SSD (rev 01)
svedrenne commented 5 years ago

@Phenecy I have an ASUS UX533FN and haven't upgraded the BIOS yet. But I've had problems with the temperature going too high and the fan not running at all, one or two weeks ago (Ubuntu 19.04).

See this post on StackOverflow AskUbuntu: https://askubuntu.com/q/1148604 No more problem with the fan since I ran sudo prime-select intel to shut down the NVidia GPU... Now the temperature stays low. Hope this helps.

Phenecy commented 5 years ago

@svedrenne Thank you! Sadly, but this workaround is not enough if one planning to play or work with 3D... Gonna look for some more fixes. Thanks a lot

jerbob92 commented 5 years ago

I have started the process of adding dis_ucode_ldr to grub recovery mode in Ubuntu. https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1831789

Enjymon commented 5 years ago

Same problem here with an ASUSPRO P5440FA. No BIOS update indicated on ASUS website for this model (https://www.asus.com/Laptops/ASUSPRO-P5440FA/HelpDesk_Download/). Kernel version: 4.15.0-52-generic Last working micrcode: Intel-microcode 3.20190514.0ubuntu0.18.04.2 All subsequent updates (I think I saw a 3.xxxxxxxx.0ubuntu0.18.04.3 at some point), up to the latest Intel-microcode 3.20190618.0ubuntu0.18.04.1, did not solve the problem for now.

Processor Information
    Socket Designation: U3E1
    Type: Central Processor
    Family: Core i7
    Manufacturer: Intel(R) Corporation
    Signature: Type 0, Family 6, Model 142, Stepping 11
    Version: Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz
BIOS Information
    Vendor: ASUSTeK COMPUTER INC.
    Version: P5440FA.204
    Release Date: 10/11/2018
    BIOS Revision: 5.13
Enjymon commented 5 years ago

@jerbob92 I have just read the thread from https://bugs.launchpad.net/ubuntu/+source/intel-microcode/+bug/1829620. It is not clear to me what is the best option for now until the microcode gets fixed: booting with the dis_ucode_ldr option or rather holding the microcode update until a newer update is released?

dsd commented 5 years ago

The only reason the old intel-microcode package version avoids this problem is that the old version does not ship a microcode file for the CPU in question here.

So disabling the microcode update has precisely the same result as the dis_ucode_ldr kernel parameter and it doesn't matter which one you use.

svedrenne commented 5 years ago

BTW, I just updated the BIOS of my ASUS UX533FN to latest version 302.

My problem now is I can't enter the laptop setup anymore, be it only to check the BIOS was updated with success... I tried pressing the usual F2 key until the ASUS logo displays. I also tried ESC.

I just can't access the setup anymore. Any solution?

EDIT:

@naijopkr Thanks for the suggestion about the shift key, though it didn't work for me.

Finally, by pressing the ESC key quickly and repeatedly (like a monkey) right after pressing the power button, I've been able to have the [Select boot device: ] GUI show up and to select the ASUS setup.

From the ASUS Flash Utility of the BIOS setup menu, I've been able to verify the ASUS BIOS of my UX533FN is now up-to-date, it is version 302 ("2019/06/14" on the website and "2019/3/29" in the Flash Utility). I deactivated "Fast Boot" so as to be able to enter setup more easily, with the F2 key.

naijopkr commented 5 years ago

Try holding shift when the ASUS logo is displayed. This should make the Grub menu show up. Then you can select the option System Setup.

tpapp commented 5 years ago

I can confirm this bug with an Asus UX362FA with an Intel i7-8565U, running Ubuntu 19.04.

dis_ucode_ldr provides a workaround.

philjoseph commented 5 years ago

Update: We have received a system from Asus and have been able to reproduce the failure in our lab. Debug is underway. I'll provide the next update when we have the root cause and a plan for the availability of a fix.

Hello there, do you have any update to share here ?

svedrenne commented 5 years ago

@naijopkr Now that I'm using BIOS 302 on my UX533FN, I tried removing the dis_ucode_ldr kernel parameter workaround, and... it worked for me. The laptop booted alright. Strange, isn't it?

$ apt-mark showhold returns nothing so I'm not holding the intel-microcode package.

$ dpkg -l | grep -i microcode | grep intel
ii  intel-microcode    3.20190618.0ubuntu0.19.04.1    amd64    Processor microcode firmware for Intel CPUs

And the kernel is actally running without the dis_ucode_ldr parameter:

$ dmesg | head
[    0.000000] microcode: microcode updated early to revision 0xb8, date = 2019-03-30
[    0.000000] Linux version 5.0.0-17-generic (buildd@lcy01-amd64-015) (gcc version 8.3.0 (Ubuntu 8.3.0-6ubuntu1)) #18-Ubuntu SMP Tue Jun 4 15:34:08 UTC 2019 (Ubuntu 5.0.0-17.18-generic 5.0.8)
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.0.0-17-generic root=UUID=f643e450-7b07-4a36-ae3f-a20cc3555941 ro
[    0.000000] KERNEL supported cpus:
[    0.000000]   Intel GenuineIntel
[    0.000000]   AMD AuthenticAMD
[    0.000000]   Hygon HygonGenuine
[    0.000000]   Centaur CentaurHauls
[    0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
[    0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'

Hope this helps for debugging, because I haven't heard that the problem is fixed for any platform or is it? @mcu-administrator

By the way, when I run the GRUB menu, most of the time the laptop keyboard gets stuck before I edit the boot commands. I don't remember having this problem before upgrading the BIOS to version 302, but I'm not sure. Each time the keyboard gets stuck (unusable), it follows a sort of display blink that I don't know how to interpret.

tpapp commented 5 years ago

I tried removing the dis_ucode_ldr kernel parameter workaround, and... it worked for me. The laptop booted alright. Strange, isn't it?

On an Asus UX362FA, I get the error about 1/3 of the time during boot, it is not deterministic.

soccerdroid commented 5 years ago

I can also confirm I have the same issue with Asus UX533FD, running Ubuntu 18..04 with kernel v5.1.10. I have not tried yet to upgrade BIOS version. Can anyone confirm me which workaround suits the best? Adding the dis_ucode_ldr parameter to the grub or update the BIOS? The version of the BIOS that Asus offers for my computer model is 304.

naijopkr commented 5 years ago

@soccerdroid you should definitely update the BIOS. Only try the workaround as last resource.

soccerdroid commented 5 years ago

@naijopkr ok thank you, I'll try to update the BIOS then (hope it does not mess up with the grub). I can confirm the other workaround works for now.

philjoseph commented 5 years ago

@naijopkr what are the negative effects of the workaround ?

dsd commented 5 years ago

@mcu-administrator you've had the affected hardware a while now, is there any progress on resolving this issue?

johnnyasantoss commented 5 years ago

Updating the BIOS to 302 fixes the problem on model RX533FN.

tyhicks commented 5 years ago

@mcu-administrator Can you please provide an update? Many of these folks are updating their BIOS so they are no longer experiencing the bug but I feel like there's a high likelihood that they'll have the same boot problems the next time that you release microcode updates for their processor and Linux distros provide the updated microcodes via software updates.

jerbob92 commented 4 years ago

@mcu-administrator Can you please provide an update? Or can you at least confirm that this issue won't return when a new microcode version is released?

tpapp commented 4 years ago

Update: on an Asus UX362FA with an Intel i7-8565U, running Ubuntu 19.04, the latest BIOS from Asus (version 303) fixes this bug.

jerbob92 commented 4 years ago

@tpapp That's probably not true. Updating your BIOS does not fix this bug, you BIOS contains the latest microcode, so your BIOS loads it instead of the Linux kernel. When a new microcode is released which is not in your BIOS this bug will probably be triggered again, hence my question.

tpapp commented 4 years ago

@jerbob92: all I am saying that I had an issue which required the dis_ucode_ldr workaround on this laptop, and after the BIOS update it is not required, and the laptop boots normally. I suppose some people may find this information useful. I don't know what, if anything, will break this in the future.

jerbob92 commented 4 years ago

@tpapp I'm just trying to stop spreading misinformation. I don't want people ending up here, updating their BIOS and thinking the issue is gone and then ending up with the same issue in a couple of months.

tpapp commented 4 years ago

@jerbob92: I just reported some facts, what you consider "misinformation" is subsequent speculation on your part. Whether this issue will resurface is something that I cannot and did not predict — please don't put words in my mouth.

In any case, I don't see why users should not just update their BIOS (when an update is available), see what happens, and then disable the workarounds if they are no longer necessary. If the issue comes back, they should just report back here, I will also do that if necessary.

jerbob92 commented 4 years ago

@tpapp I'm not saying they should not update their BIOS, I'm saying that upgrading your BIOS does not fix this bug, it's just a workaround. This is still an issue report about a bug in the microcode data, not an Ask Ubuntu topic, please keep this on-topic. Reports on workarounds, being a BIOS upgrade or dis_ucode_ldr have been widely reported already and don't add anything to this issue anymore.

Anyway, this discussion also does not add anything to the issue, so I will not reply anymore.

TroyDowling commented 4 years ago

To add my report: I had the same problem with an ASUS UX433FA (i7-8565U) on Arch Linux, but not Windows 10. Updating the BIOS from 301 to 309 resolved the issue. /proc/cpuinfo reports being on microcode 0xb8. (My curiosity makes me wonder if Windows has some special sauce to get around the bug, if it was late-loading the microcode safely, or if it ever loaded it at all...)

svedrenne commented 4 years ago

@mcu-administrator Could you please let us know the actual status of the problem investigation/solving?

jledun commented 4 years ago

I confirm: after BIOS upgrade to 304, no problem anymore, I can update intel-ucode then my laptop boots as usual.

breznak commented 4 years ago

upgrade to 304, no problem anymore, I can update intel-ucode then my laptop boots as usual.

the question asked at the Ubuntu bug is: what happens after another ucode update? Will it again break our notebooks? (unless there's again a new BIOS etc).

So I'd suggest reopening the issue and I wish people from Intel ( @mcu-administrator ?) were more communicative after people here spend time debugging the issue,finding workarounds and answering questions here.

vieirajlt commented 4 years ago

On Asus Zenbook ux461fn (i5-8265U) this also happens, can't even boot. There is no BIOS upgrade (still on 302) so there is no solution.

jsfry commented 4 years ago

Bad news. I can confirm that I have this same problem and I am not running an Asus Zen laptop but an Asus G703GXR with Intel i9-9980HK cpu. So this is affecting more than just the i7 cpus (as vieirjlt confirmed above with his i5-8265U). How widespread is this issue? My story is that after installing samba via the right mouse click on a particular folder in Ubuntu 16.04 I could not boot anymore - it stalled with a message saying something about "loading initial ramdisk". My investigations led me to this page. As soon as I instituted the workaround (dis_ucode_ldr) my laptop booted no problem (at least for now - I will in a minute try to make this workaround permanent). But the question persists to the mcu-administrator - what will happen on the next microcode update? Could you pls inform us of your findings.

My details: intel core i9-9980HK cpu @ 2.40Ghz x 16 intel hd graphics (Coffeelake 3x8 GT2) os 64 bit ubuntu 16.04 lts

PS. I have the latest bios update for my laptop - v.302

esyr-rh commented 4 years ago

intel core i9-9980HK cpu @ 2.40Ghz x 16

May I ask you to provide information from /proc/cpuinfo (specifically, grep -E '^(cpu family|model|stepping|microcode)' /proc/cpuinfo | sort -u)? The previous reports were related to 06-8e-0b CPUs, and this is (presumably) 06-9e-0d.

jsfry commented 4 years ago

esyr-rh here you go:

$ grep -E '^(cpu family|model|stepping|microcode)' /proc/cpuinfo | sort -u cpu family : 6 microcode : 0xb8 model : 158 model name : Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz stepping : 13

my machine: Asus g703gxr

KathyReid commented 4 years ago

I was also experiencing this issue, but an update to BIOS v304 fixed it. Details of CPU and drivers follow for completeness.

kathyreid@kathyreid-zenbook-ux533fd:~$ grep -E '^(cpu family|model|stepping|microcode)' /proc/cpuinfo | sort -u
cpu family  : 6
microcode   : 0xca
model       : 142
model name  : Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz
stepping    : 12
kathyreid@kathyreid-zenbook-ux533fd:~$ uname -a
Linux kathyreid-zenbook-ux533fd 5.3.0-26-generic #28-Ubuntu SMP Wed Dec 18 05:37:46 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

I'd previously held back intel-microcode

kathyreid@kathyreid-zenbook-ux533fd:~$ sudo apt-get install intel-microcode
Reading package lists... Done
Building dependency tree       
Reading state information... Done
intel-microcode is already the newest version (3.20191115.1ubuntu0.19.10.2).
intel-microcode set to manually installed.
0 to upgrade, 0 to newly install, 0 to remove and 0 not to upgrade.

Happy to provide further diagnostics if needed.

Best, Kathy

Edward-Zion-Saji commented 4 years ago

@victormmtorres You can add the dis_ucode_ldr to the startup line when going to Advanced Startup Options and press e on the option you want to use. Then add dis_ucode_ldr to the linux line.

You can also edit /etc/default/grub and add it to GRUB_CMDLINE_LINUX_DEFAULT, then run sudo update-grub for a more permanent fix.

I'm currently on a downgraded version of the microcode, which is the best fix IMHO: sudo apt install intel-microcode=3.20180312.0~ubuntu18.04.1

This doesn't seem to work for me. It freezes at 'Loading initial ramdisk'

tornado80 commented 4 years ago

Since yesterday, technique 'dis_ucode_ldr' is not working anymore after a suspected software install. Normal booting fails at splash screen while recovery mode boot fails and freezes at 'loading initial ramdisk'. System: Asus VivoBook S430FN CPU: Intel i7-8565u OS: Ubuntu 18.04

tornado80 commented 4 years ago

Also it is worthy to mention that two days ago 'Ubuntu software and updates' brought me a new update and I installed it. The "suspected" term comes from here that after update I booted with no problem but after the second boot (occasionally having installed the software) it failed. Also I have not updated my BIOS but using dis_icode_ldr trick always through grub fix.

svedrenne commented 4 years ago

I suspect another issue (not Intel microcode related) is causing you current boot failure.

Try to gather more information (kernel version shown in Grub ?, logs if possible, etc.) in order to qualify your current problem.

Good luck!

tornado80 commented 4 years ago

I suspect another issue (not Intel microcode related) is causing you current boot failure.

Try to gather more information (kernel version shown in Grub ?, logs if possible, etc.) in order to qualify your current problem.

Good luck!

Thanks. By double checking boot logs which failed on Gnome display manager, I found the solution to use "lightdm instead of gdm3. But why did really "gdm3" fail suddenly on Nividia graphics card?

svedrenne commented 4 years ago

Maybe the Nvidia driver was updated as well when you accepted the Ubuntu update. The fragile configuration for the Nvidia card got broken in the process and needs urgent fine tuning (select the correct driver, etc.).

These Nvidia graphics cards are the cause of many problems. Personnaly I did: $ sudo prime-select intel in order to never use it. (I would have selected a laptop without an Nvidia card if I ever had the choice). This solution is Ok only if, like me, you actually don't need the Nvidia graphics card.

ramayer commented 4 years ago

Same problem on a

Asus Q504U Ubuntu 18.04

My workaround is to boot the 4.13.0-37 kernel (which works fine). The 4.15.0-101 and 4.15.0-106 kernels both fail for me.

block6791 commented 4 years ago

Surely there is a guide to install dis_ucode_ldr could anybody give me a reference about how to do it?

cc @jerbob92 @breznak

If you are on Pop_OS! (Systemd), then press e at boot time to add dis_ucode_ldr to the systemd options. If that works, you can make the changes permanent by editing Pop_OS-current.conf in /boot/efi/loader/entries.

rhiaro commented 3 years ago

Adding my report. I'm using Asus Zenbook UX433FA with i5-8265U, running Ubuntu 18.04. BIOS version is 300. I have had this problem intermittently for a year (usually boots after 3 or 4 attempts), but with a recent kernel update to 5.4.0-51 I can't boot at all (stuck on "Loading initial RAMdisk").

svedrenne commented 3 years ago

Hi rhiaro, You need to look at the kernel boot logs. Maybe this is another issue that you might solve easily by looking at the logs. Cheers

block6791 commented 3 years ago

That error message, "Loading initial RAMdisk", can also be caused by having Secure Boot enabled. Check this setting in your BIOS. Should be somewhere in either the Boot or Security settings.