MSattler

So I have a Quadro RTX4000 that works splendid 99.9% of the time. Sometimes though my family complains that most movies will simply not play. When I check the Plex Logs I see: TPU: hardware transcoding: enabled, but no hardware decode accelerator found A restart of the plex container does not fix this, only a complete restart of unraid get's me back to transcodes working. Now I remember for years we sometimes had issues where containers would have the ability to communicate with the video card, but not transcode. I'm assuming this is the same thing. is there a way for me to forcefully reset the video card without a reboot? Right now I have a script running that emails me when this starts occurring so I can reboot it myself. If I can script the resolution without a reboot, that would be preferable. Drivers I'm running: NVIDIA-SMI 535.104.05 Driver Version: 535.104.05 CUDA Version: 12.2 Thanks!

Resurrecting this thread to see if this old patch works on the newer builds. I have a different card on the way with LSI firmware but like to see if I can get this 8003 card working.

Wondering this as well

If the interface is for VM's, the interface itself doesn't need a gateway. The VM's themselves would have the gateway set, the nic would just be the connection. At least that's how it works on the VMWare side. I don't run any VM's on my unraid boxes.

Typically you should only have one default gw. You can add a route specific for the /24 on eth 2. Not sure where to store it so it's added on every future reboot.

Ah ok. Yup that makes total sense. Will do that tomm. thanks!

All, I have a somewhat weird config. eth0 - 1Gbe NIC Onboard eth1 - 10Gb Mellanox ConnectX-2 NIC Basically what I want to do is use the 1Gbe NIC for managing the unraid host. The 10Gb interface would be used for host access. The thing is that I cannot find anyway to assign the gateway/dns to eth1. unRaid automatically wants me to assign the gateway to eth0. Basically I have this setup, and it works, but it looks funky in the gui: eth0 - 10.10.10.42 / 255.255.255.0 / GW 192.168.1.1 / DNS 192.168.1.1 eth1 - 192.168.1.42 / 255.255.255.0 Is there a way to switch the interfaces around so that I'm assigning the gateway with the right interface?

Fixed it. Thanks!

So just updated one tower from 6.2.4 to 6.3.1. Everything went find except I no longer see all network interfaces. Both servers have the onboard NIC, and then a quad port nic. 6.2.4 is still fine. On 6.3.1 I see eth0, eth1, and then eth118. I had to unplug the last two connections else I would drop pings. I never had an issue before connecting 5 x 1 Gbe through the LAG on my switch. I would see all 5 interfaces come up. Working tower on 6.2.4: root@Tower:~# dmesg | grep eth [ 9.573807] tg3 0000:08:00.0 eth0: Tigon3 [partno(BCM57781) rev 57785100] (PCI Express) MAC address bc:5f:f4:87:19:e6 [ 9.573892] tg3 0000:08:00.0 eth0: attached PHY is 57765 (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1]) [ 9.574016] tg3 0000:08:00.0 eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1] [ 9.574068] tg3 0000:08:00.0 eth0: dma_rwctrl[00000001] dma_mask[64-bit] [ 9.765278] igb 0000:03:00.0: eth1: (PCIe:2.5Gb/s:Width x4) 00:1b:21:42:8a:08 [ 9.765340] igb 0000:03:00.0: eth1: PBA No: Unknown [ 9.953454] igb 0000:03:00.1: eth2: (PCIe:2.5Gb/s:Width x4) 00:1b:21:42:8a:09 [ 9.953521] igb 0000:03:00.1: eth2: PBA No: Unknown [ 10.159261] igb 0000:04:00.0: eth3: (PCIe:2.5Gb/s:Width x4) 00:1b:21:42:8a:0c [ 10.159334] igb 0000:04:00.0: eth3: PBA No: Unknown [ 10.365182] igb 0000:04:00.1: eth4: (PCIe:2.5Gb/s:Width x4) 00:1b:21:42:8a:0d [ 10.365232] igb 0000:04:00.1: eth4: PBA No: Unknown [ 20.042353] tg3 0000:08:00.0 eth0: Tigon3 [partno(BCM57781) rev 57785100] (PCI Express) MAC address bc:5f:f4:87:19:e6 [ 20.042358] tg3 0000:08:00.0 eth0: attached PHY is 57765 (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1]) [ 20.042361] tg3 0000:08:00.0 eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1] [ 20.042364] tg3 0000:08:00.0 eth0: dma_rwctrl[00000001] dma_mask[64-bit] [ 20.252389] igb 0000:03:00.0: eth1: (PCIe:2.5Gb/s:Width x4) 00:1b:21:42:8a:08 [ 20.252393] igb 0000:03:00.0: eth1: PBA No: Unknown [ 20.459400] igb 0000:03:00.1: eth2: (PCIe:2.5Gb/s:Width x4) 00:1b:21:42:8a:09 [ 20.459404] igb 0000:03:00.1: eth2: PBA No: Unknown [ 20.656405] igb 0000:04:00.0: eth3: (PCIe:2.5Gb/s:Width x4) 00:1b:21:42:8a:0c [ 20.656409] igb 0000:04:00.0: eth3: PBA No: Unknown [ 20.853399] igb 0000:04:00.1: eth4: (PCIe:2.5Gb/s:Width x4) 00:1b:21:42:8a:0d [ 20.853403] igb 0000:04:00.1: eth4: PBA No: Unknown [ 21.518242] bond0: Enslaving eth0 as an active interface with a down link [ 21.769348] 8021q: adding VLAN 0 to HW filter on device eth1 [ 21.769559] bond0: Enslaving eth1 as an active interface with a down link [ 22.022354] 8021q: adding VLAN 0 to HW filter on device eth2 [ 22.022541] bond0: Enslaving eth2 as an active interface with a down link [ 22.275346] 8021q: adding VLAN 0 to HW filter on device eth3 [ 22.275539] bond0: Enslaving eth3 as an active interface with a down link [ 22.528361] 8021q: adding VLAN 0 to HW filter on device eth4 [ 22.528571] bond0: Enslaving eth4 as an active interface with a down link [ 24.232944] igb 0000:03:00.0 eth1: igb: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX [ 24.264441] bond0: link status definitely up for interface eth1, 1000 Mbps full duplex [ 24.366671] tg3 0000:08:00.0 eth0: Link is up at 1000 Mbps, full duplex [ 24.366679] tg3 0000:08:00.0 eth0: Flow control is off for TX and off for RX [ 24.366683] tg3 0000:08:00.0 eth0: EEE is enabled [ 24.457949] igb 0000:03:00.1 eth2: igb: eth2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX [ 24.464455] bond0: link status definitely up for interface eth0, 1000 Mbps full duplex [ 24.464458] bond0: link status definitely up for interface eth2, 1000 Mbps full duplex [ 24.774960] igb 0000:04:00.0 eth3: igb: eth3 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX [ 24.864470] bond0: link status definitely up for interface eth3, 1000 Mbps full duplex [ 25.026975] igb 0000:04:00.1 eth4: igb: eth4 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX [ 25.064480] bond0: link status definitely up for interface eth4, 1000 Mbps full duplex [ 34.874785] mdcmd (34): set md_write_method Non working Tower on 6.3.1: root@Tower2:~# dmesg | grep eth [ 12.685324] alx 0000:03:00.0 eth0: Qualcomm Atheros AR816x/AR817x Ethernet [e8:39:35:0e:06:41] [ 12.882026] e1000e 0000:06:00.0 eth1: (PCI Express:2.5GT/s:Width x4) e8:39:35:0e:06:41 [ 12.882190] e1000e 0000:06:00.0 eth1: Intel® PRO/1000 Network Connection [ 12.882422] e1000e 0000:06:00.0 eth1: MAC: 0, PHY: 4, PBA No: D98771-010 [ 13.049996] e1000e 0000:06:00.1 eth2: (PCI Express:2.5GT/s:Width x4) e8:39:35:0e:06:40 [ 13.050160] e1000e 0000:06:00.1 eth2: Intel® PRO/1000 Network Connection [ 13.050391] e1000e 0000:06:00.1 eth2: MAC: 0, PHY: 4, PBA No: D98771-010 [ 16.125588] alx 0000:03:00.0 eth0: Qualcomm Atheros AR816x/AR817x Ethernet [e8:39:35:0e:06:41] [ 16.313898] e1000e 0000:06:00.0 eth1: (PCI Express:2.5GT/s:Width x4) e8:39:35:0e:06:41 [ 16.313911] e1000e 0000:06:00.0 eth1: Intel® PRO/1000 Network Connection [ 16.313989] e1000e 0000:06:00.0 eth1: MAC: 0, PHY: 4, PBA No: D98771-010 [ 16.314664] e1000e 0000:06:00.0 eth118: renamed from eth1 [ 16.489959] e1000e 0000:06:00.1 eth1: (PCI Express:2.5GT/s:Width x4) e8:39:35:0e:06:40 [ 16.489963] e1000e 0000:06:00.1 eth1: Intel® PRO/1000 Network Connection [ 16.490040] e1000e 0000:06:00.1 eth1: MAC: 0, PHY: 4, PBA No: D98771-010 [ 46.735221] bond0: Enslaving eth0 as an active interface with a down link [ 46.736114] alx 0000:03:00.0 eth0: NIC Up: 1 Gbps Full [ 46.996271] 8021q: adding VLAN 0 to HW filter on device eth1 [ 46.996569] bond0: Enslaving eth1 as an active interface with a down link [ 46.998030] bond0: link status definitely up for interface eth0, 1000 Mbps full duplex [ 47.008680] e1000e 0000:06:00.1 eth1: changing MTU from 1500 to 9014 [ 47.204165] alx 0000:03:00.0 eth0: NIC Up: 1 Gbps Full [ 47.211283] device eth0 entered promiscuous mode [ 47.211350] device eth1 entered promiscuous mode [ 49.720842] e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None [ 49.812009] bond0: link status definitely up for interface eth1, 1000 Mbps full duplex [ 106.966331] udevd[1459]: Error changing net interface name eth118 to eth0: File exists [ 131.519290] alx 0000:03:00.0 eth0: Link Down [ 131.553699] bond0: link status definitely down for interface eth0, disabling it [ 138.635053] alx 0000:03:00.0 eth0: NIC Up: 1 Gbps Full [ 138.729493] bond0: link status definitely up for interface eth0, 1000 Mbps full duplex [ 151.880355] mdcmd (34): set md_write_method [ 193.170137] device eth0 left promiscuous mode [ 193.170204] device eth1 left promiscuous mode [ 193.211403] bond0: Releasing backup interface eth0 [ 193.211406] bond0: the permanent HWaddr of eth0 - e8:39:35:0e:06:41 - is still in use by bond0 - set the HWaddr of eth0 to a different address to avoid conflicts [ 193.225806] bond0: Releasing backup interface eth1 [ 193.412912] e1000e: eth1 NIC Link is Down [ 193.413122] e1000e 0000:06:00.1 eth1: changing MTU from 9014 to 1500 [ 193.650607] bond0: Enslaving eth0 as an active interface with a down link [ 193.651480] alx 0000:03:00.0 eth0: NIC Up: 1 Gbps Full [ 193.904120] 8021q: adding VLAN 0 to HW filter on device eth118 [ 193.904438] bond0: Enslaving eth118 as an active interface with a down link [ 193.905864] bond0: link status definitely up for interface eth0, 1000 Mbps full duplex [ 194.160101] 8021q: adding VLAN 0 to HW filter on device eth1 [ 194.160454] bond0: Enslaving eth1 as an active interface with a down link [ 194.173071] e1000e 0000:06:00.0 eth118: changing MTU from 1500 to 9014 [ 194.367164] e1000e 0000:06:00.1 eth1: changing MTU from 1500 to 9014 [ 194.559910] alx 0000:03:00.0 eth0: NIC Up: 1 Gbps Full [ 194.567501] device eth0 entered promiscuous mode [ 194.567586] device eth118 entered promiscuous mode [ 194.567601] device eth1 entered promiscuous mode [ 196.845673] e1000e: eth118 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None [ 196.855830] bond0: link status definitely up for interface eth118, 1000 Mbps full duplex [ 197.060656] e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None [ 197.063839] bond0: link status definitely up for interface eth1, 1000 Mbps full duplex [ 222.386136] e1000e: eth118 NIC Link is Down [ 222.463073] bond0: link status definitely down for interface eth118, disabling it [ 230.686266] alx 0000:03:00.0 eth0: Link Down [ 230.702895] bond0: link status definitely down for interface eth0, disabling it [ 237.764696] e1000e: eth1 NIC Link is Down [ 237.774638] bond0: link status definitely down for interface eth1, disabling it [ 245.289946] alx 0000:03:00.0 eth0: NIC Up: 1 Gbps Full [ 245.366477] bond0: link status definitely up for interface eth0, 1000 Mbps full duplex [ 377.865520] e1000e: eth118 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None [ 377.906686] bond0: link status definitely up for interface eth118, 1000 Mbps full duplex [ 410.712768] e1000e: eth118 NIC Link is Down [ 410.769687] bond0: link status definitely down for interface eth118, disabling it [ 415.221476] e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None [ 415.241635] bond0: link status definitely up for interface eth1, 1000 Mbps full duplex [ 416.348617] e1000e: eth1 NIC Link is Down [ 416.385529] bond0: link status definitely down for interface eth1, disabling it [ 419.081273] e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None [ 419.089441] bond0: link status definitely up for interface eth1, 1000 Mbps full duplex [ 548.350670] e1000e: eth118 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None [ 548.421823] bond0: link status definitely up for interface eth118, 1000 Mbps full duplex thoughts? Thanks!

I like that. That way when copying things between unRaid servers I'm not crushing the main interfaces. Granted, drive access may be slowed if they grab something from that drive. I was thinking about grabbing a Quanta LB6M, and trunking the ethernet ports to my main ethernet switches, and switching all my servers over to IPoIB.

Did you get any feedback on this elsewhere? Thanks!

So what are you guys using for your config file? I am now running 2 CyberPower 1500's. One for my Emby Server, ESXi Host, and router, another for 2 unRaid servers and a Cisco switch. I'd like the one 1500 to shut down both unraid servers. Since there is only one USB cable I figured the unraid server I connect the cable to will have a script in it's shutdown script to shut the other server down as well? thanks!

Is irqbalance enabled? Years ago I ran into issues like this on xenserver because irqbalance was disabled, and a single threaded application would make core 0 very busy, and then cause network issues. Enabling irqbalance would then let any cores deal with network requests.

Hello, Am running two unRaid 6 servers, and I'm curious if the Quad Port Intel 82571EB Gigabit Ethernet Controller is supposed to be supported? The host does not seem to see the interface. thanks!

I think you are seeing what I saw with my prior issue. Your SATA controller card has some theoretical top throughput that it can handle. When you are doing a parity check you are initially starting out with all disks, and the speed of it at that point can be limited by 1) the speed of your slowest drive, and 2) the throughput capability of your SATA controllers. If I hook up a firehose to a garden hose, I limit the water going through, same thing here with the data. Ton of data going through that controller, perhaps you are getting close to the actual throughput your card can handle, and typically your smaller drives are going to be older and slower. So once you get above 2TB's, your 2TB drives spin down and won't be used anymore, if the bigger drivers are faster you will now see higher throughput and your sync completion time will get lower. You also are now sending less data through the controller, which helps as well. Typically my numbers start VERY low, and as the 2TB disks drop off it increases, when it gets to just the 4TB disks it flies. Totally expected. The best you can do, is figure out out to best split up your drives between the AOC-SAS2LP-MV8 controller and the onboard controller. And remember, these numbers are totally pointless, it is rare that all your drives will ever be spinning up at the same time, except for parity checks.

If you limit access to the unraid server it should not be a big deal, but any additional plugins/docker apps could make it more vulnerable.

I just upgraded to BETA9 and was looking through the syslog when I saw the following entry: VMware vmxnet3 virtual NIC driver - version 1.2.0.0-k-NAPI Is it normal for the Xen to be using a VMWare driver? Thanks, Marcus

So.... I don't actually want to backup my user shares, but is it possible to setup crashplan to backup to the mnt/share location? I have a secondary tower that I would like to use purely just for backups, but I want the storage to go to the array not the cache disks. thanks!

Odd, I get the following: Warning: scandir(/boot/config/plugins/Docker): failed to open dir: No such file or directory in /usr/local/emhttp/plugins/dockerMan/DockerClient.php on line 24 Warning: scandir(): (errno 2): No such file or directory in /usr/local/emhttp/plugins/dockerMan/DockerClient.php on line 24 Warning: natcasesort() expects parameter 1 to be array, boolean given in /usr/local/emhttp/plugins/dockerMan/DockerClient.php on line 25 mediabrowser/mbserver:latest Think I got it, believe it was permission based. Let me test!

Odd, I get the following: Warning: scandir(/boot/config/plugins/Docker): failed to open dir: No such file or directory in /usr/local/emhttp/plugins/dockerMan/DockerClient.php on line 24 Warning: scandir(): (errno 2): No such file or directory in /usr/local/emhttp/plugins/dockerMan/DockerClient.php on line 24 Warning: natcasesort() expects parameter 1 to be array, boolean given in /usr/local/emhttp/plugins/dockerMan/DockerClient.php on line 25 mediabrowser/mbserver:latest

Awesome, I'm going to go ahead and try it now. Did you just the base Ubuntu image and the the command referenced above? Thanks! I was already running CrashPlan and PlexWatch...so whatever base image that is is what I was using. I then SSH'd into my unRAID box and ran that command. A few minutes later it started and I was able to connect and set all the settings. I let it run for a day or so, before I switched a couple of my HTPCs over to it. So I enabled Docker. Then ran docker pull ubuntu Is that enough to have the base image? Or is there configuration/installation for the base beyond that? Thanks!

Awesome, I'm going to go ahead and try it now. Did you just the base Ubuntu image and the the command referenced above? Thanks!

How large of a library? I've got about 800 items. Also for Live TV do you just point to the ServerWMC host on another box? Thanks!

As the array is stopped and you add the disk to the slot, click on the disk name, such as "Disk7" and then there is a drop down to select the filesystem type. It worked for me without any hitches.. If we upgrade from a 2TB to a 4TB disk, do we have the option to make the new 4TB disk XFS even if the old disk was ReiserFS?

How are you assigning the devices for PCI passthrough before starting the VM? Do you have a go script for assigning them or what? Also please share with me what you have in your syslinux.cfg. Lastly, please try making the following changes to your VM config file: CHANGE "memory" to ~3GB: memory = '3072' Remove these lines or comment them out: device_model_version="qemu-xen-traditional" sdl = '0' vnc = '1' vnclisten = '0.0.0.0' vncpasswd = '' stdvga = '0' usb = '1' usbdevice = 'tablet' FYI, you can use the VNC stuff and usb tablet if you're not doing GPU pass through. If you need remote access to your VM with GPU pass through enabled, I'd suggest installing a VNC client in the VM or enabling Windows Remote Desktop. Send me back a syslog after trying this stuff. FWIW, in Beta5 I could allow VNC to be enabled in the config, and still be able to passthrough video with no issues. I typically use RDP to access the VM, however, when enabling passthrough in beta5, it was helpful to see what the OS was doing if it wasn't coming up. I've tried what you suggested, just as I did with beta6, and although it at least runs with pci passthrough disabled, I just get continued reboots when I try to enable it. Syslinux.cfg: default /syslinux/menu.c32 menu title Lime Technology prompt 0 timeout 50 label unRAID OS kernel /bzimage append initrd=/bzroot label unRAID OS Safe Mode (no plugins) kernel /bzimage append initrd=/bzroot unraidsafemode label Memtest86+ kernel /memtest label Xen/unRAID OS menu default kernel /syslinux/mboot.c32 append /xen dom0_mem=2097152 --- /bzimage xen-pciback.hide=(01:00.1)(01:00.0)(07:00.0)(00:1b.0) --- / bzroot label Xen/unRAID OS Safe Mode (no plugins) kernel /syslinux/mboot.c32 append /xen dom0_mem=2097152 --- /bzimage --- /bzroot unraidsafemode VM Config file: name = 'myvm' builder = 'hvm' vcpus = '4' memory = '3072' #device_model_version="qemu-xen-traditional" disk = [ 'file:/mnt/vmdisk/MybedroomDT.img,hda,w', ] vif = [ 'mac=00:16:3E:51:20:4E,bridge=xenbr0,model=e1000' ] on_poweroff = 'destroy' on_reboot = 'restart' on_crash = 'destroy' #gfx_passthru=1 boot = 'cd' acpi = '1' apic = '1' viridian = '1' xen_platform_pci='1' #sdl = '0' #vnc = '1' #vnclisten = '0.0.0.0' #vncpasswd = '' #stdvga = '1' #usb = '1' #usbdevice = 'tablet' # ATI Config pci = ['01:00.0','01:00.1','00:1b.0'] tail on syslog: Aug 23 15:42:05 Tower root: /etc/xen/scripts/vif-bridge: offline type_if=vif XENBUS_PATH=backend/vif/17/0 Aug 23 15:42:05 Tower root: /etc/xen/scripts/vif-bridge: brctl delif xenbr0 vif17.0 failed Aug 23 15:42:05 Tower root: /etc/xen/scripts/vif-bridge: ifconfig vif17.0 down failed Aug 23 15:42:05 Tower root: /etc/xen/scripts/vif-bridge: Successful vif-bridge offline for vif17.0, bridge xenbr0. Aug 23 15:42:05 Tower root: /etc/xen/scripts/vif-bridge: remove type_if=tap XENBUS_PATH=backend/vif/17/0 Aug 23 15:42:05 Tower root: /etc/xen/scripts/vif-bridge: Successful vif-bridge remove for vif17.0-emu, bridge xenbr0. Aug 23 15:42:24 Tower root: /etc/xen/scripts/vif-bridge: online type_if=vif XENBUS_PATH=backend/vif/18/0 Aug 23 15:42:24 Tower kernel: device vif18.0 entered promiscuous mode Aug 23 15:42:24 Tower root: /etc/xen/scripts/vif-bridge: Successful vif-bridge online for vif18.0, bridge xenbr0. Aug 23 15:42:24 Tower root: /etc/xen/scripts/vif-bridge: Writing backend/vif/18/0/hotplug-status connected to xenstore. Aug 23 15:42:24 Tower root: /etc/xen/scripts/vif-bridge: add type_if=tap XENBUS_PATH=backend/vif/18/0 Aug 23 15:42:24 Tower root: /etc/xen/scripts/vif-bridge: Successful vif-bridge add for vif18.0-emu, bridge xenbr0. Aug 23 15:42:24 Tower kernel: device vif18.0-emu entered promiscuous mode Aug 23 15:42:24 Tower kernel: xenbr0: port 4(vif18.0-emu) entered listening state Aug 23 15:42:24 Tower kernel: xenbr0: port 4(vif18.0-emu) entered listening state Aug 23 15:42:25 Tower kernel: xen_pciback: vpci: 0000:01:00.0: assign to virtual slot 0 Aug 23 15:42:25 Tower kernel: xen_pciback: vpci: 0000:01:00.1: assign to virtual slot 0 func 1 Aug 23 15:42:25 Tower kernel: xen_pciback: vpci: 0000:00:1b.0: assign to virtual slot 1 Aug 23 15:42:39 Tower kernel: xenbr0: port 4(vif18.0-emu) entered learning state Aug 23 15:42:54 Tower kernel: xenbr0: topology change detected, sending tcn bpdu Aug 23 15:42:54 Tower kernel: xenbr0: port 4(vif18.0-emu) entered forwarding state Aug 23 15:43:25 Tower kernel: xenbr0: port 4(vif18.0-emu) entered disabled state Aug 23 15:43:25 Tower kernel: device vif18.0-emu left promiscuous mode Aug 23 15:43:25 Tower kernel: xenbr0: port 4(vif18.0-emu) entered disabled state Aug 23 15:43:25 Tower avahi-daemon[7594]: Withdrawing workstation service for vif18.0-emu. Aug 23 15:43:26 Tower kernel: xenbr0: port 3(vif18.0) entered disabled state Aug 23 15:43:26 Tower avahi-daemon[7594]: Withdrawing workstation service for vif18.0. Aug 23 15:43:26 Tower kernel: device vif18.0 left promiscuous mode Aug 23 15:43:26 Tower kernel: xenbr0: port 3(vif18.0) entered disabled state Aug 23 15:43:26 Tower logger: /etc/xen/scripts/vif-bridge: offline type_if=vif XENBUS_PATH=backend/vif/18/0 Aug 23 15:43:26 Tower logger: /etc/xen/scripts/vif-bridge: brctl delif xenbr0 vif18.0 failed Aug 23 15:43:26 Tower logger: /etc/xen/scripts/vif-bridge: ifconfig vif18.0 down failed Aug 23 15:43:26 Tower logger: /etc/xen/scripts/vif-bridge: Successful vif-bridge offline for vif18.0, bridge xenbr0. Aug 23 15:43:26 Tower logger: /etc/xen/scripts/vif-bridge: remove type_if=tap XENBUS_PATH=backend/vif/18/0 Aug 23 15:43:26 Tower logger: /etc/xen/scripts/vif-bridge: Successful vif-bridge remove for vif18.0-emu, bridge xenbr0. Aug 23 15:43:30 Tower logger: /etc/xen/scripts/vif-bridge: online type_if=vif XENBUS_PATH=backend/vif/19/0 Aug 23 15:43:30 Tower kernel: device vif19.0 entered promiscuous mode Aug 23 15:43:30 Tower logger: /etc/xen/scripts/vif-bridge: Successful vif-bridge online for vif19.0, bridge xenbr0. Aug 23 15:43:30 Tower logger: /etc/xen/scripts/vif-bridge: Writing backend/vif/19/0/hotplug-status connected to xenstore. Aug 23 15:43:30 Tower logger: /etc/xen/scripts/vif-bridge: add type_if=tap XENBUS_PATH=backend/vif/19/0 Aug 23 15:43:30 Tower kernel: device vif19.0-emu entered promiscuous mode Aug 23 15:43:30 Tower kernel: xenbr0: port 4(vif19.0-emu) entered listening state Aug 23 15:43:30 Tower kernel: xenbr0: port 4(vif19.0-emu) entered listening state Aug 23 15:43:30 Tower logger: /etc/xen/scripts/vif-bridge: Successful vif-bridge add for vif19.0-emu, bridge xenbr0. Aug 23 15:43:30 Tower kernel: xen_pciback: vpci: 0000:01:00.0: assign to virtual slot 0 Aug 23 15:43:30 Tower kernel: xen_pciback: vpci: 0000:01:00.1: assign to virtual slot 0 func 1 Aug 23 15:43:30 Tower kernel: xen_pciback: vpci: 0000:00:1b.0: assign to virtual slot 1 Aug 23 15:43:45 Tower kernel: xenbr0: port 4(vif19.0-emu) entered learning state Aug 23 15:44:00 Tower kernel: xenbr0: topology change detected, sending tcn bpdu Aug 23 15:44:00 Tower kernel: xenbr0: port 4(vif19.0-emu) entered forwarding state Aug 23 15:44:31 Tower kernel: xenbr0: port 4(vif19.0-emu) entered disabled state Aug 23 15:44:31 Tower kernel: device vif19.0-emu left promiscuous mode Aug 23 15:44:31 Tower kernel: xenbr0: port 4(vif19.0-emu) entered disabled state Aug 23 15:44:31 Tower avahi-daemon[7594]: Withdrawing workstation service for vif19.0-emu. Aug 23 15:44:31 Tower kernel: xenbr0: port 3(vif19.0) entered disabled state Aug 23 15:44:31 Tower avahi-daemon[7594]: Withdrawing workstation service for vif19.0. Aug 23 15:44:31 Tower kernel: device vif19.0 left promiscuous mode Aug 23 15:44:31 Tower kernel: xenbr0: port 3(vif19.0) entered disabled state Aug 23 15:44:32 Tower logger: /etc/xen/scripts/vif-bridge: offline type_if=vif XENBUS_PATH=backend/vif/19/0 Aug 23 15:44:32 Tower logger: /etc/xen/scripts/vif-bridge: brctl delif xenbr0 vif19.0 failed Aug 23 15:44:32 Tower logger: /etc/xen/scripts/vif-bridge: ifconfig vif19.0 down failed Aug 23 15:44:32 Tower logger: /etc/xen/scripts/vif-bridge: Successful vif-bridge offline for vif19.0, bridge xenbr0. Aug 23 15:44:32 Tower logger: /etc/xen/scripts/vif-bridge: remove type_if=tap XENBUS_PATH=backend/vif/19/0 Aug 23 15:44:32 Tower logger: /etc/xen/scripts/vif-bridge: Successful vif-bridge remove for vif19.0-emu, bridge xenbr0. Aug 23 15:44:36 Tower logger: /etc/xen/scripts/vif-bridge: online type_if=vif XENBUS_PATH=backend/vif/20/0 Aug 23 15:44:36 Tower kernel: device vif20.0 entered promiscuous mode Aug 23 15:44:36 Tower logger: /etc/xen/scripts/vif-bridge: Successful vif-bridge online for vif20.0, bridge xenbr0. Aug 23 15:44:36 Tower logger: /etc/xen/scripts/vif-bridge: Writing backend/vif/20/0/hotplug-status connected to xenstore. Aug 23 15:44:36 Tower logger: /etc/xen/scripts/vif-bridge: add type_if=tap XENBUS_PATH=backend/vif/20/0 Aug 23 15:44:36 Tower logger: /etc/xen/scripts/vif-bridge: Successful vif-bridge add for vif20.0-emu, bridge xenbr0. Aug 23 15:44:36 Tower kernel: device vif20.0-emu entered promiscuous mode Aug 23 15:44:36 Tower kernel: xenbr0: port 4(vif20.0-emu) entered listening state Aug 23 15:44:36 Tower kernel: xenbr0: port 4(vif20.0-emu) entered listening state Aug 23 15:44:36 Tower kernel: xen_pciback: vpci: 0000:01:00.0: assign to virtual slot 0 Aug 23 15:44:36 Tower kernel: xen_pciback: vpci: 0000:01:00.1: assign to virtual slot 0 func 1 Aug 23 15:44:36 Tower kernel: xen_pciback: vpci: 0000:00:1b.0: assign to virtual slot 1 Aug 23 15:44:51 Tower kernel: xenbr0: port 4(vif20.0-emu) entered learning state Aug 23 15:45:06 Tower kernel: xenbr0: topology change detected, sending tcn bpdu Aug 23 15:45:06 Tower kernel: xenbr0: port 4(vif20.0-emu) entered forwarding state qemu-dm-myvm.log contains this: [00:06.0] xen_pt_pci_config_access_check: Error: Failed to access register with invalid access size alignment. (addr: 0x0e, len: 4) If I comment out the PCI, and uncomment device_model_version="qemu-xen-traditional" it boots fine. If I try and boot without qemu-xen-traditional it will not boot, and just continues to reboot over and over. Thanks!