On Jul 31, 2016 10:40 AM, "ac via talk" <talk@gtalug.org> wrote:

On Sun, 31 Jul 2016 16:30:37 +0200 ac via talk <talk@gtalug.org> wrote:

...

On Sun, 31 Jul 2016 10:01:01 -0400 (EDT) "D. Hugh Redelmeier via talk" <talk@gtalug.org> wrote:

...

BTW, this link is to discussion of a problem that I'm having. My Fujitsu Scansnap ix500 won't work when plugged into a USB 3 port on Linux. Very odd. This report is two years old and the problem persists. ---

eeek, soz, I only just saw this..

please post any output from dmesg (directly after plugging usb)?

whahaha, triple eeek... (- Sundays... go figure) just reading the way back when link and your logs (http://spark.crystalorb.net/mikem/dmesg.log)

I see this. [ 426.246318] xhci_hcd 0000:00:14.0: Can't reset device (slot ID 4) in default state [ 426.246322] xhci_hcd 0000:00:14.0: Not freeing device rings Not sure if this helps? Does the device work on USB 2. Apparently there are some issues with xhci memory leaks. http://linux-usb.vger.kernel.narkive.com/SiQeYEDB/patch-1-2-xhci-fix-memory-... Here's a snippet from that thread. Unfortunately, the original code in xhci_free_or_cache_endpoint_ring() would put the first entry into the ring cache in array index 1, instead of array index 0. This was caused by the second assignment to rings_cached: rings_cached = virt_dev >num_rings_cached; if (rings_cached < XHCI_MAX_RINGS_CACHED) { virt_dev->num_rings_cached++; rings_cached = virt_dev->num_rings_cached; virt_dev->ring_cache[rings_cached] = virt_dev->eps[ep_index].ring; This meant that when the device was freed, cached rings with indexes 0 to N would be freed, and the last cached ring in index N+1 would not be freed. When the driver was unloaded, this caused interesting messages like: xhci_hcd 0000:06:00.0: dma_pool_destroy xHCI ring segments, ffff880063040000 busy

I do not yet have anything easy/constructive to add and I promise to only reply if I do :)

Andre --- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk

Russell Sent from mobile.