Announcement

Collapse
No announcement yet.

Google Uncovers CPU Bug For Geminilake, Affecting At Least Firefox & Chrome

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Google Uncovers CPU Bug For Geminilake, Affecting At Least Firefox & Chrome

    Phoronix: Google Uncovers CPU Bug For Geminilake, Affecting At Least Firefox & Chrome

    We were alerted this morning to a CPU bug resulting in crashes for Intel Geminilake processors. At least Chrome and Firefox are affected but sounds like other software may be affected too, just that Google has enough engineering resources for investigating the issue...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    If you read through the Firefox bugzilla, it was already closed three months ago as bug reports had stopped; it only affected version 67 of Firefox; and it did not seem to be related to microcode as the "microcode versions associated with the crashes we're seeing are all over the place".

    Sounds like Google is introducing a bug fix and trying to blame it on Intel, when it's probably Google's own code that's to blame.

    Comment


    • #3
      Originally posted by andyprough View Post
      If you read through the Firefox bugzilla, it was already closed three months ago as bug reports had stopped; it only affected version 67 of Firefox; and it did not seem to be related to microcode as the "microcode versions associated with the crashes we're seeing are all over the place".

      Sounds like Google is introducing a bug fix and trying to blame it on Intel, when it's probably Google's own code that's to blame.
      Sounds more like it's a hard to reproduce bug that depends (amidst other things) on where the linker places stuff.

      Hard to blame Google if a cpu can be singled out. Especially if at the same time Mozilla did the "don't care/works for me" instead of investigating.

      Comment


      • #4
        The real bug is intel itself.

        Comment


        • #5
          Originally posted by discordian View Post
          Sounds more like it's a hard to reproduce bug that depends (amidst other things) on where the linker places stuff.

          Hard to blame Google if a cpu can be singled out. Especially if at the same time Mozilla did the "don't care/works for me" instead of investigating.
          I think you are right - when I look further, I see that one Firefox dev said their microcode reporting mechanism may have been giving them incorrect values: "I'm not sure I entirely trust our microcode version reporting code". So, probably Google is correct.

          Comment


          • #6
            Sounds like a pretty severe and basic bug.
            I'm surprised it hasn't triggered all sorts of havoc all over the place?
            Maybe it isn't a hardware bug after all?
            What's so special about the browsers that they keep (apparently?) triggering the bug?

            I hate fixing code for apparently broken hardware.
            If it was up to me I'd write a detection routine instead.

            "You have a P.O.S CPU. Go tell Intel to shove it."

            Comment


            • #7
              Originally posted by milkylainen View Post
              Sounds like a pretty severe and basic bug.
              I'm surprised it hasn't triggered all sorts of havoc all over the place?
              Maybe it isn't a hardware bug after all?
              What's so special about the browsers that they keep (apparently?) triggering the bug?
              I think that it's not so much only browser triggering the bug, but only browsers have so large widespread use and (for Chrome) so extensive telemetry info that allows them to actually be notified of crashes and their probable cause.

              Most other software won't do that, and people will blame Windows, or the software, or the Gods that didn't smile back at them or something.

              This is a prime reason why I strongly believe that telemetry about technical and performance information is a very important thing to have.

              Comment


              • #8
                Originally posted by Azrael5 View Post
                The real bug is intel itself.
                Despite preferring AMD CPU, I must recall the "Ryzen bug", which was much more serious. But AMD replaced our CPUs for free.

                Comment


                • #9
                  Originally posted by milkylainen View Post
                  I hate fixing code for apparently broken hardware.
                  If it was up to me I'd write a detection routine instead.

                  "You have a P.O.S CPU. Go tell Intel to shove it."
                  That's a juvenile dream.

                  You know full well that you can't just disable the program for something you can work around in software. This is the real world for like 1000% of actual software development.

                  Comment


                  • #10
                    Originally posted by ALRBP View Post

                    Despite preferring AMD CPU, I must recall the "Ryzen bug", which was much more serious. But AMD replaced our CPUs for free.
                    They also added special options in the UEFI setup to disable the most likely source of the crashes (some deeper C-states, C6 or something), so that you can still live with an affected system if you can't just call AMD and send over the CPU.

                    Comment

                    Working...
                    X