From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Cornelius Subject: USB passthrough - strange device keeps resetting Date: Fri, 7 Apr 2017 16:10:15 +0200 Message-ID: <20170407161015.7a644b12@lenovo> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit To: kvm@vger.kernel.org Return-path: Received: from mx1.redhat.com ([209.132.183.28]:46322 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932178AbdDGOKT (ORCPT ); Fri, 7 Apr 2017 10:10:19 -0400 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 069B6C05AA4E for ; Fri, 7 Apr 2017 14:10:19 +0000 (UTC) Received: from lenovo (ovpn-117-85.ams2.redhat.com [10.36.117.85]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 772E01883C for ; Fri, 7 Apr 2017 14:10:18 +0000 (UTC) Sender: kvm-owner@vger.kernel.org List-ID: Hi, I'm trying to passthrough a peculiar USB device. My best guess on what's happening: It's not supposed to be talked to from anything but the custom, non-Linux libusb-based "driver application" and resets itself whenever it detects something that's not according to their driver - including operations that are pretty standard and no problem at all for other devices. Unfortunately, that also means that it resets itself when trying boot the guest it's supposed to be passed through. This causes the USB address on the Linux host to change (/dev/usb/01/xx becomes /dev/usb/01/xx+1), which in turn appears to prevent it from being passed through the guest correctly. I've tried both the spice-based and the other redirection method, I've tried attaching it purely based on USB vendor and product id, tested various suggestions that I could find across the internet, but I constantly run into the same problem over and over again. I've tested a number of other devices, they all work fine - it's only this one device that's acting up and I'm now out of ideas. I will appreciate any and every suggestion. Thanks, -- Stefan Cornelius / Red Hat Product Security