07-18-2012 08:16 PM - edited 07-18-2012 08:56 PM
After much digging, seems as though there is a BIOS bug on the W520 BIOS. The Linux kernel dev's found it, but this still applies to other operating systems, include windows.
In summary from (https://groups.google.com/forum/?fromgroups#!topic
1. W520 BIOS reports CPU is X2APIC capable
2. W520 BIOS does not export DMAR table, which is needed to enable interrupt remapping in the kernel
3. OS Kernel Hangs on boot since it it thinks CPU is X2APIC capable, does not have the information to enable it.
Seems as though this works in Windows, but not Linux. If the CPU is X2APIC cabable though, I do not see how windows can make use of this cpu feature without a DMAR table, so it must fall back to XAPIC, which means those who bought this machine from Lenovo with its advertised specifications do not get the features we expected.
This is a definite BIOS bug which I hope is addressed. The Linux kernel devs are working to fallback to XAPIC so it does not cause boot issues, but the bug still remains where we have X2APIC capable hardware but due to a BIOS bug we do not get the feature.
Excuse me if I got some of the wording wrong, I am far from a kernel developer. How can those who own this machine receive a BIOS fix? I have tried to report it VIA phone, but I am just ignored and passed to the community forums. Also the phone tech's give me grief about running anything but windows and refuse to listen to anything to I have to say about the faulty product that was sold to me ![]()
Any help appreciated on how to get a fix from Lenovo (either do not report X2APIC capabilty or export a DMAR table in the BIOS).
Thanks ...
10-19-2012 01:10 PM
Is anyone at Lenovo listening?
The BIOS is broken, please fix this bug. It's affecting both Windows and Linux users.
10-19-2012 01:20 PM
have you confirmed that the issue remains in the most current BIOS?
the original post is from July and the most recent BIOS (v1.39) shows a date of 10/2/2012 in the driver matrix:
http://support.lenovo.com/en_US/research/hints-or-
regards.
10-19-2012 01:23 PM
10-19-2012 01:25 PM - edited 10-19-2012 01:28 PM
Booting the linux kernel with nox2apic solves the problem. Looking around further, x2apic is about supporting more than 128 cpu's, which will not be likely on these laptops anyway. At this point all we can hope for is for linux kernel devs to implement he xapic fallback so we do not have to specfically boot with a kernel parameter to fix the problem.
Confirmed still broken on 1.39 as well.
11-09-2012 06:47 AM
is x2APIC merely for >128 CPU support? I believe it has to do with more than just that...
There's mention on the Internet that setting VT-d off in the BIOS fixes this... along with this, there's a rumor that re-enabling it after turning it off keeps the fix... no one has confirmed this and I am not near my machine to verify.
11-14-2012 09:50 AM
dimm0k wrote:is x2APIC merely for >128 CPU support? I believe it has to do with more than just that...
There's mention on the Internet that setting VT-d off in the BIOS fixes this... along with this, there's a rumor that re-enabling it after turning it off keeps the fix... no one has confirmed this and I am not near my machine to verify.
Is there a way/tool to see/test this in Windows for o/s independant confirmation?
Not to hijack this thread but I wonder if the suggestion to disable VT-d bypasses this of sorts. Would explain misc booting issues with Windows 8 related to having VT-d on? I definitely don't know what I'm talking about though.
11-14-2012 11:08 AM
Definitely confirmed this with kernel 3.2.x and disabling VT-d in the BIOS. Without disabling this, I have not been able to workaround this via any kernel manipulations the way some have been able to. Can't comment on Windows 7/8 since Windows 7 works fine for me whether VT-d is enabled or disabled. Kernel 2.6.x worked fine as well with VT-d enabled. There's rumors the newer 3.4.x or 3.6.x fixes this...