From: Matthew Wilcox <willy@linux.intel.com>
To: Tanya Brokhman <tlinder@codeaurora.org>
Cc: 'Sarah Sharp' <sarah.a.sharp@linux.intel.com>,
gregkh@suse.de, linux-arm-msm@vger.kernel.org,
linux-usb@vger.kernel.org, ablay@codeaurora.org
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 [thread overview]
Message-ID: <20110221130307.GT3663@linux.intel.com> (raw)
In-Reply-To: <003101cbd193$4abb2ed0$e0318c70$@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).
next prev parent reply other threads:[~2011-02-21 13:03 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-21 7:43 [RFC/PATCH 0/4] UASP device driver Tatyana Brokhman
2011-01-21 15:23 ` Alan Stern
2011-01-23 5:53 ` Tanya Brokhman
2011-02-11 22:47 ` Sarah Sharp
2011-02-13 6:45 ` Tanya Brokhman
2011-02-14 18:31 ` Sarah Sharp
2011-02-21 6:48 ` UAS gadget driver & UAS host driver [was: Re: [RFC/PATCH 0/4] UASP device driver] Tanya Brokhman
2011-02-21 13:03 ` Matthew Wilcox [this message]
[not found] ` <20110221130307.GT3663-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2011-02-21 13:45 ` Tanya Brokhman
2011-02-21 14:58 ` Sarah Sharp
2011-02-21 15:35 ` Tanya Brokhman
2011-02-21 16:22 ` Sarah Sharp
2011-02-21 16:34 ` Alan Stern
2011-03-07 7:11 ` Tanya Brokhman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110221130307.GT3663@linux.intel.com \
--to=willy@linux.intel.com \
--cc=ablay@codeaurora.org \
--cc=gregkh@suse.de \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=sarah.a.sharp@linux.intel.com \
--cc=tlinder@codeaurora.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.