The Latest Kernel Release.

Aeterna · 12-19-2023, 05:54 PM

Quote:

Originally Posted by rogan

I've tried quite a few different kernel configurations,
excluding options that I think might have anything to
do with our problems. So far no luck...
This bug is probably deep, whatever it is.
Random hangs from scanning (reading writing) processes,
no btrfs send /receive, no matter what.
In the case of btrfs send/receive: after a normal start,
cpu usage drops to zero, as does io, then the process just
sits there doing nothing until killed.
Example: 16G btrfs send from a hdd to nvme which receives:
6.6.7:
send: cpu time about 3 sec user 22 sec system. Killed after 14 minutes:
receive: cpu time about 3 sek user 53 sec system. --- | | ---
5.15.143:
send: cpu time about 5 sec user 39 sec system 4 min 40 sec real.
receive: cpu time about 5 sec user 1 min 28 sec system --- | | ---

It's still early days for the 6.6 series. This is going to get fixed.

Aeterna: I might try the zen when I get the time. Thanks for the tip.
Didier: I usually use iostat, top and time because it's simple and often enough.

there are two series of zen: zen1 and lqx1. Only lqx1 has extra cpu schedulers: PDS and BMQ. I am currently running BMQ. These kernels are very stable. So no worries that something may go wrong.

good luck

rogan · 12-20-2023, 06:10 AM

lqx1: some drivers would not compile (excluded), but I could not convince it to boot.
I've tried 6.1.68, 6.5.13 and 6.7-rc6 also. Same behavour as 6.6.7 regarding btrfs send.
Perhaps this is a btrfs bug (which of course is unheard of ...

).

Aeterna · 12-20-2023, 07:34 AM

Quote:

Originally Posted by rogan

lqx1: some drivers would not compile (excluded), but I could not convince it to boot.
I've tried 6.5.13 and 6.7-rc6 also. Same behavour as 6.6.7 regarding btrfs send.
Perhaps this is a btrfs bug (which of course is unheard of ...

).

I am sorry to hear that. It must be something in your config. Issue spanning from 6.5.x to 6.7.x and nobody noticed it is difficult to imagine (still possible though).
I assume that you are using default kernel so someone else here would notice this problem. If however you did customize kernel config then maybe start with default settings.

cwizardone · 12-20-2023, 09:28 AM

Kernel updates 6.6.8, 6.1.69, 5.15.144, 5.10.205, 5.4.265, 4.19.303 and 4.14.334, are now available at, https://www.kernel.org/

https://cdn.kernel.org/pub/linux/ker...hangeLog-6.6.8

https://cdn.kernel.org/pub/linux/ker...angeLog-6.1.69

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

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

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

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

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

GazL · 12-20-2023, 09:33 AM

Quote:

Originally Posted by cwizardone

Kernel updates 6.6.8, 6.1.69, 5.15.144, 5.10.205, 5.4.265, 4.19.303 and 4.14.334, are now available at, https://www.kernel.org
The change logs,

Code:

$ git remote update origin
Fetching origin
$ git pull
Already up to date.
$ git describe
v6.6.7
$ git remote show origin
* remote origin
  Fetch URL: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
  Push  URL: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
  HEAD branch: master
  Remote branch:
    linux-6.6.y tracked
  Local branch configured for 'git pull':
    linux-6.6.y merges with remote linux-6.6.y
  Local ref configured for 'git push':
    linux-6.6.y pushes to linux-6.6.y (up to date)

Mirrors must still be syncing or something. I'll try again later.

edit: there now! (16:45 UTC)

marav · 12-20-2023, 09:37 AM

Quote:

Originally Posted by GazL

Mirrors must still be syncing or something. I'll try again later.

For now, only versions 5.15.144, 5.10.205, 5.4.265, 4.19.303 and 4.14.334 have been merged

marav · 12-20-2023, 10:26 AM

Important note:

Code:

Due to many known bugfixes not being backported properly to the 5.15.y
kernel tree, the ksmbd code in this branch is just not safe to be used
at this point in time at all. So mark it as BROKEN so it will not be
used.

https://lkml.iu.edu/hypermail/linux/...2.2/01263.html

A 5.15.145-rc1 is already on the way
https://git.kernel.org/pub/scm/linux...h=linux-5.15.y

linux91 · 12-21-2023, 04:44 PM

Quote:

Originally Posted by linux91

Maybe someone can help me with this kernel-6.6.6 issue:
After upgrade to Kernel-6.6.6, system boot locks up at rc.udev line /sbin/udevadm trigger --type=devices --action=add [just before the last 'else' in the case start) section.]
...
System: Kernel 6.6.6, lilo(no EFI), Acer 5750-6421, 16GB ram (per dmidecode/bios), 2TB crucial ssd, LVM/LUKS.
This is a relatively fresh install (< two months) from a 15.1 iso CD.
Thanks for any help

The resolution of the boot screen going blank during boot up of 6.6.X kernels
was relatively simple to implement, once the cause was found.
Apparently the newer 6.6.X kernels did not recognize the following line in this
computer's /etc/lilo.conf
vga=normal
Changing to a video mode recognized by this computer resolved the issue.
vga=795

As it turns out, the screen apparently was going blank but the computer
continued to boot. This was noticed using bootlogd (see details below)

Steps to resolve this issue included determining the available video modes for this
computer.
This was done using hwinfo, which is not installed by default.
hwinfo and the libx86emu dependency was installed using sbopkg
Running
sudo hwinfo --framebuffer
listed the available modes, of which x31b was selected
Mode designations in lilo.conf are in decimal form, not hex
So x31b was converted to decimal using:
printf "%d\n" 0x31b
returning:
795
Which provided the mode designation in /etc/lilo.conf
vga=795
The original mode entry was commented out.
# vga=normal

This worked regardless of whether the kernel append had a video assignment.
For example, either:
append=" mds=full,nosmt video=1024x768@60 vt.default_utf8=0 resume=/dev/cryptvg001/swap"
or
append=" mds=full,nosmt vt.default_utf8=0 resume=/dev/cryptvg001/swap"
worked as long as the vga=795 (or other available mode) was present.

ref_01: https://unix.stackexchange.com/quest...n-any-vga-fail

Using bootlogd to capture screen output during system boot(Thanks rworkman):
sudo touch /root/bootlog
To the beginnig of rc.S add:
/sbin/bootlogd -l /var/log/bootlog
To the end of rc.local add:
ps -ef | awk '/[b]ootlogd/{print $2}' | xargs kill
The rc.local entry is necessary to prevent capturing any further sensitive info.
Screen output of subsequent boots are appended to /var/log/bootlog.
ref: https://www.linuxquestions.org/quest...olling-642050/

There are no doubt other ways to resolve this issue, this is the most salient
for me at the moment.

Didier Spaier · 12-21-2023, 04:52 PM

Quote:

Originally Posted by linux91

There are no doubt other ways to resolve this issue.

Here is one: use grub instead of lilo.

cwizardone · 12-21-2023, 09:52 PM

The release of the 6.7.0 kernel has been delayed due to the holidays.

Quote:

.........Just FYI - my current plan is that -rc7 will happen this Saturday
(because I still follow the Finnish customs of Christmas _Eve_ being
the important day, so Sunday I'll be off), and then if anything comes
in that week - which it will do, even if networking might be offline -
I'll do an rc8 the week after.

Then, unless anything odd happens, the final 6.7 release will be Jan
7th, and so the merge window for 6.8 will open Jan 8th............

https://lore.kernel.org/netdev/CAHk-...ail.gmail.com/

rogan · 12-22-2023, 12:25 PM

I have written off kernels as a source to btrfs send/recieve not working.
It works just fine on current. btrfs-tools send on 15.0 does not work on any
stable kernel after 5.15 series as it seems (I have tested them all),at least
not on compressed volumes.

marav · 12-23-2023, 05:24 AM

kernel update 5.15.145 is now available at, https://www.kernel.org/
the change log,

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

cwizardone · 12-23-2023, 06:51 PM

6.7-rc7
Release Candidate 7, for the 6.7.0 "mainline" development kernel has been been made available for testing.

The tarball, https://git.kernel.org/pub/scm/linux...6.7-rc7.tar.gz

Mr. Torvalds' announcement, https://lkml.iu.edu/hypermail/linux/kernel/2312.2/085

linux91 · 12-28-2023, 06:57 PM

Quote:

Originally Posted by Didier Spaier

Here is one: use grub instead of lilo.

You're probably correct, but LILO goes back to the first kernels I used and configured. Just getting the kernel to run was a big thing for me then, and LILO was a part of it. I think I heard talk that there may be a move to grub only by the Team someday. No biggy, it's just my routine will have to change.

cwizardone · 12-30-2023, 08:09 AM

Year 2024, Round 01
Another batch of updates has been scheduled for release on Monday, 1 January 2024, at approximately 12:00, GMT. Since they won't be released until 1 January 2024, lets put this batch into next year's count.

The details:

6.6.9-rc1, with 156 patches, https://lkml.iu.edu/hypermail/linux/...2.3/02779.html

6.1.70-rc1, with 112 patches, https://lkml.iu.edu/hypermail/linux/...2.3/02782.html