Opened 3 years ago

Last modified 3 years ago

#719 reopened enhancement

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

Reported by: mamoch Owned by:
Priority: minor Milestone: undecided
Component: all Version: 6.5
Keywords: prolific Cc:

Description

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.

Attachments (7)

PL2773-eSATA_iSmart.txt (4.0 KB) - added by mamoch 3 years ago.
captured data by API Monitor when using iSmart.exe on eSATA
PL2773-eSATA_smartctl-A-ioctl2_0.log (17.1 KB) - added by mamoch 3 years ago.
smartctl -A -r ioctl,2 via PL2773-eSATA #0
PL2773-eSATA_smartctl-A-ioctl2_1.log (17.1 KB) - added by mamoch 3 years ago.
smartctl -A -r ioctl,2 via PL2773-eSATA #1
PL2773-eSATA_sg-raw_succ_0.log (8.6 KB) - added by mamoch 3 years ago.
sg_raw via PL2773-eSATA with success
PL2773-eSATA_sg-raw_fail.log (8.6 KB) - added by mamoch 3 years ago.
sg_raw via PL2773-eSATA with failure
SATA_smartctl-A-ioctl2.log (16.4 KB) - added by mamoch 3 years ago.
smartctl -A -r ioctl,2 via direct SATA
SATA_sg-raw.log (10.6 KB) - added by mamoch 3 years ago.
sg_raw via direct SATA

Download all attachments as: .zip

Change History (17)

Changed 3 years ago by mamoch

Attachment: PL2773-eSATA_iSmart.txt added

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

Changed 3 years ago by mamoch

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

Changed 3 years ago by mamoch

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

Changed 3 years ago by mamoch

sg_raw via PL2773-eSATA with success

Changed 3 years ago by mamoch

sg_raw via PL2773-eSATA with failure

Changed 3 years ago by mamoch

Attachment: SATA_smartctl-A-ioctl2.log added

smartctl -A -r ioctl,2 via direct SATA

Changed 3 years ago by mamoch

Attachment: SATA_sg-raw.log added

sg_raw via direct SATA

comment:1 Changed 3 years ago by 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.

comment:2 Changed 3 years ago by Christian Franke

Component: smartctlall
Keywords: prolific added; PL2773 eSATA removed
Milestone: undecided

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.

comment:3 in reply to:  2 Changed 3 years ago by 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.

comment:4 Changed 3 years ago by 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.

comment:5 Changed 3 years ago by 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/

comment:6 Changed 3 years ago by Christian Franke

Milestone: undecided
Resolution: invalid
Status: newclosed

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

comment:7 Changed 3 years ago by 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.

comment:8 Changed 3 years ago by 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.

comment:9 Changed 3 years ago by Christian Franke

Milestone: undecided
Type: defectenhancement

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

comment:10 Changed 3 years ago by Christian Franke

Resolution: invalid
Status: closedreopened

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

Note: See TracTickets for help on using tickets.