On Wed, Jan 29, 2014 at 04:16:49PM -0800, walt wrote: > Hi Sarah and David. I'm back with more ASMedia problems caused by this: > > commit ec513b16c480c6cdda1e3d597e611eafca05227b > Merge: bcee634 2fc5a7d > Author: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> > Date: Mon Jan 20 16:13:02 2014 -0800 > Merge tag 'usb-3.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb > > Pull USB updates from Greg KH: > "Here's the big USB pull request for 3.14-rc1 > > Lots of little things all over the place, and the usual USB gadget > updates, and XHCI fixes (some for an issue reported by a lot of > people). USB PHY updates as well as chipidea updates and fixes. > > I've run the latest from linus.git on a different usb3 adapter (the NEC you > know about from another thread) and it works just fine, so this appears to > be yet another ASMedia quirk, but the symptoms are different this time. > > When booting this kernel (version mentioned above) the ASMedia adapter is > recognized by the kernel, but the external disk in my USB3 disk docking > station is not discovered or recognized in any way. > > I'm attaching selected parts of the dmesg for your puzzlement. If you need > more info please let me know. > > The striking thing about the dmesg is the absence of xhci debugging output. > This kernel has usb verbose bugging enabled, but xhci has almost nothing to > say. That seems very suspicious to me. That's because 3.13 and 3.14 have dynamic debugging turned off automatically for the xHCI driver. Try running this command as root: echo -n 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control And double check if you have CONFIG_USB_DEBUG enabled. > -- > I'm ready to douse the ASMedia card with gasoline and set it ablaze :) but > if you for some strange reason want to debug this problem I'm available. Try reverting commit 7dd09a1af2c7150269350aaa567a11b06e831003 "xhci: replace xhci_write_64() with writeq()" That caused problems with another xHCI host controller that can only handle 32-bit DMA addresses. If that doesn't work, can you use `git bisect` to find the bad commit? E.g. if 3.13 worked, but that commit doesn't, do: git bisect start git bisect good v3.13 git bisect bad ec513b16c480c6cdda1e3d597e611eafca05227b You'll be compiling and testing kernels for quite some time, probably. Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
