I was thinking about 6.0.1 while I wait for 6.1 (probably LTS) and to get used to the 6.
It will come soon anyway.

Oh, I see why I feel no speed differences. Because I use that patch since it was published.

As I am just a regular user, I am NOT in a position of demanding something from Slackware. As anyone else just I make requests and I argument them.

HOWEVER, I will never disable Secure Boot, messing with the Windows security, just for sake of Slackware or anything else. I will always use the Windows as Microsoft recommends and Slackware as our BDFL recommends. BUT, if there will be an conflict of requirements, no offense intended, but Windows will prevail for me, because I use it for work.

So, let's be proud that Slackware does NOT work under Secure Boot!

I for one just I do not use it in dual boot with Windows, because the hardware is not supported by Slackware. That's all.

The patch is suppose to result in noticeable improved performance. I have yet to read it is associated with any AMD graphic problems.
And, -current will use the 6.1 kernel when it is released, but then move on to 6.2 when it becomes available, or, at least, that has been the pattern in the past.

2 members found this post helpful.

I never said that the patch affects video. What I said is that it fixes AMD ACPI performance in 6 but 6 also introduces issues with AMD video as reported by @marav. These are not related but at this point you will get better performance (patch) and AMD video issues caused by unrelated bug introduced in 6.
Improvement in 6 AMD performance was tested with Tbench which is server test (unless you run 500k simultaneous connections on desktop). Whether you see improvement or not, it depends on subjective "feeling". As not desktop bench tests were run to prove othervise it looks like unless heavy I/O takes place, you just get an impression caused by the announcement about performance correction.

1 members found this post helpful.

Year 2022, Round 61.

Another batch of updates has been scheduled for release on Saturday, 15 October 2022, at approximately 17:00 GMT. If no problems are found while testing the release candidates, they might be available sometime on Friday (depending on your time zone).

The details:

6.0.2-rc1, with 34 patches, https://lkml.iu.edu/hypermail/linux/...0.1/05940.html

5.19.16-rc1, with 33 patches, https://lkml.iu.edu/hypermail/linux/...0.1/06040.html

5.15.74-rc1, with 27 patches, https://lkml.iu.edu/hypermail/linux/...0.1/05922.html

5.10.148-rc1, with 54 patches, https://lkml.iu.edu/hypermail/linux/...0.1/05797.html

5.4.218-rc1, with 38 patches, https://lkml.iu.edu/hypermail/linux/...0.1/05757.html

3 members found this post helpful.

It appears these patches are included in the kernel updates scheduled for release on Saturday (see post #4820, above).
The full story can be found here, https://www.phoronix.com/news/Linux-...icious-Packets

2 members found this post helpful.

The bisect is in progress
https://gitlab.freedesktop.org/drm/amd/-/issues/2164

But the merge which contains the culprit is about 1000 commits ... this won't be easy

1 members found this post helpful.

Don't care about Windows security but there are options that let one keep Secure boot for windows and disable it for other OSes.
I think that pseudo security introduced by MS is in fact worse that lack of secure boot because users may really think that secure boot does provide a level of protection while in fact it does not because secure boot was broken from the beginning and still is.

As I said the fix is quite easy (well your hardware may be a limitation) so one can keep OS with secure boot and without secure boot in parallel.

It is funny though that you are projecting your problems on Slackware or whatever OS not supporting Secure boot.

Note:
As far as I remember, your hardware has crippled BIOS i.e. you can't turn off secure boot, so this seems to be a real reason why you are so vocal about secure boot: not because it is secure but because you can't switch it off

1 members found this post helpful.

A second release candidate for the 5.15.74 update has been made available for testing.

5.15.74-rc2, with 33 patches, https://lkml.iu.edu/hypermail/linux/...0.1/06623.html

2 members found this post helpful.

Yep
Because of these CVEs:
https://www.linuxquestions.org/quest...8/#post6386283

2 members found this post helpful.

But, I DO care.

Yeah, yeah, entering in BIOS and disabling it, when booting Slackware, enabling it when booting Windows?

You are joking, right? What happened with "keep it simple, stupid" ? OR, in the name of KISS you propose to use complicated methods to change the hardware settings?

Did you know what people says about Slackware? That it do simple things in complicated ways. Your suggestion is yet another proof of it.

You think, me seen with my own eyes. Because I had 3 times huge problems with ransomware, which happened to be smart enough to infect also the EFI binaries from ESP partition. I wasted time and money because I was stupid enough to NOT enable the Secure Boot on those particular Windows computers. BUT, I learned my lesson thoughtfully.

So, nope. Thanks, but I do not believe your propaganda. Trust me, I seen propagandists better than you. Much better.

Sorry, but I have no patience (or will) to walk in hands. Specially when I do not need this.

Let me explain again, even I said several times on this forum. I have no hidden agenda on advocating the support for Secure Boot.

Yes, today I have 3 laptops which has no support for disabling the Secure Boot, BUT also I have no intention to disable it. And if I count, my family (me, my wife and 3 kids) owns today a count of 25 computers, of various types.

My wife and the kids have each one one desktop and a laptop. Myself, I have a main desktop, a secondary desktop, a laptop and the rest of computers are on one of my garages, which I transformed in something like a laboratory. Supplementary, I have another 4 or 5 kits of motherboard, CPU and memories, which can be mounted in a case anytime.

So, I have many enough computers to sleep well even Slackware does not boot on those which are Secure Boot only. True, many of them are old hardware, which the neighbors given me as gift, when they moved to more modern hardware. Myself also, some of those computers, after repairing, I make them gift to others.

As bottom line, as user of Slackware, I did my duty to warn that there are computers where Slackware does NOT work, because of lack of support for Secure Boot. Yes, I did this for the greater good. I for one, if I need Linux in a computer with Secure Boot enabled, until Slackware support it, I will just install another distribution. All other major Linux distros support it, no problems there to find one which I like.

So, let's be proud that Slackware does NOT work under Secure Boot! In the end, is not my business that people can't use Slackware even they want...

1 members found this post helpful.

IIRC in the past there was a way to simply start windows without secure boot I think it was called easyBCD or something similar.
There's also a way to flash a different BIOS, in case your BIOS is really locked to that point.
Could be the menu items for legacy boot are hidden under disabled csm submenu, maybe you just never enabled the top menu so you missed them?
And it'd probably not be called 'secure boot' if it was secure, you just assume it's secure because of the name. But I guess it's nothing to do with the kernel or this thread.

Oh! Secure is great... https://www.theregister.com/2022/10/...are_kaspersky/

1 members found this post helpful.

There's an article on lwn: Some remotely exploitable kernel WiFi vulnerabilities with a link to the kernel-dev discussion from SUSe at [oss-security] Various Linux Kernel WLAN security issues (RCE/DOS) found.

As marav requested, maybe it's time again to upgrade the kernel in 15.0, depending on how 5.15.74 works out and definitely with 5.15.75 ( after all the bugs in the bug fixes are fixed )

Thanks for the info !

-- kjh

1 members found this post helpful.

Nope, they have no way to disable the Secure Boot, and this is not a big issue, because those laptops are used by my sons, mainly for school. Additionally, with sadness I have to confess that only my elder son seems interested about Open Source - however, he prefers OpenSuSE, which works well anyway with Secure Boot.

Paraphrasing a famous saying: NOTABUG for me.

Believe or not, I know exactly what Secure Boot do. It's just a checking of the cryptographic hashes of the EFI binaries, accepting to execute or load only the ones with valid and known signatures.

The idea is that UEFI with Secure Boot executes only known EFI binaries, the rest is propaganda.

Also, it wasn't invented by Microsoft - as the Prophets of Doom ventilates here, but by Intel and its pals from Unified EFI Forum and it's not particularly necessarily to use keys signed by Microsoft.

As well, the Slackware Team can make a hypothetical contract with a Dell or HP, and they to sell computers with Slackware preinstalled, which uses a particular Secure Boot key managed by our BDFL.

I agree.

Thanks for confirming what I said - that there exists dangerous malware capable to infect the EFI binaries from the ESP partition. And the single way to stop them working is to check the hashes of EFI binaries in some way, just like we do with the Slackware packages using their .md5 files. This is what Secure Boot do.

I think that many does not realize that the .efi files from the ESP partition are in fact extensions of UEFI firmware, and they can even emulate hardware likes keyloggers or even remote management. Or transparent disk or files encryption, how the ransomware do.

OR, they can be used for begin purposes, like implementing a software TPM 2.0 like I seen discussions in another places. How the Windows 11 is more and more used, seems like there are people who thinks about extending UEFI when it's need with a TPM 2.0 made in a EFI software, not much different of how some firmwares do anyway.

1 members found this post helpful.