OK, after some more digging here are my final findings:
1). Actual chip model is JMS551, not JMS539 as stated by lsusb.
2). Firmware named "JMS551_V255.0.6.0.7_Full Function Agestar.bin"
from this page does solve all device detection problems (I mean
both USB3 and eSATA) on all OSes I've tested:
http://www.usbdev.ru/files/jmicron/
I've done the upgrade only on AGESTAR 3CBT2 docking station, but
most likely it will work with AGESTAR 3CBT4 too.
On Thu, 6 Nov 2014 02:47:57 +0300
parafin <parafin@xxxxxxxx> wrote:
> Well, not everything as good as it seemed - upgrading JMS539 firmware
> completely disabled eSATA port on docking station :( So that's another
> reason to solve this issue inside Linux kernel.
>
> On Thu, 6 Nov 2014 01:26:07 +0300
> parafin <parafin@xxxxxxxx> wrote:
>
> > Update to this issue:
> > OS X has problems recognizing these devices as well - 10.9 managed to
> > enumerate it after several attempts, but after upgrade to the latest
> > release (10.10 Yosemite) OS X only sees these USB devices if they were
> > connected before booting up (so same as Linux). Windows, of course, has
> > no such problems (tested with Win 7 Pro).
> > While googling about possible solutions for OS X, I found out that it
> > is possible to upgrade firmware of JMS539 chipset inside these docking
> > stations (of course the utility is Windows-only):
> > http://www.station-drivers.com/index.php/downloads/Drivers/Jmicron/JMS539-Sata-USB-3.0-Controller/
> > Firmware version all previous tests were done with is 255.00.06.00.14,
> > I've updated it to the latest 255.31.3.41.22 and it solved enumeration
> > problem on both Linux and OS X!
> > I left old firmware on one of the devices so I still can test some
> > patches. I'm not sure though if it is worth fixing now, in the light of
> > what I wrote above, I would still say yes, because: first of all it
> > won't be obvious that firmware upgrade is required (or that it's at
> > all possible) for anyone else encountering this issue; secondly Windows
> > is required to run firmware upgrade and not everyone has readily access
> > to it; thirdly there might be other chipsets out there with same quirks
> > and no available fixes; and finally it worked before, so it is a
> > regression even though most likely it is the device who's doing the
> > wrong thing.
> >
> > On Wed, 5 Nov 2014 12:50:36 -0800
> > Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx> wrote:
> >
> > > I'm no longer the USB 3.0 driver maintainer. Please work with Mathias
> > > Nyman to fix this issue.
> > >
> > > Sarah Sharp
> > >
> > > On Fri, Oct 31, 2014 at 06:01:24PM +0300, parafin wrote:
> > > > Hi,
> > > >
> > > > it was suggested to me that since you are the author of offending
> > > > commit I should forward this email to you. Also see this bug:
> > > > https://bugzilla.kernel.org/show_bug.cgi?id=41752
> > > >
> > > > Begin forwarded message:
> > > >
> > > > Date: Thu, 30 Oct 2014 22:56:29 +0300
> > > > From: parafin <parafin@xxxxxxxx>
> > > > To: <linux-usb@xxxxxxxxxxxxxxx>
> > > > Subject: USB3: unable to enumerate, device not accepting address
> > > >
> > > >
> > > > Hi,
> > > >
> > > > I have 2 very similar USB3 devices that stopped working sometime after
> > > > kernel version 3.3 - they fail to enumerate unless I reload xhci_hcd
> > > > driver.
> > > >
> > > > These are the devices:
> > > > http://www.agestar.com/en/Products/Docking-Station/USB3-0/974-usb30esata-to-2535-sata-hdd-docking-station.html
> > > > http://www.agestar.com/en/Products/Docking-Station/USB3-0/980-usb30esata-to-2535-sata-hdd-docking-station.html
> > > > Basically it's some eSATA->USB3 bridge JMicron chip (I'm guessing it's
> > > > the same one in both devices):
> > > > Bus 009 Device 002: ID 152d:2509 JMicron Technology Corp. / JMicron USA Technology Corp. JMS539 SuperSpeed SATA II 3.0G Bridge
> > > >
> > > > This is USB controller I am testing them with:
> > > > 01:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 03)
> > > > I even tried upgrading firmware, with no result
> > > >
> > > > It appears in system as 2 buses (lsusb -t output):
> > > > /: Bus 09.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
> > > > /: Bus 08.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
> > > > One for SuperSpeed devices, another for slower.
> > > >
> > > > So here's dmesg for when it fails:
> > > > [ 195.207408] hub 8-0:1.0: unable to enumerate USB device on port 1
> > > > [ 196.016556] usb 9-1: device not accepting address 2, error -22
> > > > [ 196.520572] hub 9-0:1.0: unable to enumerate USB device on port 1
> > > >
> > > > And here how it should look (when it works):
> > > > [ 61.686218] hub 8-0:1.0: unable to enumerate USB device on port 1
> > > > [ 63.620211] usb 9-1: new SuperSpeed USB device number 2 using xhci_hcd
> > > > [ 63.636918] usb 9-1: New USB device found, idVendor=152d, idProduct=2509
> > > > [ 63.636932] usb 9-1: New USB device strings: Mfr=1, Product=11, SerialNumber=3
> > > > [ 63.636942] usb 9-1: Product: Usb production
> > > > [ 63.636950] usb 9-1: Manufacturer: JMicron
> > > > [ 63.636956] usb 9-1: SerialNumber: 00A1234578EA
> > > > [ 63.638549] scsi5 : usb-storage 9-1:1.0
> > > > [ 64.926983] scsi 5:0:0:0: Direct-Access Jmicron Corp. 0000 PQ: 0 ANSI: 5
> > > > [ 64.927925] sd 5:0:0:0: Attached scsi generic sg6 type 0
> > > > [ 64.929912] sd 5:0:0:0: [sdg] Very big device. Trying to use READ CAPACITY(16).
> > > > [ 64.930353] sd 5:0:0:0: [sdg] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
> > > > [ 64.931031] sd 5:0:0:0: [sdg] Write Protect is off
> > > > [ 64.931042] sd 5:0:0:0: [sdg] Mode Sense: 28 00 00 00
> > > > [ 64.931764] sd 5:0:0:0: [sdg] No Caching mode page present
> > > > [ 64.931772] sd 5:0:0:0: [sdg] Assuming drive cache: write through
> > > > [ 64.932486] sd 5:0:0:0: [sdg] Very big device. Trying to use READ CAPACITY(16).
> > > > [ 64.933992] sd 5:0:0:0: [sdg] No Caching mode page present
> > > > [ 64.933997] sd 5:0:0:0: [sdg] Assuming drive cache: write through
> > > > [ 64.989015] sdg: sdg1 sdg2 sdg3 sdg4
> > > > [ 64.992112] sd 5:0:0:0: [sdg] Very big device. Trying to use READ CAPACITY(16).
> > > > [ 64.993885] sd 5:0:0:0: [sdg] No Caching mode page present
> > > > [ 64.993898] sd 5:0:0:0: [sdg] Assuming drive cache: write through
> > > > [ 64.993909] sd 5:0:0:0: [sdg] Attached SCSI disk
> > > > First line doesn't always appear, might depend on kernel version, I'm
> > > > not sure.
> > > >
> > > > I managed to bisect this down to this commit:
> > > > beabe20445c60322719d8f58e9eb9dd4660c1b3e
> > > > (it's from 3.4 branch, included in 3.4.36 release, upstream commit id
> > > > from commit message seems to be invalid, at least it's missing one
> > > > character).
> > > > I backported reverse of this commit to 3.17.1 (I can't run 3.4 kernel
> > > > due to different issues) and it helps with this issue. Patch attached
> > > > in case it is helpful, sorry though for whitespace mess, I used nano:)
> > > >
> > > > I doubt that just reverting is acceptable solution for mainstream
> > > > kernel, so I'm willing to test some other patches (on top of 3.17.1
> > > > would be best) or provide additional information so that this issue
> > > > could be fixed in next releases.
--
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
