Announcement

Collapse
No announcement yet.

AMD Enduro on a Clevo P170EM

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

  • AMD Enduro on a Clevo P170EM

    So, a little report on my experience with Ivy Bridge + AMD Enduro on a Clevo P170EM / intel HM77 chipset.

    Graphics hardware:
    Code:
    00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)
    01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI WIMBLEDON XT [Radeon HD 7970M] (rev ff)
    1. Doing nothing
    Since it's a HD 7970 it runs quite hot on the default power profile.
    Code:
    default engine clock: 850000 kHz
    current engine clock: 849990 kHz
    default memory clock: 1200000 kHz
    current memory clock: 1199990 kHz
    voltage: 1050 mV

    1.1 radeon power profiles
    This is my second radeon notebook chip where the mid and the low power profile produce the same result:
    Code:
    default engine clock: 850000 kHz
    current engine clock: 299990 kHz
    default memory clock: 1200000 kHz
    current memory clock: 149990 kHz
    voltage: 1050 mV
    On the low/mid profile the temperature seems to be quite stable
    Code:
    radeon-pci-0100
    Adapter: PCI adapter
    temp1:        +46.0?C
    But occassionally the fan gets louder for a short time.


    1.2 vgaswitcheroo
    So what you really want to do is disabling that card. The first thing I tried was vgaswitcheroo:
    Code:
    echo OFF > /sys/kernel/debug/vgaswitcheroo/switch
    This disables the discrete card (DIS = discrete, IGD = integrated as I have learned):
    Code:
    cat /sys/kernel/debug/vgaswitcheroo/switch
    0:DIS: :Off:0000:01:00.0
    1:IGD:+:Pwr:0000:00:02.0
    Problem 1: It seems to disable the fan control too so the fan keeps running at whatever speed it was running before disabling the discrete card.
    So what I do is
    Code:
    echo OFF > /sys/kernel/debug/vgaswitcheroo/switch
    # wait a few seconds until the card is cool
    echo ON > /sys/kernel/debug/vgaswitcheroo/switch
    # the fan is shut off since the card is cool enough
    echo OFF > /sys/kernel/debug/vgaswitcheroo/switch
    # now the fan is off and stays off
    Problem 2: It seems to be not too reliable. It sometimes seems to freeze X and when I try OFF directly on boot it doesn't really work, and when I try it manually again it just hangs. When this happens, reboot doesn't work either.

    2.0 PRIME
    A sad topic.
    I run the latest git version of xorg, mesa and mainline linux 3.6.
    xrandr --listproviders won't show the discrete card, unless X is started while radeon is enabled.

    Then it looks like this:
    Code:
    $ xrandr --listproviders
    Providers: number : 2
    Provider 0: id: 112 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 3 outputs: 8 associated providers: 0 name:Intel
    Provider 1: id: 69 cap: 0xd, Source Output, Source Offload, Sink Offload crtcs: 6 outputs: 0 associated providers: 0 name:radeon
    The manpage of xrandr from git still doesn't contain information to offloaders, but there are only two possibilities:
    Code:
    $ xrandr --setprovideroffloadsink 112 69
    X Error of failed request:  BadValue (integer parameter out of range for operation)
      Major opcode of failed request:  140 (RANDR)
      Minor opcode of failed request:  34 ()
      Value in failed request:  0x70
      Serial number of failed request:  11
      Current serial number in output stream:  12
    
    $ xrandr --setprovideroffloadsink 69 112
    The second one has no output and I think that's a good sign.

    Code:
    $ DRI_PRIME=0 glxinfo | grep OpenGL
    ATTENTION: default value of option force_s3tc_enable overridden by environment.
    OpenGL vendor string: Intel Open Source Technology Center
    OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile 
    OpenGL version string: 3.0 Mesa 9.1-devel (git-34c58ac)
    OpenGL shading language version string: 1.30
    OpenGL extensions:
    So far so good.
    Code:
    $ DRI_PRIME=0 glxinfo | grep OpenGL
    unfortunately crashes X:
    Code:
    [  3712.534] (EE) Backtrace:
    [  3712.534] (EE) 0: /usr/bin/X (xorg_backtrace+0x36) [0x589656]
    [  3712.534] (EE) 1: /usr/bin/X (0x400000+0x18d479) [0x58d479]
    [  3712.534] (EE) 2: /usr/lib/libpthread.so.0 (0x7fa23d94c000+0xf170) [0x7fa23d95b170]
    [  3712.534] (EE) 3: /usr/bin/X (0x400000+0x15a03b) [0x55a03b]
    [  3712.534] (EE) 4: /usr/bin/X (DRI2Connect+0x77) [0x55bf27]
    [  3712.534] (EE) 5: /usr/bin/X (0x400000+0x15d0e4) [0x55d0e4]
    [  3712.534] (EE) 6: /usr/bin/X (0x400000+0x37d16) [0x437d16]
    [  3712.535] (EE) 7: /usr/bin/X (0x400000+0x268ca) [0x4268ca]
    [  3712.535] (EE) 8: /usr/lib/libc.so.6 (__libc_start_main+0xf5) [0x7fa23c5eb725]
    [  3712.535] (EE) 9: /usr/bin/X (0x400000+0x26c0d) [0x426c0d]
    [  3712.535] (EE) 
    [  3712.535] (EE) Segmentation fault at address 0x28
    [  3712.535] 
    Fatal server error:
    [  3712.535] Caught signal 11 (Segmentation fault). Server aborting
    [  3712.535] 
    [  3712.535] (EE) 
    Please consult the The X.Org Foundation support 
             at http://wiki.x.org
     for help.
    Question: Is the PRIME crash known/expected? Do I need to do something else to get it working? I got the same the last time I tried a notebook with optimus. Shall I report a bug? The HD 7970M support is maybe not ready but it surely should run glxinfo, right?


    Next I will try PCI passthrough / VGA passthrough to a windows 7 VM (I have a CPU with vt-d and even though intel says the HM77 chipset doesn't support vt-d, with a bios update it is supposed to). Let's see how that turns out.

  • #2
    Very nice report, thanks Chris!

    Comment


    • #3
      I would have liked to test fglrx/catalyst with it but even the ubuntu 12.9 beta doesn't seem to recognize the hd 7970m. Some google search results seem to say that it is supposed to work prior to 12.8 and that an october release will fix it. The same for windows.

      On windows
      - there were no drivers for ethernet, wireless, bluetooth and the card reader, second notebook where I was left without connectivity to windows update where I could have gotten that drivers
      - I could neither install the intel HD 4000 drivers nor the newest catalyst drivers from the amd website (I didn't try the beta release) I had to use the 03_VGA_AMD7970M.zip from https://www.mysn.de/secure/userarea/...p?show=Support. Unzipped it's almost 1 GB!
      But then it seemed to work - sometimes with a bit jerky rendering when I used 4x anti aliasing in skyrim and I think a little bit mouselag but fluently playable

      So for the moment the only thing left to test is vga / pci passthrough.
      For qemu it seems some patches are needed.
      vmware player doesn't seem to support pci passthrough, at least there's no gui method of setting it.
      virtualbox does support it since recently but you have to set it from the command line and I'm not sure about graphics cards passthrough. I had to change the chipset to ICH9 from the other option and windows xp (my only virtualbox vm so far) wouldn't boot, just hang there on the windows boot screen. I'm not sure it's because of the change of chipset or whether pci passthrough made it hang.
      I think the best "supported" method for vga passthrough is with xen. Many xen packages in the archlinux aur are currently marked as "out of date" so I'll see how that goes.

      Comment


      • #4
        Originally posted by ChrisXY View Post
        (I have a CPU with vt-d and even though intel says the HM77 chipset doesn't support vt-d, with a bios update it is supposed to). Let's see how that turns out.
        As it turned out it does indeed not support vt-d.

        I have tried linux 3.7-rc1 a bit and vgaswitcheroo is not stable there. I have not measured it but it seems you have a 33% chance to completely lock up the machine on switching the discrete card on or off. Also with 3.7-rc1: The fan of the HD 7970M doesn't seem to turn completely off ever.
        I think the power management header file amd released some time ago makes it first appearance in the 3.7 kernel. Maybe it is at fault.

        Comment


        • #5
          Meanwhile I'm running linux-mainline 3.7rc5 and vgaswitcheroo works fine. I disabled all power saving kernel parameters for intel and radeon and only left pcie_gen2 set to true.

          I wanted to try prime/dma-buf again and I couldn't get xrandr git to see the radeon card as provider anymore. Does anyone know what's up with that? Was it disabled because it didn't work? Or should it work and it's a bug?

          edit: Ok, I got it. You must not have any Device section in /etc/X11/xorg.conf.d/. Having both radeon and intel does not work. Maybe if both are in the same file.
          Still X crashes when trying to run glxinfo on the radeon card. Not even a graphical output, just glxinfo crashes it.
          Last edited by ChrisXY; 16 November 2012, 11:14 AM.

          Comment


          • #6
            Originally posted by ChrisXY View Post
            Still X crashes when trying to run glxinfo on the radeon card. Not even a graphical output, just glxinfo crashes it.
            I don't understand why the edit timeout is so low in this forum.

            Do I have to report that? DRI_PRIME=0 works fine. DRI_PRIME=1 is this:
            Code:
            Program received signal SIGSEGV, Segmentation fault.
            0x00000000005d66b9 in GetScreenPrime (master=0x14ce110, prime_id=1) at dri2.c:159
            159             if (ds->prime_id == prime_id)
            (gdb) bt
            #0  0x00000000005d66b9 in GetScreenPrime (master=0x14ce110, prime_id=1) at dri2.c:159
            #1  0x00000000005d6726 in DRI2GetScreenPrime (master=0x14ce110, prime_id=1) at dri2.c:170
            #2  0x00000000005d8d5a in DRI2Connect (client=0x1f242f0, pScreen=0x14ce110, driverType=65536, fd=0x7fffd72133f4, driverName=0x7fffd72133e8, 
                deviceName=0x7fffd72133e0) at dri2.c:1329
            #3  0x00000000005d99c0 in ProcDRI2Connect (client=0x1f242f0) at dri2ext.c:122
            #4  0x00000000005da930 in ProcDRI2Dispatch (client=0x1f242f0) at dri2ext.c:596
            #5  0x0000000000434168 in Dispatch () at dispatch.c:428
            #6  0x0000000000424bf9 in main (argc=7, argv=0x7fffd72135e8, envp=0x7fffd7213628) at main.c:295

            Comment


            • #7
              This thread has been immensely useful, many thanks. Unfortunately it tells me that the only way I'll be running a Linux distro on my P170em (when I get it) is from within VMWare...

              Comment


              • #8
                It's being looked at: https://bugs.freedesktop.org/show_bug.cgi?id=57200

                Maybe soon...

                Comment


                • #9
                  Well, it's alive. Will probably be in the git repositores soon.

                  Main points:
                  starting steam with the radeon card locks it up completely
                  s3tc doesn't seem to be working

                  Some simple games like supertux, minecraft, half life 1 are working fine.
                  xonotic works remarkably well.

                  I have tried exporting MESA_EXTENSION_OVERRIDE="GL_EXT_texture_compressio n_s3tc GL_S3_s3tc" but xonotic has no textures with it. Half life 2 only starts when s3tc is available and there are no textures either and it crashes.

                  Another thing that works remarkably well is webgl, I tried it in google chrome.

                  I think most of the things that don't work are limitations of radeonsi, not of prime.

                  Comment


                  • #10
                    OK, that's good news! Can you confirm that simple things like volume/brightness keys, battery life, suspend, etc. are all ok under Linux too?

                    Thanks

                    Comment

                    Working...
                    X