Alienware M11X Thread

[fedcb22]

Originally Posted by docdrow

Here's the latest.. I discovered that in fact there are ACPI Methods for control of the GPUs, however, they are not in the main DSDT table. I posted a dump of the SSDT table for the NVidia rom here:

Hybrid Graphics Linux mailing list

It's gonna take someone who knows Linux and ACPI better than I to integrate support for the R2. But, I think I'm barkin' up the right tree.

I believe that vga_switcherroo would work for us if the method were defined in the main DSDT. If someone updated the code to look in the SSDT, maybe it would work?

Beyond my skill level or time to learn the skill at this point. But.. as I get time I continue to tinker

I'm wondering if you've seen the post at http://linux-hybrid-graphics.blogspo...sus-u43jc.html

It looks like we may have a similar "problem" with the line

If (LEqual (\_SB.PCI0.P0P2.PEGP.OMPR, 0x03))

Although I'm not entirely sure. Busy recompiling my kernel with ACPI debug support, and hopefully messing about with the SSDT will yield some results

[fedcb22]

Good news everyone! It looks like I've gotten disabling that power-gobbling Nvidia card to work

# cat /proc/acpi/battery/BAT1/state
present:                 yes
capacity state:          ok
charging state:          discharging
present rate:            21925 mW
remaining capacity:      65930 mWh
present voltage:         16473 mV
# cat dd/test.aml >> /sys/kernel/debug/acpi/custom_method 
# insmod acpi_call/acpi_call.ko
# echo '\_SB.PCI0.P0P2.PEGP._PS3' > /proc/acpi/call
<Wait a bit for the results to settle>
# cat /proc/acpi/battery/BAT1/state
present:                 yes
capacity state:          ok
charging state:          discharging
present rate:            15459 mW
remaining capacity:      64790 mWh
present voltage:         16446 mV

Looks like a ~6500mW decrease in power consumption to me
I'll post a howto in a sec.

---------- Post added at 03:41 PM CDT ---------- Previous post was at 03:35 PM CDT ----------

And the how-to:
Create a file called override.asl with the following contents:

DefinitionBlock ("", "SSDT", 1, "", "", 0x20080715)
{
External (P80H)
External (SETF)
External (LNKD)
External (RLNK)
External (\_SB.PCI0.P0P2.PEGP.OMPR)
External (\_SB.PCI0.P0P2.PEGP.VGAB)
External (\_SB.PCI0.P0P2.PEGP.PO16)
External (\_SB.PCI0.P0P2.PEGP.PO36)
External (DGOS)
External (_PSC)
External (\_SB.PCI0.P0P2.VGAR)

        Method (\_SB.PCI0.P0P2.PEGP._PS3, 0, NotSerialized)
        {
            Store (0x03, P80H)
            Store ("NVGA_PS3_STR", Debug)
            //If (LEqual (\_SB.PCI0.P0P2.PEGP.OMPR, 0x03))
            //{
                Store (\_SB.PCI0.P0P2.VGAR, \_SB.PCI0.P0P2.PEGP.VGAB)
                Store (One, SETF)
                Store (One, LNKD)
                Store (One, RLNK)
                If (Ones)
                {
                    Store (Zero, \_SB.PCI0.P0P2.PEGP.PO16)
                }
                Else
                {
                    Store (One, \_SB.PCI0.P0P2.PEGP.PO16)
                }

                If (Ones)
                {
                    Store (Zero, \_SB.PCI0.P0P2.PEGP.PO36)
                }
                Else
                {
                    Store (One, \_SB.PCI0.P0P2.PEGP.PO36)
                }

                Store (One, DGOS)
                Store (0x02, \_SB.PCI0.P0P2.PEGP.OMPR)
            //}

            Store (0x03, _PSC)
        }
}

Use iasl to compile this down to bytecode

# iasl override.asl

This will give you override.aml. Mount debugfs

# mount -t debugfs none /sys/kernel/debugfs

And insert out custom method

# override.aml >> /sys/kernel/debug/acpi/custom_method

Finally make sure acpi_call is loaded, and call the _PS3 function

# echo '\_SB.PCI0.P0P2.PEGP._PS3' > /proc/acpi/call

I've gone by memory here, so let me know if any of the steps don't work...

[erroneus]

Most impressive. Just about all of that went way over my head. Is it possible to package up things that we can just "download this" and then "put this here, that there and change this file here"?

You really seem to know a lot more than most of us. Any chance you could figure out a way to get access to certain sensor data?

---

I am unable to follow along. The part where I try to mount /sys/kernel/debugfs was wrong. It seemed to work when I changed that to /sys/kernel/debug but there was no acpi in the /sys/kernel/debug folder.

Following that, I am uncertain about the whole override.aml >> command line

[fedcb22]

Originally Posted by erroneus

Most impressive. Just about all of that went way over my head. Is it possible to package up things that we can just "download this" and then "put this here, that there and change this file here"?

You really seem to know a lot more than most of us. Any chance you could figure out a way to get access to certain sensor data?

---

I am unable to follow along. The part where I try to mount /sys/kernel/debugfs was wrong. It seemed to work when I changed that to /sys/kernel/debug but there was no acpi in the /sys/kernel/debug folder.

Following that, I am uncertain about the whole override.aml >> command line

Hmm, truth be told, I don't actually run Fedora - I'm an ArchLinux user (hope I don't get banned :P ), but I think it was your post about the SSDT that gave me the idea about where to look.

Oops, that was a typo on my part, it was meant to be /sys/kernel/debug. Which kernel are you running, and what do you see in that folder?

What sensor data are you speaking of?

On a side note, my power consumption under Linux, backlight low with WiFi on and browsing the web is round about 12-13W, which beats Windows in my case

[erroneus]

Contributions of information and research are all good no matter where they come from.

Yeah, got the /sys/kernel/debug mounted and new things appear, just not acpi. What appears is:

bdi, bluetooth, boot_params, dri, dynamic_debug, hid, ieee80211, kprobes, mmc0, sched_features, slow_work, tracing, usb, x86, xen

All are directories except sched_features.

uname reveals: 2.6.34.7-56.fc13.x86_64 as the kernel.

The sensor data I speak of is that which tells the temperature of the video and other chips on the system board. The only temperature I can get is from the hard drive.

[docdrow]

Excellent find! I missed that thread. It looks like this is a 'hack' rather than a problem to get past 0x03 being stored at that location.

There's reference to that in the NVOP method, so I'm guessing that NVOP could still be used prior or is some combination with calling PS3 to achieve this without avoiding that if().

Hmm..

erroneus, you'll need to do: yum -y install kernel-debug

And reboot on the debug enabled kernel. With debug options enabled, however, your system may run significantly slower.

So.. we may have to build a custom kernel with just ACPI DEBUG enabled for Fedora. *sigh*

-G

[erroneus]

Yuk. I don't like either suggestion. Couldn't the acpi_call.ko get modified to accommodate this?

On an unrelated note, I found another problem. Moments ago, I unplugged my machine from wired network and power to move to another desk. When I came back and plugged back in, I could not connect to the network. The light would not return on the network connection and the machine just thought the network cable was unplugged.

What would cause this?

The problem is consistent. Unplugging the network cable and plugging it back in results in loss of networking. This is really bad.

#rmmod atl1c
#insmod atl1c.ko

fixes it... but sheesh. This kernel module can't handle being unplugged? Did I just find a bug? Does anyone else have this?

[docdrow]

I'm toying with a hacked acpi_call.c rigtht now Stay tuned...

[docdrow]

Experiment with this for me guys.. I took acpi_call.c and made a test/hack to call NVOP ACPI method first, then PS3 second. I spent more time than I care to admit looking at the ACPI Spec (section 18), and trying to understand what options to pass to NVOP.

Looks like I got lucky

Just take this m11xr2hack.c and replace your acpi_call.c (or add m11xr2hack.c to the Makefile)

build it, and insmod it.. Thats it.. My battery usage dropped from 17000 mW to about 13000 mW.

Let em know if you have any luck. I'm going to experiment with NVOP and turning the GPU on, and see if I can get nouveau working.

_G

[erroneus]

I will get to this first thing when I get into the office this morning. You, sir, are a god compared to me. I am humbled and humiliated in your presence. Now let's see if I can figure out how to add this to the make file on my own. Could this be an exception for once where a Fedora user will win the race before an Ubuntu user?

[fedcb22]

Originally Posted by docdrow

Experiment with this for me guys.. I took acpi_call.c and made a test/hack to call NVOP ACPI method first, then PS3 second. I spent more time than I care to admit looking at the ACPI Spec (section 18), and trying to understand what options to pass to NVOP.

Looks like I got lucky

Just take this m11xr2hack.c and replace your acpi_call.c (or add m11xr2hack.c to the Makefile)

build it, and insmod it.. Thats it.. My battery usage dropped from 17000 mW to about 13000 mW.

Let em know if you have any luck. I'm going to experiment with NVOP and turning the GPU on, and see if I can get nouveau working.

_G

Great work! This is far more elegant than my hacked up override method. As for using the Nvidia, I'm not sure how easy that's going to be. The Nvidia card is connected to the Intel GPU, not to the screen directly. AFAIK some work was being done on this (See the PRIME project), but that was to do with an ATI card.

On the other hand, I don't see why it wouldn't be possible to use the Nvidia card for CUDA and the like.

[evad]

Originally Posted by docdrow

Experiment with this for me guys.. I took acpi_call.c and made a test/hack to call NVOP ACPI method first, then PS3 second. I spent more time than I care to admit looking at the ACPI Spec (section 18), and trying to understand what options to pass to NVOP.

Looks like I got lucky :)

Just take this m11xr2hack.c and replace your acpi_call.c (or add m11xr2hack.c to the Makefile)

build it, and insmod it.. Thats it.. My battery usage dropped from 17000 mW to about 13000 mW.

Hmm, make fails for me (after replacing original acpi_call.c from linux-hybrid-graphics with your file):

[root@v3300 acpi_call]# make
make -C /lib/modules/2.6.34.7-56.fc13.i686.PAE/build M=/home/adl/Downloads/acpi_call modules
make[1]: Entering directory `/usr/src/kernels/2.6.34.7-56.fc13.i686.PAE'
  CC [M]  /home/adl/Downloads/acpi_call/acpi_call.o
/home/adl/Downloads/acpi_call/acpi_call.c: In function ‘do_acpi_call’:
/home/adl/Downloads/acpi_call/acpi_call.c:48: error: ‘meh’ undeclared (first use in this function)
/home/adl/Downloads/acpi_call/acpi_call.c:48: error: (Each undeclared identifier is reported only once
/home/adl/Downloads/acpi_call/acpi_call.c:48: error: for each function it appears in.)
/home/adl/Downloads/acpi_call/acpi_call.c:20: warning: unused variable ‘hack’
make[2]: *** [/home/adl/Downloads/acpi_call/acpi_call.o] Error 1
make[1]: *** [_module_/home/adl/Downloads/acpi_call] Error 2
make[1]: Leaving directory `/usr/src/kernels/2.6.34.7-56.fc13.i686.PAE'
make: *** [default] Error 2

Btw, I have Dell Vostro 3300 with Optimus Intel+nVidia combo, whereas I'm very interested to get only nVidia running, so I greatly appreciate your effort and findings, and waiting for the case to evolve! :)

[erroneus]

Originally Posted by evad

Btw, I have Dell Vostro 3300 with Optimus Intel+nVidia combo, whereas I'm very interested to get only nVidia running, so I greatly appreciate your effort and findings, and waiting for the case to evolve!

As I understand it, the Intel part is the one with the direct connection to video. So at the very least, the Intel part needs to be set up to do some sort of pass-through mode. I may need to pay closer attention to what is going on but from what I have heard, even on the Windows side making full use of the nVidia GPU is not easily done. One person with a machine similar to mine (M11x R2) says he was playing one of the games he plays and didn't get much improvement in game play performance at all that he could tell. I think part of the problem was that he is running 64 bit Windows while running a 32 bit game. But as you can see, challenges are all around.

Ultimately what will need to happen is that Intel needs to share with the world what it has done. It will be an Intel driver update that will enable all other things to happen I think.

[MrMEEE]

Originally Posted by fedcb22

Good news everyone! It looks like I've gotten disabling that power-gobbling Nvidia card to work

# cat /proc/acpi/battery/BAT1/state
present:                 yes
capacity state:          ok
charging state:          discharging
present rate:            21925 mW
remaining capacity:      65930 mWh
present voltage:         16473 mV
# cat dd/test.aml >> /sys/kernel/debug/acpi/custom_method 
# insmod acpi_call/acpi_call.ko
# echo '\_SB.PCI0.P0P2.PEGP._PS3' > /proc/acpi/call
<Wait a bit for the results to settle>
# cat /proc/acpi/battery/BAT1/state
present:                 yes
capacity state:          ok
charging state:          discharging
present rate:            15459 mW
remaining capacity:      64790 mWh
present voltage:         16446 mV

Looks like a ~6500mW decrease in power consumption to me
I'll post a howto in a sec.

---------- Post added at 03:41 PM CDT ---------- Previous post was at 03:35 PM CDT ----------

And the how-to:
Create a file called override.asl with the following contents:

DefinitionBlock ("", "SSDT", 1, "", "", 0x20080715)
{
External (P80H)
External (SETF)
External (LNKD)
External (RLNK)
External (\_SB.PCI0.P0P2.PEGP.OMPR)
External (\_SB.PCI0.P0P2.PEGP.VGAB)
External (\_SB.PCI0.P0P2.PEGP.PO16)
External (\_SB.PCI0.P0P2.PEGP.PO36)
External (DGOS)
External (_PSC)
External (\_SB.PCI0.P0P2.VGAR)

        Method (\_SB.PCI0.P0P2.PEGP._PS3, 0, NotSerialized)
        {
            Store (0x03, P80H)
            Store ("NVGA_PS3_STR", Debug)
            //If (LEqual (\_SB.PCI0.P0P2.PEGP.OMPR, 0x03))
            //{
                Store (\_SB.PCI0.P0P2.VGAR, \_SB.PCI0.P0P2.PEGP.VGAB)
                Store (One, SETF)
                Store (One, LNKD)
                Store (One, RLNK)
                If (Ones)
                {
                    Store (Zero, \_SB.PCI0.P0P2.PEGP.PO16)
                }
                Else
                {
                    Store (One, \_SB.PCI0.P0P2.PEGP.PO16)
                }

                If (Ones)
                {
                    Store (Zero, \_SB.PCI0.P0P2.PEGP.PO36)
                }
                Else
                {
                    Store (One, \_SB.PCI0.P0P2.PEGP.PO36)
                }

                Store (One, DGOS)
                Store (0x02, \_SB.PCI0.P0P2.PEGP.OMPR)
            //}

            Store (0x03, _PSC)
        }
}

Use iasl to compile this down to bytecode

# iasl override.asl

This will give you override.aml. Mount debugfs

# mount -t debugfs none /sys/kernel/debugfs

And insert out custom method

# override.aml >> /sys/kernel/debug/acpi/custom_method

Finally make sure acpi_call is loaded, and call the _PS3 function

# echo '\_SB.PCI0.P0P2.PEGP._PS3' > /proc/acpi/call

I've gone by memory here, so let me know if any of the steps don't work...

Hi..

# mount -t debugfs none /sys/kernel/debugfs

should be changed to:

# mount -t debugfs none /sys/kernel/debug

and

# override.aml >> /sys/kernel/debug/acpi/custom_method

to

# cat override.aml >> /sys/kernel/debug/acpi/custom_method


Also.. the standard acpi_call module should be installed:

<code>
git clone http://github.com/mkottman/acpi_call.git

cd acpi_call

make

sudo insmod acpi_call.ko
</code>

[docdrow]

Sorry, I had a typo in mine. No need for that debug kernel now guys! Here ya go.

In /etc/rc.d/rc.local put:

echo 0 >/sys/bus/pci/devices/0000:01:00.0/enable
echo 1 >/sys/bus/pci/devices/0000:01:00.0/remove
/sbin/insmod /usr/local/lib/m11xr2hack.ko
/sbin/rmmod /usr/local/lib/m11xr2hack.ko

Make sure you blacklist nouveau:

echo blacklist nouveau >/etc/modprobe.d/blacklist-nouveau.conf

And rebuild your initrd after placing that blacklist file in modprobe.d:

/sbin/new-kernel-pkg --package kernel --mkinitrd --dracut --depmod --install $(uname -r)

And finally, build this hack module You'll have to do this everytime you update your kernel:

make clean
make
mv m11xr2hack.ko /usr/local/lib
chmod 0400 /usr/local/lib/m11xr2hack.ko

See attached Makefile and m11xr2hack.c

-George