The Latest Kernel Release.

Originally Posted by Spidergawd And here I thought it was 5.10 that was LTS, but now I see it's merely "stable".

Maybe the 5.10 kernel will be an STS (Short-Term Support) and we get rid of it faster!

Year 2021, Round 16.

Another batch of updates has been scheduled for release on Wednesday, 3 March 2021, at approximately 16:00, GMT. If no problems are found while testing the release candidates, they might be available sometime on Tuesday (depending on your time zone).

The details,

5.11.3-rc1, with 775 patches, http://lkml.iu.edu/hypermail/linux/k...3.0/02389.html

5.10.20-rc1, with 663 patches, http://lkml.iu.edu/hypermail/linux/k...3.0/02239.html

5.4.102-rc1, with 340 patches, http://lkml.iu.edu/hypermail/linux/k...3.0/01469.html

4.19.178-rc1, with 247 patches, http://lkml.iu.edu/hypermail/linux/k...3.0/01172.html

4.14.223-rc1, with 176 patches, http://lkml.iu.edu/hypermail/linux/k...3.0/00991.html

4.9.259-rc1, with 134 patches, http://lkml.iu.edu/hypermail/linux/k...3.0/00833.html

4.4.259-rc1, with 93 patches, http://lkml.iu.edu/hypermail/linux/k...3.0/00756.html

Additional testing is needed.


5.11.3-rc2, with 774 patches, http://lkml.iu.edu/hypermail/linux/k...3.0/03360.html

5.10.20-rc3, with 658 patches, http://lkml.iu.edu/hypermail/linux/k...3.0/04408.html

5.4.102-rc4, with 338 patches, http://lkml.iu.edu/hypermail/linux/k...3.0/04407.html

4.19.178-rc3, with 247 patches, http://lkml.iu.edu/hypermail/linux/k...3.0/04371.html

4.14.223-rc3, with 176 patches, http://lkml.iu.edu/hypermail/linux/k...3.0/04367.html

4.9.259-rc2, with 135 patches, http://lkml.iu.edu/hypermail/linux/k...3.0/04370.html

And, again. I guess this is to be expected when making so many changes.
They are now scheduled to be released on Thursday.

5.11.3-rc3, with 773 patches, http://lkml.iu.edu/hypermail/linux/k...3.0/05024.html

5.10.20-rc4, with 657 patches, http://lkml.iu.edu/hypermail/linux/k...3.0/05022.html

5.4.102-rc5, with 337 patches, http://lkml.iu.edu/hypermail/linux/k...3.0/05026.html

4.19.178-rc4, with 246 patches, http://lkml.iu.edu/hypermail/linux/k...3.0/04992.html

4.14.223-rc4, with 175 patches, http://lkml.iu.edu/hypermail/linux/k...3.0/05008.html

4.9.259-rc3, with 134 patches, http://lkml.iu.edu/hypermail/linux/k...3.0/05009.html

4.4.259-rc2, with 92 patches, http://lkml.iu.edu/hypermail/linux/k...3.0/05007.html

More on the data corruption problem with the 5.12 kernel.

That Linux 5.12 Severe Data Corruption Bug Hits Intel CI Systems - Issue Caused By Swap File Written by Michael Larabel in Linux Kernel on 2 March 2021 at 01:43 PM EST. Last week I issued a warning of possible data loss on the early Linux 5.12 kernel code that was reliably leaving my test systems severely corrupted. Intel's internal graphics test systems it turns out have now been bitten by this issue in encountering this significant file-system corruption and as such they've been quick to jump on the issue - there's now an idea what's causing the nasty issue and a workaround by reverting select patches. As reported last week, on my test systems with the Linux 5.12 kernel I have been suffering from significant data corruption during benchmarking. Running e2fsck on the EXT4 file-systems would yield a plethora of errors and ultimately not recoverable. Besides the fact of having to either recover from a backup image or reinstall from scratch each time, making it more complex was seeing this behavior even before EXT4 file-system changes were merged for the 5.12 cycle and they tended to be on the mundane side anyhow -- likely indicating a problem elsewhere in the kernel and not something specific to EXT4, just that many of my test systems are using EXT4..........

The full story is here, https://www.phoronix.com/scan.php?pa...apfile-Corrupt

Yet, again, the "Linux-Kernel Archive By Thread" message board hasn't been updated in over 9 hours, so we are flying in thick fog at the moment.
Considering the problems with the 5.10 and 5.12 kernels, I starting to wonder who is watching the store?

5.11 is running ok here, no problems.
I replaced the stock kernel in slackpkgplus.conf packages priority array with 'testing:kernel'.

Originally Posted by cwizardone Yet, again, the "Linux-Kernel Archive By Thread" message board hasn't been updated in over 9 hours, so we are flying in thick fog at the moment. Considering the problems with the 5.10 and 5.12 kernels, I starting to wonder who is watching the store?

More testing as far as I can see:
5.10.20-rc4
https://mirrors.edge.kernel.org/pub/...5.10.20-rc4.xz
5.4.102-rc5
https://mirrors.edge.kernel.org/pub/...5.4.102-rc5.gz

A patch for the 5.12 problem.

Linux 5.12 Lands Fix For File-System Corruption Caused By Swapfile Issue Written by Michael Larabel in Linux Kernel on 3 March 2021 at 06:20 AM EST. For those wanting to help in testing out the Linux 5.12 kernel, at least it should no longer eat your data now if you rely on a swapfile. The file-system corruption issue on Linux 5.12 Git noted last week and then followed up on yesterday when the corruption hit Intel's graphics CI systems and narrowed down to a set of swap-related changes, has now been resolved with today's latest Git code. The fix isn't simply reverting the set of memory management patches talked about yesterday but fortunately a new patch was brewed that properly addresses the problem. Linux block maintainer and storage expert Jens Axboe was able to come up with a fix and got it punctually merged into the mainline tree. The fix is about properly handling the swapfile read/write offset. Axboe noted in the patch, "We're not factoring in the start of the file for where to write and read the swapfile, which leads to very unfortunate side effects of writing where we should not be..." In other words, clobbering the underlying file-system where the system's swapfile is placed. With that fix now in, we can get back to looking at Linux 5.12 performance changes and other more interesting testing than worrying about data loss.

https://www.phoronix.com/scan.php?pa...rruption-Fixed

The patch, https://git.kernel.org/pub/scm/linux...a2008f81b93f14

Within the last twenty minutes or so the "Linux-Kernel Archive By Thread" message board came back to life.
The last post yesterday was at 18:41 EST (U.S.) and the first post this morning is time stamped
05:40 EST.

Kernel updates 4.14.223, 4.9.259 and 4.4.259 are now available at,
https://www.kernel.org/

The change logs,

https://cdn.kernel.org/pub/linux/ker...geLog-4.14.223

https://cdn.kernel.org/pub/linux/ker...ngeLog-4.9.259

https://cdn.kernel.org/pub/linux/ker...ngeLog-4.4.259

Originally Posted by cwizardone Yet, again, the "Linux-Kernel Archive By Thread" message board hasn't been updated in over 9 hours, so we are flying in thick fog at the moment. Considering the problems with the 5.10 and 5.12 kernels, I starting to wonder who is watching the store?

Lunduke was right we're clearly past the point of maintainability with the kernel, and continue to move forth.

It would be much more practical to keep fewer branches and more eyes (and for longer) peeled at each.

Just my 2c.

Running 5.12-rc1: so far, so good.

More on the 5.12 kernel file corruption problem.
If you use a swap file instead of a swap partition do NOT use 5.12-rc1.

Excuses are like.......

.....The bad news is that the reason we support swapfiles in the first place is that they do end up having some flexibility advantages, and so some people do use them for that reason. If so, do not use rc1. Thus the renaming of the tag........

Mr. Torvalds' full explanation can be found here, http://lkml.iu.edu/hypermail/linux/k...3.0/06524.html

What?
They're going to fix this, right?
Sorry I'm not asking at you just... wtf