Bug 913326

I got it working via workarounds. I first had to put the BIOS into Legacy only mode from Both. This disabled UEFI. I then had to use pci=noacpi to get it to boot. Then I had to upgrade the nvidia driver to 313.18 from 304.64 to support the K2000M. Then it would switch from pci=noacpi to nolapic to get the nvidia driver working.

Just found the serious downside of nolapic is I only get one core. So I am going to have to keep digging for a better workaround. Though otherwise the nvidia card and driver seem to be fully working. I have triple head going via the dock.

Found disabling the VT-D option fixed it. Now no kernel command line options are required. Not to be confused with VT.

this is still an Issue, also reported here:
http://forums.lenovo.com/t5/Linux-Discussion/Using-a-monitor-with-W530-and-Ubuntu/m-p/1085615#M4867

till now, you cannot use VT-d together with nvidia with linux system (windows7 has no problems).
system freezes at startup or during operations

sorry, kernel used: 3.14.2 and nvidia-331

The same boot hang also occurs for me on my Lenovo W530 with Fedora 20.

Steps to reproduce:
1. BIOS:
   - Configure for Discrete Graphics  
   - Enable VT-x and VT-d under Security -> Virtualization
2. Use Nvidia driver
3. Configure kernel commandline *without* nox2apic
4. Boot Fedora
5. Early boot hang when udev becomes active, close to the
   likely unrelated "Could not configure common clock" message

Boot hang is 100% reproducible with the S/W versions shown below.


Option A to avoid boot hang (preferred):
Steps as above, but add nox2apic to kernel commandline

Option B to avoid boot hang:
Steps as above, but disable VT-d in BIOS


Digging further, I found the following related bugs, and infos [2] on the solution combining VT-x + VT-d with the nox2apic kernel parameter, which is preferable to disabling VT-d:

[1] https://bugzilla.kernel.org/show_bug.cgi?id=43054
[2] https://lkml.org/lkml/2011/5/23/196
[3] https://groups.google.com/forum/?fromgroups#!topic/fa.linux.kernel/iCAzjSyIHdI

[4] http://forums.lenovo.com/t5/W-Series-ThinkPad-Laptops/W520-BIOS-Bug-Please-fix-or-comment-Lenovo/td-p/802085
[5] http://forums.lenovo.com/t5/Linux-Discussion/W520-Debian-64-bit-Testing-VT-enabled/td-p/671621

Based on [1], it seems the kernel should blacklist the W530 from using x2apic if Discrete Graphics are detected.


Installed BIOS, kernel and driver
---------------------------------

# dmidecode -s bios-version && dmidecode -t11
G5ET93WW (2.53 )
# dmidecode 2.12
SMBIOS 2.7 present.
(latest BIOS is 2.59, unclear from README if it's worth updating)

# uname -r
3.15.10-201.fc20.x86_64

kmod-nvidia-3.15.10-201.fc20.x86_64-331.89-2.fc20.10.x86_64

We don't support setups with proprietary drivers.  Sorry.

Lol... closed / can'tfix 
here's a "me too" data point if anyone is still working on this. 

https://ask.fedoraproject.org/en/question/64153/aspm-could-not-configure-common-clock/

Hi I'm just adding this comment in case others find it through an internet search like I did: I had this same exact problem on a W530 (trying to use discrete graphics and seeing a hang at the ASPM message) and I was able to use comment #3's workaround by disabling VT-d (but not VT) and now it works. Thanks Nathan!

Have finally resolved this issue on my W530.  Thank you to all of the previous commenters for leads to resolution.

Running Debian with most recent Stretch kernel, 4.9.0-8.

I am using discrete graphics in BIOS, Nvidia driver, and have both VT-x and VT-d enabled in BIOS.  VMware Workstation VMs are functional.

Thanks to comments above, added no2xapic kernel option to grub config.  This resolved the occasional boot hangs.  The cannot configure common clock appeared to be harmless, just annoying.

dmesg output shows:

ACPI FADT declares the system doesn't support PCIe ASPM, so disable it

Searched for how to disable that and found, pcie-aspm=off

With both nox2apic and pcie-aspm=off kernel options, no longer have the common clock message, no boot hangs, and both full virtualization and discrete graphics are functional.

Thanks again.