iommu=on results in PVE not booting at all

[andreab]

Hi,

I have an AsRock Z77 Extreme 4 (http://www.asrock.com/mb/overview.us.asp?Model=Z77 Extreme4) and an Intel i5-3550 (http://ark.intel.com/products/65516).
Both support VT-d.

Intel® Virtualization Technology (aka VT-x) and VT-d are both enabled in the BIOS/UEFI.

I want to passthrough a TV card to a Linux virtual machine (KVM or openvz, whichever works really).
To do so, I followed the simple proxmox instructions (http://pve.proxmox.com/wiki/Pci_passthrough)
but unfortunately as soon as I add "intel_iommu=on" to the command in the grub config file and reboot the computer doesn't boot anymore.

I can see the Proxmox initial mask, which means that it passes the BIOS successfully but then it goes into some sort of infinite loop.
The text on the screen flows so fast that basically it's impossible to read.

I've attached a picture of it if anyone can take a guess of what is going on.
I seem to read "DMAR" (which is related to IOMMU) as the first word on the left, not sure about the rest...

Anyway, has this happened to anyone else?
Any clue of what I should be doing?

Any help would be much appreciated.

Regards,
Andrea

 

[maxprox]

No, I don't have this error. Did you get ahead? Today I will do the same like you (it is not the first time for me) with a new system, Asus CS-B Motherboard with a Intel Xeon E3-1245 v3, 4x 3.40GHz, Sockel-1150, I will have a look regards, maxprox

 

[tin]

I realise this is an old thread, but in case it helps anyone, I'll post my 2 cents...

I want to passthrough a TV card to a Linux virtual machine (KVM or openvz, whichever works really).

If the card is supported by the Proxmox kernel out of the box and you're trying to feed it into a Linux VM, OpenVZ will be many times easier... And OpenVZ containers should run a lot smoother and use less resources.

The text on the screen flows so fast that basically it's impossible to read.

This is what Scroll Lock is for... Always give scroll lock a try in Linux systems if the text is too fast. It sometimes does nothing, but with kernel errors spewing out, it usually stops them so you can read it.

 

[andreab]

I didn't try the "scroll lock"... it's a good tip for the next time! Thanks ;-)


I was trying to passthrough a dual tuner TV card (Hauppauge WinTV Nova-T-500) to KVM as I thought it would be easier but, as tin pointed out, it actally is much easier to implement on openVZ.

Once you know what devices you want to passthrough, in my case everything under "/dev/dvb"

tree /dev/dvb/
/dev/dvb/
├── adapter0
│ ├── demux0
│ ├── dvr0
│ ├── frontend0
│ └── net0
└── adapter1
├── demux0
├── dvr0
├── frontend0
└── net0

you have to add them to "DEVNODES" on the configuration file of the openVZ machine you are targeting (eg: "/etc/vz/conf/114.conf") like this:
DEVNODES="dvb/adapter0/demux0:rw dvb/adapter0/dvr0:rw dvb/adapter0/frontend0:rw dvb/adapter0/net0:rw dvb/adapter1/demux0:rw dvb/adapter1/dvr0:rw dvb/adapter1/frontend0:rw dvb/adapter1/net0:rw"

Instead of adding the entries manually, you can also use vzctl: http://wiki.openvz.org/Devnodes

Hope it helps.
Andrea

 

[Ribs]

Hi,

Thanks for posting this. I came across this thread in a last ditch search on Google.

I had similar problems. IOMMU booted just fine, as long as the Nova T500 wasn't plugged in.

With it plugged in, I was getting a lot of errors into VT1, and in the logfiles ("DMAR:[fault reason 06] PTE Read access is not set" alongst others). And the system took a fair bit of time to boot. Once booted, it all seemed fine, but the system wasn't seeing all of the adapters that it should have.

Everywhere on the Internet seemed to point to a BIOS bug. Even after updating, I simply couldn't get it to work with the Nova plugged in.

I think it's actually the Nova card causing the problems. I understand it's actually a USB hub and has two tuners "plugged" into it. Presumably a cost cutting measure.

With your advice, I was able to get the Nova seen inside a OpenVZ container. So now my virtual machine server can run my mythtv master backend without a hitch, and using less resources than a KVM instance would have! A marked upgrade from the dual-core atom machine that it replaces.

So, thanks again for taking the time to update on the solution, it's helped out at least one person!

 

[andreab]

I'm glad to hear that it helped!

Regards,
Andrea

 

[maxprox]

No, I don't have this error. Did you get ahead? Today I will do the same like you (it is not the first time for me) with a new system, Asus CS-B Motherboard with a Intel Xeon E3-1245 v3, 4x 3.40GHz, Sockel-1150, I will have a look regards, maxprox

Maby it helps,
here is my solution for a very well running digital TV Videorecorder Linux distribution with HDTV.

My Hardware Proxmox Home Server is:
Motherboard: Asus CS-B, CPU: Intel Xeon E3-1245 v3 4x 3.40GHz Sockel-1150, RAM: 32 GB, HDD: Seagate Constellation (without any Raid)

The TV Card is:
Technotrend S2-6400 full-features HD PCIe x1

The TV Linux Distribution (VM) is:
easyVDR 2.0 (in Feb.2014:Alpha) (Ubuntu 14.04) => http://www.easy-vdr.de/

In the BIOS VT-x AND! VT-d is enabled, this is mandatory

my VMID.conf:
cat /etc/pve/nodes/proxmox/qemu-server/112.conf

boot: cdn
bootdisk: virtio0
cores: 2
hostpci0: 02:00.0      <<=
ide2: none,media=cdrom
keyboard: de
memory: 2048
name: easyvdr
net0: virtio=C2:13:C1:0F:A9:77,bridge=vmbr0
ostype: l26
sockets: 1
virtio0: local:112/vm-112-disk-1.raw,format=raw,size=23G
virtio1: wdr4t:112/vm-112-disk-1.raw,backup=no,size=976G

my root@proxmox:~# cat /etc/default/grub:

....
### gp Feb2014    
### GRUB_CMDLINE_LINUX_DEFAULT="quiet"                                                                                                    
GRUB_CMDLINE_LINUX_DEFAULT="intel_iommu=on"            
....

my root@proxmox:~# cat /etc/modprobe.d/blacklist

## only one entry 
blacklist saa7160

have a look at:
http://www.hevelmann.de/2011/10/durchgeschleift-proxmox-pci-passthrough/

root@proxmox:~# pveversion -v
proxmox-ve-2.6.32: 3.1-121 (running kernel: 2.6.32-27-pve)
pve-manager: 3.1-43 (running version: 3.1-43/1d4b0dfb)
pve-kernel-2.6.32-27-pve: 2.6.32-121
pve-kernel-2.6.32-26-pve: 2.6.32-114
lvm2: 2.02.98-pve4
clvm: 2.02.98-pve4
corosync-pve: 1.4.5-1
openais-pve: 1.1.4-3
libqb0: 0.11.1-2
redhat-cluster-pve: 3.2.0-2
resource-agents-pve: 3.9.2-4
fence-agents-pve: 4.0.5-1
pve-cluster: 3.0-12
qemu-server: 3.1-15
pve-firmware: 1.1-1
libpve-common-perl: 3.0-13
libpve-access-control: 3.0-11
libpve-storage-perl: 3.0-19
pve-libspice-server1: 0.12.4-3
vncterm: 1.1-6
vzctl: 4.0-1pve4
vzprocps: 2.0.11-2
vzquota: 3.1-2
pve-qemu-kvm: 1.7-4
ksm-control-daemon: 1.1-1
glusterfs-client: 3.4.2-1

best regards,
maxprox