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). -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
