Prolific PL2773 USB3.0/eSATAII-to-SATAII bridge via eSATA not working

[mamoch]

The external 2.5" HDD enclosure fantec DB-228U3e contains a PL2773 bridge, for which USB support was recently added (cf. #482) and it works with this enclosure. But if you connect via eSATA then you don’t get proper SMART readings

I did some research using the same techniques described in #482: using vendor’s iSmart.exe and API Monitor to figure out what the vendor is doing; looking at smartctl’s raw commands; feeding the raw SCSI commands via sg_raw to drive.

This is what I found:

• smartctl doesn’t get proper readings of SMART attributes because drive responds to SMART READ ATTRIBUTE VALUES with same answer as to IDENTIFY DEVICE.
• On the other hand, if you send the raw SCSI commands via sg_raw you get valid responses, at least most times. If you do twice IDENTIFY DEVICE before SMART commands, just like smartctl does, you get more often the ”wrong” answer. Sounds like a race condition?
• PL2773 inserts its signature 06 7b 27 73 into the answer of IDENTIFY DEVICE at ”retired” words 20 & 21 (cf. ATA Command Set) and modifies some other bytes.
• SMART READ ATTRIBUTE THRESHOLDS always fails, even with iSmart.exe, but works with direct SATA access, so HDD firmware seems fine.

[mamoch]

captured data by API Monitor when using iSmart.exe on eSATA

[mamoch]

smartctl -A -r ioctl,2 via PL2773-eSATA #0

[mamoch]

smartctl -A -r ioctl,2 via PL2773-eSATA #1

[mamoch]

sg_raw via PL2773-eSATA with success

[mamoch]

sg_raw via PL2773-eSATA with failure

[mamoch]

smartctl -A -r ioctl,2 via direct SATA

[mamoch]

sg_raw via direct SATA

[mamoch]

I forgot:

• smartctl shows the same error on Windows.
• Inserting sleep 1 between every sg_raw call never triggers bad responses. That points again to a race condition.

[Christian Franke]

This is unrelated to Prolific USB support (#482). An eSATA connection should route the ATA commands transparently to the SATA disk.

Do other eSATA devices work properly with the same eSATA controller of the test machine?

Does this device show same behavior on other machines with a different eSATA controller (or on a regular SATA port with SATA<->eSATA adapter) ?

If both is the case, the eSATA implementation of this chip is apparently broken.

[mamoch]

Replying to chrfranke:

This is unrelated to Prolific USB support (#482). An eSATA connection should route the ATA commands transparently to the SATA disk.

I know that it’s not related to the Prolific USB implementation of smartctl, but it is the same chip in the HDD enclosure handling the ATA pass-through.

Do other eSATA devices work properly with the same eSATA controller of the test machine?

Yes, as you can see for example from SATA_smartctl-A-ioctl2.log and SATA_sg-raw.log which are recorded with a direct connection from that test machine (It’s a notebook.) to the HDD through an eSATA-SATA cable.

Does this device show same behavior on other machines with a different eSATA controller (or on a regular SATA port with SATA<->eSATA adapter) ?

I’ll test that

If both is the case, the eSATA implementation of this chip is apparently broken.

That was my assumption and I hoped, that maybe it is possible to implement a workaround into smartctl, at least for SMART READ ATTRIBUTE VALUES because this works with sg_raw.

[mamoch]

The enclosure shows exactly the same behavior when connected to a different machine’s SATA port with an eSATA-SATA cable. So most likely the chip has some flaws…

Ironically I always bought enclosures with eSATA ports to get direct SATA access to enclosed HDDs and not to worry about buggy chipsets, because I thought when eSATA is used the enclosure’s circuit board establishes direct wiring of the eSATA pins with the internal SATA connector. Now I must realize that everything still runs through the chip and again one has to rely on proper implementation of pass-through.

[Christian Franke]

The same problem was reported for an ICY BOX enclosure with PL2773:
​https://sourceforge.net/p/smartmontools/mailman/message/35326008/

There is a firmware update on the Prolific web site, but "For Vendors Only":
​http://prolificusa.com/portfolio/pl-2773-usb3-0-esataii-to-sataii-bridge-controller/

[Christian Franke]

This is a problem of the eSATA firmware of the Prolific PL2773.

[mamoch]

From the beginning my suspicion was that this is a firmware bug. But one can prevent it by inserting a waiting time between each consecutive SMART query as I mentioned before and of course one should not use the broken SMART READ ATTRIBUTE THRESHOLDS.

So I hoped that smartmontools could implement this workaround so that you can at least get all SMART values properly even if the vendor doesn’t fix the problem at all.

PS: How do you know that the firmware update on the Prolific website fixes this issue? There’s no changelog given.

[Christian Franke]

A workaround could possibly implemented as a filter class selected by e.g. -d prolific-esata. Its ata_pass_through() function shall insert a delay before issuing the supported ATA commands via basedev->ata_pass_through() and shall reject or emulate the unsupported commands.

PS: Of course I do not know whether the firmware update fixes this problem.

[Christian Franke]

Reopen ticket as an enhancement request for a firmware bug workaround. Volunteers with access to an affected device are welcome to provide a patch.

[Christian Franke]

Reopen ticket as an enhancement request for a firmware bug workaround. Volunteers with access to an affected device are welcome to provide a patch.