HCL Report Lenovo 440P with Nvidia Discreet

Skip to first unread message


Sep 30, 2015, 5:00:37 AM9/30/15
to qubes-users
Here is the report on a brand new (Sept 2015) Lenovo 440P with discreet Nividia.

Key note: Lenovo on the 440P model has removed the bios module that gives switchable control over the display adapters. 

On all other models I have had you had options to always have switched/optimus and intel only disabling the discreet card.  As they mainly cater to Windows they have allowed the control to go to the drivers thru OS. Thus you are stuck disabling it via Modset and blacklist. 
  • Vt-d/IOMMU: Yes
  • Vt-x: Yes
  • TMP:Yes 
As I have only run it off the USB drive I have not trying creating a USBVM.

Despite the issues with the lose of the display disable function in the bios I find Lenovo T series has one of the most option rich bios found in laptops.   While I am not one to trust SED encrypt given its blackbox nature I have to use one for consulting per customer contract opsec requirements. Using mdsed to configure Opal 2 options for a linux option.   The one thing I do like about the SED function is the secure erase feature (if its not been purposely broken).  Ideally I am hoping to get a program written to allow a different password at the same prompt to script the secure erase function.  Thus if made to give up a password I can wipe the whole drive.

I am wondering the opal 2.0 SED effects will have with AEM function but will not be getting around to that until I get the new laptop.

I was running the qubes off fast flash drive as without the bios control over the discreet card I was not sure if I was keeping it and have decided to swap it for a intel only version (The Nvidia cards are soldered onto the motherboard BTW)

I have run been in charge of Windows only shop for years so my Linux fu is very very rough.  But even though I can not recall how to much of anything from a linux shell was able to simply use the commands listed in the old https://www.qubes-os.org/doc/InstallNvidiaDriver/ how to.

created: nouveau-disable.conf is /etc/modprobe.d/

cat /etc/modprobe.d/nouveau-disable.conf

added line blacklist nouveau to above file

/etc/default/grub added line:

GRUB_CMDLINE_LINUX="quiet rhgb nouveau.modeset=0 rd.driver.blacklist=nouveau video=vesa:off"

regenerated grub via: grub2-mkconfig -o /boot/grub2/grub.cfg

After a reboot the weird unresponsive periods that happened every few minutes stopped.

But I did find that this does not fully disable the power to the nvidia card thus you are still running higher
watt draw than needed.

It seems that whatever Lenovo has done in there powermanagment you need to actually manually enter

acpi_calls for the kernel so that it will fully disable this card and get you back a good amount of power watts.

If you are not worried about this power drain then the above seemed to work in terms of useage for the short time I have
played with it. If not you need to take further steps below that I found thru researching a bug o github with bumblebee
bbswitch which basically makes the acpi calls. Here is the thread: https://github.com/Bumblebee-Project/bbswitch/issues/78

If you follow the comment posts about half way down the list you will find post :


He gave the best consolidated instructions that could otherwise be found by picking thru the whole thread as I did so I figured I would c&p it here for anyone that may need it or choose to use it:
mkottman created a small  acpi calls program on github here: https://github.com/mkottman/acpi_call
git clone https://github.com/mkottman/acpi_call
cd acpi_call
sudo cp acpi_call
.ko /lib/modules/`uname -r`/kernel/drivers/acpi
sudo depmod
sudo modprobe acpi_call

Create a script with the following in it (e.g. at /usr/local/bin/disable_nvidia.sh, remember chmod +x it):

echo "\_SB.PCI0.PEG.VID._DSM {0xF8,0xD8,0x86,0xA4,0xDA,0x0B,0x1B,0x47,0x60,0x42,0xA6,0xB5,0xBE,0xE0} 0x100 0x1A {0x1,0x0,0x0,0x3}" >/proc/acpi/call
echo "\_SB.PCI0.PEG.VID.GPOF" >/proc/acpi/call
exit 0

  • Call the script from /etc/rc.local
  • Add rdblacklist=nouveau i965.modeset=1 nouveau.modeset to the GRUB_CMDLINE_LINUX_DEFAULT flags in /etc/default/grub, also for full KVM support (e.g. better brightness control etc.) I've found adding acpi_osi=\"!Windows 2012\" helps too.
  • run sudo update-grub
His next post states :

You may also need to force the disable on resume, create a /etc/pm/sleep.d/10_disable_nvidia:
case $1 in

I thought this could all be of possible use to many others than have issue with disabling their nvidia cards. The info at the
various links should give info for what acpi calls need to be made to fully disable the cards in much the same way as if the bios
itself had the module to do so.

BTW I would like to give a huge prop to the Lenovo customer support team I dealt with a Regina Goods out of North Carolina center.
She was fantastic. First tech support found that the ones in charge of bios support would not that what would be
5-15mins to send me a bios flash with the added display module. They were also suprised it was not in the bios themselves.
They immediately offered to take back the laptop and send a new one out to me without the nvidia card. I also got to keep this one
till the other arrives and then rma it back to them.

Otherwise everything after initial install AND FULL UPDATING seems functional and without issues. Whonix was very irratic with stutterin
effect trying to scroll in the browser etc. Updating took care of this. You must do this from the terminal. The auto update and
scripted does not seem to work and I do believe is documented IIRC.

The only issue I seem to have which I am thinking maybe a issue of the fact its on a flash drive but feel I need to mention:
For the initial Luk encryption password credentials box. If I enter my password immediately when it shows up on the screen and press enter
the system ended up not loading and I end up at a cmd shell prompt to save the log file. But if I wait till the status bar
shows its 3/4 finished it will load fine and I get the standard OS login and everything is fine from that point.

I have to give enormous props to Joanna, Marek,and rest of the those doing the dev work. Qubes 3.0 is a far cry from the the very rendition
Joanna first released for experimentation. Its a huge jump forward. At this point its fully usable and configurable for an experienced Linux
 user or anyone willing to take some time to search thru the doc and group etc. the fact I have extremely spare contact with linux boxes
(and not much prior)since Qubes was initially released and yet was able to load and configure this on a flash drive speaks volumes to all the hard work
that has gone into this project and the OS's level of maturity.



Reply all
Reply to author
Message has been deleted
0 new messages