From mboxrd@z Thu Jan 1 00:00:00 1970 From: Noboru Iwamatsu Subject: Re: anyone using pvusb? Date: Wed, 09 Sep 2009 11:28:16 +0900 Message-ID: <4AA712C0.2080807@jp.fujitsu.com> References: <4AA06437.1030009@jp.fujitsu.com> <4AA0AE5E.10901@jp.fujitsu.com> <4AA0B55F.9080503@jp.fujitsu.com> <4AA0EF35.6010509@jp.fujitsu.com> <4AA106D1.3080606@jp.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Hi James, > I am wondering if maybe it is just a quirk of that model or something > that the first usb packet that gets sent times out or something and > needs to be unlinked. When I look at what happens under Linux, the > frontend tries to unlink it but fails. Is it normally the hcd or the > device driver that is responsible for maintaining timeouts and retrying > etc? HCD's urb_dequeue() function that is called from hcd_unlink_urb() has to be responsible for dequeueing the urb from the actual HCD hardware and giving back the urb within the next time of the HCD hardware interrupt. If no urb returns for a given length of time after usbcore or device drivers unlinked the urb, they might identify the HCD as broken. About the PVUSB's implementation of urb_dequeue(), it's incomplete. usbfront can only dequeue the urb that is in the frontend, and cannot dequeue the urb already transferred to the backend. So, if the device goes into stalled state in the backend (probably triggered from wrong urb), The frontend can do nothing. I think main cause of the flash drive failure is the above wrong urb, but I will solve the urb-canceling issue too. Thanks, Noboru.