Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(WIP) (KGPE-D16) Bump to Linux 5.4.69 #946

Closed
wants to merge 2 commits into from

Conversation

Tonux599
Copy link
Contributor

@Tonux599 Tonux599 commented Jan 1, 2021

Note: Not currently functioning as intended

This bumps Linux to 5.4.69 for the KGPE-D16 which should generally bring better graphics support.

However there appears to be an issue in that when coreboot loads the latest fam15 microcode, Linux panics. The symptoms are outlined here also: https://lkml.org/lkml/2019/1/3/540 and after a brief discussion with @paulmenzel the possible solutions appear to be:

  1. Ensure that the user has both types of coloured memory slots populated. I prefer to avoid this as it alienates users
  2. Somehow pin an older, working microcode update to be include in the CBFS. Users can then have newer microcode loaded by Linux later if desired.
  3. Include no microcode in the CBFS. My concern with this is if the users would have enough stability in the heads environment given that 6300 series CPUs have buggy microcode built-in
  4. Include the microcode update in initramfs and be loaded by Linux.
  5. Reach out to developers on mailing lists to see why when identical microcode is loaded by coreboot, kernel panic occurs as opposed to when it is loaded by Linux and if there is any resolution to this. (@miczyg1 @pietrushnic ?)

@Tonux599
Copy link
Contributor Author

Tonux599 commented Jan 5, 2021

Currently modelling option 4. Messy as hell. Haven't tested yet. If builds and runs consider POC. Personal preferred option is 5.

@Tonux599
Copy link
Contributor Author

Tonux599 commented Jan 5, 2021

So upon reading more it seems like option 3 might be best. It looks like the 6300 series instability stems from issues with virtualisation, so 6300 series should be okay in Heads. And users can load microcode from their operating system if they require it (Qubes does this by default so shouldn't be a problem there).

As a result I think I'll focus on option 3. However KGPE-D16 users/owners please give your opinion also!
@tlaurion @zifxify @blobless @0rb677

@tlaurion
Copy link
Collaborator

tlaurion commented Jan 5, 2021

Needs #954 related changes

@Tonux599
Copy link
Contributor Author

Tonux599 commented Jan 5, 2021

Needs #954 related changes

@tlaurion I wouldn't bother doing it immediately, when #954 is merged I can rebase which will implement it anyway. Lemme know your opinion of the OP and post above!

@tlaurion
Copy link
Collaborator

tlaurion commented Jan 6, 2021

@Tonux599 Agreed with option #3. Needs rebase.
Please point to testing roms directly so users can test. (Using CI builds roms are not an habit as of now for testers it seems. Should document...)

@tlaurion
Copy link
Collaborator

tlaurion commented Jan 6, 2021

@Tonux599 If I understand correctly, this PR will change removing ucode state in Makefile and basically upgrade kernel.
If that is, then I would select the latest LTS version including upgraded graphical support. This is basically it under Heads. Not really a threat vector per se to use older kernel (single user mode, no interaction other then planned code path, no input validation... limited risks), since going into recovery console should not be trusted and should invalidate measurements (Disk Unlock Key released by TPM for the win, typed by BMC or on local PS/2 keyboard for better security, where USB keyboard users should be aware of added risk in using their flashy usb backlit keyboards vs a plain PS/2 one...)

@tlaurion
Copy link
Collaborator

tlaurion commented Jan 6, 2021

@Tonux599 : maybe adding a note in the board configs about microcode upgrade being left ot the responsibility of the OS?

…for 5.4.69 with savedefconfig. HW_RANDOM_TPM may have been deprecated so not selected.
…This disables microcode being included and loaded by Coreboot because of a current issue in which newer kernels panic when doing so.

Added note to KGPE-D16 configs about the current microcode bug, why microcode is not included and encouraging AMD Opteron 6300 series users to make sure their operating system loads microcode.
@Tonux599
Copy link
Contributor Author

Tonux599 commented Jan 6, 2021

Needs #954 related changes

Rebased and done.

@Tonux599 : maybe adding a note in the board configs about microcode upgrade being left ot the responsibility of the OS?

Done.

So now modelling option 3, build is happening and will point to test roms soon.

@Tonux599
Copy link
Contributor Author

Tonux599 commented Jan 7, 2021

Superseded by #957

@Tonux599 Tonux599 closed this Jan 7, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants