@kernellogger@fosstodon.org
@kernellogger@fosstodon.org avatar

kernellogger

@kernellogger@fosstodon.org

Mainly tooting about #Linux the #kernel and things related to the #LinuxKernel – e.g. #bootloader, #compiler, #git, #glibc, #mesa, #qemu, #xorg, #X11, #wayland, and other stuff in the 'plumbing' layer.

Opinions are my own.

Topic account. Other accounts of mine:

https://social.linux.pizza/@knurd42 (EN): #FLOSS, #Fedora as well as Life, the Universe and Everything
https://norden.social/@thleemhuis (DE): Das Leben, das Universum und der ganze Rest
https://social.tchncs.de/@thleemhuisfoss (DE): #FLOSS

searchable

This profile is from a federated server and may be incomplete. Browse more on the original instance.

kernellogger, to linux
@kernellogger@fosstodon.org avatar

6.4-rc2 is out:

[…] This being rc2, it's been a fairly calm week as people are only starting to find any issues from the merge window, but it all looks fine. […]

https://lore.kernel.org/lkml/CAHk-=wj3jDtVCi2LqyijGzut2cq=AkPrAMfF0+6gtZ1WB6ruWQ@mail.gmail.com/

jbowen, to random
@jbowen@mast.hpc.social avatar

@kernellogger Have you heard reports of blank screens with the 6.4-rc1 vanilla kernels from the copr repos you maintain?

On my AMD 5700G system I get to GDM, but after I log in the screen goes blank and doesn't recover with typical troubleshooting steps. If I boot into the 6.2.x distro kernel from the Fedora repos everything is fine.

I'm happy to provide any logs that would be helpful. Admittedly graphics/display issues are probably my weakest area.

kernellogger,
@kernellogger@fosstodon.org avatar

@jbowen

Not aware of anything specific for 6.4, but later in the 6.3 cycle this started to happen:

https://gitlab.freedesktop.org/drm/amd/-/issues/2553

But you might want to search
https://gitlab.freedesktop.org/drm/amd/ yourself, I currently sadly don't really want that tracker (there are only so many hours in a day) 🥴

klausman, to linux
@klausman@mas.to avatar

Say you have a regression between #Linux v6.3 and v6.4-rc1 and you bisect it, nail a bad commit (repeatedly!), reverse the patch on a fresh v6.4-rc1 --- and the regression is still there. What now?

@kernellogger might know

kernellogger,
@kernellogger@fosstodon.org avatar

@klausman

Sorry, guess I'm not much of a help here.

Is the bad commit the first one diverging from mainline? I had ran into that situation myself once and it was caused by something I couldn't figure out. 😟

Sounds a bit odd, but maybe later commits from the same patch-set also cause the same regression to occur.

Is https://nathanchance.dev/posts/working-with-git-bisect/ maybe any help?

kernellogger, to random
@kernellogger@fosstodon.org avatar

Calling "X12" would have had one important benefit:

It would have made it pretty obvious that Wayland is primarily a protocol[1] – and thus if something "works with wayland" often depend on the display server (read: compositor, aka gnome-shell/mutter, kde plasma/kwin, …) built with it.

Screenshot of https://chaos.social/@karolherbst/110366488521596678

[1] and a library implementing it; but definitely not a replacement for a particular dominating X11 implementation called Xorg (not to be confused with X.org).

kernellogger,
@kernellogger@fosstodon.org avatar

@tongpu

  • change is hard for people
  • a radical change with a totally different approach like here is even harder
  • it's yet again harder when you are emotionally attached
  • it corners some projects (e.g. Xfce et al)
  • people tried it and ran into problems, as it's a complex ecosystem -- taking care of many corner cases will still takes years, even if a wayland compositor already works for say 95 of the people
  • people don't understand it

that was just what immediately came to my mind…

kernellogger, to linux
@kernellogger@fosstodon.org avatar 

We can now reliably fork a VM within 1.5s, regardless of how much memory is used for the VM […]```

<https://codesandbox.io/blog/cloning-microvms-using-userfaultfd>
kernellogger, to linux
@kernellogger@fosstodon.org avatar

quote of the day from @torvalds on avoiding compiler warnings:

you can make some compilers happy all of the time, and all compilers happy some of the time, but you can't make all compilers happy all of the time

https://lore.kernel.org/all/CAHk-=whtWTqXXD29n4z0qni-xM_4OPE-6u3vw_qjkiz05BHVZg@mail.gmail.com/

kernellogger, to random
@kernellogger@fosstodon.org avatar

Kent submitted the filesystem ("a new COW fs") for review and inclusion: https://lore.kernel.org/all/20230509165657.1735798-1-kent.overstreet@linux.dev/


Snapshots have been declared stable; […]

Erasure coding is getting really close; […]

Tons of scalabality work finished over the past year […]

https://bcachefs.org/

kernellogger,
@kernellogger@fosstodon.org avatar

@froqstar

good luck with that, from experience with other file systems it takes years to properly stabilize and tune file systems once merged, as usually all sorts of corner cases turn up during broad field testing. Hence better ensure you have good backup strategy, just in case one of them hits you.

kernellogger, to linux
@kernellogger@fosstodon.org avatar

Interesting things the 's developers are doing:

Oh, CONFIG_XFS_DEBUG=y, which means: […] We randomly chose a near block allocation strategy to use to improve code coverage, not the optimal one for IO performance. Hence the CPU usage and allocation patterns that impact IO performance are simply not predictable or reproducable from run to run. So, yeah, trying to bisect […] will not be reliable....

https://lore.kernel.org/all/20230509071053.GE2651828@dread.disaster.area/

kernellogger, (edited ) to linux
@kernellogger@fosstodon.org avatar

Reminder: a where uname -r prints something like "5.15.0-71-generic" is a vendor kernel that is likely quite different from 5.15.71[1].

In case of problems with such a kernel you thus must report them to your vendor.

That's because almost all upstream developers don't care about problems in such kernels, as they might happen due to modifications the vendor applied.

[1] it in fact is likely based on a much later Linux 5.15.y release

kernellogger,
@kernellogger@fosstodon.org avatar

@amonakov

I'm a friend of texts that ask kindly, but sometimes being clear is more important.

Yes, I might have gone a tinly bit too far here (hey, it's not documentation, it's just a toot), but your words from my point of view and experience are much to soft to bring the point across.

kernellogger,
@kernellogger@fosstodon.org avatar

@amonakov

FWIW, I'm working on a text to cover these any other aspects why bug reports are ignored by upstream developers. Feel free to comment:

https://docs.google.com/document/d/1Yu1QdK9PicMrkPWTHEMWlJ7AC70gXZPtpTA_oCEbKkE/edit?usp=sharing

kernellogger,
@kernellogger@fosstodon.org avatar

@maruel @amonakov

thx for saying that, it's still a lot of work to cover the other stuff (even if some more of it is already written)

kernellogger,
@kernellogger@fosstodon.org avatar

@maruel @amonakov

I guess nobody has a good guess how many systems using Linux are running an unmodified kernel.

I'd say the share is quite small, but it's just a feeling.

It gets different if you are willing to accept kernels not that different from vanilla, as then the kernels from Arch Linux, Tumbleweed, Fedora could start to count.

kernellogger,
@kernellogger@fosstodon.org avatar

@comrad @maruel @amonakov

I strongly disagree.

The versions released by kernel developer are an offer meant for users, if they use it OTOH is totally up to them.

What distributions do with those versions is also totally up to them. They thus are also free to modify the code – but as a consequence of that the upstream developers then might not care at all about bugs that happen with those kernels, as they might be caused by those modifications.

kernellogger, to linux
@kernellogger@fosstodon.org avatar

6.4-rc1 is out:

https://lore.kernel.org/lkml/CAHk-=wiUxm-NZ1si8dXWVTTJ9n3c+1SRTC0V+Lk7hOE4bDVwJQ@mail.gmail.com/


[…] So I'm now using the 'histogram' algorithm, […] it does occasionally cause line number differences in the diffstats […]

The diffstat is completely dominated by AMD GPU hardware description files once again, and this time the 'perf' tool has followed suite […]

The one feature that didn't make it was the x86 shadow stack code. […]

Anyway, please do go test it all out,

 Linus```
kernellogger, (edited ) to linux
@kernellogger@fosstodon.org avatar

Kinda funny that the person that triggered the creation of the following website since then multiple times shared the link to it when somebody wrote something like:

" has always been about choice."

That's because the website is right.

http://www.islinuxaboutchoice.com/ (use http, not https)

sima, to random
@sima@chaos.social avatar

some thoughts on when to be pragmatic and do you want to actually document that or not

plus a repetition that there's no taking back uapi in the kernel

https://lore.kernel.org/dri-devel/ZFTXl3qPn7E0pQWO@phenom.ffwll.local/

kernellogger,
@kernellogger@fosstodon.org avatar

@sima

Has anyone ever successfully added all the infra for a new api to the upstream kernel, but kept the code exposing the api as an out-of-tree patch until things have somewhat settled?

That does not eliminate the risk of regressions and strong worded mails from Linus, but it might reduce it enough.

kernellogger, (edited ) to random
@kernellogger@fosstodon.org avatar

"The latest major version of the GNU Compiler Collection (), 13.1, was released in April 2023. […] This article describes new features implemented in the C front end […] GCC 13 implements many C2X proposals. These proposals align the C and C++ languages a little bit closer to each other by entwining certain features, and make programming in C easier and more secure."

https://developers.redhat.com/articles/2023/05/04/new-c-features-gcc-13 (written by @strudlzrout)

kernellogger, to linux
@kernellogger@fosstodon.org avatar

I'm planning to submit a rewritten section about "expectations and best practices for fixing [ regressions]" in https://docs.kernel.org/process/handling-regressions.html as RFC early next week.

If you want a early look, follow this link:

https://gitlab.com/knurd42/linux/-/compare/master...docs-handling-regs-procedures-v1?from_project_id=11281838#702893b97b365e04d2e19a5428975ff6a59111c0_201_132

kernellogger,
@kernellogger@fosstodon.org avatar

@SchwarzeLocke

yup, already noticed that and fixed that locally, but need to recheck and compare, maybe your version is even better (or it might be the same).

kernellogger,
@kernellogger@fosstodon.org avatar

@SchwarzeLocke

I agree that it's long, but I'll likely will leave it as it is.

This is the general/overall goal/idea, what follows then are rules of thumb to achieve/implement that goal.

Those are two different things; and having such a goal is important to understand quickly what the aim of those guidelines is, especially when you run into corner cases not covered.

kernellogger, to linux
@kernellogger@fosstodon.org avatar

Hmmm, immutable distros are currently ignored by the "How to quickly build a trimmed " text I recently added to the 's documentation[1].

Is that fine for now? Or should I add a sentence or two about those?

For @fedora at al. it seems using "ostree admin unlock --hotfix" might be the best solution when say doing a bisection.

But what's the best way for @opensuse MicroOS?

[1]https://docs.kernel.org/next/admin-guide/quickly-build-trimmed-linux.html

kernellogger,
@kernellogger@fosstodon.org avatar

@siosm @fedora @dustymabe

ahh, there it is, many thx; I vaguely remembered to have seen that text, but I failed to find it, as I had "silverblue" in my search terms; stupid me. 😒

Section 1 sounds like nothing special is needed, which sounds a bit odd; but well, guess /sbin/installkernel then must directly or indirectly make the OS writable.

kernellogger,
@kernellogger@fosstodon.org avatar

@dustymabe @siosm @fedora

/me looks

Ohh, might have helped to read the top section; sorry.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • JUstTest
  • GTA5RPClips
  • DreamBathrooms
  • cubers
  • mdbf
  • everett
  • magazineikmin
  • Durango
  • Youngstown
  • rosin
  • slotface
  • modclub
  • kavyap
  • ethstaker
  • provamag3
  • ngwrru68w68
  • thenastyranch
  • cisconetworking
  • khanakhh
  • osvaldo12
  • InstantRegret
  • normalnudes
  • Leos
  • tacticalgear
  • tester
  • megavids
  • anitta
  • lostlight
  • All magazines
    •