• chevron_right

      Linux is not exactly “ready to run” on Apple silicon, but give it time

      news.movim.eu / ArsTechnica · Monday, 27 February, 2023 - 16:12

    Asahi Linux image on a MacBook

    Enlarge / Everything Asahi Linux's four-person team has done to make Linux work on Apple's M-series chips is remarkable, but "ready to run" is a stretch. (credit: Apple/Asahi Linux)

    It's an odd thing to see the leaders of an impressive open source project ask the press and their followers to please calm down and stop celebrating their accomplishments.

    But that's the situation the Asahi Linux team finds itself in after many reports last week that the recently issued Linux 6.2 kernel made Linux "ready to run" on Apple's M-series hardware . It is true that upstream support for Apple's M1 chips is present in 6.2 and that the 6.2 kernel will gradually make its way into many popular distributions, including Ubuntu and Fedora. Work on Apple's integrated GPU by the four-person Asahi core team has come remarkably far . And founder Linus Torvalds himself is particularly eager to see Linux running on his favorite portable hardware, going so far as to issue a kernel in August 2022 from an M2 MacBook Air .

    But the builders of the one Linux system that runs pretty well on Apple silicon are asking everybody to please just give it a moment.

    Read 5 remaining paragraphs | Comments

    • chevron_right

      Linux kernel 5.19.2 code could cause permanent damage to some laptop displays

      news.movim.eu / ArsTechnica · Thursday, 6 October, 2022 - 17:36

    It's not specific to Framework, but a number of Framework-owning Linux enthusiasts saw a kernel quirk set their screens flickering this week, potentially with lasting damage.

    Enlarge / It's not specific to Framework, but a number of Framework-owning Linux enthusiasts saw a kernel quirk set their screens flickering this week, potentially with lasting damage. (credit: Andrew Cunningham)

    For desktop Linux users, updating to a new Linux kernel typically carries relatively small, contained risks: wonky drivers, GRUB pain, maybe a full wipe and reinstall. For one subset of laptop owners on rolling release distributions, however, kernel version 5.19.2 could cause actual LCD screen damage.

    "After looking at some logs we do end up with potentially bogus panel power sequencing delays, which may harm the LCD panel," wrote Intel engineer Ville Syrjälä in a discussion on the issue . "I recommend immediate revert of this stuff, and new stable release ASAP. Plus a recommendation that no one using laptops with Intel GPUs run 5.19.2."

    The conflict between Linux kernel 5.19.2 and Intel GPU drivers, captured by Michael Kan.

    One day later, kernel 5.19.13 was released. But there's a distribution chain between kernel work and distribution desktops, and certain laptop owners were caught up in it.

    Read 5 remaining paragraphs | Comments

    • chevron_right

      20-year-old Linux workaround is still slowing down AMD systems

      news.movim.eu / ArsTechnica · Monday, 26 September, 2022 - 20:51 · 1 minute

    A second-generation Epyc server chip from AMD, one that may have been running 2002-era Linux code slowing it down.

    Enlarge / A second-generation Epyc server chip from AMD, one that may have been running 2002-era Linux code slowing it down. (credit: Getty Images)

    AMD has come a long way since 2002 , but the Linux kernel still treats modern Threadrippers like Athlon-era systems—at least in one potentially lag-inducing respect.

    AMD engineer Prateek Nayak recently submitted a patch to Linux's processor idle drivers that would "skip dummy wait for processors based on the Zen microarchitecture." When ACPI support was added to the Linux kernel in 2002—written by Andy Grover, committed by Linus Torvalds—it included a "dummy wait op." The system essentially read data with no purpose other than delaying the next instruction until the CPU could fully stop with the STPCLK# command. This allowed for some power saving and compatibility during the early days of ACPI implementation when some chipsets wouldn't move to an idle state when one would expect it.

    But today's Zen-based AMD chips don't need this workaround, and, as Nayak writes, it's hurting them, at least in specific workloads on Linux. Testing with instruction-based sampling (IBS) workloads shows that "a significant amount of time is spent in the dummy op, which incorrectly gets accounted as C-State residency." The CPU, seeing all this low-effort dummy work, can push into deeper, slower C-State, which then makes the CPU take longer to "wake up," especially on jobs that require lots of switching between busy and idle states.

    Read 3 remaining paragraphs | Comments