From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Wilcox Subject: Re: UAS gadget driver & UAS host driver [was: Re: [RFC/PATCH 0/4] UASP device driver] Date: Mon, 21 Feb 2011 08:03:07 -0500 Message-ID: <20110221130307.GT3663@linux.intel.com> References: <1295595794-23194-1-git-send-email-tlinder@codeaurora.org> <20110211224703.GC9008@xanatos> <000001cbcb49$8bba88e0$a32f9aa0$@org> <20110214183125.GC4059@xanatos> <003101cbd193$4abb2ed0$e0318c70$@org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mga01.intel.com ([192.55.52.88]:37170 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932074Ab1BUNDJ (ORCPT ); Mon, 21 Feb 2011 08:03:09 -0500 Content-Disposition: inline In-Reply-To: <003101cbd193$4abb2ed0$e0318c70$@org> Sender: linux-arm-msm-owner@vger.kernel.org List-Id: linux-arm-msm@vger.kernel.org To: Tanya Brokhman Cc: 'Sarah Sharp' , gregkh@suse.de, linux-arm-msm@vger.kernel.org, linux-usb@vger.kernel.org, ablay@codeaurora.org On Mon, Feb 21, 2011 at 08:48:01AM +0200, Tanya Brokhman wrote: > Attached is the dmesg snippet from the UAS host. (I've added a few dbg > printk while debugging) > The SCSI command sequence that occurs after enumeration is INQUERY, TEST > UNIT READY, READ CAPACITY, MODE SENSE. The first 3 finish correctly but > after issuing MODE SENSE command I observe 2 strange warnings: > > [ 4335.771653] xhci_hcd 0000:01:00.0: WARN: babble error on endpoint > [ 4335.771657] usb 9-1: ep 0x81 - asked for 4 bytes, 4 bytes untransferred This bit, I understand. The kernel asked for 4 bytes of MODE SENSE data, and your device returned 8 bytes. > [ 4335.771771] xhci_hcd 0000:01:00.0: WARN Set TR Deq Ptr cmd invalid > because of stream ID configuration ... that's from Sarah's driver; it's a consequence of the previous error, I should think. > After that the scsi error handling mechanism takes over and tries to reset > the device, which fails since TM aren't implemented yet. The error handling does leave a great deal to be desired, yes. > Another thing I've noticed in the code is that all the IUs are issued with > stream_id = 1. This is set in uas_queuecommand_lck() (from uas.c) since > blk_rq_tagged(cmnd->request) == FALSE. The latest condition would be true if > REQ_QUEUED flag would be turned on in request->cmd_flags. I found no > reference of this flag usage at all so all the commands right now are issued > with stream_id=1. Is there a reason behind this? All the commands you've seen so far are untagged because we're not into the reading and writing phases yet. Once we start doing real I/Os, you'll see tags used (and stream IDs != 1 being used).