from:"Tushar Nimkar"

Re: Fwd: usb: uas: device reset most the time while enumeration- usb3.0

2018-06-05 Thread Tushar Nimkar

Hi,

On 2018-06-04 19:57, Oliver Neukum wrote:

Am Dienstag, den 29.05.2018, 14:32 +0530 schrieb Tushar Nimkar:

Hi,

On 2018-05-28 18:12, Oliver Neukum wrote:
> Am Donnerstag, den 24.05.2018, 20:13 +0530 schrieb Tushar Nimkar:
> > We have built SCSI as module will it cause any problem to enable
> > CONFIG_SCSI_SCAN_ASYNC ?
>
> No, that should work. But the failure is bizzare. You say

yes there is no problem! I have run some test over night.
> synchronous scanning fails, but async scan works?

yes!

Odd. Extremely odd. Does this show on all architectures?

I have tried with different SOC version with same architecture(ARM)and
Synopsys host controller.

I am asking because that is the crucial question.

I see two possibilities

1. the sync probing code has a bug that shows only on some
architectures
2. architectures were a coincidence - the drive is broken

We absolutely need to know what is happening.

Please let me know if I could contribute on this issue.
I would always like to work on it :)

I am afraid this will have to be tested on another architecture.

Regards
Oliver

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
Best Regards,
Tushar R Nimkar

QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member of Code Aurora Forum, hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fwd: usb: uas: device reset most the time while enumeration- usb3.0

2018-05-29 Thread Tushar Nimkar


Hi,

On 2018-05-28 18:12, Oliver Neukum wrote:

Am Donnerstag, den 24.05.2018, 20:13 +0530 schrieb Tushar Nimkar:

We have built SCSI as module will it cause any problem to enable
CONFIG_SCSI_SCAN_ASYNC ?


No, that should work. But the failure is bizzare. You say

yes there is no problem! I have run some test over night.

synchronous scanning fails, but async scan works?

yes!
Can you check for other host too? I have only dwc3 (3.0a)
That's why my patch(shared already) was working as it was synchronous 
scanning.


Regards
Oliver

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
Best Regards,
Tushar R Nimkar

QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member of Code Aurora Forum, hosted by The Linux Foundation


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fwd: usb: uas: device reset most the time while enumeration- usb3.0

2018-05-24 Thread Tushar Nimkar


Oliver,
On 2018-05-17 19:04, Oliver Neukum wrote:

Am Donnerstag, den 17.05.2018, 12:29 +0530 schrieb Tushar Nimkar:

Those commands issued from different layers say: sd.. uas.. scsi..
so making them to go one after other. Once REPORT_LUN done go with
READ_CAPACITY_16.
This is only for the UAS devices. I believe no disturb to BOT 
behavior.


Hi,

this is good news.

1. We cannot slow down all UAS devices because a few are broken. This
would need to be selective.
2. What is insufficient about "shost->async_scan" for your approach?

Unfortunately for our build CONFIG_SCSI_SCAN_ASYNC wan not set.
And enabling it solves our issue of enumeration.
But as per bellow commit

"If you have built SCSI as modules, enabling this option can
be a problem as the devices may not have been found by the time your
system expects them to have been."

commit 21db1882f79a1ad5977cae6766376a63f60ec414
Author: Matthew Wilcox <matt...@wil.cx>
Date:   Wed Nov 22 13:24:52 2006 -0700

[SCSI] Add Kconfig option for asynchronous SCSI scanning

Without this patch, the user has to add a kernel command line 
parameter
to get asynchronous SCSI scanning.  Now they can select the default 
at

compile time and still override it at boot time if they need to.

Signed-off-by: Matthew Wilcox <matt...@wil.cx>
Signed-off-by: James Bottomley <james.bottom...@steeleye.com>


We have built SCSI as module will it cause any problem to enable
CONFIG_SCSI_SCAN_ASYNC ?




Regards
Oliver

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
Best Regards,
Tushar R Nimkar

QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member of Code Aurora Forum, hosted by The Linux Foundation


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fwd: usb: uas: device reset most the time while enumeration- usb3.0

2018-05-18 Thread Tushar Nimkar


Manu,
On 2018-05-18 16:10, Manu Gautam wrote:

Hi,


On 4/16/2018 3:47 PM, Tushar Nimkar wrote:

On 2018-04-05 12:39, Felipe Balbi wrote:

Hi,

tnim...@codeaurora.org writes:

On 2018-04-05 11:24, Felipe Balbi wrote:

Hi,

Greg KH <gre...@linuxfoundation.org> writes:

On Wed, Apr 04, 2018 at 05:14:50PM +0530, tnim...@codeaurora.org
wrote:

Hi Oliver/Greg,

I am able to duplicated the UAS issue on 4.16 as well.
The behavior is same new usb device detects and reset after aprox 
30

sec(SD_TIMEOUT)
Logs are already shared below.

We are using Synopsys dwc3 as host controller, May I know have 
tested

it
with dwc3?
I have tried it on Linux PC (x86 Ubuntu machine) I could not see 
the

issue.
It enumerates well.


Great, stick with an x86 platform!  :)

Looks like a dwc3 host controller issue, try enabling tracing and
debugging in that driver when this happens to see what is going 
on.

Also look at all of the recent dwc3 patches that were just sent to
Linus
for 4.17-rc1 to verify if that solves the issue.


dwc3's host side is xhci compliant :-) Some revisions have some 
quirks

which may not all be supported.


Felipe, "not all be supported" do u mean some xhci compliant host do
not support uas? and they have such quirks already defined?


No. I mean that some of dwc3's host side quirks may not have 
workarounds

implemented


Tushar, which dwc3 revision are you using? Have you gotten in touch
with

it is DWC3_REVISION_300A   ..3.0a


that's rather recent...


We have seen some data stall issues on 3.00a core in SS mode.
Workaround was to set EnableEpCacheEvict bit (12)  in GUCTL2 register. 
You can

try that as well.

yes.. I am aware about this workaround.I have already tried this.
Still issue is able to reproduce.






your HW designers to ask for Errata List? A run with xhci 
tracepoints

will response you, let me cross check once again with errata list.


okay

there is no uas related stuff in errata list, Felipe.




--
Best Regards,
Tushar R Nimkar

QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member of Code Aurora Forum, hosted by The Linux Foundation


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fwd: usb: uas: device reset most the time while enumeration- usb3.0

2018-05-17 Thread Tushar Nimkar


Hi All,

On 2018-04-24 14:42, Oliver Neukum wrote:

Am Montag, den 23.04.2018, 18:35 +0530 schrieb Tushar Nimkar:

hi,

On 2018-04-23 18:20, Oliver Neukum wrote:
> Am Donnerstag, den 19.04.2018, 20:18 +0530 schrieb Tushar Nimkar:



> No. But for testing we don't need to. Can you confirm that
> the problem is triggered by specific commands?

Observed with REPORT_LUN or READ_CAP16 or INQUIRY command.


Well, that is not the same thing. It is possible that these commands
generally fail, but x86_64 has a working error handling but ARM does
not.


Are you planning to test it with dwc3?


No, I am sorry. I would need to acquire some very specific hardware.

Regards
Oliver

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



Please have look on the proposed fix for the slow enumeration and reset 
issue

for UAS devices(after SD_TIMEOUT).
Fix for :
...
[  123.672358] usb 2-1: new SuperSpeed USB device number 2 using 
xhci-hcd

[  123.711940] scsi host0: uas
[  123.867378] scsi 0:0:0:0: Direct-Access Samsung  Portable SSD T3  
0PQ: 0 ANSI: 6
[  155.132319] sd 0:0:0:0: tag#1 uas_eh_abort_handler 0 uas-tag 2 
inflight: CMD IN
[  155.132359] sd 0:0:0:0: tag#1 CDB: opcode=0x9e, sa=0x10 9e 10 00 00 
00 00 00 00 00 00 00 00 00 20 00 00

[  155.138868] scsi host0: uas_eh_device_reset_handler start
...

If changes seems fine will push this patch to upstream : )

Issue is mostly occurring while we issue the READ_CAPACITY_16 or 
REPORT_LUNS or INQ commands.
I have confirm this with USB analyzer too. But issue is not in those 
commands(they are supported)
Also which mean there is no problem in scanning lun with REPORT_LUN or 
older sequential scan,

which I was suspecting the issue cause.
Those commands issued from different layers say: sd.. uas.. scsi..
so making them to go one after other. Once REPORT_LUN done go with 
READ_CAPACITY_16.

This is only for the UAS devices. I believe no disturb to BOT behavior.

so far tested with two UAS SSDs  dwc3 as host controller with 3.00a as 
version

1) StoreJet TS256GESD400K
2) Samsung  Portable SSD T3

Draft Patch :

--
 drivers/scsi/sd.c  | 8 
 drivers/usb/storage/scsiglue.c | 1 +
 drivers/usb/storage/uas.c  | 6 ++
 include/scsi/scsi_host.h   | 6 ++
 4 files changed, 21 insertions(+)

diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index 78430ef..38c23ad 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -2979,6 +2979,14 @@ static void sd_probe_async(void *data, 
async_cookie_t cookie)

struct device *dev;

sdp = sdkp->device;
+
+   /*
+*  Continue async probe once host scanning is finished
+*  this is only for uas devices
+*/
+   if (sdp->host->hostt->is_uas)
+   
wait_for_completion_interruptible_timeout(>host->hscan_done,
+   msecs_to_jiffies(500));
gd = sdkp->disk;
index = sdkp->index;
dev = >sdev_gendev;
diff --git a/drivers/usb/storage/scsiglue.c 
b/drivers/usb/storage/scsiglue.c

index dba5136..fbd397a 100644
--- a/drivers/usb/storage/scsiglue.c
+++ b/drivers/usb/storage/scsiglue.c
@@ -594,6 +594,7 @@ void usb_stor_host_template_init(struct 
scsi_host_template *sht,

sht->name = name;
sht->proc_name = name;
sht->module = owner;
+   sht->is_uas = false;/* BOT device */
 }
 EXPORT_SYMBOL_GPL(usb_stor_host_template_init);

diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
index f952635..ead73d0 100644
--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@ -44,6 +44,7 @@ struct uas_dev_info {
unsigned use_streams:1;
unsigned shutdown:1;
struct scsi_cmnd *cmnd[MAX_CMNDS];
+   struct Scsi_Host *shost;
spinlock_t lock;
struct work_struct work;
 };
@@ -828,6 +829,7 @@ static struct scsi_host_template uas_host_template = 
{

.this_id = -1,
.sg_tablesize = SG_NONE,
.skip_settle_delay = 1,
+   .is_uas = true,
 };

 #define UNUSUAL_DEV(id_vendor, id_product, bcdDeviceMin, bcdDeviceMax, 
\
@@ -934,11 +936,13 @@ static int uas_probe(struct usb_interface *intf, 
const struct usb_device_id *id)

devinfo->resetting = 0;
devinfo->shutdown = 0;
devinfo->flags = dev_flags;
+   devinfo->shost = shost;
init_usb_anchor(>cmd_urbs);
init_usb_anchor(>sense_urbs);
init_usb_anchor(>data_urbs);
spin_lock_init(>lock);
INIT_WORK(>work, uas_do_work);
+   init_completion(>hscan_done);

result = uas_configure_endpoints(devinfo);
if (result)
@@ -956,6 +960,8 @@ static int uas_probe(struct usb_interface *intf, 
const struct usb_device_id

usb: storage: what is the correct sequence for? sd_probe| storage_probe/1/2 and uas_probe | scsi_scan_host

2018-05-15 Thread Tushar Nimkar


Everyone,

Please help me in understanding sd_probe| storage_probe/1/2 and 
uas_probe | scsi_scan_host :)
Basically want to know the correct sequence for them? How 
sd_probe_async() is called (ASYNC_DOMAIN(scsi_sd_probe_domain))?

Is there any document which say it in detail ?

--
Best Regards,
Tushar R Nimkar

QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member of Code Aurora Forum, hosted by The Linux Foundation


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: howto debug xhci driver?

2018-04-23 Thread Tushar Nimkar


Hi,

On 2018-04-23 18:58, Bin Liu wrote:

On Mon, Apr 23, 2018 at 11:14:55AM +0530, Tushar Nimkar wrote:

On 2018-04-21 00:03, Bin Liu wrote:
>Hi,
>
>On Tue, Mar 20, 2018 at 02:28:00PM -0700, Paul Zimmerman wrote:
>>Forgot to CC linux-usb.
>>
>>
>> Forwarded Message 
>>Subject: Re: howto debug xhci driver?
>>Date: Tue, 20 Mar 2018 13:56:21 -0700
>>From: Paul Zimmerman <pauld...@gmail.com>
>>To: Bin Liu <b-...@ti.com>
>>CC: Felipe Balbi <felipe.ba...@linux.intel.com>
>>
>>Hi,
>>
>>Bin Liu <b-...@ti.com> writes:
>>>>Bin Liu <b-...@ti.com> writes:
>>>>>>>>>>BTY, the issue I am trying to debug is when reading
>>>>>>>>>>bulk IN data from a USB2.0 device, if the device
>>>>>>>>>>doesn't have data to transmit and NAKs the IN packet,
>>>>>>>>>>after 4 pairs of IN-NAK transactions, xhci stops
>>>>>>>>>>sending further IN tokens until the next SOF, which
>>>>>>>>>>leaves ~90us gape on the bus.
>>>>>>>>>>
>>>>>>>>>>But when reading data from a USB2.0 thumb drive, this
>>>>>>>>>>issue doesn't happen, even if the device NAKs the IN
>>>>>>>>>>tokens, xhci still keeps sending IN tokens, which is
>>>>>>>>>>way more than 4 pairs of IN-NAK transactions.
>>>>>>>>>
>>>>>>>>>Thumb drive has Bulk endpoints, what is the other
>>>>>>>>>device's transfer type?
>>>>>>>>
>>>>>>>>It is bulk too. I asked for device descriptors. This is a
>>>>>>>>remote debug effort for me, I don't have that device...
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>Any one has a clue on what causes xhci to stop sending
>>>>>>>>>>IN tokens after the device NAK'd 4 times?
>>>>>>>
>>>>>>>By accident, I reproduced the issue if addng a hub in the
>>>>>>>middle... any comments about why a hub changes this xhci
>>>>>>>behavior is appreciated.
>>>>>>
>>>>>>none off the top of my head. Maybe Mathias can suggest
>>>>>>something.
>>>>>
>>>>>The issue seems to be not related to how many bulk IN-NAK pairs
>>>>>before host stops sending IN token, but the host stops IN token
>>>>>if 1) the device ever NAK'd an bulk IN token, and 2) there is
>>>>>about 90~100us left to the next SOF. Then all the rest of
>>>>>bandwidth is wasted.
>>>>>
>>>>>Is it about xhci bandwidth schduling? /me started reading...
>>>>
>>>>is this AM4 or AM5? Perhaps go after Synopsys' known errata list?
>>>
>>>I see the issue on both AM4 & AM5. I don't have access to the
>>>errata list, I guess I should talk to TI internal for the list?
>>
>>I have a hazy recollection of something like this being a "feature" of
>>the Synopsys core, to cut down on the excessive number of IN-NAK
>>transactions you can sometimes get on the USB bus. So yep, you
>>should talk to your Synopsys guy about this.
>
>Thanks for the information. We have been talking to Synopsis for this
>issue, the progress is slow, one of the reasons is that the DWC3
>version
>is very old :(
Bin, What is the version no? I have seen similar thing but on USB3.0


On multiple versions: from 2.02a to 2.60a.

suggest you to check errata list if not.



with dwc3 3.00a


Do you mean you only see the problem in super-speed but not high-speed
with 3.00a?

yes so far..



May I know how you confirmed/debug missing IN-ACK?


Using bus protocol analyzer to capture bus traces. However my issue is 
not

about missing IN-ACK, but IN-NAK - the host stops sending IN tokens too
early if the device NAK'd previous IN packets.

Please confirm you mean IN-NAK instead in your case?
it is IN-ACK, ss device send ERDY there should be IN-ACK saying NumP > 0 
from host :)


Regards,
-Bin.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
Best Regards,
Tushar R Nimkar

QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member of Code Aurora Forum, hosted by The Linux Foundation


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fwd: usb: uas: device reset most the time while enumeration- usb3.0

2018-04-23 Thread Tushar Nimkar


hi,

On 2018-04-23 18:20, Oliver Neukum wrote:

Am Donnerstag, den 19.04.2018, 20:18 +0530 schrieb Tushar Nimkar:

On 2018-04-19 14:15, Oliver Neukum wrote:
> Am Mittwoch, den 18.04.2018, 12:44 +0530 schrieb Tushar Nimkar:
> > On 2018-04-17 12:03, Tushar Nimkar wrote:
>
> Hi,
>
> > I have doubt that sequential scan(scsi_sequential_lun_scan) work well
> > for uas device(SCSI>3)..
> > Why? As I have seen in most cases failed to enumerate during
> > REPORT_LUN
> > command...and there is older way to scan disk is also present,
> > so I was thinking to try that.. did following things
> >
> > starget->no_report_luns = 1  ---> for my target while uas_target_alloc
> > (for try)
>
> In general the spec is one thing and reality is another thing.
> You can depend really only on what recent versions of Windows do.

did not get you!


Devices often implement the spec only to the extent they need to
in order to work with Windows.


oh, so no backward old way of scanning(sequential)?


No. But for testing we don't need to. Can you confirm that
the problem is triggered by specific commands?


Observed with REPORT_LUN or READ_CAP16 or INQUIRY command.

Are you planning to test it with dwc3?


Regards
Oliver

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
Best Regards,
Tushar R Nimkar

QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member of Code Aurora Forum, hosted by The Linux Foundation


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fwd: usb: uas: device reset most the time while enumeration- usb3.0

2018-04-23 Thread Tushar Nimkar


hi,

On 2018-04-04 19:28, Greg KH wrote:

On Wed, Apr 04, 2018 at 06:41:41PM +0530, tnim...@codeaurora.org wrote:

On 2018-04-04 18:07, Greg KH wrote:
> On Wed, Apr 04, 2018 at 05:14:50PM +0530, tnim...@codeaurora.org wrote:
> > Hi Oliver/Greg,
> >
> > I am able to duplicated the UAS issue on 4.16 as well.
> > The behavior is same new usb device detects and reset after aprox 30
> > sec(SD_TIMEOUT)
> > Logs are already shared below.
> >
> > We are using Synopsys dwc3 as host controller, May I know have
> > tested it
> > with dwc3?
> > I have tried it on Linux PC (x86 Ubuntu machine) I could not see the
> > issue.
> > It enumerates well.
>
> Great, stick with an x86 platform!  :)
>
> Looks like a dwc3 host controller issue, try enabling tracing and
> debugging in that driver when this happens to see what is going on.

Oh if so let me enable the trace for that. I will respond you on this.

> Also look at all of the recent dwc3 patches that were just sent to Linus
> for 4.17-rc1 to verify if that solves the issue.
>
I do not have idea how I can get those patches. Could you please tell 
me?


Look at the git tree listed in the MAINTAINERS file.


Is there any mailing list/link for this ?


Yes, this one (linux-usb@vger).  Also, all of the patches are in
the linux-next tree.


Greg/Oliver, Switched to 4.17.0-rc1.. issues is observed too. :(

[ 5518.577155] usb 2-1: new SuperSpeed USB device number 5 using 
xhci-hcd

[ 5518.605780] scsi host1: uas
[ 5518.606435] scsi 1:0:0:0: Direct-Access Samsung  Portable SSD T3  
0PQ: 0 ANSI: 6
[ 5549.037127] sd 1:0:0:0: tag#0 uas_eh_abort_handler 0 uas-tag 1 
inflight: CMD IN

[ 5549.037160] sd 1:0:0:0: tag#0 CDB: opcode=0x12 12 01 b0 00 40 00
[ 5549.057118] scsi host1: uas_eh_device_reset_handler start
[ 5549.057159] xhci-hcd xhci-hcd.0.auto: ERROR Transfer event for 
unknown stream ring slot 1 ep 6
[ 5549.061491] xhci-hcd xhci-hcd.0.auto: @7f044f20  
 1b00 01078000
[ 5549.197272] usb 2-1: reset SuperSpeed USB device number 5 using 
xhci-hcd

[ 5549.219833] scsi host1: uas_eh_device_reset_handler success
[ 5549.225472] sd 1:0:0:0: [sdb] 976773168 512-byte logical blocks: (500 
GB/466 GiB)

[ 5549.225626] sd 1:0:0:0: [sdb] Write Protect is off
[ 5549.232118] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: 
enabled, doesn't support DPO or FUA
[ 5549.236739] xhci-hcd xhci-hcd.0.auto: ERROR Transfer event for 
unknown stream ring slot 1 ep 2
[ 5549.24] xhci-hcd xhci-hcd.0.auto: @7f044280  
 1b00 01038001

[ 5549.257868]  sdb: sdb1
[ 5549.263899] sd 1:0:0:0: [sdb] Attached SCSI disk




thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
Best Regards,
Tushar R Nimkar

QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member of Code Aurora Forum, hosted by The Linux Foundation


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: howto debug xhci driver?

2018-04-22 Thread Tushar Nimkar

On 2018-04-21 00:03, Bin Liu wrote:

Hi,

On Tue, Mar 20, 2018 at 02:28:00PM -0700, Paul Zimmerman wrote:

Forgot to CC linux-usb.

 Forwarded Message 
Subject: Re: howto debug xhci driver?
Date: Tue, 20 Mar 2018 13:56:21 -0700
From: Paul Zimmerman 
To: Bin Liu 
CC: Felipe Balbi 

Hi,

Bin Liu  writes:
>>Bin Liu  writes:
BTY, the issue I am trying to debug is when reading
bulk IN data from a USB2.0 device, if the device
doesn't have data to transmit and NAKs the IN packet,
after 4 pairs of IN-NAK transactions, xhci stops
sending further IN tokens until the next SOF, which
leaves ~90us gape on the bus.

But when reading data from a USB2.0 thumb drive, this
issue doesn't happen, even if the device NAKs the IN
tokens, xhci still keeps sending IN tokens, which is
way more than 4 pairs of IN-NAK transactions.
>>>
>>>Thumb drive has Bulk endpoints, what is the other
>>>device's transfer type?
>>
>>It is bulk too. I asked for device descriptors. This is a
>>remote debug effort for me, I don't have that device...
>>
>>>
Any one has a clue on what causes xhci to stop sending
IN tokens after the device NAK'd 4 times?
>
>By accident, I reproduced the issue if addng a hub in the
>middle... any comments about why a hub changes this xhci
>behavior is appreciated.

none off the top of my head. Maybe Mathias can suggest
something.
>>>
>>>The issue seems to be not related to how many bulk IN-NAK pairs
>>>before host stops sending IN token, but the host stops IN token
>>>if 1) the device ever NAK'd an bulk IN token, and 2) there is
>>>about 90~100us left to the next SOF. Then all the rest of
>>>bandwidth is wasted.
>>>
>>>Is it about xhci bandwidth schduling? /me started reading...
>>
>>is this AM4 or AM5? Perhaps go after Synopsys' known errata list?
>
>I see the issue on both AM4 & AM5. I don't have access to the
>errata list, I guess I should talk to TI internal for the list?

I have a hazy recollection of something like this being a "feature" of
the Synopsys core, to cut down on the excessive number of IN-NAK
transactions you can sometimes get on the USB bus. So yep, you
should talk to your Synopsys guy about this.

Thanks for the information. We have been talking to Synopsis for this
issue, the progress is slow, one of the reasons is that the DWC3 
version

is very old :(
Bin, What is the version no? I have seen similar thing but on USB3.0 
with dwc3 3.00a

May I know how you confirmed/debug missing IN-ACK?

However, I just realized that in this case even though DWC3 in host 
mode

doesn't fully utilize the bus bandwidth, it doesn't violate any of the
USB Specs, as the Specs don't define flow control for bulk IN transfer.
The USB device shouldn't use bulk protocol at the first place if it has
bus bandwidth requirements. Isoch probably is a better choice. I will
check if there is anything can be done on the USB device side to solve
the problem.

Thanks all for the help.

Regards,
-Bin.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
Best Regards,
Tushar R Nimkar

QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member of Code Aurora Forum, hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fwd: usb: uas: device reset most the time while enumeration- usb3.0

2018-04-19 Thread Tushar Nimkar


On 2018-04-19 14:18, Oliver Neukum wrote:

Am Mittwoch, den 18.04.2018, 12:34 +0530 schrieb Tushar Nimkar:

Oliver/Greg,
Weather you are able to reproduce the issue?
Did you tested it on dwc3 previously?


I don't even have a dwc3.

Great, so uas on dwc3 new to all...

May I suggest that you try to determine whether the issue
happens on the same SCSI command? We need to know what
triggers it.


It is not same command for sure...But as i told previously, occurs
while 1) read_capacity_16(0x9e) or 2) REPORT_LUN(0xa0) or 3) 
INQUIRY(0x12) command

(I can say while sd_revalidate_disk)
If issue occur no status "missing" for above (one of the or more) 
command/s in LeCroy.




Sorry
Oliver


don't be we all can figure it out for sure :)

--
Best Regards,
Tushar R Nimkar

QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member of Code Aurora Forum, hosted by The Linux Foundation


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fwd: usb: uas: device reset most the time while enumeration- usb3.0

2018-04-19 Thread Tushar Nimkar


On 2018-04-19 14:15, Oliver Neukum wrote:

Am Mittwoch, den 18.04.2018, 12:44 +0530 schrieb Tushar Nimkar:

On 2018-04-17 12:03, Tushar Nimkar wrote:


Hi,


I have doubt that sequential scan(scsi_sequential_lun_scan) work well
for uas device(SCSI>3)..
Why? As I have seen in most cases failed to enumerate during 
REPORT_LUN

command...and there is older way to scan disk is also present,
so I was thinking to try that.. did following things

starget->no_report_luns = 1  ---> for my target while uas_target_alloc
(for try)


In general the spec is one thing and reality is another thing.
You can depend really only on what recent versions of Windows do.


did not get you!




Found it is doing sequential scan but popuating 256 entries in cat
proc/partiction
for one disk
root@OpenWrt:/# cat proc/partitions
major minor  #blocks  name

80  488386584 sda
81  488384032 sda1
8   48  488386584 sdd
8   49  488384032 sdd1
8   64  488386584 sde
8   65  488384032 sde1
8   80  488386584 sdf
8   81  488384032 sdf1
8   96  488386584 sdg
8   97  488384032 sdg1
8  112  488386584 sdh
8  113  488384032 sdh1
  256 total.

...though it is SCSI>3 device ,it should support both sequential as 
well

as REPORT_LUN?


In theory.


oh, so no backward old way of scanning(sequential)?


Do not know weather this is the cause for the issue or not ...but if 
so

need to think on this too :)


Well, does your original issue go away if you use NO_REPORT_LUN



most of the time it works (observerd non working case too!) but 256 
similar logs will come on console

.

[  217.464158] xhci-hcd xhci-hcd.0.auto: ERROR Transfer event for 
disabled erect stream ring
[  217.464162] xhci-hcd xhci-hcd.0.auto: @7d933690  
00
[  217.464608] sd 1:0:0:200: [sdgs] 976773168 512-byte logical blocks: 
(500
[  217.464987] scsi 1:0:0:201: Direct-Access Samsung  Portable SSD 
T3  06

[  217.465329] sd 1:0:0:200: [sdgs] Write Protect is off
[  217.465585] sd 1:0:0:200: [sdgs] Write cache: enabled, read cache: 
enablert DPO or FUA
[  217.465695] xhci-hcd xhci-hcd.0.auto: ERROR Transfer event for 
disabled erect stream ring
[  217.465699] xhci-hcd xhci-hcd.0.auto: @7d933b00  
00

[  217.466264]  sdgr: sdgr1
[  217.466525] sd 1:0:0:201: [sdgt] 976773168 512-byte logical blocks: 
(500
[  217.466656] scsi 1:0:0:202: Direct-Access Samsung  Portable SSD 
T3  06

...


Did one more thing along with starget->no_report_luns = 1 , 
shost->max_lun = 1 instead if (= 256) [uas.c]
It Enumerates and no 256 cat proc/partitions entries. But doesn't not 
seems good to me to restrict max_lun to 1 :(



and does your device have multiple LUNs?

how to check that? maybe yes ...


Regards
Oliver


--
Best Regards,
Tushar R Nimkar

QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member of Code Aurora Forum, hosted by The Linux Foundation


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fwd: usb: uas: device reset most the time while enumeration- usb3.0

2018-04-18 Thread Tushar Nimkar

On 2018-04-17 12:03, Tushar Nimkar wrote:

On 2018-04-16 20:03, Oliver Neukum wrote:

Am Montag, den 16.04.2018, 10:23 -0400 schrieb Alan Stern:

> > > > [57246.701096] sd 1:0:0:0: tag#0 uas_eh_abort_handler 0 uas-tag 1
> > > > inflight: CMD IN
> > > > [57246.701130] sd 1:0:0:0: tag#0 CDB: opcode=0x1a 1a 00 3f 00 04 00
>
> URB is canceled, maybe that URB never finished?

No doubt.  Perhaps the device doesn't support this particular 
command.

Then we should expect the enumeration to always fail.
Possibly the lower layers swallow the transfer.

Note not every time abort with 0x1a command ..sometimes it is with
0x9e, 0x12, 0xa0.
As my observation issue is observed during read_capacity_16/REPORT_LUN
or INQUIRY.

Regards
Oliver

Oliver,

I have doubt that sequential scan(scsi_sequential_lun_scan) work well 
for uas device(SCSI>3)..
Why? As I have seen in most cases failed to enumerate during REPORT_LUN 
command...and there is older way to scan disk is also present,

so I was thinking to try that.. did following things

starget->no_report_luns = 1  ---> for my target while uas_target_alloc 
(for try)

Found it is doing sequential scan but popuating 256 entries in cat 
proc/partiction

for one disk
root@OpenWrt:/# cat proc/partitions
major minor  #blocks  name

   80  488386584 sda
   81  488384032 sda1
   8   48  488386584 sdd
   8   49  488384032 sdd1
   8   64  488386584 sde
   8   65  488384032 sde1
   8   80  488386584 sdf
   8   81  488384032 sdf1
   8   96  488386584 sdg
   8   97  488384032 sdg1
   8  112  488386584 sdh
   8  113  488384032 sdh1
  256 total.

...though it is SCSI>3 device ,it should support both sequential as well 
as REPORT_LUN?

refering bellow commit ..no idea how this Seagate device is using 
Sequential scan

commit 1363074667a6b7d0507527742ccd7bbed5e3ceaa
Author: Hans de Goede <hdego...@redhat.com>
Date:   Tue Apr 12 12:27:09 2016 +0200

USB: uas: Add a new NO_REPORT_LUNS quirk

Add a new NO_REPORT_LUNS quirk and set it for Seagate drives with
an usb-id of: 0bc2:331a, as these will fail to respond to a
REPORT_LUNS command.

Cc: sta...@vger.kernel.org
Reported-and-tested-by: David Webb <d...@noc.ac.uk>
Signed-off-by: Hans de Goede <hdego...@redhat.com>
Acked-by: Alan Stern <st...@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

Do not know weather this is the cause for the issue or not ...but if so 
need to think on this too :)

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 
in

the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
Best Regards,
Tushar R Nimkar

QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member of Code Aurora Forum, hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fwd: usb: uas: device reset most the time while enumeration- usb3.0

2018-04-18 Thread Tushar Nimkar

On 2018-04-17 18:04, Mathias Nyman wrote:

On 17.04.2018 09:23, Tushar Nimkar wrote:

On 2018-04-16 18:46, Mathias Nyman wrote:

On 16.04.2018 13:20, Tushar Nimkar wrote:

On 2018-04-05 11:31, Felipe Balbi wrote:

Hi,

it would help if you would Cc XHCI's maintainer :-)

tnim...@codeaurora.org writes:

On 2018-04-04 19:28, Greg KH wrote:
On Wed, Apr 04, 2018 at 06:41:41PM +0530, tnim...@codeaurora.org 
wrote:

On 2018-04-04 18:07, Greg KH wrote:
> On Wed, Apr 04, 2018 at 05:14:50PM +0530, tnim...@codeaurora.org wrote:
> > Hi Oliver/Greg,
> >
> > I am able to duplicated the UAS issue on 4.16 as well.
> > The behavior is same new usb device detects and reset after aprox 30
> > sec(SD_TIMEOUT)
> > Logs are already shared below.
> >
> > We are using Synopsys dwc3 as host controller, May I know have
> > tested it
> > with dwc3?
> > I have tried it on Linux PC (x86 Ubuntu machine) I could not see the
> > issue.
> > It enumerates well.
>
> Great, stick with an x86 platform!  :)
>
> Looks like a dwc3 host controller issue, try enabling tracing and
> debugging in that driver when this happens to see what is going on.

Oh if so let me enable the trace for that. I will respond you on 
this.

I did not get much clue, Greg.  sometime this device enumerates 
well,

attached both working and non working case logs.
following is not working case
root@OpenWrt:/# dmesg

...

[57214.172683] xhci-hcd xhci-hcd.0.auto: ep 0x83 - asked for 112 
bytes,

96 bytes untransferred
[57214.172809] xhci-hcd xhci-hcd.0.auto: ep 0x83 - asked for 112 
bytes,

96 bytes untransferred
[57214.172840] sd 1:0:0:0: [sdb] 976773168 512-byte logical 
blocks: (500

GB/466 GiB)
[57214.172843] xhci-hcd xhci-hcd.0.auto: ep 0x81 - asked for 4096 
bytes,

4080 bytes untransferred
[57214.172851] xhci-hcd xhci-hcd.0.auto: ep 0x83 - asked for 112 
bytes,

96 bytes untransferred
[57214.253085] xhci-hcd xhci-hcd.0.auto: xhci_hub_status_data: 
stopping

port polling.

Huge gap before uas_eh_abort_eh_handler is called.

SD_TIMEOUT of 30 sec ...

[57246.701096] sd 1:0:0:0: tag#0 uas_eh_abort_handler 0 uas-tag 1
inflight: CMD IN
[57246.701130] sd 1:0:0:0: tag#0 CDB: opcode=0x1a 1a 00 3f 00 04 
00

URB is canceled, maybe that URB never finished?

[57246.707583] xhci-hcd xhci-hcd.0.auto: Cancel URB 
07b523f0,

dev 1, ep 0x81, starting at offset 0
[57246.707594] xhci-hcd xhci-hcd.0.auto: // Ding dong!
[57246.707616] xhci-hcd xhci-hcd.0.auto: Stopped on No-op or Link 
TRB

for slot 1 ep 2
[57246.707625] xhci-hcd xhci-hcd.0.auto: Removing canceled TD 
starting

at 0x7f0cd0a0 (dma).
[57246.707630] xhci-hcd xhci-hcd.0.auto: Finding endpoint context
[57246.707634] xhci-hcd xhci-hcd.0.auto: Cycle state = 0x1
[57246.707637] xhci-hcd xhci-hcd.0.auto: New dequeue segment =
890c7dc4 (virtual)
[57246.707641] xhci-hcd xhci-hcd.0.auto: New dequeue pointer =
0x7f0cd0b0 (DMA)
[57246.707646] xhci-hcd xhci-hcd.0.auto: Set TR Deq Ptr cmd, new 
deq seg
= 890c7dc4 (0x7f0cd000 dmeq ptr = 0ce7faa0 
(0x7f0cd0b0

dma), new cycle = 1
[57246.707651] xhci-hcd xhci-hcd.0.auto: // Ding dong!
[57246.707671] xhci-hcd xhci-hcd.0.auto: Successful Set TR Deq Ptr 
cmd,

deq = @7f0cd0b0
[57246.721090] scsi host1: uas_eh_device_reset_handler start
[57246.721114] xhci-hcd xhci-hcd.0.auto: Cancel URB 
279f06a2,

dev 1, ep 0x83, starting at offset 0
[57246.721120] xhci-hcd xhci-hcd.0.auto: // Ding dong!
[57246.721135] xhci-hcd xhci-hcd.0.auto: ERROR Transfer event for
unknown stream ring slot 1 ep 6
[57246.725463] xhci-hcd xhci-hcd.0.auto: @7f044780 

 1b00 01078001

Stop -Length invalid transfer event. That is normal when canceling a 
URB,

but it should point to the TRB xhc was working on when stopped.
Here it just points to 0. That part looks like some issue with this 
specific

controller.

Some other errors may return 0 as their TRB pointer, but not this 
event.
 But this is not the cause, just a detail while handling the real 
cause.
Nothing in this log shows why the URB was canceled in the first 
place.

usbmon and xhci traces could help, xhci traces:

mount -t debugfs none /sys/kernel/debug
echo 81920 > /sys/kernel/debug/tracing/buffer_size_kb
echo 1 > /sys/kernel/debug/tracing/events/xhci-hcd/enable

then send /sys/kernel/debug/tracing/trace after issue triggered.

-Mathias

Mathias, here is usbmon and trace ..let us know on your observation 
which will help to learn more on xhci level :-)

(same is attached)

The xhci traces show that a ep1in bulk URB is queued on Stream 1, but
never completes.
Similar URBs queued on the same stream ring before this one work and
complete fine.

xhci driver never gets a short or success completion transfer event for 
the URB.

No error messages, nothing special going on either.

To me it looks like the URB was queued correctly, but after the stream
protocol chose
to transfe

Re: Fwd: usb: uas: device reset most the time while enumeration- usb3.0

2018-04-17 Thread Tushar Nimkar

On 2018-04-16 20:03, Oliver Neukum wrote:

Am Montag, den 16.04.2018, 10:23 -0400 schrieb Alan Stern:

> > > > [57246.701096] sd 1:0:0:0: tag#0 uas_eh_abort_handler 0 uas-tag 1
> > > > inflight: CMD IN
> > > > [57246.701130] sd 1:0:0:0: tag#0 CDB: opcode=0x1a 1a 00 3f 00 04 00
>
> URB is canceled, maybe that URB never finished?

No doubt.  Perhaps the device doesn't support this particular command.

Then we should expect the enumeration to always fail.
Possibly the lower layers swallow the transfer.

Note not every time abort with 0x1a command ..sometimes it is with 0x9e, 
0x12, 0xa0.
As my observation issue is observed during read_capacity_16/REPORT_LUN 
or INQUIRY.

Regards
Oliver

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
Best Regards,
Tushar R Nimkar

QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member of Code Aurora Forum, hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fwd: usb: uas: device reset most the time while enumeration- usb3.0

2018-04-16 Thread Tushar Nimkar


On 2018-04-05 11:31, Felipe Balbi wrote:

Hi,

it would help if you would Cc XHCI's maintainer :-)

tnim...@codeaurora.org writes:


On 2018-04-04 19:28, Greg KH wrote:
On Wed, Apr 04, 2018 at 06:41:41PM +0530, tnim...@codeaurora.org 
wrote:

On 2018-04-04 18:07, Greg KH wrote:
> On Wed, Apr 04, 2018 at 05:14:50PM +0530, tnim...@codeaurora.org wrote:
> > Hi Oliver/Greg,
> >
> > I am able to duplicated the UAS issue on 4.16 as well.
> > The behavior is same new usb device detects and reset after aprox 30
> > sec(SD_TIMEOUT)
> > Logs are already shared below.
> >
> > We are using Synopsys dwc3 as host controller, May I know have
> > tested it
> > with dwc3?
> > I have tried it on Linux PC (x86 Ubuntu machine) I could not see the
> > issue.
> > It enumerates well.
>
> Great, stick with an x86 platform!  :)
>
> Looks like a dwc3 host controller issue, try enabling tracing and
> debugging in that driver when this happens to see what is going on.

Oh if so let me enable the trace for that. I will respond you on 
this.


I did not get much clue, Greg.  sometime this device enumerates well,
attached both working and non working case logs.
following is not working case
root@OpenWrt:/# dmesg
[57213.906164] xhci-hcd xhci-hcd.0.auto: Port Status Change Event for
port 2
[57213.906172] xhci-hcd xhci-hcd.0.auto: resume root hub
[57213.906183] xhci-hcd xhci-hcd.0.auto: handle_port_status: starting
port polling.
[57213.906243] xhci-hcd xhci-hcd.0.auto: get port status, actual port 
0

status  = 0x21203
[57213.906246] xhci-hcd xhci-hcd.0.auto: Get port status returned
0x10203
[57213.906275] xhci-hcd xhci-hcd.0.auto: clear port connect change,
actual port 0 status  = 0x1203
[57214.005073] xhci-hcd xhci-hcd.0.auto: xhci_hub_status_data: 
stopping

port polling.
[57214.013094] xhci-hcd xhci-hcd.0.auto: get port status, actual port 
0

status  = 0x1203
[57214.013098] xhci-hcd xhci-hcd.0.auto: Get port status returned 
0x203

[57214.013117] xhci-hcd xhci-hcd.0.auto: // Ding dong!
[57214.013142] xhci-hcd xhci-hcd.0.auto: Slot 1 output ctx = 
0x7f0d8000

(dma)
[57214.013147] xhci-hcd xhci-hcd.0.auto: Slot 1 input ctx = 0x7f097000
(dma)
[57214.013160] xhci-hcd xhci-hcd.0.auto: Set slot id 1 dcbaa entry
9c24453d to 0x7f0d8000
[57214.013215] xhci-hcd xhci-hcd.0.auto: get port status, actual port 
0

status  = 0x1203
[57214.013218] xhci-hcd xhci-hcd.0.auto: Get port status returned 
0x203

[57214.013232] xhci-hcd xhci-hcd.0.auto: set port reset, actual port 0
status  = 0x1311
[57214.013240] xhci-hcd xhci-hcd.0.auto: Port Status Change Event for
port 2
[57214.013243] xhci-hcd xhci-hcd.0.auto: handle_port_status: starting
port polling.
[57214.081080] xhci-hcd xhci-hcd.0.auto: get port status, actual port 
0

status  = 0x201203
[57214.081084] xhci-hcd xhci-hcd.0.auto: Get port status returned
0x100203
[57214.081097] xhci-hcd xhci-hcd.0.auto: clear port reset change, 
actual

port 0 status  = 0x1203
[57214.081109] xhci-hcd xhci-hcd.0.auto: clear port warm(BH) reset
change, actual port 0 status  = 0x1203
[57214.081120] xhci-hcd xhci-hcd.0.auto: clear port link state change,
actual port 0 status  = 0x1203
[57214.081131] xhci-hcd xhci-hcd.0.auto: clear port connect change,
actual port 0 status  = 0x1203
[57214.081141] xhci-hcd xhci-hcd.0.auto: get port status, actual port 
0

status  = 0x1203
[57214.081144] xhci-hcd xhci-hcd.0.auto: Get port status returned 
0x203

[57214.141084] xhci-hcd xhci-hcd.0.auto: Set root hub portnum to 2
[57214.141087] xhci-hcd xhci-hcd.0.auto: Set fake root hub portnum to 
1

[57214.141091] xhci-hcd xhci-hcd.0.auto: udev->tt =   (null)
[57214.141094] xhci-hcd xhci-hcd.0.auto: udev->ttport = 0x0
[57214.141098] xhci-hcd xhci-hcd.0.auto: // Ding dong!
[57214.141131] xhci-hcd xhci-hcd.0.auto: Successful setup address
command
[57214.141136] xhci-hcd xhci-hcd.0.auto: Op regs DCBAA ptr =
0x007f041000
[57214.141140] xhci-hcd xhci-hcd.0.auto: Slot ID 1 dcbaa entry
@9c24453d = 0x007f0d8000
[57214.141144] xhci-hcd xhci-hcd.0.auto: Output Context DMA address =
0x7f0d8000
[57214.141147] xhci-hcd xhci-hcd.0.auto: Internal device address = 0
[57214.141153] xhci-hcd xhci-hcd.0.auto: Endpoint 0x0 ep reset 
callback

called
[57214.141157] usb 2-1: new SuperSpeed USB device number 12 using
xhci-hcd
[57214.167026] xhci-hcd xhci-hcd.0.auto: Waiting for status stage 
event
[57214.167123] xhci-hcd xhci-hcd.0.auto: Waiting for status stage 
event
[57214.167214] xhci-hcd xhci-hcd.0.auto: Waiting for status stage 
event
[57214.167311] xhci-hcd xhci-hcd.0.auto: Waiting for status stage 
event

[57214.167635] xhci-hcd xhci-hcd.0.auto: add ep 0x81, slot id 1, new
drop flags = 0x0, new add flags = 0x8
[57214.167659] xhci-hcd xhci-hcd.0.auto: add ep 0x2, slot id 1, new 
drop

flags = 0x0, new add flags = 0x18
[57214.167665] xhci-hcd xhci-hcd.0.auto: xhci_check_bandwidth called 
for

udev 3ae473f7
[57214.167676] xhci-hcd xhci-hcd.0.auto: // Ding dong!
[57214.167708] xhci-hcd xhci-hcd.0.auto: Successful

Re: Fwd: usb: uas: device reset most the time while enumeration- usb3.0

2018-04-16 Thread Tushar Nimkar


On 2018-04-05 12:39, Felipe Balbi wrote:

Hi,

tnim...@codeaurora.org writes:

On 2018-04-05 11:24, Felipe Balbi wrote:

Hi,

Greg KH  writes:

On Wed, Apr 04, 2018 at 05:14:50PM +0530, tnim...@codeaurora.org
wrote:

Hi Oliver/Greg,

I am able to duplicated the UAS issue on 4.16 as well.
The behavior is same new usb device detects and reset after aprox 
30

sec(SD_TIMEOUT)
Logs are already shared below.

We are using Synopsys dwc3 as host controller, May I know have 
tested

it
with dwc3?
I have tried it on Linux PC (x86 Ubuntu machine) I could not see 
the

issue.
It enumerates well.


Great, stick with an x86 platform!  :)

Looks like a dwc3 host controller issue, try enabling tracing and
debugging in that driver when this happens to see what is going on.
Also look at all of the recent dwc3 patches that were just sent to
Linus
for 4.17-rc1 to verify if that solves the issue.


dwc3's host side is xhci compliant :-) Some revisions have some 
quirks

which may not all be supported.


Felipe, "not all be supported" do u mean some xhci compliant host do
not support uas? and they have such quirks already defined?


No. I mean that some of dwc3's host side quirks may not have 
workarounds

implemented


Tushar, which dwc3 revision are you using? Have you gotten in touch
with

it is DWC3_REVISION_300A   ..3.0a


that's rather recent...


your HW designers to ask for Errata List? A run with xhci tracepoints

will response you, let me cross check once again with errata list.


okay

there is no uas related stuff in errata list, Felipe.


--
Best Regards,
Tushar R Nimkar

QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member of Code Aurora Forum, hosted by The Linux Foundation


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

usb: storage: uas: want to print the all IN ACK(Data-in)

2018-04-11 Thread Tushar Nimkar


Hi,

Talking about UASP Rev 1.0.pdf 
(http://www.usb.org/developers/docs/devclass_docs/)

"5.4.3 Data-in transfer"

As part of my debug..want to understand the flow. suspecting IN 
ACK(Data-in) is missing as per the lecroy log. And same I want to 
check/print.


Is there any way to do so?

I am receiving ERDY(Data-in) from device but not IN ACK(data-in), I 
could see on leCroy.



--
Best Regards,
Tushar R Nimkar

QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member of Code Aurora Forum, hosted by The Linux Foundation


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

need UASP/UAS spec

2018-03-12 Thread Tushar Nimkar

Hi,
Can u please help me  in getting UAS spec.?
I have "UASP Revision 1.0" but which is very old.

Want to understand what this "uas-tags"/ "initiator transfer tags" mean.
For only one case transfer (Command IU) it is 0x0002 rest case it is 0x0001

Please provide any link so that I can download spec.
Any help on "tags" is welcome.

-- 
Best Regards,
Tushar R Nimkar
Mob No : +91-9052258800
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb: uas: device reset most the time while enumeration- usb3.0

2018-02-07 Thread Tushar Nimkar

Oliver/Greg,
sorry to say but for my custom board it's difficult to flash 4.14 or
4.15. I are not sure that it will boot or not on my platform.
But Still i will try to do that and in parallel will try to flash on
Beagle bone.And will try.

 I used Lecroy today following are some observation..

working case :
for every try of ready_capacity_16 (total 3), there are bulk
transfer(OUT and IN) and status for read_capacity_16 is  "GOOD"

non-working case:
for first try of ready_capacity_16 there is bulk OUT but no IN
transfer , status for read_capacity_16 is "MISSING"
...seems that's that is the case we are receiving the
blk_rq_timed_out_timer() and eventually uas_eh_device_reset_handler()
I could not find why the bulk transfer could not  complete and causing
timer to expire.

Also  adding some msleep(100) before calling sd_read_capacity(), many
times i could not see the issue.

I don't know how to share Lecroy logs here. I can share the logs.

On Tue, Feb 6, 2018 at 3:32 PM, Oliver Neukum <oneu...@suse.com> wrote:
> Am Montag, den 05.02.2018, 23:46 +0530 schrieb Tushar Nimkar:
>> Greg,
>>
>> I have cherry-picked 9 patches as follows.
>
> Those won't do you any good. Please test
>
> a) with 4.14 or 4.15
> b) test on another host
>
> And tell me what read_capacity_16() does at USB2.0 speeds
>
> We need to determine whether error handling just works better
> at lower speed or high speed triggers the error. And with
> a current kernel if possible at all.
>
> Regards
> Oliver
>

-- 
Best Regards,
Tushar R Nimkar
Mob No : +91-9052258800
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb: uas : working uas devices ?

2018-02-07 Thread Tushar Nimkar

JMS567 is already reported and under "unusual_devs.h"
correct me if wrong.

commit ID :d92146222c96c22b45486961be642b1ba1c4129c

On Wed, Feb 7, 2018 at 8:09 PM, Menion <men...@gmail.com> wrote:
> This is not fully true
> Multibay enclosure may have problem, see my thread "uas failing on
> multiple disk access on a jmicron JMS567 bridge"
>
> 2018-02-07 15:38 GMT+01:00 Tushar Nimkar <tushar.n...@gmail.com>:
>> Thanks Adrian and Greg.
>>
>> On Wed, Feb 7, 2018 at 7:59 PM, Greg KH <g...@kroah.com> wrote:
>>> On Wed, Feb 07, 2018 at 12:13:36PM +0530, Tushar Nimkar wrote:
>>>> Can anyone help me in selecting UASP/UAS device ?
>>>> Any link/ model no. will be helpful.
>>>> I could see unusual_uas.h has many devices which are not behaving well
>>>> so don't want to take risk in selecting.
>>>
>>> The majority work just fine, I've bought lots of them and they all work
>>> with no issues at all.  Look for good reviews on sites like amazon
>>> saying that the enclosure works on Linux, and you should be fine.
>>>
>>> good luck!
>>>
>>> greg k-h
>>
>>
>>
>> --
>> Best Regards,
>> Tushar R Nimkar
>> Mob No : +91-9052258800
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Best Regards,
Tushar R Nimkar
Mob No : +91-9052258800
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb: uas : working uas devices ?

2018-02-07 Thread Tushar Nimkar

Thanks Adrian and Greg.

On Wed, Feb 7, 2018 at 7:59 PM, Greg KH <g...@kroah.com> wrote:
> On Wed, Feb 07, 2018 at 12:13:36PM +0530, Tushar Nimkar wrote:
>> Can anyone help me in selecting UASP/UAS device ?
>> Any link/ model no. will be helpful.
>> I could see unusual_uas.h has many devices which are not behaving well
>> so don't want to take risk in selecting.
>
> The majority work just fine, I've bought lots of them and they all work
> with no issues at all.  Look for good reviews on sites like amazon
> saying that the enclosure works on Linux, and you should be fine.
>
> good luck!
>
> greg k-h



-- 
Best Regards,
Tushar R Nimkar
Mob No : +91-9052258800
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

usb: uas : working uas devices ?

2018-02-06 Thread Tushar Nimkar

Can anyone help me in selecting UASP/UAS device ?
Any link/ model no. will be helpful.
I could see unusual_uas.h has many devices which are not behaving well
so don't want to take risk in selecting.

Other then Trancend SSDs because I have that. Want to check on other disks.

-- 
Best Regards,
Tushar R Nimkar
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb: uas: device reset most the time while enumeration- usb3.0

2018-02-05 Thread Tushar Nimkar

Greg,

I have cherry-picked 9 patches as follows.


d921462 USB: uas and storage: Add US_FL_BROKEN_FUA for another JMicron JMS567 ID

d7321ce uas: Add US_FL_IGNORE_RESIDUE for Initio Corporation INIC-3069

b3568a9 uas: Always apply US_FL_NO_ATA_1X quirk to Seagate devices

66215a3 USB: uas: fix bug in handling of alternate settings

34ce628 scsi: uas: move eh_bus_reset_handler to eh_device_reset_handler

c5afd93 uas: remove can_queue set in host template

75b8da4 USB: uas: add full support for RESPONSE IU

befea02 uas: no gfp argument to uas_submit_urbs()

849b7c6 uas: use the BIT() macro




I will try and update the same if possible to duplicate this on 4.14.14 or 4.15

On Mon, Feb 5, 2018 at 11:40 PM, Greg KH <gre...@linuxfoundation.org> wrote:
> On Mon, Feb 05, 2018 at 11:34:40PM +0530, Tushar Nimkar wrote:
>> Hi ,
>>
>> I am enabling uas support. And facing the issue as follows.
>>
>> I have observed that when ( Transcend StoreJet TS256GESD400K )
>> connected to my custom board,  it detects first then
>> uas_eh_abort_handler() get call and then reset and enumerates
>> properly.When same device is used with 2.0 HUB their is no such issue.
>>
>>
>> logs-->Super-speed
>>
>>  [  323.912384] usb 2-1: new SuperSpeed USB device number 3 using xhci-hcd
>> [  323.947103] scsi host1: uas
>> [  323.948153] scsi 1:0:0:0: Direct-Access StoreJet TS256GESD400K
>>   0PQ: 0 ANSI: 6
>> [  323.949825] sd 1:0:0:0: [sda] 500118192 512-byte logical blocks:
>> (256 GB/238 GiB)
>> [  354.092341] sd 1:0:0:0: tag#0 uas_eh_abort_handler 0 uas-tag 1
>> inflight: CMD IN
>> [  354.092380] sd 1:0:0:0: tag#0 CDB: opcode=0x12 12 01 00 00 40 00
>> [  354.098922] scsi host1: uas_eh_device_reset_handler start
>> [  354.104963] xhci-hcd xhci-hcd.0.auto: ERROR Transfer event for
>> disabled endpoint or incorrect stream ring
>> [  354.110095] xhci-hcd xhci-hcd.0.auto: @7d41f750 
>>  1b00 01078001
>> [  354.232398] usb 2-1: reset SuperSpeed USB device number 3 using xhci-hcd
>> [  354.253844] scsi host1: uas_eh_device_reset_handler success
>> [  354.263222] sd 1:0:0:0: [sda] Write Protect is off
>> [  354.263461] sd 1:0:0:0: [sda] Write cache: enabled, read cache:
>> enabled, doesn't support DPO or FUA
>> [  354.267036] xhci-hcd xhci-hcd.0.auto: ERROR Transfer event for
>> disabled endpoint or incorrect stream ring
>> [  354.275847] xhci-hcd xhci-hcd.0.auto: @7d41fa00 
>>  1b00 01038001
>> [  354.287566]  sda: sda1 sda2
>> [  354.295407] sd 1:0:0:0: [sda] Attached SCSI disk
>>
>> logs-->checked with 2.0 hub(same device)
>>
>> [  104.292324] usb 3-1: new high-speed USB device number 2 using xhci-hcd
>> [  104.457236] hub 3-1:1.0: USB hub found
>> [  104.457305] hub 3-1:1.0: 4 ports detected
>> [  105.392323] usb 3-1.4: new high-speed USB device number 3 using xhci-hcd
>> [  105.545492] scsi host1: uas
>> [  105.546777] scsi 1:0:0:0: Direct-Access StoreJet TS256GESD400K
>>   0PQ: 0 ANSI: 6
>> [  105.548876] sd 1:0:0:0: [sda] 500118192 512-byte logical blocks:
>> (256 GB/238 GiB)
>> [  105.556591] sd 1:0:0:0: [sda] Write Protect is off
>> [  105.563321] sd 1:0:0:0: [sda] Write cache: enabled, read cache:
>> enabled, doesn't support DPO or FUA
>> [  105.570685]  sda: sda1 sda2
>> [  105.579182] sd 1:0:0:0: [sda] Attached SCSI disk
>>
>>
>>
>> Digging into issue I found that blk_rq_timed_out_timer() gets calls
>> and which calls scsi_time_out() and further uas_eh_abort_handler().
>> [ blk_rq_timed_out_timer() --> blk_rq_check_expired()-->
>> scsi_times_out()-->scsi_abort_command()--> scmd_eh_abort_handler()-->
>> scsi_try_to_abort_cmd ()-->uas_eh_abort_handler() ]
>>
>> Also would like to add whenever we execute read_capacity_16() to read
>> the capacity of the device suddenly we are receiving
>> blk_rq_timed_out_timer() and around 30 sec device will reset and
>> enumerate.
>>
>> Also there are errors from xhci driver too.
>>
>>
>> Kernel : 4.4.60 and uas patches cherry-picked from kernel-4.14.13
>
> 4.4.60 is _really_ old and obsolete and insecure, and by randomly
> cherry-picking patches, we really have no idea what you are running.
>
> Can you duplicate this on 4.14.14?  4.15?
>
> thanks,
>
> greg k-h



-- 
Best Regards,
Tushar R Nimkar
Mob No : +91-9052258800
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

usb: uas: device reset most the time while enumeration- usb3.0

2018-02-05 Thread Tushar Nimkar

Hi ,

I am enabling uas support. And facing the issue as follows.

I have observed that when ( Transcend StoreJet TS256GESD400K )
connected to my custom board,  it detects first then
uas_eh_abort_handler() get call and then reset and enumerates
properly.When same device is used with 2.0 HUB their is no such issue.


logs-->Super-speed

 [  323.912384] usb 2-1: new SuperSpeed USB device number 3 using xhci-hcd
[  323.947103] scsi host1: uas
[  323.948153] scsi 1:0:0:0: Direct-Access StoreJet TS256GESD400K
  0PQ: 0 ANSI: 6
[  323.949825] sd 1:0:0:0: [sda] 500118192 512-byte logical blocks:
(256 GB/238 GiB)
[  354.092341] sd 1:0:0:0: tag#0 uas_eh_abort_handler 0 uas-tag 1
inflight: CMD IN
[  354.092380] sd 1:0:0:0: tag#0 CDB: opcode=0x12 12 01 00 00 40 00
[  354.098922] scsi host1: uas_eh_device_reset_handler start
[  354.104963] xhci-hcd xhci-hcd.0.auto: ERROR Transfer event for
disabled endpoint or incorrect stream ring
[  354.110095] xhci-hcd xhci-hcd.0.auto: @7d41f750 
 1b00 01078001
[  354.232398] usb 2-1: reset SuperSpeed USB device number 3 using xhci-hcd
[  354.253844] scsi host1: uas_eh_device_reset_handler success
[  354.263222] sd 1:0:0:0: [sda] Write Protect is off
[  354.263461] sd 1:0:0:0: [sda] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[  354.267036] xhci-hcd xhci-hcd.0.auto: ERROR Transfer event for
disabled endpoint or incorrect stream ring
[  354.275847] xhci-hcd xhci-hcd.0.auto: @7d41fa00 
 1b00 01038001
[  354.287566]  sda: sda1 sda2
[  354.295407] sd 1:0:0:0: [sda] Attached SCSI disk

logs-->checked with 2.0 hub(same device)

[  104.292324] usb 3-1: new high-speed USB device number 2 using xhci-hcd
[  104.457236] hub 3-1:1.0: USB hub found
[  104.457305] hub 3-1:1.0: 4 ports detected
[  105.392323] usb 3-1.4: new high-speed USB device number 3 using xhci-hcd
[  105.545492] scsi host1: uas
[  105.546777] scsi 1:0:0:0: Direct-Access StoreJet TS256GESD400K
  0PQ: 0 ANSI: 6
[  105.548876] sd 1:0:0:0: [sda] 500118192 512-byte logical blocks:
(256 GB/238 GiB)
[  105.556591] sd 1:0:0:0: [sda] Write Protect is off
[  105.563321] sd 1:0:0:0: [sda] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[  105.570685]  sda: sda1 sda2
[  105.579182] sd 1:0:0:0: [sda] Attached SCSI disk



Digging into issue I found that blk_rq_timed_out_timer() gets calls
and which calls scsi_time_out() and further uas_eh_abort_handler().
[ blk_rq_timed_out_timer() --> blk_rq_check_expired()-->
scsi_times_out()-->scsi_abort_command()--> scmd_eh_abort_handler()-->
scsi_try_to_abort_cmd ()-->uas_eh_abort_handler() ]

Also would like to add whenever we execute read_capacity_16() to read
the capacity of the device suddenly we are receiving
blk_rq_timed_out_timer() and around 30 sec device will reset and
enumerate.

Also there are errors from xhci driver too.


Kernel : 4.4.60 and uas patches cherry-picked from kernel-4.14.13

Do we have such issue present in the upstream too?
Please help in solving this issue.Any inputs will be helpful.
Eager to solve this.

Best Regards
Tushar R. Nimkar
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fwd: usb: uas: device reset most the time while enumeration- usb3.0

Re: Fwd: usb: uas: device reset most the time while enumeration- usb3.0

Re: Fwd: usb: uas: device reset most the time while enumeration- usb3.0

Re: Fwd: usb: uas: device reset most the time while enumeration- usb3.0

Re: Fwd: usb: uas: device reset most the time while enumeration- usb3.0

usb: storage: what is the correct sequence for? sd_probe| storage_probe/1/2 and uas_probe | scsi_scan_host

Re: howto debug xhci driver?

Re: Fwd: usb: uas: device reset most the time while enumeration- usb3.0

Re: Fwd: usb: uas: device reset most the time while enumeration- usb3.0

Re: howto debug xhci driver?

Re: Fwd: usb: uas: device reset most the time while enumeration- usb3.0

Re: Fwd: usb: uas: device reset most the time while enumeration- usb3.0

Re: Fwd: usb: uas: device reset most the time while enumeration- usb3.0

Re: Fwd: usb: uas: device reset most the time while enumeration- usb3.0

Re: Fwd: usb: uas: device reset most the time while enumeration- usb3.0

Re: Fwd: usb: uas: device reset most the time while enumeration- usb3.0

Re: Fwd: usb: uas: device reset most the time while enumeration- usb3.0

usb: storage: uas: want to print the all IN ACK(Data-in)

need UASP/UAS spec

Re: usb: uas: device reset most the time while enumeration- usb3.0

Re: usb: uas : working uas devices ?

Re: usb: uas : working uas devices ?

usb: uas : working uas devices ?

Re: usb: uas: device reset most the time while enumeration- usb3.0

usb: uas: device reset most the time while enumeration- usb3.0

25 matches

Site Navigation

Mail list logo

Footer information