Dell Latitude 7300/7400, i7-8665U/i5-8265U, sig=0x806eb/20200609, sometimes stuck at purple screen after grub and fails to boot up

Reproduce this issue on 4.15.0-1079-oem kernel and also on 4.15.0-101 Ubuntu kernel.

Reproduce this issue on 4.15.0-20-generic kernel.

It's a grub issue.
After downgraded grub(2.02-2ubuntu8.15 -> 2.02-2ubuntu8) and shim(15+1533136590.3beb971-0ubuntu1 -> 13-0ubuntu2), can't reproduce this issue
   4.15.0-1081-oem (0/10)

1. sudo apt update
2. sudo apt upgrade # to revert all what downgraded packages
3. do reboot test(battery mode) (3/10)
   failed at 2nd, 7th, 9th trial (4.15.0-1081-oem)
4. do reboot test, again(ac mode) (4/10)
   failed at 2nd, 4th, 7th, 10th trial (4.15.0-1081-oem)
5. sudo apt install shim=13-0ubuntu2 shim-signed=1.34.9+13-0ubuntu2 # downgrade shim only
6. do reboot test(battery mode (1/10)
   failed at 10th trial
7. do reboot test(ac mode) (6/10)
   failed at 1st, 3rd, 4th, 5th, 8th, 9th trial
8. do reboot test, again(battery mode) (6/20) (because it fails to boot up at 11th and 12th, I do 10 more reboot tests. BTW, it fails to boot up at 21st trial.)
   failed at 10th, 11th, 12th, 15th, 17th, 20th trial
It looks like downgrade shim doesn't help.

9. sudo apt install grub-common=2.02-2ubuntu8 grub-efi-amd64=2.02-2ubuntu8 grub-efi-amd64-bin=2.02-2ubuntu8 grub2-common=2.02-2ubuntu8 grub-efi-amd64-signed=1.93+2.02-2ubuntu8
10. do reboot test(battery mode) (3/10)
   failed at 3rd, 6th, 9th trial
11. do reboot test(ac mode) (2/10)
   failed at 2nd, 8th trial
Downgrade both grub and shim do not work.

12. disable TPM in BIOS(secure boot is off already)
13. do reboot test (4/10)
   failed at 3rd, 7th, 9th, 10th

Final grub output with
set debug=all

After restore OS to factory state(kernel 4.15.0-1037-oem, gub2 2.02-2ubuntu8.12), tested with more that 30 times, it worked fine.

Update grub2 to latest one (2.02-2ubuntu8.15), keep kernel version(4.15.0-1037-oem) and test more that 10 times, it worked fine.

Update kernel to 4.15.1081-oem with "apt upgrade" and it got fail to reboot.

From above testings, I think we should bisect kernel to see which kernel patch cause the issue.

Readding linux-oem

After restore OS to factory state and directly update to latest kernel with "apt install linux-oem", it will not hang. It seems not the kernel issue. May upgrade certain package that cause the issue.

After restore OS to factory state and directly update intel-microcode by "apt install intel-microcode", then will meet this issue.

this should be the intel-microcode issue.
the info of intel-microcode,
before update,
[ 1.131499] microcode: sig=0x806eb, pf=0x80, revision=0xc6
[ 1.132064] microcode: Microcode Update Driver: v2.2.
after update
[ 0.000000] microcode: microcode updated early to revision 0xd6, date = 2020-04-27
[ 1.156375] microcode: sig=0x806eb, pf=0x80, revision=0xd6
[ 1.156916] microcode: Microcode Update Driver: v2.2.

lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Thread(s) per core: 2
Core(s) per socket: 4
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 142
Model name: Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz
Stepping: 11
CPU MHz: 989.418
CPU max MHz: 3900.0000
CPU min MHz: 400.0000
BogoMIPS: 3600.00
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 6144K
NUMA node0 CPU(s): 0-7
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 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

sig=0x806eb, revision=0xc6 was released in 20191112, and revision=0xd6 is in 20200609 release. There was also an rev 0x00ca on 20191115.

https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/33

Status changed to 'Confirmed' because the bug affects multiple users.

Acelan, did this system also fail with the 20191115 microcode, revision 0x00ca?

I have a Inspiron-7380 with i5-8265U with the same cpu signature. Microcode 0x806eb revision 0xca doesn't hang system at boot.

$ lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Thread(s) per core: 2
Core(s) per socket: 4
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 142
Model name: Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz
Stepping: 11
CPU MHz: 900.340
CPU max MHz: 3900.0000
CPU min MHz: 400.0000
BogoMIPS: 3600.00
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 6144K
NUMA node0 CPU(s): 0-7
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 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 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 md_clear flush_l1d arch_capabilities

$ dmesg | grep microcode
Inspiron-7380 kernel: microcode: microcode updated early to revision 0xca, date = 2019-10-03
Inspiron-7380 kernel: microcode: sig=0x806eb, pf=0x80, revision=0xca

@vicamo

It seems the issue was reproduced with grub2 2.02-2ubuntu 8.15 + 4.15.0-1030-oem/4.15.0-1080-oem/4.15.0-1081-oem. Could you confirm that the tests done in comment #18 is using the same version of the kernel and grub?

While that was not meant for me, I can confirm that the issue happened to me with this configuration.
grub2 2.02-2ubuntu 8.15 is still there, and
http://paste.ubuntu.com/p/9GqBwtW7sd/

lists the mentioned kernels when I reported the issue on the Ubuntu forums:
https://ubuntuforums.org/showthread.php?t=2443622

Are there any news on this issue? While I don't fully understand all the contributions, it looks to me that:
* the issue is confirmed;
* its not clear whether it is a grub or a kernel issue;
* nobody found a solution so far.

From my point of view things have gotten worse. Also with Ubuntu 20.04 LTS the problem appears more often now. I think now especially with the jump to kernel 5.8. basically, I am afraid of updating my kernel and I am afraid of a reboot since I don't know when and if I will come back.