I have been having this issue on other distributions as well since kernel 3.2, and I have tried every release up to 3.6.2. The issue still exists. I have tried the latest bios for the w520 as well (1.39)
Some workarounds include:
1) Use integrated graphics only
2) Use optimus with bumblebee
3) Use 32-bit instead of 64-bit
3) Disable VT-D, but leave VT-X enabled. This still allows for fast VM's, as I do not think there is an implement of VT-D yet. VT-D is PCI pass-through, and should increase speed to some calls, however VirtualBox at this time only supports VT-X.
4)Pass in "intel_iommu=off" as a kernel parameter during boot time.
I was looking around further and some say this is a bios issue with the W520 (W530 too?) where the DMA tables are not exported properly for linux to do PCI pass-through, resulting in a lockup during boot time.
It would nice for the kernel devs to fix this (yes it is an annoying bios workaround, agreed), as this is the most annoying bug I have experienced in a long time. If the table is really not being exported properly, at least show an error and move on instead of locking up.
I was looking further around the net, and saw some documentation here http://www.mjmwired.net/kernel/Documentation/Intel-IOMMU.txt and saw another possible workaround "intel_iommu=igfx_off" as a kernel parameter. I have not tested this yet as I do not have linux installed, but if anyone can try it that would provide more information about the problem. The documentation there says to submit a bug if this fixes a problem in any situations.
Another possible workaround could be to bypass the bios (if it is truely a bios bug) and use UEFI instead. I have not tried this yet.
Sorry for the long text, I figured I would let people know my experiences for over a year now with this annoying bug. For now I workaround with VT-D disabled as nothing uses it anyway. If anyone can confirm if the "intel_iommu=igfx_off" option works during boot with Discrete, 64-bit, VT-X / VT-D enabled we can work on submitting a kernel but as suggested in the documentation.
I have been having this issue on other distributions as well since kernel 3.2, and I have tried every release up to 3.6.2. The issue still exists. I have tried the latest bios for the w520 as well (1.39)
Some workarounds include:
1) Use integrated graphics only
2) Use optimus with bumblebee
3) Use 32-bit instead of 64-bit
3) Disable VT-D, but leave VT-X enabled. This still allows for fast VM's, as I do not think there is an implement of VT-D yet. VT-D is PCI pass-through, and should increase speed to some calls, however VirtualBox at this time only supports VT-X.
4)Pass in "intel_iommu=off" as a kernel parameter during boot time.
I was looking around further and some say this is a bios issue with the W520 (W530 too?) where the DMA tables are not exported properly for linux to do PCI pass-through, resulting in a lockup during boot time.
It would nice for the kernel devs to fix this (yes it is an annoying bios workaround, agreed), as this is the most annoying bug I have experienced in a long time. If the table is really not being exported properly, at least show an error and move on instead of locking up.
I was looking further around the net, and saw some documentation here http:// www.mjmwired. net/kernel/ Documentation/ Intel-IOMMU. txt and saw another possible workaround "intel_ iommu=igfx_ off" as a kernel parameter. I have not tested this yet as I do not have linux installed, but if anyone can try it that would provide more information about the problem. The documentation there says to submit a bug if this fixes a problem in any situations.
Another possible workaround could be to bypass the bios (if it is truely a bios bug) and use UEFI instead. I have not tried this yet.
Sorry for the long text, I figured I would let people know my experiences for over a year now with this annoying bug. For now I workaround with VT-D disabled as nothing uses it anyway. If anyone can confirm if the "intel_ iommu=igfx_ off" option works during boot with Discrete, 64-bit, VT-X / VT-D enabled we can work on submitting a kernel but as suggested in the documentation.