Announcement

Collapse
No announcement yet.

Intel Core i7 5775C: Once Going, This Broadwell CPU Is Great On Linux

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

  • Intel Core i7 5775C: Once Going, This Broadwell CPU Is Great On Linux

    Phoronix: Intel Core i7 5775C: Once Going, This Broadwell CPU Is Great On Linux

    For the past few weeks I've been testing out the Core i7 5775C on Linux as mentioned in a few posts up to this point. While there were some initial headaches on getting this socketed Broadwell CPU playing nicely under Linux, once working around those problems, this processor is great on Linux. With its Iris Pro Graphics 6200 is able to serve as a compelling choice for those who want a powerful open-source system.

    http://www.phoronix.com/vr.php?view=21880

  • #2
    @Michael:

    Big german tech portal Golem.de ran into similar issues, although with Windows. They found that updating the UEFI was not enough, or to be more clear, that updating UEFI was only *really* done once they've installed the Intel Management Engine driver under Windows, after which they were able to complete the UEFI update they thought was already done. They said they couldn't really figure out what the fuck is going on, but that they got it working after this bullshit.

    http://www.golem.de/news/broadwell-c...-115218-2.html

    Comment


    • #3
      Originally posted by d2kx View Post
      @Michael:

      Big german tech portal Golem.de ran into similar issues, although with Windows. They found that updating the UEFI was not enough, or to be more clear, that updating UEFI was only *really* done once they've installed the Intel Management Engine driver under Windows, after which they were able to complete the UEFI update they thought was already done. They said they couldn't really figure out what the fuck is going on, but that they got it working after this bullshit.

      http://www.golem.de/news/broadwell-c...-115218-2.html
      Hmmm, interesting; thanks for pointing it out. Odd. I just followed up with Intel PR contact to see if anything new. Strange that with Fedora 22 it continues running excellent when the same hardware and kernel version on Ubuntu 15.04 is enough to trigger stability issues.
      Michael Larabel
      http://www.michaellarabel.com/

      Comment


      • #4
        Originally posted by Michael View Post

        Hmmm, interesting; thanks for pointing it out. Odd. I just followed up with Intel PR contact to see if anything new. Strange that with Fedora 22 it continues running excellent when the same hardware and kernel version on Ubuntu 15.04 is enough to trigger stability issues.
        One would suspect different patches, or configs. I just checked the fedora config file from the kde spin, v4.0.4, but could not find anything obvious. It is a generic config after all, way different from my personal config.

        I also tested vanilla kernel 4.2rc3, but the crashes still show up. Sometimes the X-Server works, sometimes starting it triggers the crash.

        What I saw was that there is no microcode update for this cpu in the latest microcode archive for linux. I was thinking i loaded it too late in the boot process. I have rev 0xb, before and after. The cpu stepping is 1.

        As a sidenote, when applying a patch to enable more -march options for kernel compilation, naturally -march=broadwell the compilation fails very early, asm-offsets.s or something.

        Michael Does the Fedora kernel get the mtrrs right with your setup? How much RAM have you assigned to the igd? I have assigned 1024 mb, and i have to give values for mtrr.

        Comment


        • #5
          Originally posted by mtthsme View Post
          Michael Does the Fedora kernel get the mtrrs right with your setup? How much RAM have you assigned to the igd? I have assigned 1024 mb, and i have to give values for mtrr.
          Does this really matter? I though nowadays Linux uses Page Attribute Tables to control the memory type. AFAIK the sole purpose of the MTRR optimizer is to free an MTRR register so the graphics stack can configure write-combined access for the graphics memory. Do you get graphics slowdowns or crashes when the MTRR optimizer cannot find suitable config?

          Comment


          • #6
            Originally posted by kobblestown View Post

            Does this really matter? I though nowadays Linux uses Page Attribute Tables to control the memory type. AFAIK the sole purpose of the MTRR optimizer is to free an MTRR register so the graphics stack can configure write-combined access for the graphics memory. Do you get graphics slowdowns or crashes when the MTRR optimizer cannot find suitable config?
            Right, it should not matter. Since the crashes seem to have no easily visible cause, I wanted to know whether this aspect has an impact. And I cannot test the performance on my system since it is way too unstable.

            Comment


            • #7
              Originally posted by mtthsme View Post
              Since the crashes seem to have no easily visible cause, I wanted to know whether this aspect has an impact. And I cannot test the performance on my system since it is way too unstable.
              The only reason I know about MTRR/PAT is that I too was chasing a strange kernel freeze on one of my machines (Core i7 4770 on a Q87 mobo). It would only happen when transfering huge amounts of data over the built-in Intel NIC when more than 16GB of memory are installed (tested with 24GB and 32GB). I saw the scary MTRR optimizer warnings and I though it might be related. However, I tried disabling the IGP (it's a server mechine, so it doesn't matter. I have a serial console configured on it) and then there are no MTRR warning but the bug is still triggered. The solution was to blacklist the intel graphics driver kernel module. I guess it's used to implement the framebuffer console. Without it I get regular text mode only. But the system is stable. You could try and see whether that fixes it for you, although, I imagine, you need the graphics on your machine

              Comment


              • #8
                Originally posted by kobblestown View Post

                The only reason I know about MTRR/PAT is that I too was chasing a strange kernel freeze on one of my machines (Core i7 4770 on a Q87 mobo). It would only happen when transfering huge amounts of data over the built-in Intel NIC when more than 16GB of memory are installed (tested with 24GB and 32GB). I saw the scary MTRR optimizer warnings and I though it might be related. However, I tried disabling the IGP (it's a server mechine, so it doesn't matter. I have a serial console configured on it) and then there are no MTRR warning but the bug is still triggered. The solution was to blacklist the intel graphics driver kernel module. I guess it's used to implement the framebuffer console. Without it I get regular text mode only. But the system is stable. You could try and see whether that fixes it for you, although, I imagine, you need the graphics on your machine
                Thanks for sharing this story. It might be an option still to not compile the intel graphics driver, and to try to work on the framebuffer console only (efifb).

                And I checked with theworking fedora kernel. It doesn't care about mtrrs either, the cleanup is disabled there. I tried to replicate the fedora config with gentoo-sources-4.1.3 as much as possible, but the system still crashes . I will check the kernel logs and configs again.

                Comment


                • #9
                  I think Broadwell is more mature on a desktop platform than on a hybrid laptop.
                  In any case. Hybrid GPU solutions are creating many complex issues yet to be uncovered.
                  The lack of a standard muxless hybrid open source solution really is a fly in the ointment.

                  Comment


                  • #10
                    Just this weekend I seem to have found a solution to (my) problems with this setup.

                    I reinstalled my system, compiled a 4.1.3 kernel, there disabled intel_idle and cpuidle, with only pstates and cpufreq keeping the power consumption a bit lower. Right now I am at 32? C, also with turboboost disabled. My Desktop is finally back, and I had no crash for several hours, even under high load on all cores.

                    Next I will check whether all the things work good enough.

                    Comment

                    Working...
                    X