You can see these with gzcat /proc/config.gz | grep ALTERA. There are several Altera items in my arch kernel configuration that are flagged as modules perhaps they need to be loaded.

Next, I would compare the outputs of lsmod for Arch (with the programmer attached) and for Fedora in the VM (with the programmer 'attached'). There is a tool available to change the mode of devices that behave this way -but it is not relevant here. Some devices do that to provide a mechanism to ship Window drivers on the device and have them auto install. Yeah, it is not showing up as a mass storage device. I'm guessing it is something specific to Arch, given that with all other things equal, the Fedora VM does not fail where the Arch VM does. I'm not sure where to go from here in terms of troubleshooting this, but any suggestions are appreciated.

I've tried both disabling and enabling EHCI forwarding in the machine's BIOS with no difference in behavior I don't speak USB, but it looks like in the failed mode it will go into an infinite loop of USB_BULK_IN messages between the host and enpoint (both directions alternating) and eventually time out. I have used wireshark to capture both a successful and a failed usage of the device. The programming software is the same between all systems - intel quartus 17.1 - and it does not report any helpful errors. Udev rules have been set up identically on all test systems, and permissions are identical (0666) in the /dev fs for the device

The device is detected and enumerated correctly in all test systems - eg it will show up correctly in the output of lsusb with id 09fb:6001 I thought this might have been due to ohci_pci vs xhci_pci drivers, but using a 2.0 controller with the physical machine, arch will use ohci_pci drivers as seen in dmesg and still fail (whereas if plugged into a 3.0 port, xhci will handle it and also fail).ĭevice does not work when forwarded to a VM running the same version of Arch as the hardware with VirtualBox USB mode set to 2.0Īlso does not work if running the Arch system with Fedora kernel on the Arch VM or Arch Physical MachineĪrch-Zen and Arch LTS kernels have also been tried with no success. This is only true if the VM's USB controller is in 2.0 or 1.0 mode - if in 3.0 mode, it will fail in much the same way as it does in Arch. Using VirtualBox, the device and software works when forwarded to the Fedora VM The device does not work when attempting to use it from Arch natively All systems are fully up to date as of this post. I have essentially 3 test systems: A physical box running Arch, and on that box: a VM running Arch and a VM running Fedora 28 with kernel 4.18.4 (also tested with Fedora 4.17.11 kernel). I've spent the last few days trying to get to the bottom of it but I haven't found any solutions. I'm having difficulties getting an Altera USB blaster to work with an Arch linux system.

Altera usb blaster linux