# Kernel 5.10.37 doesnt boot

## pietinger

Today I tried 5.10.37 coming from 5.10.36 (with "make oldconfig") on a Gigabyte Z270X-K5. It compiled with no errors or warnings.

Before I had an Update of the Intel Microcode also (I have intel-ucode/06-5e-03). So it is also possible this is the reason.

Anybody else with this problem ?

P.S.: It is a stub kernel which will be loaded from UEFI directly. No errors or screen output; only black screen and BIOS trying to load again.

----------

## CaptainBlood

Fails to boot here, as non UEFI.

µcode updated here, not causing any issue with 5.12.4.

Didn't fallback to previous firmware yet.

Thks 4 ur attention, interest & support.

----------

## CaptainBlood

firmware fallback didn't help.

Thks 4 spotting it out.

```
gcc-11 installed versions:  5.10.37(5.10.37)^bs(12:37:13 15/05/2021)(experimental -build -symlink)

```

Thks 4 ur attention, interest & support.

----------

## pietinger

 *CaptainBlood wrote:*   

> µcode updated here, not causing any issue with 5.12.4.

 

Thank you very much for your feedback. So, I dont need to test the new microcode with 5.10.36

I looked into https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?h=linux-5.10.y

Such a huge amount of patches in one minor version I only saw a long time before ...

----------

## web.user

See https://forums.gentoo.org/viewtopic-t-1135239.html

That person has same problem as you if I understand correctly

----------

## Goverp

This will be of neither use nor comfort, but that's why I settled on installing grub as my boot manager, and having a suitable grub.conf to select new, current and old kernels.

The trouble with the EFI stub is that it tells BIOS (or rather EFI) that your linux kernel is a bootloader, but that's really a lie - it's just a kernel that implements the EFI bootloader ABI.  It's great until it breaks  :Sad:  .

----------

## Tony0945

Easy to switch kernels with sys-boot/refind using keyboard

----------

## CaptainBlood

It would be nice if buddies with easy kernel switch capabilities could effectivly test 5.10.37 bootability.

Thks 4 ur attention, interest & support.

----------

## Tony0945

 *CaptainBlood wrote:*   

> It would be nice if buddies with easy kernel switch capabilities could effectivly test 5.10.37 bootability.
> 
> 

 

I would but I don't want to unmask gcc and glibc and I'm running all AMD systems anyway so I can't test 5the microcode.

I think the microcode is the problem. Sometimes you get a bad BIOS. Sometimes you get bad microcode.

----------

## CaptainBlood

 *Tony0945 wrote:*   

> I think the microcode is the problem.

 Both former and updated intel µcode failed to boot 5.10.37.

5.10.36 boots fine here.

gcc-11 isn't required. OP doesn't say anything about it.

Thks 4 ur attention, interest & support.

----------

## Tony0945

Updating portage to get 5.10.37

First I have 218 updates to build. i notice that they are amending ebuilds without revbump. Example: guchar unconditionally requires vala even if -vala flag is set. if a flag dopes nothing, why have it? and why not revbump the ebuild?

When I'm all through, I can report if 5.10.37 boots on ryzen. I still don't think that it proves anything for intel, but it's a data point.

Still encourage OP to install refind instead of stub kernel. For one thing when you build a new kernel it becomes default without any extra commands.

----------

## pietinger

 *Goverp wrote:*   

> This will be of neither use nor comfort, but that's why I settled on installing grub as my boot manager, and having a suitable grub.conf to select new, current and old kernels.

 

Maybe I wasnt exact when writing my first post. I have no problem with going back to 5.10.36 because I have two other entries in my UEFI: One is my old grub2, the other is a stub kernel with a command line doing no IMA (ima_appraise=fix). So I have no problems when a new kernel has problems - I can go back immediately.

My real intention was only to see if it is a very special problem only I have (because I have e.g.: SecureBoot and IMA), or if there are more users concerned - and if yes it should/could be a little warning. So please let me apologize if I was not concrete.

----------

## Tony0945

Updated 217 packages (ugh another python change), keyworded gentoo-sources-5.10.27 and built it. Interestingly, the only config change was breaking GCC-NATIVE into two listings, one for Intel and one for AMD (why? gcc can determine amd or intel!).

Will test tomorrow

EDIT"

Wait a minute! You are taling about 5.10.37 but only up to 5.10.32 is in the tree! As of this afternoon.

EDIT2:

Forget it. i was looking at the wrong machine. on the right machine:

```
MSI ~ # ls -ltr /boot/vml*

-rw-r--r-- 1 root root 5517968 Mar 25  2020 /boot/vmlinuz-4.17.19-gentoo.old

-rw-r--r-- 1 root root 8364784 Aug 24  2020 /boot/vmlinuz-4.17.19-gentoo

-rw-r--r-- 1 root root 5579328 Aug 26  2020 /boot/vmlinuz-4.14.194-gentoo

-rw-r--r-- 1 root root 5669536 Aug 26  2020 /boot/vmlinuz-4.19.141-gentoo

-rw-r--r-- 1 root root 8610976 Oct 27  2020 /boot/vmlinuz-5.4.72-gentoo.old

-rw-r--r-- 1 root root 8610976 Jan  8 14:04 /boot/vmlinuz-5.4.72-gentoo

-rw-r--r-- 1 root root 8619168 Feb  7 10:39 /boot/vmlinuz-5.4.92-gentoo

-rw-r--r-- 1 root root 8623200 Mar 25 21:35 /boot/vmlinuz-5.4.97-gentoo.old

-rw-r--r-- 1 root root 8627296 Apr  3 11:43 /boot/vmlinuz-5.4.97-gentoo

-rw-r--r-- 1 root root 8727168 Apr 28 18:36 /boot/vmlinuz-5.10.27-gentoo.old

-rw-r--r-- 1 root root 8727104 Apr 30 09:04 /boot/vmlinuz-5.10.27-gentoo

-rw-r--r-- 1 root root 8727328 May 15 21:14 /boot/vmlinuz-5.10.37-gentoo

```

  Not going to test until I have a night's sleep!

----------

## Tony0945

```
tony@MSI ~ $ uname -a

Linux MSI 5.10.37-gentoo #1 SMP Sat May 15 21:11:36 CDT 2021 x86_64 AMD Ryzen 7 2700X Eight-Core Processor AuthenticAMD GNU/Linux

```

No problem at all booting.  I still think it's an Intel microcode issue.

Here's my config ...  Oops. wgetpaste stopped working!

https://dpaste.com/3KFPJC5LK

Problem was latest "stable" wgetpaste. I re-emerged the previous version and it works. Masking latest stable.

----------

## CaptainBlood

Finally got it working as in:

```
uname -r

5.10.37-gentoo-try

make mrproper

make x86_64_defconfig

make
```

which I should have tried in the first place.

gcc-11 + latest intel µcode here.

Thks 4 ur attention, interest & support.

----------

## pietinger

 *CaptainBlood wrote:*   

> gcc-11 + latest intel µcode here.

 

Thanks again. Yes, I forgot to mention gcc; I have gcc 10.2.0-r5 (actual stable).

----------

## Tony0945

Ah? I used gcc-9.3

Reading lots of problems with 11 on the forum.

----------

## CaptainBlood

```
diff /usr/src/linux-5.10.36-gentoo-classic/.config  /usr/src/linux-5.10.37-gentoo-classic/.config 

3c3

< # Linux/x86 5.10.36-gentoo-classic Kernel Configuration

---

> # Linux/x86 5.10.37-gentoo-classic Kernel Configuration

3389c3389

< CONFIG_INTEL_IOMMU_DEFAULT_ON=y

---

> # CONFIG_INTEL_IOMMU_DEFAULT_ON is not set
```

seems to be the culprit here.

Context:

```
[    0.313747] DMAR: [Firmware Bug]: No firmware reserved region can cover this RMRR [0x0000000088800000-0x000000008affffff], contact BIOS vendor for fixes

[    0.313750] DMAR: [Firmware Bug]: Your BIOS is broken; bad RMRR [0x0000000088800000-0x000000008affffff]

               BIOS vendor: American Megatrends Inc.; Ver: R01-A2
```

persistently reported here, whatever kernel major version.

Could be the source of the issue when activating INTEL_IOMMU.

Kernel command line activation untested here yet.

Will see if issue keeps raising for forthcoming version.

Thks 4 ur attention, interest & support.

----------

## CaptainBlood

 *CaptainBlood wrote:*   

> 
> 
> Will see if issue keeps raising for forthcoming version.

 5.10.38 seems to revert some former commits...

Wait & see...

Thks 4 ur attention, interest & support.

----------

## Zucca

Thanks for the heads up guys. I'll refrain from updating my intel laptop's kernel then.

On my old AMD desktop (FX-8350) 5.10 was unusable (wayland crashes).

I'm starting to dislike 5.10 -series...

----------

## pietinger

 *CaptainBlood wrote:*   

> 5.10.38 seems to revert some former commits...
> 
> Wait & see...

 

I have just looked into the content of 5.10.38. Not quite as huge as 37 but also very many patches. I will it test as soon as possible.

@ Zucca: For me I had no problems with 5.10 (I had almost every minor version of it)   :Smile: 

----------

## Zucca

 *pietinger wrote:*   

> Zucca: For me I had no problems with 5.10 (I had almost every minor version of it)  

 What's your CPU and GPU?

I have a hunch which tell me that the problems are because of certain hardware combinations.   :Sad: 

----------

## pietinger

 *Zucca wrote:*   

> What's your CPU and GPU?

 

I have an Intel i7-6700 and using it also as gpu (no extra graphics card) on a Gigabyte Z270X-K5 with 16 GB RAM. At the moment I am on 5.10.36 as a monolithic signed stub kernel (doing SecureBoot). I am using IMA and AppArmor as security solutions.

----------

## Zucca

Yup. I suspect its either  my GPU, R9 Nano, or the CPU FX-8350.

Gotta suffer with that old CPU until chip makers' supply chain starts working again.

As for intel side of things - I'll wait and see how people manage with later updates to 5.10...

----------

## pietinger

I have just booted Kernel 5.10.38 without any problem.

A diff of "dmesg -t" from 5.10.36 and this one showed me:

1. I have a new microcode; from old "e2" switched now to "ea" (2021-01-25). (This was the microcode update between 5.10.36 and ..37). So, I know the microcde was NOT the problem.

2. I have one new log-entry:

 *Quote:*   

> IP idents hash table entries: 262144 (order: 9, 2097152 bytes, linear)

 

My suspicion is there was a problem with IOMMU in 5.10.37 ... because I saw two reverts in 5.10.38 ... but I dont know.

----------

## CaptainBlood

```
CONFIG_INTEL_IOMMU_DEFAULT_ON=y
```

working fine with 5.10.38 here.

Thks 4 ur attention, interest & support.

----------

## Zucca

So maybe I should mask 5.10.37...

----------

