From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:47068) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rch3g-0005dw-SR for qemu-devel@nongnu.org; Mon, 19 Dec 2011 12:31:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rch3b-0001mC-0s for qemu-devel@nongnu.org; Mon, 19 Dec 2011 12:31:28 -0500 Received: from moutng.kundenserver.de ([212.227.17.9]:59278) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rch3a-0001lh-Lj for qemu-devel@nongnu.org; Mon, 19 Dec 2011 12:31:22 -0500 Message-ID: <4EEF74EC.7090800@rdsoftware.de> Date: Mon, 19 Dec 2011 18:31:24 +0100 From: Erik Rull MIME-Version: 1.0 References: <0N8zjs-1QswR10QHR-00iSes@icpu819.kundenserver.de> <4EEEFD20.9000506@redhat.com> In-Reply-To: <4EEEFD20.9000506@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] USB continuous reset / unplug cleanup not done properly List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: qemu-devel@nongnu.org Hi Gerd, Gerd Hoffmann wrote: > Hi, > >> 1) Devices get resetted again and again on the host side and do not work >> properly on the guest side - they work fine on the host side outside qemu. > > I see those too. Not clear what is going on here. usbfs requests seem > to get stuck now and then for not-yet known reasons. Sometimes they > finish after a few seconds. Sometimes they get stuck long enougth that > some timeout within the guest fires and the guest resets the device. Is it possible to increase either the timeout periods or "block" the USB device during it is in use by the guest, so that usbfs does not want to reset it? > I see those with a F16 guest which polls the usb stick with > test-unit-ready requests. Letting it run idle produces a ... > > usb 1-6: reset high speed USB device number 3 using ehci_hcd > > ... log line line in the guest now and then. Tried to write a small > reproducer (tool constantly sending test-unit-ready via usbfs), but that > one works just fine without any hangs. Is it possible to trace the USB requests at this level? Maybe there is a possibility to figure out why the reset happens. > cheers, > Gerd > Any idea about the second point regarding the remaining devices in the info usb list? Best regards, Erik