eSATA Drive Detection issues on mvsas

Hi,
I have couple of external drives (Western Digital and Seagate) that
have an eSATA interface. My Linux box with a Marvell HBA (9445) running Ubuntu 12.04 with 3.2.48 kernel doest not seem to detect the drive. I tried with the latest upstream kernel and it behaves the same. But both the drives detect fine if I enter the mvsas BIOS during bootup. So I have hooked up a SATA analyzer and this is what I found
- When I tried to detect the drives in the mvsas BIOS, all the ATA
commands that the bios issues have the port multiplier byte set to 0.
- If I bootup my Linux system and then connect the drives, the first
IDENTIFY command has the port multiplier set to 0 (this one is successful) and the subsequent IDENTIFY command has port multiplier set to 1 (this one fails).
- If I connect any other SATA drives I have to the HBA, all the ATA
commands have port multiplier set to 1 but they detects and work fine.

Just to rule out the port-multiplier possibility I changed the following line in drivers/scsi/libsas/sas_ata.c - fucntion sas_ata_qc_issue()

ata_tf_to_fis(&qc->tf, 1, 0, (u8*)&task->ata_task.fis);

to

ata_tf_to_fis(&qc->tf, 0, 0, (u8*)&task->ata_task.fis);

now all my drives seem to detect just fine. I believe, the eSATA interface on these external drives is a port multiplier, which is why the command fails. Also, the normal drives ignore this field thats why they work fine with port multiplier being set to either 0 or 1.

Question(s): Are my above assumtions correct? If so, what is the reasoning behind setting the port multiplier to 1 by default in libsas layer?

Thanks,
Praveen

Signature · 3 lines

To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Dan/James,
Can you please take a look at this and let me know if I am at the right
place? Or point me in the right direction? As I understand, this deost not look like an mvsas driver issue.

Quoted 14 lines

Hi,
I have couple of external drives (Western Digital and Seagate) that have
an eSATA interface. My Linux box with a Marvell HBA (9445) running Ubuntu 12.04 with 3.2.48 kernel doest not seem to detect the drive. I tried with the latest upstream kernel and it behaves the same. But both the drives detect fine if I enter the mvsas BIOS during bootup. So I have hooked up a SATA analyzer and this is what I found
- When I tried to detect the drives in the mvsas BIOS, all the ATA commands that the bios issues have the port multiplier byte set to 0.
- If I bootup my Linux system and then connect the drives, the first IDENTIFY command has the port multiplier set to 0 (this one is successful) and the subsequent IDENTIFY command has port multiplier set to 1 (this one fails).

Quoted 25 lines

- If I connect any other SATA drives I have to the HBA, all the ATA commands have port multiplier set to 1 but they detects and work fine.

Just to rule out the port-multiplier possibility I changed the following line in drivers/scsi/libsas/sas_ata.c - fucntion sas_ata_qc_issue()

ata_tf_to_fis(&qc->tf, 1, 0, (u8*)&task->ata_task.fis);

to

ata_tf_to_fis(&qc->tf, 0, 0, (u8*)&task->ata_task.fis);

now all my drives seem to detect just fine. I believe, the eSATA interface on these external drives is a port multiplier, which is why the command fails. Also, the normal drives ignore this field thats why they work fine with port multiplier being set to either 0 or 1.

Question(s): Are my above assumtions correct? If so, what is the reasoning behind setting the port multiplier to 1 by default in libsas layer?

Thanks,
Praveen

Quoted 5 lines · Praveen Murali

Dan/James,
Can you please take a look at this and let me know if I am at the right
place? Or point me in the right direction? As I understand, this deost not look like an mvsas driver issue.

Looks like a latent bug in libsas to me. Commit 110dd8f1 "[SCSI]
libsas: fix scr_read/write users and update the libata documentation" looks like a compile fix when the build was broken by commit 9977126c "libata: add @is_cmd to ata_tf_to_fis()" where libata changed the interface for ata_tf_to_fis(). We were passing 0 for pmp prior to that and changed to 1 here, probably a typo intending 'is_cmd to always be 1.

Somehow we have gotten away with is_cmd being 0? Does the following patch work for you:

drivers/scsi/libsas/sas_ata.c +1 -1

index 161c98efade9..d0fb99d5da95 100644
@@ -211,7 +211,7 @@ static unsigned int sas_ata_qc_issue(struct
 ata_queued_cmd *qc)
                 qc->tf.nsect = 0;
         }
 
-       ata_tf_to_fis(&qc->tf, 1, 0, (u8*)&task->ata_task.fis);
+       ata_tf_to_fis(&qc->tf, qc->dev->link->pmp, 1, (u8*)&task->ata_task.fis);
         task->uldd_task = qc;
         if (ata_is_atapi(qc->tf.protocol)) {

                 memcpy(task->ata_task.atapi_packet, qc->cdb, qc->dev->cdb_len);

That being said I don't think anybody has really checked out port-multiplier support on libsas, but we shouldn't be setting this bit by default.

--
Dan

Quoted 6 lines · Praveen Murali

Quoted 5 lines

Hi,
I have couple of external drives (Western Digital and Seagate) that have
an eSATA interface. My Linux box with a Marvell HBA (9445) running Ubuntu 12.04 with 3.2.48 kernel doest not seem to detect the drive. I tried with the latest upstream kernel and it behaves the same. But both the drives

Quoted 8 lines

Quoted 8 lines

detect fine if I enter the mvsas BIOS during bootup. So I have hooked up a SATA analyzer and this is what I found
- When I tried to detect the drives in the mvsas BIOS, all the ATA commands that the bios issues have the port multiplier byte set to 0.
- If I bootup my Linux system and then connect the drives, the first IDENTIFY command has the port multiplier set to 0 (this one is successful) and the subsequent IDENTIFY command has port multiplier set to 1 (this one fails).

I assume the first IDENTIFY is coming from the BIOS, not Linux correct?

Quoted 17 lines

Quoted 17 lines

- If I connect any other SATA drives I have to the HBA, all the ATA commands have port multiplier set to 1 but they detects and work fine.

Just to rule out the port-multiplier possibility I changed the following line in drivers/scsi/libsas/sas_ata.c - fucntion sas_ata_qc_issue()

ata_tf_to_fis(&qc->tf, 1, 0, (u8*)&task->ata_task.fis);

to

ata_tf_to_fis(&qc->tf, 0, 0, (u8*)&task->ata_task.fis);

now all my drives seem to detect just fine. I believe, the eSATA interface on these external drives is a port multiplier, which is why the command fails. Also, the normal drives ignore this field thats why they work fine with port multiplier being set to either 0 or 1.

Quoted 8 lines

Quoted 8 lines

Question(s): Are my above assumtions correct? If so, what is the reasoning behind setting the port multiplier to 1 by default in libsas layer?

Thanks,
Praveen

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 9 lines

drivers/scsi/libsas/sas_ata.c +0 -0

index 161c98efade9..d0fb99d5da95 100644
@@ -211,7 +211,7 @@ static unsigned int sas_ata_qc_issue(struct
 ata_queued_cmd *qc)
                 qc->tf.nsect = 0;
         }
 

Quoted 8 lines

drivers/scsi/libsas/sas_ata.c +1 -1

-       ata_tf_to_fis(&qc->tf, 1, 0, (u8*)&task->ata_task.fis);
+       ata_tf_to_fis(&qc->tf, qc->dev->link->pmp, 1,
 (u8*)&task->ata_task.fis);
         task->uldd_task = qc;

         if (ata_is_atapi(qc->tf.protocol)) {
                 memcpy(task->ata_task.atapi_packet, qc->cdb,

qc->dev->cdb_len);

Hi Dan,
I tested this patch and it works great!