date:20150913

Re: xhci woes continued

2015-09-13 Thread Hans-Peter Jansen

On Samstag, 12. September 2015 14:46:42 Alan Stern wrote:
> On Sat, 12 Sep 2015, Hans-Peter Jansen wrote:
> > On Freitag, 11. September 2015 10:23:45 Alan Stern wrote:
> > > On Fri, 11 Sep 2015, Hans-Peter Jansen wrote:
> > > > I still have trouble with storage devices on xhci ports, that
> > > > disappear as
> > > > soon as I change to an ehci port.
> > > > 
> > > > My current kernel version is 4.1.6.
> > > > Device is a Transcend TS-RDF8K USB3.0 sdcard reader, tested directly
> > > > on
> > > > rear panel I/O USB3.0 port of a z97 series MB (ASUS Z97-A) with the
> > > > original cable, and a SanDisk Ultra 64GB SDXC media.
> > > 
> > > Can you post a usbmon trace showing what happens when the card reader
> > > is plugged in?  Instructions are in the kernel source file
> > > Documentation/usb/usbmon.txt.
> > 
> > With pleasure, Alan.
> > 
> > Here we go, plugged the reader for about 20 secs, result attached.
> 
> The usbmon trace clearly shows the problem: The card reader's firmware
> doesn't handle transfers larger than 64 KB properly.  (That's a bit of
> a guess on my part; what the trace really shows is that transfers of
> length 120 KB and 72 KB failed whereas lengths 28 KB and below worked.)
> 
> Anyway, you can supply a quirks parameter for the usb-storage module to
> force all transfers to be short:
> 
>   modprobe usb-storage quirks=8564:4000:m
> 
> (That's the vendor and product IDs of your card reader, together with a
> flag to limit the Max number of sectors per transfer.)  Does that fix
> the problem?

Yes, sort of, thanks, Alan. Unfortunately, write operations render my (fairly 
capable) desktop nearly unusable, stalls for a couple of seconds, switching 
desktops take 10-20 secs, while write performance is abysmal for USB 3.0 SDXC 
class 1 devices. 

But that got me going. I've updated the firmware on this device to TS26, and 
now, it behaves better: it performs ok and the desktop is still usable. Cool.

May I introduce another faulty device: Fantec AluPro U3 external 2,5" case  
(Asmedia AS2105 controller) with a HGST HTS721010 7K1000 harddisk. I wasn't 
able to locate any firmware for this device.

Issue here is, the drive is continusly connecting and disconnecting:

2015-09-13T11:55:30.641698+02:00 xrated kernel: [171947.841309] usb 7-1: USB 
disconnect, device number 91
2015-09-13T11:55:30.853671+02:00 xrated kernel: [171948.053246] usb 7-1: new 
SuperSpeed USB device number 92 using xhci_hcd
2015-09-13T11:55:30.864676+02:00 xrated kernel: [171948.065133] usb 7-1: New 
USB device found, idVendor=174c, idProduct=5106
2015-09-13T11:55:30.864681+02:00 xrated kernel: [171948.065134] usb 7-1: New 
USB device strings: Mfr=2, Product=3, SerialNumber=1
2015-09-13T11:55:30.864682+02:00 xrated kernel: [171948.065136] usb 7-1: 
Product: AS2105
2015-09-13T11:55:30.864682+02:00 xrated kernel: [171948.065136] usb 7-1: 
Manufacturer: ASMedia
2015-09-13T11:55:30.864683+02:00 xrated kernel: [171948.065137] usb 7-1: 
SerialNumber:   JR10046P2HAJ8N
2015-09-13T11:55:30.865663+02:00 xrated kernel: [171948.065961] usb-storage 
7-1:1.0: USB Mass Storage device detected
2015-09-13T11:55:30.865666+02:00 xrated kernel: [171948.066046] scsi host196: 
usb-storage 7-1:1.0
2015-09-13T11:55:30.867001+02:00 xrated mtp-probe: checking bus 7, device 92: 
"/sys/devices/pci:00/:00:14.0/usb7/7-1"
2015-09-13T11:55:30.867182+02:00 xrated mtp-probe: bus: 7, device: 92 was not 
an MTP device
2015-09-13T11:55:32.111692+02:00 xrated kernel: [171949.310429] usb 7-1: USB 
disconnect, device number 92
2015-09-13T11:55:32.323698+02:00 xrated kernel: [171949.522367] usb 7-1: new 
SuperSpeed USB device number 93 using xhci_hcd
2015-09-13T11:55:32.334669+02:00 xrated kernel: [171949.534190] usb 7-1: New 
USB device found, idVendor=174c, idProduct=5106
2015-09-13T11:55:32.334672+02:00 xrated kernel: [171949.534192] usb 7-1: New 
USB device strings: Mfr=2, Product=3, SerialNumber=1
2015-09-13T11:55:32.334673+02:00 xrated kernel: [171949.534193] usb 7-1: 
Product: AS2105
2015-09-13T11:55:32.334674+02:00 xrated kernel: [171949.534194] usb 7-1: 
Manufacturer: ASMedia
2015-09-13T11:55:32.334674+02:00 xrated kernel: [171949.534195] usb 7-1: 
SerialNumber:   JR10046P2HAJ8N
2015-09-13T11:55:32.335663+02:00 xrated kernel: [171949.534983] usb-storage 
7-1:1.0: USB Mass Storage device detected
2015-09-13T11:55:32.335665+02:00 xrated kernel: [171949.535057] scsi host197: 
usb-storage 7-1:1.0
2015-09-13T11:55:32.336710+02:00 xrated mtp-probe: checking bus 7, device 93: 
"/sys/devices/pci:00/:00:14.0/usb7/7-1"
2015-09-13T11:55:32.336853+02:00 xrated mtp-probe: bus: 7, device: 93 was not 
an MTP device
2015-09-13T11:55:33.339668+02:00 xrated kernel: [171950.538223] scsi 197:0:0:0: 
Direct-Access HGST HTS 721010A9E630 JB0O PQ: 0 ANSI: 5
2015-09-13T11:55:33.339675+02:00 xrated kernel: [171950.538410] sd 197:0:0:0: 
Attached scsi generic sg5 type 0
2015-09-13T11:55:33.339676+02:00 xrated kernel: [171950.538551] sd 197:0:0:

[PATCH 39/39] usb: host: drop null test before destroy functions

2015-09-13 Thread Julia Lawall

Remove unneeded NULL test.

The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)

// 
@@
expression x;
@@

-if (x != NULL)
  \(kmem_cache_destroy\|mempool_destroy\|dma_pool_destroy\)(x);

@@
expression x;
@@

-if (x != NULL) {
  \(kmem_cache_destroy\|mempool_destroy\|dma_pool_destroy\)(x);
  x = NULL;
-}
// 

Signed-off-by: Julia Lawall 

---
 drivers/usb/host/fotg210-hcd.c  |   12 
 drivers/usb/host/fusbh200-hcd.c |   12 
 2 files changed, 8 insertions(+), 16 deletions(-)

diff --git a/drivers/usb/host/fotg210-hcd.c b/drivers/usb/host/fotg210-hcd.c
index 000ed80..287d595 100644
--- a/drivers/usb/host/fotg210-hcd.c
+++ b/drivers/usb/host/fotg210-hcd.c
@@ -1976,17 +1976,13 @@ static void fotg210_mem_cleanup(struct fotg210_hcd 
*fotg210)
fotg210->dummy = NULL;
 
/* DMA consistent memory and pools */
-   if (fotg210->qtd_pool)
-   dma_pool_destroy(fotg210->qtd_pool);
+   dma_pool_destroy(fotg210->qtd_pool);
fotg210->qtd_pool = NULL;
 
-   if (fotg210->qh_pool) {
-   dma_pool_destroy(fotg210->qh_pool);
-   fotg210->qh_pool = NULL;
-   }
+   dma_pool_destroy(fotg210->qh_pool);
+   fotg210->qh_pool = NULL;
 
-   if (fotg210->itd_pool)
-   dma_pool_destroy(fotg210->itd_pool);
+   dma_pool_destroy(fotg210->itd_pool);
fotg210->itd_pool = NULL;
 
if (fotg210->periodic)
diff --git a/drivers/usb/host/fusbh200-hcd.c b/drivers/usb/host/fusbh200-hcd.c
index 1fd8718..b247d71 100644
--- a/drivers/usb/host/fusbh200-hcd.c
+++ b/drivers/usb/host/fusbh200-hcd.c
@@ -1927,17 +1927,13 @@ static void fusbh200_mem_cleanup (struct fusbh200_hcd 
*fusbh200)
fusbh200->dummy = NULL;
 
/* DMA consistent memory and pools */
-   if (fusbh200->qtd_pool)
-   dma_pool_destroy (fusbh200->qtd_pool);
+   dma_pool_destroy(fusbh200->qtd_pool);
fusbh200->qtd_pool = NULL;
 
-   if (fusbh200->qh_pool) {
-   dma_pool_destroy (fusbh200->qh_pool);
-   fusbh200->qh_pool = NULL;
-   }
+   dma_pool_destroy(fusbh200->qh_pool);
+   fusbh200->qh_pool = NULL;
 
-   if (fusbh200->itd_pool)
-   dma_pool_destroy (fusbh200->itd_pool);
+   dma_pool_destroy(fusbh200->itd_pool);
fusbh200->itd_pool = NULL;
 
if (fusbh200->periodic)

--
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

[PATCH 18/39] whci: drop null test before destroy functions

2015-09-13 Thread Julia Lawall

Remove unneeded NULL test.

The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)

// 
@@ expression x; @@
-if (x != NULL)
  \(kmem_cache_destroy\|mempool_destroy\|dma_pool_destroy\)(x);
// 

Signed-off-by: Julia Lawall 

---
 drivers/usb/host/whci/init.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/usb/host/whci/init.c b/drivers/usb/host/whci/init.c
index d3e13b6..e363723 100644
--- a/drivers/usb/host/whci/init.c
+++ b/drivers/usb/host/whci/init.c
@@ -175,8 +175,7 @@ void whc_clean_up(struct whc *whc)
pzl_clean_up(whc);
asl_clean_up(whc);
 
-   if (whc->qset_pool)
-   dma_pool_destroy(whc->qset_pool);
+   dma_pool_destroy(whc->qset_pool);
 
len   = resource_size(&whc->umc->resource);
if (whc->base)

--
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

[PATCH 16/39] usb: gadget: drop null test before destroy functions

2015-09-13 Thread Julia Lawall

Remove unneeded NULL test.

The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)

// 
@@ expression x; @@
-if (x != NULL)
  \(kmem_cache_destroy\|mempool_destroy\|dma_pool_destroy\)(x);
// 

Signed-off-by: Julia Lawall 

---
 drivers/usb/gadget/udc/bdc/bdc_core.c |3 +--
 drivers/usb/gadget/udc/gr_udc.c   |3 +--
 drivers/usb/gadget/udc/mv_u3d_core.c  |3 +--
 drivers/usb/gadget/udc/mv_udc_core.c  |3 +--
 4 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/gadget/udc/mv_udc_core.c 
b/drivers/usb/gadget/udc/mv_udc_core.c
index 339af51..81b6229 100644
--- a/drivers/usb/gadget/udc/mv_udc_core.c
+++ b/drivers/usb/gadget/udc/mv_udc_core.c
@@ -2100,8 +2100,7 @@ static int mv_udc_remove(struct platform_device *pdev)
}
 
/* free memory allocated in probe */
-   if (udc->dtd_pool)
-   dma_pool_destroy(udc->dtd_pool);
+   dma_pool_destroy(udc->dtd_pool);
 
if (udc->ep_dqh)
dma_free_coherent(&pdev->dev, udc->ep_dqh_size,
diff --git a/drivers/usb/gadget/udc/gr_udc.c b/drivers/usb/gadget/udc/gr_udc.c
index 8aa2593..b9429bc 100644
--- a/drivers/usb/gadget/udc/gr_udc.c
+++ b/drivers/usb/gadget/udc/gr_udc.c
@@ -2117,8 +2117,7 @@ static int gr_remove(struct platform_device *pdev)
return -EBUSY;
 
gr_dfs_delete(dev);
-   if (dev->desc_pool)
-   dma_pool_destroy(dev->desc_pool);
+   dma_pool_destroy(dev->desc_pool);
platform_set_drvdata(pdev, NULL);
 
gr_free_request(&dev->epi[0].ep, &dev->ep0reqi->req);
diff --git a/drivers/usb/gadget/udc/mv_u3d_core.c 
b/drivers/usb/gadget/udc/mv_u3d_core.c
index 4c48969..dafe74e 100644
--- a/drivers/usb/gadget/udc/mv_u3d_core.c
+++ b/drivers/usb/gadget/udc/mv_u3d_core.c
@@ -1767,8 +1767,7 @@ static int mv_u3d_remove(struct platform_device *dev)
usb_del_gadget_udc(&u3d->gadget);
 
/* free memory allocated in probe */
-   if (u3d->trb_pool)
-   dma_pool_destroy(u3d->trb_pool);
+   dma_pool_destroy(u3d->trb_pool);
 
if (u3d->ep_context)
dma_free_coherent(&dev->dev, u3d->ep_context_size,
diff --git a/drivers/usb/gadget/udc/bdc/bdc_core.c 
b/drivers/usb/gadget/udc/bdc/bdc_core.c
index 5c8f4ef..ccb9c21 100644
--- a/drivers/usb/gadget/udc/bdc/bdc_core.c
+++ b/drivers/usb/gadget/udc/bdc/bdc_core.c
@@ -324,8 +324,7 @@ static void bdc_mem_free(struct bdc *bdc)
bdc->scratchpad.buff, bdc->scratchpad.sp_dma);
 
/* Destroy the dma pools */
-   if (bdc->bd_table_pool)
-   dma_pool_destroy(bdc->bd_table_pool);
+   dma_pool_destroy(bdc->bd_table_pool);
 
/* Free the bdc_ep array */
kfree(bdc->bdc_ep_array);

--
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

[PATCH 00/39] drop null test before destroy functions

2015-09-13 Thread Julia Lawall

Recent commits to kernel/git/torvalds/linux.git have made the following
functions able to tolerate NULL arguments:

kmem_cache_destroy (commit 3942d29918522)
mempool_destroy (commit 4e3ca3e033d1)
dma_pool_destroy (commit 44d7175da6ea)

These patches remove the associated NULL tests for the files that I found
easy to compile test.  If these changes are OK, I will address the
remainder later.

---

 arch/x86/kvm/mmu.c |6 --
 block/bio-integrity.c  |7 --
 block/bio.c|7 --
 block/blk-core.c   |3 -
 block/elevator.c   |3 -
 drivers/atm/he.c   |7 --
 drivers/block/aoe/aoedev.c |3 -
 drivers/block/drbd/drbd_main.c |   21 ++-
 drivers/block/pktcdvd.c|3 -
 drivers/block/rbd.c|6 --
 drivers/dma/dmaengine.c|6 --
 drivers/firmware/google/gsmi.c |3 -
 drivers/gpu/drm/i915/i915_dma.c|   19 ++
 drivers/iommu/amd_iommu_init.c |7 --
 drivers/md/bcache/bset.c   |3 -
 drivers/md/bcache/request.c|3 -
 drivers/md/bcache/super.c  |9 +--
 drivers/md/dm-bufio.c  |3 -
 drivers/md/dm-cache-target.c   |3 -
 drivers/md/dm-crypt.c  |6 --
 drivers/md/dm-io.c |3 -
 drivers/md/dm-log-userspace-base.c |3 -
 drivers/md/dm-region-hash.c|4 -
 drivers/md/dm.c|   13 +---
 drivers/md/multipath.c |3 -
 drivers/md/raid1.c |6 --
 drivers/md/raid10.c|9 +--
 drivers/md/raid5.c |3 -
 drivers/mtd/nand/nandsim.c |3 -
 drivers/mtd/ubi/attach.c   |4 -
 drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c  |3 -
 drivers/staging/lustre/lustre/llite/super25.c  |   16 +
 drivers/staging/lustre/lustre/obdclass/genops.c|   24 ++--
 drivers/staging/lustre/lustre/obdclass/lu_object.c |6 --
 drivers/staging/rdma/hfi1/user_sdma.c  |3 -
 drivers/thunderbolt/ctl.c  |3 -
 drivers/usb/gadget/udc/bdc/bdc_core.c  |3 -
 drivers/usb/gadget/udc/gr_udc.c|3 -
 drivers/usb/gadget/udc/mv_u3d_core.c   |3 -
 drivers/usb/gadget/udc/mv_udc_core.c   |3 -
 drivers/usb/host/fotg210-hcd.c |   12 +---
 drivers/usb/host/fusbh200-hcd.c|   12 +---
 drivers/usb/host/whci/init.c   |3 -
 drivers/usb/host/xhci-mem.c|   12 +---
 fs/btrfs/backref.c |3 -
 fs/btrfs/delayed-inode.c   |3 -
 fs/btrfs/delayed-ref.c |   12 +---
 fs/btrfs/disk-io.c |3 -
 fs/btrfs/extent_io.c   |6 --
 fs/btrfs/extent_map.c  |3 -
 fs/btrfs/file.c|3 -
 fs/btrfs/inode.c   |   18 ++
 fs/btrfs/ordered-data.c|3 -
 fs/dlm/memory.c|6 --
 fs/ecryptfs/main.c |3 -
 fs/ext4/crypto.c   |9 +--
 fs/ext4/extents_status.c   |3 -
 fs/ext4/mballoc.c  |3 -
 fs/f2fs/crypto.c   |9 +--
 fs/gfs2/main.c |   29 ++
 fs/jbd2/journal.c  |   15 +
 fs/jbd2/revoke.c   |   12 +---
 fs/jbd2/transaction.c  |6 --
 fs/jffs2/malloc.c  |   27 +++--
 fs/nfsd/nfscache.c |6 --
 fs/nilfs2/super.c  |   12 +---
 fs/ocfs2/dlm/dlmlock.c |3 -
 fs/ocfs2/dlm/dlmmaster.c   |   16 +
 fs/ocfs2/super.c   |   18 ++
 fs/ocfs2/uptodate.c|3 -
 lib/debugobjects.c |3 -
 net/core/sock.c|   12 +---
 net/dccp/ackvec.c  |   12 +---
 net/dccp/ccid.c

[PATCH 05/39] xhci: drop null test before destroy functions

2015-09-13 Thread Julia Lawall

Remove unneeded NULL test.

The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)

// 
@@ expression x; @@
-if (x != NULL)
  \(kmem_cache_destroy\|mempool_destroy\|dma_pool_destroy\)(x);
// 

Signed-off-by: Julia Lawall 

---
 drivers/usb/host/xhci-mem.c |   12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 9a8c936..40618d1 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1829,24 +1829,20 @@ void xhci_mem_cleanup(struct xhci_hcd *xhci)
for (i = 1; i < MAX_HC_SLOTS; ++i)
xhci_free_virt_device(xhci, i);
 
-   if (xhci->segment_pool)
-   dma_pool_destroy(xhci->segment_pool);
+   dma_pool_destroy(xhci->segment_pool);
xhci->segment_pool = NULL;
xhci_dbg_trace(xhci, trace_xhci_dbg_init, "Freed segment pool");
 
-   if (xhci->device_pool)
-   dma_pool_destroy(xhci->device_pool);
+   dma_pool_destroy(xhci->device_pool);
xhci->device_pool = NULL;
xhci_dbg_trace(xhci, trace_xhci_dbg_init, "Freed device context pool");
 
-   if (xhci->small_streams_pool)
-   dma_pool_destroy(xhci->small_streams_pool);
+   dma_pool_destroy(xhci->small_streams_pool);
xhci->small_streams_pool = NULL;
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
"Freed small stream array pool");
 
-   if (xhci->medium_streams_pool)
-   dma_pool_destroy(xhci->medium_streams_pool);
+   dma_pool_destroy(xhci->medium_streams_pool);
xhci->medium_streams_pool = NULL;
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
"Freed medium stream array pool");

--
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: xhci woes continued

2015-09-13 Thread Alan Stern

On Sun, 13 Sep 2015, Hans-Peter Jansen wrote:

> > The usbmon trace clearly shows the problem: The card reader's firmware
> > doesn't handle transfers larger than 64 KB properly.  (That's a bit of
> > a guess on my part; what the trace really shows is that transfers of
> > length 120 KB and 72 KB failed whereas lengths 28 KB and below worked.)
> > 
> > Anyway, you can supply a quirks parameter for the usb-storage module to
> > force all transfers to be short:
> > 
> > modprobe usb-storage quirks=8564:4000:m
> > 
> > (That's the vendor and product IDs of your card reader, together with a
> > flag to limit the Max number of sectors per transfer.)  Does that fix
> > the problem?
> 
> Yes, sort of, thanks, Alan. Unfortunately, write operations render my (fairly 
> capable) desktop nearly unusable, stalls for a couple of seconds, switching 
> desktops take 10-20 secs, while write performance is abysmal for USB 3.0 SDXC 
> class 1 devices. 
> 
> But that got me going. I've updated the firmware on this device to TS26, and 
> now, it behaves better: it performs ok and the desktop is still usable. Cool.

Does the new firmware still require the usb-storage quirk?

> May I introduce another faulty device: Fantec AluPro U3 external 2,5" case  
> (Asmedia AS2105 controller) with a HGST HTS721010 7K1000 harddisk. I wasn't 
> able to locate any firmware for this device.
> 
> Issue here is, the drive is continusly connecting and disconnecting:
> 
> 2015-09-13T11:55:30.641698+02:00 xrated kernel: [171947.841309] usb 7-1: USB 
> disconnect, device number 91
> 2015-09-13T11:55:30.853671+02:00 xrated kernel: [171948.053246] usb 7-1: new 
> SuperSpeed USB device number 92 using xhci_hcd
> 2015-09-13T11:55:30.864676+02:00 xrated kernel: [171948.065133] usb 7-1: New 
> USB device found, idVendor=174c, idProduct=5106
> 2015-09-13T11:55:30.864681+02:00 xrated kernel: [171948.065134] usb 7-1: New 
> USB device strings: Mfr=2, Product=3, SerialNumber=1
> 2015-09-13T11:55:30.864682+02:00 xrated kernel: [171948.065136] usb 7-1: 
> Product: AS2105
> 2015-09-13T11:55:30.864682+02:00 xrated kernel: [171948.065136] usb 7-1: 
> Manufacturer: ASMedia
> 2015-09-13T11:55:30.864683+02:00 xrated kernel: [171948.065137] usb 7-1: 
> SerialNumber:   JR10046P2HAJ8N
> 2015-09-13T11:55:30.865663+02:00 xrated kernel: [171948.065961] usb-storage 
> 7-1:1.0: USB Mass Storage device detected
> 2015-09-13T11:55:30.865666+02:00 xrated kernel: [171948.066046] scsi host196: 
> usb-storage 7-1:1.0
> 2015-09-13T11:55:30.867001+02:00 xrated mtp-probe: checking bus 7, device 92: 
> "/sys/devices/pci:00/:00:14.0/usb7/7-1"
> 2015-09-13T11:55:30.867182+02:00 xrated mtp-probe: bus: 7, device: 92 was not 
> an MTP device
> 2015-09-13T11:55:32.111692+02:00 xrated kernel: [171949.310429] usb 7-1: USB 
> disconnect, device number 92
> 2015-09-13T11:55:32.323698+02:00 xrated kernel: [171949.522367] usb 7-1: new 
> SuperSpeed USB device number 93 using xhci_hcd
...

> usbmon log attached.

It wasn't attached.

Alan Stern

--
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: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M

2015-09-13 Thread Roland Weber

Hi Alan, hi all,

> > I can also produce the freeze on 3.17, with some extra steps:
> 
> Okay, that's worth knowing.
> 
> > (after boot there's just the ehci-pci bus with no device)
> > - unbind ehci-pci
> > - bind ehci-pci
> 
> During both the unbind and the bind, the debugging lines you added to
> ehci-hcd.c should show up.  Do they?

I'm afraid my statement wasn't entirely accurate. I was using a
precompiled kernel 3.17.8 (not 3.17 plain) without my debugging lines.
>From the regular kernel debug output, I get:

(first unbind)
ehci-pci :00:1d.0: remove, state 4
usb usb1: USB disconnect, device number 1
ehci-pci :00:1d.0: USB bus 1 deregistered

(bind)
ehci-pci :00:1d.0: EHCI Host Controller
ehci-pci :00:1d.0: new USB bus registered, assigned bus number 1
ehci-pci :00:1d.0: debug port 2
ehci-pci :00:1d.0: cache line size of 64 is not supported
ehci-pci :00:1d.0: irq 23, io mem 0x90918000
ehci-pci :00:1d.0: USB 2.0 started, EHCI 1.00
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: EHCI Host Controller
usb usb1: Manufacturer: Linux 3.17.8-031708-generic ehci_hcd
usb usb1: SerialNumber :00:1d.0
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 8 ports detected
usb 1-1: new high-speed USB device number 2 using ehci-pci
usb 1-1: New USB device found, idVendor=8087, idProduct=07e6
usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
hub 1-1:1.0: USB hub found
hub 1-1:1.0: 4 ports detected

(second unbind)
ehci-pci :00:1d.0: remove, state 4
usb usb1: USB disconnect, device number 1
usb 1-1: USB disconnect, device number 2
(freeze)


I compiled a kernel 3.17(.0) with my additional debug lines...
and this one does NOT freeze! The output is:

(first unbind)
ehci-pci :00:1d.0: remove, state 4
ehci-pci :00:1d.0: roothub graceful disconnect
usb usb1: USB disconnect, device number 1
ehci-pci :00:1d.0: shutdown urb 880072bf4300 ep1in-intr
usb_remove_hcd: calling stop
ehci-pci :00:1d.0: stop
ehci_silence_controller: entry
ehci_halt: entry
ehci_halt: after spin_lock_irq
ehci_halt: about to readl prematurely
ehci_halt: premature readl returned 10001
ehci_halt: after first ehci_writel
ehci_halt: before ehci_readl
ehci_halt: after ehci_readl, before ehci_writel
ehci_halt: after second ehci_writel
ehci_halt: after spin_unlock_irq
ehci_halt: after_synchronize_irq, before ehci_handshake
ehci_silence_controller: after ehci_silence_controller
ehci-pci :00:1d.0: reset command 0010002 (park)=0 ithresh=1 period=1024 
Reset HALT
ehci-pci :00:1d.0: ehci_stop completed status 1000 Halt
usb_remove_hcd: returned from stop
usb_remove_hcd: after del_timer_sync
ehci-pci :00:1d.0: USB bus 1 deregistered

(bind)
ehci-pci :00:1d.0: EHCI Host Controller
ehci-pci :00:1d.0: new USB bus registered, assigned bus number 1
ehci-pci :00:1d.0: debug port 2
ehci-pci :00:1d.0: cache line size of 64 is not supported
ehci-pci :00:1d.0: reset hcs_params 0x28 dbg=2 cc=0 pcc=0 ordered !ppc 
ports=8
ehci-pci :00:1d.0: reset hcc_params 36881 caching frame 1024 64 bit addr
ehci_halt: entry
ehci_halt: after spin_lock_irq
ehci_halt: about to readl prematurely
ehci_halt: premature readl returned 8
ehci_halt: after first ehci_writel
ehci_halt: before ehci_readl
ehci_halt: after ehci_readl, before ehci_writel
ehci_halt: after second ehci_writel
ehci_halt: after spin_unlock_irq
ehci_halt: after_synchronize_irq, before ehci_handshake
ehci-pci :00:1d.0: reset command 0010002 (park)=0 ithresh=1 period=1024 
Reset HALT
ehci-pci :00:1d.0: cache line size of 64 is not supported
ehci-pci :00:1d.0: supports USB remote wakeup
ehci-pci :00:1d.0: irq 23, io mem 0x90918000
ehci-pci :00:1d.0: init command 0010001 (park)=0 ithresh=1 period=1024 RUN
ehci-pci :00:1d.0: USB 2.0 started, EHCI 1.00
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: EHCI Host Controller
usb usb1: Manufacturer: Linux 3.17.0-w ehci_hcd
usb usb1: SerialNumber :00:1d.0
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 8 ports detected
ehci-pci :00:1d.0: GetStatus port:1 status 001803 0 ACK POWER sig=j CSC 
CONNECT
ehci-pci :00:1d.0: port 1 reset complete, port enabled
ehci-pci :00:1d.0: GetStatus port:1 status 001005 0 ACK POWER sig=se0 PE 
CONNECT
usb 1-1: new high-speed USB device number 2 using ehci-pci
ehci-pci :00:1d.0: port 1 reset complete, port enabled
ehci-pci :00:1d.0: GetStatus port:1 status 001005 0 ACK POWER sig=se0 PE CO
N
usb 1-1: New USB device found, idVendor=8087, idProduct=07e6
usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
hub 1-1:1.0: USB hub found
hub 1-1:1.0: 4 ports detected
usb 1-1: ep 81: reserve intr @ 8+64 (1.0+256) [1/0 us] mask 0001
usb 1-1: link qh256-0001/88007516dcc0 start 1 [1/0 us]

(second unbind)
ehci-pci :00

Re: xhci woes continued

2015-09-13 Thread Hans-Peter Jansen

On Sonntag, 13. September 2015 10:23:13 Alan Stern wrote:
> On Sun, 13 Sep 2015, Hans-Peter Jansen wrote:
> > > The usbmon trace clearly shows the problem: The card reader's firmware
> > > doesn't handle transfers larger than 64 KB properly.  (That's a bit of
> > > a guess on my part; what the trace really shows is that transfers of
> > > length 120 KB and 72 KB failed whereas lengths 28 KB and below worked.)
> > > 
> > > Anyway, you can supply a quirks parameter for the usb-storage module to
> > > 
> > > force all transfers to be short:
> > >   modprobe usb-storage quirks=8564:4000:m
> > > 
> > > (That's the vendor and product IDs of your card reader, together with a
> > > flag to limit the Max number of sectors per transfer.)  Does that fix
> > > the problem?
> > 
> > Yes, sort of, thanks, Alan. Unfortunately, write operations render my
> > (fairly capable) desktop nearly unusable, stalls for a couple of seconds,
> > switching desktops take 10-20 secs, while write performance is abysmal
> > for USB 3.0 SDXC class 1 devices.
> > 
> > But that got me going. I've updated the firmware on this device to TS26,
> > and now, it behaves better: it performs ok and the desktop is still
> > usable. Cool.
> Does the new firmware still require the usb-storage quirk?

No, that's working fine without.

> > May I introduce another faulty device: Fantec AluPro U3 external 2,5" case
> > (Asmedia AS2105 controller) with a HGST HTS721010 7K1000 harddisk. I
> > wasn't
> > able to locate any firmware for this device.
> > 
> > Issue here is, the drive is continusly connecting and disconnecting:
> > 
> > 2015-09-13T11:55:30.641698+02:00 xrated kernel: [171947.841309] usb 7-1:
> > USB disconnect, device number 91 2015-09-13T11:55:30.853671+02:00 xrated
> > kernel: [171948.053246] usb 7-1: new SuperSpeed USB device number 92
> > using xhci_hcd 2015-09-13T11:55:30.864676+02:00 xrated kernel:
> > [171948.065133] usb 7-1: New USB device found, idVendor=174c,
> > idProduct=5106 2015-09-13T11:55:30.864681+02:00 xrated kernel:
> > [171948.065134] usb 7-1: New USB device strings: Mfr=2, Product=3,
> > SerialNumber=1 2015-09-13T11:55:30.864682+02:00 xrated kernel:
> > [171948.065136] usb 7-1: Product: AS2105 2015-09-13T11:55:30.864682+02:00
> > xrated kernel: [171948.065136] usb 7-1: Manufacturer: ASMedia
> > 2015-09-13T11:55:30.864683+02:00 xrated kernel: [171948.065137] usb 7-1:
> > SerialNumber:   JR10046P2HAJ8N 2015-09-13T11:55:30.865663+02:00
> > xrated kernel: [171948.065961] usb-storage 7-1:1.0: USB Mass Storage
> > device detected 2015-09-13T11:55:30.865666+02:00 xrated kernel:
> > [171948.066046] scsi host196: usb-storage 7-1:1.0
> > 2015-09-13T11:55:30.867001+02:00 xrated mtp-probe: checking bus 7, device
> > 92: "/sys/devices/pci:00/:00:14.0/usb7/7-1"
> > 2015-09-13T11:55:30.867182+02:00 xrated mtp-probe: bus: 7, device: 92 was
> > not an MTP device 2015-09-13T11:55:32.111692+02:00 xrated kernel:
> > [171949.310429] usb 7-1: USB disconnect, device number 92
> > 2015-09-13T11:55:32.323698+02:00 xrated kernel: [171949.522367] usb 7-1:
> > new SuperSpeed USB device number 93 using xhci_hcd
> ...
> 
> > usbmon log attached.
> 
> It wasn't attached.

Hrmpf. Hopefully now...

Thanks,
Pete

fantec.mon.out.xz
Description: application/xz

Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M

2015-09-13 Thread Roland Weber

Hi all,

I wrote:
> I cannot yet tell whether the difference between freeze and non-freeze
> is due to code changes, or because I used a different kernel config.
> (It brings down compilation times from 3h to 2h.)
> 
> So next I'll compile 3.17.8 with my config.

Actually, it made more sense to try other precompiled kernels.
I can freeze the precompiled 3.17.0 with unbind/bind/unbind,
but not the one I compiled myself. I'm currently compiling
3.17.0 with the exact config of the precompiled kernel, to
rule out differences in the build environment as the cause.

Assuming that this kernel does freeze, I will start to 'bisect' the
differences in the kernel configurations, based on the assumption
that it might give us a clue about where the problem comes from.
I expect this to take several days... please stop me if you've got
a better lead.

cheers,
  Roland
--
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: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M

2015-09-13 Thread Alan Stern

On Sun, 13 Sep 2015, Roland Weber wrote:

> I compiled a kernel 3.17(.0) with my additional debug lines...
> and this one does NOT freeze! The output is:
> 
> (first unbind)
> ehci-pci :00:1d.0: remove, state 4
> ehci-pci :00:1d.0: roothub graceful disconnect
> usb usb1: USB disconnect, device number 1
> ehci-pci :00:1d.0: shutdown urb 880072bf4300 ep1in-intr
> usb_remove_hcd: calling stop
> ehci-pci :00:1d.0: stop
> ehci_silence_controller: entry
> ehci_halt: entry
> ehci_halt: after spin_lock_irq
> ehci_halt: about to readl prematurely
> ehci_halt: premature readl returned 10001

Note: 10001 instead of 1, which is what you saw in the other 
kernel.  That could be highly relevant.

> I cannot yet tell whether the difference between freeze and non-freeze
> is due to code changes, or because I used a different kernel config.
> (It brings down compilation times from 3h to 2h.)
> 
> So next I'll compile 3.17.8 with my config.

On Sun, 13 Sep 2015, Roland Weber wrote:

> Actually, it made more sense to try other precompiled kernels.
> I can freeze the precompiled 3.17.0 with unbind/bind/unbind,
> but not the one I compiled myself. I'm currently compiling
> 3.17.0 with the exact config of the precompiled kernel, to
> rule out differences in the build environment as the cause.
> 
> Assuming that this kernel does freeze, I will start to 'bisect' the
> differences in the kernel configurations, based on the assumption
> that it might give us a clue about where the problem comes from.
> I expect this to take several days... please stop me if you've got
> a better lead.

At some point along the way, can you try adding some printk statements 
to ehci_suspend() and ehci_resume() in ehci-hcd.c?  I'd like to know if 
they get called during the bind/unbind procedure and are responsible 
for that 10001 vs. 1 value.

Alan Stern

--
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

Fwd: Announce libusb-1.0.20

2015-09-13 Thread Chris Dickens

Resending to linux-usb without HTML.

Hi All,

I'm pleased to announce the libusb-1.0.20 final release.

It has been over a year since the last release, and a lot of changes
have gone in during that time (95 commits).

Changelog:
* Add Haiku support
* Fix multiple memory and resource leaks (#16, #52, #76, #81)
* Fix possible deadlock when executing transfer callback
* New libusb_free_pollfds() API
* Darwin: Fix devices not being detected on OS X 10.8 (#48)
* Linux: Allow larger isochronous transfer submission (#23)
* Windows: Fix broken builds Cygwin/MinGW builds and compiler warnings
* Windows: Fix broken bus number lookup
* Windows: Improve submission of control requests for composite devices
* Examples: Add two-stage load support to fxload (#12)
* Correctly report cancellations due to timeouts
* Improve efficiency of event handling
* Improve speed of transfer submission in multi-threaded environments
* Various other bug fixes and improvements
The (#xx) numbers are libusb issue numbers, see ie:
https://github.com/libusb/libusb/issues/16

You can download the source code here:

https://github.com/libusb/libusb/releases/download/v1.0.20/libusb-1.0.20.tar.bz2
http://downloads.sourceforge.net/libusb/libusb-1.0.20.tar.bz2

The Windows binary tarball is available here:

https://github.com/libusb/libusb/releases/download/v1.0.20/libusb-1.0.20.7z
http://downloads.sourceforge.net/libusb/libusb-1.0.20.7z

Regards,
Chris
--
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: [PATCH] Revert "usb: chipidea: usbmisc_imx: delete clock information"

2015-09-13 Thread Peter Chen

On Fri, Sep 11, 2015 at 10:17:20AM -0300, Fabio Estevam wrote:
> On Fri, Sep 11, 2015 at 4:52 AM, Peter Chen  wrote:
> 
> > Hi Fabio,
> >
> > Would you please help to test build patches for this issue?
> 
> Tested the patch on a mx27pdk running 4.2 and I got the same crash:
> 
> usbcore: registered new interface driver usb-storage
> Unhandled fault: external abort on non-linefetch (0x008) at 0xf4424600
> pgd = c0004000
> [f4424600] *pgd=1452(bad)
> Internal error: : 8 [#1] PREEMPT ARM
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper Not tainted 4.2.0-dirty #93
> Hardware name: Freescale i.MX27 (Device Tree Support)
> task: c7832b60 ti: c783e000 task.ti: c783e000
> PC is at usbmisc_imx27_init+0x4c/0xbc
> LR is at usbmisc_imx27_init+0x40/0xbc
> pc : []lr : []psr: 6093
> sp : c783fe10  ip :   fp : 
> r10:   r9 : 009c  r8 : c056d488
> r7 : 0100  r6 : 6013  r5 : c7a785d0  r4 : c7a782f0
> r3 : f4424600  r2 :   r1 : 0001  r0 : 0001
> Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
> Control: 0005317f  Table: a0004000  DAC: 0017
> Process swapper (pid: 1, stack limit = 0xc783e190)
> Stack: (0xc783fe10 to 0xc784)
> fe00: c03c4a50 c7946410 c7946400 
> fe20: c79b8290 c03c46c4  c03c5254 c7a77538 c79553c0 0100 
> fe40:  c7989c30  0008    
> fe60: ffed c7946410 fdfb c0792418  c02fdb94 c02fdb4c c7946410
> fe80: c07c19d0  c0792418 c02fc1f0 c7946410 c0792418 c7946444 
> fea0: c072c0c8 c02fc324  c0792418 c02fc298 c02fa978 c7895d2c c78d8f10
> fec0: c0792418 c7a5fb20 c077e268 c02fb948 c067f7f4 c0284118 c0792418 c0792418
> fee0: c07502b8 c7a78620 c07ab460 c02fcdc0  c07502b8 c07502b8 c00095c8
> ff00: c07b372c c78bc980 c053c958 004f    c013b43c
> ff20: c7ffc890 c0552e20 009c c0032448  c067ff7c c06d5d94 0006
> ff40: c7ffc897 0006 c07552f8 c7ffc840 c074b090 0006 c073f8dc c07ab460
> ff60: c0704594 009c c073f8e8 c0704d20 0006 0006  c0704594
> ff80: c78327a0 c052f55c  c052f55c    
> ffa0:  c052f564  c000a320    
> ffc0:        
> ffe0:     0013  bfff efff
> [] (usbmisc_imx27_init) from [] 
> (imx_usbmisc_init+0x2c/0x38)
> [] (imx_usbmisc_init) from []
> (ci_hdrc_imx_probe+0x208/0x35c)
> [] (ci_hdrc_imx_probe) from []
> (platform_drv_probe+0x48/0xa4)
> [] (platform_drv_probe) from []
> (driver_probe_device+0x1d0/0x278)
> [] (driver_probe_device) from [] 
> (__driver_attach+0x8c/0x90)
> [] (__driver_attach) from [] (bus_for_each_dev+0x5c/0x8c)
> [] (bus_for_each_dev) from [] (bus_add_driver+0xe8/0x1f8)
> [] (bus_add_driver) from [] (driver_register+0x78/0xf4)
> [] (driver_register) from [] (do_one_initcall+0x84/0x1f0)
> [] (do_one_initcall) from []
> (kernel_init_freeable+0xfc/0x1c0)
> [] (kernel_init_freeable) from [] (kernel_init+0x8/0xec)
> [] (kernel_init) from [] (ret_from_fork+0x14/0x34)
> Code: ebf1cfb7 e5d43008 e3130001 e5953000 (e5932000)
> ---[ end trace 69bc01e63a4b5221 ]---
> note: swapper[1] exited with preempt_count 1
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b
> 
> ---[ end Kernel panic - not syncing: Attempted to kill init! 
> exitcode=0x000b
> 
> If I revert 73dea4a912b2("usb: chipidea: usbmisc_imx: delete clock
> information") then the board boots fine.
> 
> Regards,
> 
> Fabio Estevam

Sorry, a bug at former patch, it the clk_ahb has been override. 
Mind to try below one?

>From ef644a2cfb8050c004ec2b54239fe5982ef0dcda Mon Sep 17 00:00:00 2001
From: Peter Chen 
Date: Fri, 11 Sep 2015 15:50:22 +0800
Subject: [PATCH 1/1] usb: chipidea: add three clks for imx

Signed-off-by: Peter Chen 
---
 arch/arm/boot/dts/imx27.dtsi   |  19 +++--
 drivers/usb/chipidea/ci_hdrc_imx.c | 140 -
 drivers/usb/chipidea/udc.c |   1 +
 3 files changed, 138 insertions(+), 22 deletions(-)

diff --git a/arch/arm/boot/dts/imx27.dtsi b/arch/arm/boot/dts/imx27.dtsi
index b69be5c..d0dcf4a 100644
--- a/arch/arm/boot/dts/imx27.dtsi
+++ b/arch/arm/boot/dts/imx27.dtsi
@@ -477,7 +477,11 @@
compatible = "fsl,imx27-usb";
reg = <0x10024000 0x200>;
interrupts = <56>;
-   clocks = <&clks IMX27_CLK_USB_IPG_GATE>;
+   need-three-clocks;
+   clocks = <&clks IMX27_CLK_USB_IPG_GATE>,
+   <&clks IMX27_CLK_USB_AHB_GATE>,
+   <&clks IMX27_CLK_USB_DIV>;
+   clock-names = "ipg", "ahb",

Re: USB client crash on Vybrid with USB gadget RNDIS connection

2015-09-13 Thread Peter Chen

On Fri, Sep 11, 2015 at 04:51:22PM +0530, maitysancha...@gmail.com wrote:
> On 15-09-11 15:56:17, maitysancha...@gmail.com wrote:
> > Hello Peter,
> > 
> > On 15-09-11 16:58:52, Peter Chen wrote:
> > > On Fri, Sep 11, 2015 at 02:36:58PM +0530, maitysancha...@gmail.com wrote:
> > > > Hello,
> > > > 
> > > > We are using the 4.1.5 kernel on Freescale Vybrid SoC which has a 
> > > > Chipidea
> > > > IP. One of our customer's reported a kernel crash while using USB client
> > > > with the USB gadget RNDIS functionality while being connected to a host
> > > > running Windows 7 SP1 Pro and I was also able to reproduce the issue 
> > > > here.
> > > > 
> > > > The issue seems reproducible and occurs while doing bidirectional 
> > > > communication
> > > > over socket after an hour or so. Strangely it did not happen while 
> > > > doing one
> > > > way transfers from the Vybrid to PC side which I tested by running for 
> > > > almost
> > > > 16 hours. For testing birectional communication I had a simple Python 
> > > > echo server
> > > > running on PC and client on Vybrid side while for one way test I had 
> > > > Python
> > > > client on Vybrid and Hercules application on Windows side.
> > > > 
> > > > Both the Python client and server do a continous send/recv in a while 
> > > > loop.
> > > > 
> > > > I could not reproduce it while doing bidirectional iperf tests for 5-6 
> > > > hours
> > > > with a Linux machine.
> > > > 
> > > > The same issue is also seen with 4.0.5. Is this a known issue or 
> > > > reported
> > > > earlier?
> > > > 
> > > > The stack trace is below on 4.1.5 kernel.
> > > > 
> > > > [69253.557550] Unable to handle kernel NULL pointer dereference at 
> > > > virtual address 
> > > > [69253.565681] pgd = 80004000
> > > > [69253.568396] [] *pgd=
> > > > [69253.572004] Internal error: Oops: 817 [#1] ARM
> > > > [69253.576457] Modules linked in: mcp251x can_dev
> > > > [69253.580963] CPU: 0 PID: 0 Comm: swapper Not tainted 
> > > > 4.1.4-v2.5b1+gdc92514 #1
> > > > [69253.588016] Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree)
> > > > [69253.594469] task: 807d04b0 ti: 807ca000 task.ti: 807ca000
> > > > [69253.599896] PC is at add_td_to_list+0x118/0x1a0
> > > > [69253.604441] LR is at add_td_to_list+0x58/0x1a0
> > > > [69253.608895] pc : [<803b9fd4>]lr : [<803b9f14>]psr: 30010193
> > > > [69253.608895] sp : 807cbcf0  ip : 0006  fp : 807cbd14
> > > > [69253.620379] r10: 0008  r9 : 4000  r8 : 8da82db4
> > > > [69253.625614] r7 : 8e02f6e8  r6 : 0008  r5 : 8da82d80  r4 : 
> > > > 8da321c0
> > > > [69253.632148] r3 :   r2 : 8e403580  r1 : 8da82dbc  r0 : 
> > > > 
> > > > [69253.638687] Flags: nzCV  IRQs off  FIQs on  Mode SVC_32  ISA ARM  
> > > > Segment kernel
> > > > [69253.646087] Control: 10c5387d  Table: 8cb50059  DAC: 0015
> > > > [69253.651839] Process swapper (pid: 0, stack limit = 0x807ca208)
> > > > [69253.657681] Stack: (0x807cbcf0 to 0x807cc000)
> > > > [69253.662053] bce0: 8da82d80 
> > > > 8e02f6e8 0008 8e02f010
> > > > [69253.670248] bd00: 8da82db4 4000 807cbd54 807cbd18 803ba9dc 
> > > > 803b9ec8  
> > > > [69253.678439] bd20:    a0010193 8d94d5f4 
> > > > 8e23f3d4  0024
> > > > [69253.686633] bd40: 8e02f408 8db1773c 807cbd6c 807cbd58 803bad8c 
> > > > 803ba8a4 8d94d540 8d94d5f4
> > > > [69253.694825] bd60: 807cbd84 807cbd70 803ca360 803bad68 8081f3f8 
> > > > 8d8ce000 807cbda4 807cbd88
> > > > [69253.703017] bd80: 803cbd78 803ca310 8db17700 8db1773c 0024 
> > > > 8db17700 807cbdbc 807cbda8
> > > > [69253.711209] bda0: 803ca624 803cbaec 0024 8db1773c 807cbdcc 
> > > > 807cbdc0 803c30e4 803ca610
> > > > [69253.719402] bdc0: 807cbe3c 807cbdd0 803bb264 803c30dc 807cbdec 
> > > > 80815d74 803ba500 8e02f408
> > > > [69253.727594] bde0: 807cc044 0001 8e02f440 8e02f630 8e02f010 
> > > > 8e02f010  8db17734
> > > > [69253.735787] be00: 8e02f40c 8e02f460 0021 0024 807cbe5c 
> > > > 8e02f010 807dd644 
> > > > [69253.743979] be20:  0027 8e0b8480 807fdc3d 807cbe54 
> > > > 807cbe40 803b81ac 803bada8
> > > > [69253.752172] be40: 8e2c2580 807dd644 807cbe8c 807cbe58 8004ced0 
> > > > 803b8160 800644b8 80040464
> > > > [69253.760363] be60: 3efc 8e0b8480 807dd644  0001 
> > > > 8e006000 0001 807f2430
> > > > [69253.768556] be80: 807cbea4 807cbe90 8004cfc8 8004ce5c 8e0b8480 
> > > > 807dd644 807cbebc 807cbea8
> > > > [69253.776748] bea0: 8004f538 8004cfa4 0027  807cbed4 
> > > > 807cbec0 8004c638 8004f4a0
> > > > [69253.784941] bec0: 807dd47c  807cbefc 807cbed8 8004c89c 
> > > > 8004c610 9000210c 807cc364
> > > > [69253.793133] bee0: 807cbf20 90002100 807cc0cc 0001 807cbf1c 
> > > > 807cbf00 8000935c 8004c84c
> > > > [69253.801325] bf00: 8000ff2c 60010013  807cbf54 807cbf74 
> > > > 807cbf20 80013700 8000933c
> > > > [69253.809517] bf

Re: Chipidea ULPI driver

2015-09-13 Thread Peter Chen

On Fri, Sep 11, 2015 at 11:34:10AM +, Subbaraya Sundeep Bhatta wrote:
> Hi,
> 
> > -Original Message-
> > From: Peter Chen [mailto:peter.c...@freescale.com]
> > Sent: Friday, September 11, 2015 6:52 AM
> > To: Punnaiah Choudary Kalluri
> > Cc: ba...@ti.com; Subbaraya Sundeep Bhatta; linux-usb@vger.kernel.org; 
> > linux-
> > ker...@vger.kernel.org; Greg Kroah-Hartman (gre...@linuxfoundation.org);
> > kis...@ti.com
> > Subject: Re: Chipidea ULPI driver
> > 
> > On Thu, Sep 10, 2015 at 02:57:49PM +, Punnaiah Choudary Kalluri wrote:
> > >
> > >
> > > > -Original Message-
> > > > From: Felipe Balbi [mailto:ba...@ti.com]
> > > > Sent: Thursday, September 10, 2015 8:14 PM
> > > > To: Subbaraya Sundeep Bhatta
> > > > Cc: Peter Chen; ba...@ti.com; linux-usb@vger.kernel.org; linux-
> > > > ker...@vger.kernel.org; Greg Kroah-Hartman
> > > > (gre...@linuxfoundation.org); kis...@ti.com; Punnaiah Choudary
> > > > Kalluri
> > > > Subject: Re: Chipidea ULPI driver
> > > >
> > > > (break your lines at 80-characters)
> > > >
> > > > On Thu, Sep 10, 2015 at 12:44:58PM +, Subbaraya Sundeep Bhatta
> > wrote:
> > > > > Hi Peter,
> > > > >
> > > > > We are using NOP transceiver driver for USB3320 ULPI PHY with
> > > > > ChipIdea controller.
> > > > >
> > > > > Recently we found that one of the boards (zedboard) requires PHY
> > > > > register access to set VBUS.
> > > > >
> > > > > Note that our local driver we had before migrating to ChipIdea
> > > > > driver calls otg_ulpi_create with flags  ULPI_OTG_DRVVBUS |
> > > > > ULPI_OTG_DRVVBUS_EXT so that VBUS is enabled at initialization.
> > > > >
> > > > > Can you please let me know how to do this with ChipIdea case? I
> > > > > see the following solutions:
> > > > >
> > > > > 1. Write ULPI driver for USB3320 similar to tusb1210.
> > > >
> > > > this
> > >
> > > How about extending the phy-ulpi driver to use it as platform driver?
> > > So that boards that are using the ulpi compatible phy and driving vbus
> > > from the phy can use this driver.
> > >
> > 
> > Yes, you can improve phy-ulpi driver, and it can not depend on NOP 
> > transceiver
> > driver.
> 
> AFAIK phy-ulpi.c is just exporting functions and not registering to platform
> bus since it is not connected to SOC bus. I don't think we can create platform
> driver for this. I have read TUSB1210 data sheet and it is similar to USB3320
> with no additional SOC bus connection and has only ULPI interface. 
> So it should register to ULPI bus which is in kernel recently. I will make
> changes to chipidea similar to dwc3(adding ulpi.c) and write driver similar
> to tusb1210.c. Is that okay?
> 

It should be ok.

-- 

Best Regards,
Peter Chen
--
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 client crash on Vybrid with USB gadget RNDIS connection

2015-09-13 Thread maitysanchayan

On 15-09-14 13:11:16, Peter Chen wrote:
> On Fri, Sep 11, 2015 at 04:51:22PM +0530, maitysancha...@gmail.com wrote:
> > On 15-09-11 15:56:17, maitysancha...@gmail.com wrote:
> > > Hello Peter,
> > > 
> > > On 15-09-11 16:58:52, Peter Chen wrote:
> > > > On Fri, Sep 11, 2015 at 02:36:58PM +0530, maitysancha...@gmail.com 
> > > > wrote:
> > > > > Hello,
> > > > > 
> > > > > We are using the 4.1.5 kernel on Freescale Vybrid SoC which has a 
> > > > > Chipidea
> > > > > IP. One of our customer's reported a kernel crash while using USB 
> > > > > client
> > > > > with the USB gadget RNDIS functionality while being connected to a 
> > > > > host
> > > > > running Windows 7 SP1 Pro and I was also able to reproduce the issue 
> > > > > here.
> > > > > 
> > > > > The issue seems reproducible and occurs while doing bidirectional 
> > > > > communication
> > > > > over socket after an hour or so. Strangely it did not happen while 
> > > > > doing one
> > > > > way transfers from the Vybrid to PC side which I tested by running 
> > > > > for almost
> > > > > 16 hours. For testing birectional communication I had a simple Python 
> > > > > echo server
> > > > > running on PC and client on Vybrid side while for one way test I had 
> > > > > Python
> > > > > client on Vybrid and Hercules application on Windows side.
> > > > > 
> > > > > Both the Python client and server do a continous send/recv in a while 
> > > > > loop.
> > > > > 
> > > > > I could not reproduce it while doing bidirectional iperf tests for 
> > > > > 5-6 hours
> > > > > with a Linux machine.
> > > > > 
> > > > > The same issue is also seen with 4.0.5. Is this a known issue or 
> > > > > reported
> > > > > earlier?
> > > > > 
> > > > > The stack trace is below on 4.1.5 kernel.
> > > > > 
> > > > > [69253.557550] Unable to handle kernel NULL pointer dereference at 
> > > > > virtual address 
> > > > > [69253.565681] pgd = 80004000
> > > > > [69253.568396] [] *pgd=
> > > > > [69253.572004] Internal error: Oops: 817 [#1] ARM
> > > > > [69253.576457] Modules linked in: mcp251x can_dev
> > > > > [69253.580963] CPU: 0 PID: 0 Comm: swapper Not tainted 
> > > > > 4.1.4-v2.5b1+gdc92514 #1
> > > > > [69253.588016] Hardware name: Freescale Vybrid VF5xx/VF6xx (Device 
> > > > > Tree)
> > > > > [69253.594469] task: 807d04b0 ti: 807ca000 task.ti: 807ca000
> > > > > [69253.599896] PC is at add_td_to_list+0x118/0x1a0
> > > > > [69253.604441] LR is at add_td_to_list+0x58/0x1a0
> > > > > [69253.608895] pc : [<803b9fd4>]lr : [<803b9f14>]psr: 30010193
> > > > > [69253.608895] sp : 807cbcf0  ip : 0006  fp : 807cbd14
> > > > > [69253.620379] r10: 0008  r9 : 4000  r8 : 8da82db4
> > > > > [69253.625614] r7 : 8e02f6e8  r6 : 0008  r5 : 8da82d80  r4 : 
> > > > > 8da321c0
> > > > > [69253.632148] r3 :   r2 : 8e403580  r1 : 8da82dbc  r0 : 
> > > > > 
> > > > > [69253.638687] Flags: nzCV  IRQs off  FIQs on  Mode SVC_32  ISA ARM  
> > > > > Segment kernel
> > > > > [69253.646087] Control: 10c5387d  Table: 8cb50059  DAC: 0015
> > > > > [69253.651839] Process swapper (pid: 0, stack limit = 0x807ca208)
> > > > > [69253.657681] Stack: (0x807cbcf0 to 0x807cc000)
> > > > > [69253.662053] bce0: 8da82d80 
> > > > > 8e02f6e8 0008 8e02f010
> > > > > [69253.670248] bd00: 8da82db4 4000 807cbd54 807cbd18 803ba9dc 
> > > > > 803b9ec8  
> > > > > [69253.678439] bd20:    a0010193 8d94d5f4 
> > > > > 8e23f3d4  0024
> > > > > [69253.686633] bd40: 8e02f408 8db1773c 807cbd6c 807cbd58 803bad8c 
> > > > > 803ba8a4 8d94d540 8d94d5f4
> > > > > [69253.694825] bd60: 807cbd84 807cbd70 803ca360 803bad68 8081f3f8 
> > > > > 8d8ce000 807cbda4 807cbd88
> > > > > [69253.703017] bd80: 803cbd78 803ca310 8db17700 8db1773c 0024 
> > > > > 8db17700 807cbdbc 807cbda8
> > > > > [69253.711209] bda0: 803ca624 803cbaec 0024 8db1773c 807cbdcc 
> > > > > 807cbdc0 803c30e4 803ca610
> > > > > [69253.719402] bdc0: 807cbe3c 807cbdd0 803bb264 803c30dc 807cbdec 
> > > > > 80815d74 803ba500 8e02f408
> > > > > [69253.727594] bde0: 807cc044 0001 8e02f440 8e02f630 8e02f010 
> > > > > 8e02f010  8db17734
> > > > > [69253.735787] be00: 8e02f40c 8e02f460 0021 0024 807cbe5c 
> > > > > 8e02f010 807dd644 
> > > > > [69253.743979] be20:  0027 8e0b8480 807fdc3d 807cbe54 
> > > > > 807cbe40 803b81ac 803bada8
> > > > > [69253.752172] be40: 8e2c2580 807dd644 807cbe8c 807cbe58 8004ced0 
> > > > > 803b8160 800644b8 80040464
> > > > > [69253.760363] be60: 3efc 8e0b8480 807dd644  0001 
> > > > > 8e006000 0001 807f2430
> > > > > [69253.768556] be80: 807cbea4 807cbe90 8004cfc8 8004ce5c 8e0b8480 
> > > > > 807dd644 807cbebc 807cbea8
> > > > > [69253.776748] bea0: 8004f538 8004cfa4 0027  807cbed4 
> > > > > 807cbec0 8004c638 8004f4a0
> > > > > [69253.784941] bec0: 807dd47c  807cbefc 807cbed8 8004c89c 
> > > >

Re: MIDI gadget allocating too much from coherent pool

2015-09-13 Thread Clemens Ladisch

Felipe Tonello wrote:
> DSP (read sensors and read/send MIDI) <- UART -> SOC (imx6) <- USB
> MIDI GADGET -> HOST
>
> When the throughput from the DSP is high, thus causing the throughput
> on the USB to be high as well, I get a Kernel Panic saying to increase
> the coherent_pool. I've used some crazy sizes like 1M, 4M and even 8M.
> Obviously when I increase, it takes longer to crash but it still
> crashes.

This sounds like a memory leak in your USB host controller's driver
(whatever it is).

The USB MIDI driver uses URB_NO_TRANSFER_DMA_MAP with bulk transfers,
and continually resubmits the same URBs.  Both might be somewhat
unusual.


Regards,
Clemens
--
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: xhci woes continued

[PATCH 39/39] usb: host: drop null test before destroy functions

[PATCH 18/39] whci: drop null test before destroy functions

[PATCH 16/39] usb: gadget: drop null test before destroy functions

[PATCH 00/39] drop null test before destroy functions

[PATCH 05/39] xhci: drop null test before destroy functions

Re: xhci woes continued

Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M

Re: xhci woes continued

Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M

Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M

Fwd: Announce libusb-1.0.20

Re: [PATCH] Revert "usb: chipidea: usbmisc_imx: delete clock information"

Re: USB client crash on Vybrid with USB gadget RNDIS connection

Re: Chipidea ULPI driver

Re: USB client crash on Vybrid with USB gadget RNDIS connection

Re: MIDI gadget allocating too much from coherent pool

17 matches

Site Navigation

Mail list logo

Footer information