scorcho99

Hmm, and it only happens when you use your one flash drive? Or do other devices give the code 10 if they are connected? It also happened with a USB3 hard drive, not not a usb2 flash drive. Have you tried to hide the controller from unraid with pci-stub.ids yet? Yes, I thought for sure that would fix it. I confirmed in the logs it was being assigned to pci-stub as well.

Well, I installed Windows 7 and preliminary tests show it behaves pretty much the same as XP. Code 10 if something is connected at startup.

Its even more specific, only one of my flash drives (USB3 Lexar) causes this problem if its installed prior to the VM starting. An older USB2 one is fine. I even tried adding the controllers to pci-stub but that didn't fix it either. I was going to say maybe unraid loads them first or something and they aren't getting cleanly unbound on VM start, but given it still happens when its stubbed and doesn't happen with an old sandisk cruizer that doesn't really add up to me. I ran a lot of tests and on both the NEC pci-e card and the onboard AMD USB controller it has the same effect on both and seems very reproducible once I figured out what was causing it. Since the AMD controller has two sets of ports only the one the flash drive is installed to gets a cannot start code 10. Weird. Now I should try this on bare metal to rule that out and maybe try a couple other devices. I wouldn't be surprised if esxi has the problem as well, I didn't own this flash drive when I was testing on that.

So I did a few more tests last night and what I found was that my original assumption was not correct. When I started the server yesterday I was surprised to find that one of the controllers had a code 10 again. I had previously thought this was cleared up when rebooting the hypervisor. I then ran a bunch of reboot, shutdown, restart tests with both controllers using a couple different USB flash drives on both passed through controllers. I had one weird situation where windows may not have yet polled the flash drive (had a drive present but said "please insert a drive" or something when I tried to open it immediately after boot) but no other problems at all. My running theory now is that if I have a flash drive installed on a passed through controller, unraid tries to do something with it on startup which causes the strange state. In theory the controller should just reset. In practice, maybe that doesn't always work. I didn't run a lot of hypervisor reboot tests so I'm still not sure I've nailed it down. I would think adding the devices to the syslinux.cfg file under pci-stub.ids would prevent unraid from ever looking at them directly but I didn't have a chance to try that either.

I can check it out at some point, but honestly running these devices on Windows 7 isn't really part of the end goal. I only have a few licenses for that and the installs take up to much space for what I want them to do. But it would be interesting to know regardless. I don't think I had any issues with the NEC card like this with ESXi but it wasn't possible to even pass through the onboard USB with ESXi.

So with the help of this guide and others I have essentially successfully passed through an onboard AMD USB3 controller and a NEC 720200? controller that worked well with ESXi. More testing is required. A problem I have though (this is in Windows XP by the way) is that when I shut down the VM and then start it again (not restart) both the AMD and NEC controllers get a code 10, cannot start problem. This seemed repeatable in limited testing. The safely remove hardware option actually lists all passed through devices and the virt devices as well. It seemed (tested once) if I safely removed the USB controller before shutting down it worked when started back up. I seem to recall people having this problem with video cards at one point. I suspect this is because FLR or something is not handled well. I know this implementation frees up devices when the machine is shut down so other machines could use them. I wonder if setting the managed option to "no" in the XML combined with blacklisting the device from unraid with that pci stub option would alleviate this problem. Weirdly, my HVR-1850 capture card seems to have no issues.

I had some questions about this guide. In the guide, there is a step about adding a line: pci-stub.ids=8086:153b to the syslinux.cfg I assume this line is "black listing" the device from unraid/hypervisor to make sure it is available to VMs. Edit: I saw in another post another user had this question as well. This guide is about network controllers which are sort of special compared to many devices in that unraid will grab them. Thus this command is needed to explicitly prevent that from happening. I suppose you might want it for SATA controllers...USB controllers? as well. But things like video and sound cards it should not be needed since unraid never tries to control them in the first place. Is this necessary? I've read other guides: https://lime-technology.com/forum/index.php?topic=38259.msg368555#msg368555 CHBMB that seem to suggest nothing being added to the syslinux.cfg or go file (where is the go file located btw) and it worked just editing the XML. I have devices that have "dependent" devices, like PCI devices behind a bridge or PCI-e cards that actually are PCI devices attached behind a bridge chip on board. Do I simply have to add all these devices to the XML together or does this complicate matters? Related question, when logged in with PuTTy to the server can you edit the syslinux.cfg or other files directly on the flash drive safely? What command should I use to do that. I apologize I am a linux noob.