home.social

Search

320 results for “kernellogger”

  1. 2/ For completeness, as it's easy to miss in Kent's long post:

    Kent refuses to send a public apology for a remark to a mm developer that lead to the escalation to the COC. Search for "you should probably send him an apology" in his Patreon post to find a good place to start.

    Also note that Kent resurrected the thread with the remark yesterday; new messages start here: lore.kernel.org/all/vvulqfvftc

  2. 2/ Side note for users of :

    6.12 is now available for all Fedora releases in the "stable" of my vanilla repositories.

    For install instructions, see copr.fedorainfracloud.org/copr and fedoraproject.org/wiki/Kernel_

    In addition to the regular kernel package that copr as of today started shipping a dedicated kernel which has enabled. Install it by running:

    $ sudo dnf install kernel-rt

  3. The two [1] recently affecting many people in mainline and various stable/longterm series should soon be a thing of the past:

    Linus merged fixes into 6.12-rc4[2] and Greg queued them for the next stable releases[3].

    Wondering what we should learn from this wrt to handling such regressions quickly and ideally even preventing them from hitting stable.

    [1] lore.kernel.org/all/4e1977ca-6

    [2] git.kernel.org/torvalds/c/d7f5

    [3] lore.kernel.org/all/2024102100

  4. Linus on today:

    """Honestly, I'm pretty damn fed up with buggy hardware and completely theoretical attacks that have never actually shown themselves to be used in practice.

    So I think this time we push back on the hardware people […]

    Because dammit, let's put the onus on where the blame lies, and not just take any random shit from bad hardware and say "oh, but it *might* be a problem".

    Linus"'"

    lore.kernel.org/all/CAHk-=wiUa

  5. Jan plans to remove with 6.13:

    "Deprecation period of reiserfs ends with the end of this year so it is time to remove it from the ."

    63 files changed, 12 insertions, 32804 deletions

    git.kernel.org/pub/scm/linux/k

  6. and Form Ecosystem Advisory Group to Accelerate Innovation for Developers and Customers

    amd.com/en/newsroom/press-rele

    "'Leading tech companies to collaborate on architectural interoperability and simplify software development across the ecosystem.

    Luminaries and Tim Sweeney join founding members , , , , Inc., , , , , and .'"

  7. Many dozens of recordings from this years @linuxplumbersconf are now available on YouTube. You can find them in the list of videos (youtube.com/@LinuxPlumbersConf ) on in a dedicated playlist (youtube.com/playlist?list=PLVs ).

    Abstracts as well as slides for most of the talks are available through the 's schedule page: lpc.events/event/18/timetable/

  8. v6.12-rc1-rt1 is out:

    lore.kernel.org/all/2024093015

    If you wonder what's still in the RT-Tree now that support is upstream, checkout git.kernel.org/pub/scm/linux/k

    In short: about 40 patches that among others switch 8250 to nbcon console, add support for ARM and PowerPC, or fix some drivers (like i915).

  9. 6.12-rc1 is out:

    lore.kernel.org/lkml/CAHk-=wiw

    '"Despite conference travel (both for me and several maintainers), things seemed to go mostly fairly normally. There's a couple of notable new features in here: For one thing, is now mainlined and enabled as a config option (you do need to enable "EXPERT" to get the question). For another, also got merged.

    […]

    Let's get the testing and calming down period started, ok?

    Linus"'

  10. , which allows scheduling policies to be implemented as programs, has been merged for 6.12:

    git.kernel.org/torvalds/c/8826

    See lwn.net/Articles/922405/ for a description of what it does and lwn.net/Articles/972710/ for the controversy it caused that is the reason why it took so long to land in mainline.

  11. They joys of bugs in hardware or firmware[1]:

    A user reported updating to 6.4.y broke on a Intel 3165 NIC. Bisection identified 5fc3f6c90cc ("r8169: consolidate disabling ASPM before EPHY access") as culprit.

    Turns out it was not a faulty bisection, as it seems enabling on some chips supported by can harm other PCI devices. 🥴 🤨

    bugzilla.kernel.org/show_bug.c

    [1] or maybe it one day turns out that this is caused by a bug somewhere in the

  12. Lai Jiangshan posted a RFC patch-set introducing a new hypervisor called :

    lore.kernel.org/lkml/202402261

    "'"This RFC series proposes a new virtualization framework built upon the hypervisor that does not require hardware-assisted virtualization techniques.

    So the over-arching goals of PVM are to 1) enable nested virtualization within any IaaS clouds […] 2) avoid costly exits to the host hypervisor […]"'"

    Pbonzini already replied: lore.kernel.org/lkml/CABgObfaS

  13. Wedson Almeida Filho steps down as one of the maintainers of
    the project:

    '"[…] After almost 4 years, I find myself lacking the energy and enthusiasm I once had to respond to some of the nontechnical nonsense, so it's best to leave it up to those who still have it in them.

    To the Rust for Linux team: thank you, you are great. It was a pleasure working with you all; […]"'

    lore.kernel.org/lkml/202408282

  14. 2/ It's done! 🥳

    A few minutes ago (aka: support) support landed in mainline, as Linus honored the PR that Tglx handed him yesterday in person (see first toot in thread): git.kernel.org/torvalds/c/baeb

    Congrats and thx to everyone who was involved in this 20 year long journey!

  15. The 6.12 pull request for is handed to Linus. Likely the first PR ever submitted in printed form.

  16. aka the support for hit -next today! 🥳 👏

    git.kernel.org/pub/scm/linux/k

    Still remains to be seen if those changes really makes it upstream during the 6.12 merge window and stick:

    * It afaics is still unclear if some prerequisites will be submitted for 6.12: lore.kernel.org/all/87ed5za2oj

    * Troublemaking changes sometimes are reverted before the final, which in fact happened to some of printk prerequisites a while ago: lore.kernel.org/lkml/202206231

  17. v6 of the patch-set "add threaded printing + the rest" which "provides the remaining pieces of the rework."[1] is now in -next – but as of now it's not yet clear if this will be merged for 6.12.

    lore.kernel.org/all/ZthvGoJE26

    [1] e.g. the last big missing piece for support through in the mainline . But note, this series does *not* provide an nbcon console driver. That will come in a follow-up series.

  18. The improved series "wire up write_atomic() printing" is now in -next again and thus slated for inclusion in 6.12. This is one of the last important bits for proper support with in mainline – but not the last, as this series does not include threaded printing or nbcon drivers, as those will come later: lore.kernel.org/all/ZsWxpVG8uZ

    A earlier version of the patch set was supposed to go into 6.11, but Linus was unhappy: lore.kernel.org/lkml/CAHk-=whU

  19. Linus did not pull the latest printk changes for 6.11, as he did not like the what some of the changes required for proper aka support do:

    lore.kernel.org/all/CAHk-%3Dwh

    "'
    > The messages are flushed at the end of the emergency section to allow storing the full log (backtrace) first.

    What? No.

    One of the historically problematic situations is when a recursive oops or a deadlock occurs *during* the first oops.

    […]
    '"

  20. John posted v3 of the patch-set with the "remaining pieces of the rework" to support threaded console printing, which is last big missing piece missing to support with the mainline through :

    lore.kernel.org/all/2024072217

  21. The last step in the rework saga (the last big pre-requisite before can be mainlined) is getting closer:

    John submitted the printk patch series "add threaded printing + the rest", which '"provides the remaining pieces of the printk rework. All other components are either already mainline or are currently in linux-next. […] Note that this series does *not* provide an nbcon console driver. That will come in a follow-up series."'

    lore.kernel.org/all/2024060323

  22. Interesting detail in the description of the main EFI changes merged for #Linux 6.9[1]:

    "'"Avoid creating mappings that are both writable and executable while running in the EFI boot services. This is a prerequisite for getting the x86 #shim loader signed by MicroSoft again, which allows the distros to install on x86 PCs that ship with EFI secure boot enabled."'"

    [1] git.kernel.org/torvalds/c/70ef

    #Kernel #LinuxKernel #SecureBoot

  23. Interesting detail in the description of the main EFI changes merged for 6.9[1]:

    "'"Avoid creating mappings that are both writable and executable while running in the EFI boot services. This is a prerequisite for getting the x86 loader signed by MicroSoft again, which allows the distros to install on x86 PCs that ship with EFI secure boot enabled."'"

    [1] git.kernel.org/torvalds/c/70ef

  24. Interesting detail in the description of the main EFI changes merged for #Linux 6.9[1]:

    "'"Avoid creating mappings that are both writable and executable while running in the EFI boot services. This is a prerequisite for getting the x86 #shim loader signed by MicroSoft again, which allows the distros to install on x86 PCs that ship with EFI secure boot enabled."'"

    [1] git.kernel.org/torvalds/c/70ef

    #Kernel #LinuxKernel #SecureBoot

  25. Interesting detail in the description of the main EFI changes merged for #Linux 6.9[1]:

    "'"Avoid creating mappings that are both writable and executable while running in the EFI boot services. This is a prerequisite for getting the x86 #shim loader signed by MicroSoft again, which allows the distros to install on x86 PCs that ship with EFI secure boot enabled."'"

    [1] git.kernel.org/torvalds/c/70ef

    #Kernel #LinuxKernel #SecureBoot

  26. Interesting detail in the description of the main EFI changes merged for #Linux 6.9[1]:

    "'"Avoid creating mappings that are both writable and executable while running in the EFI boot services. This is a prerequisite for getting the x86 #shim loader signed by MicroSoft again, which allows the distros to install on x86 PCs that ship with EFI secure boot enabled."'"

    [1] git.kernel.org/torvalds/c/70ef

    #Kernel #LinuxKernel #SecureBoot

  27. "'[…] was created as a tool to unblock future releases — not intended as a global reinvention of all source code management; Linus’s comments highlight that he explicitly saw source code management as the domain of other tools that would then interface with git. […]'"

    graphite.dev/blog/bitkeeper-li