Re: [PATCH] [RFC] scsi: mvsas: Try to enable MSI

[Marek Vasut <marex@xxxxxxx>]

On 10/24/23 12:46, John Garry wrote:
> On 22/10/2023 21:03, Marek Vasut wrote:
> > This seems to be needed on OCZ RevoDrive 3 X2 / RevoDrive 350
> > OCZ Technology Group, Inc. RevoDrive 3 X2 PCIe SSD 240 GB (Marvell SAS 
> > Controller) [1b85:1021] (rev 02)
>
> By chance do you have any documentation on this controller

None what-so-ever, only this ancient oczpcie mvsas driver fork, which I 
injected hunk by hunk into existing mvsas, tested, etc. until I got to 
this one PCIe MSI line thing which made that controller work.

> which tells us that it requires MSI?

The situation is even worse in that OCZ got assimilated by Toshiba and 
all information about this device disappeared from toshiba website long 
ago. It is still in archive.org, but whatever software they released is 
non-trivial to even get working at all, and tbh even this drive itself 
is weird piece of hardware.

> > Without MSI enabled, the controller fails as follows:
> > "
> > mvsas 0000:00:02.0: mvsas: PCI-E x0, Bandwidth Usage: UnKnown Gbps
> > scsi host0: mvsas
> > sas: Enter sas_scsi_recover_host busy: 0 failed: 0
> > ata1.00: qc timeout after 5000 msecs (cmd 0xec)
> > ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4)
> > ata1.00: qc timeout after 10000 msecs (cmd 0xec)
> > ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4)
> > ata1.00: qc timeout after 30000 msecs (cmd 0xec)
> > ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4)
> > sas: --- Exit sas_scsi_recover_host: busy: 0 failed: 0 tries: 1
> > sas: sas_probe_sata: for direct-attached device 0000000000000000 
> > returned -19
> > sas: Enter sas_scsi_recover_host busy: 0 failed: 0
> > ata2.00: qc timeout after 5000 msecs (cmd 0xec)
> > ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4)
> > ata2.00: qc timeout after 10000 msecs (cmd 0xec)
> > ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4)
> > ata2.00: qc timeout after 30000 msecs (cmd 0xec)
> > ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4)
> > sas: --- Exit sas_scsi_recover_host: busy: 0 failed: 0 tries: 1
> > sas: sas_probe_sata: for direct-attached device 0100000000000000 
> > returned -19
> > "
> >
> > With this patch, the controller detects the two SSD drives on it:
> > "
> > mvsas 0000:00:02.0: mvsas: PCI-E x0, Bandwidth Usage: UnKnown Gbps
> > scsi host0: mvsas
> > sas: Enter sas_scsi_recover_host busy: 0 failed: 0
> > ata1.00: ATA-8: OCZ-REVODRIVE350, 2.50, max UDMA/133
> > ata1.00: 234441648 sectors, multi 1: LBA48 NCQ (depth 32)
> > ata1.00: configured for UDMA/133
> > sas: --- Exit sas_scsi_recover_host: busy: 0 failed: 0 tries: 1
> > scsi 0:0:0:0: Direct-Access     ATA      OCZ-REVODRIVE350 2.50 PQ: 0 
> > ANSI: 5
> > sas: Enter sas_scsi_recover_host busy: 0 failed: 0
> > ata2.00: ATA-8: OCZ-REVODRIVE350, 2.50, max UDMA/133
> > ata2.00: 234441648 sectors, multi 1: LBA48 NCQ (depth 32)
> > ata2.00: configured for UDMA/133
> > sas: --- Exit sas_scsi_recover_host: busy: 0 failed: 0 tries: 1
> > scsi 0:0:1:0: Direct-Access     ATA      OCZ-REVODRIVE350 2.50 PQ: 0 
> > ANSI: 5
> > scsi 0:0:0:0: Attached scsi generic sg0 type 0
> > sd 0:0:0:0: [sda] 234441648 512-byte logical blocks: (120 GB/112 GiB)
> > sd 0:0:1:0: [sdb] 234441648 512-byte logical blocks: (120 GB/112 GiB)
> > sd 0:0:1:0: Attached scsi generic sg1 type 0
> > sd 0:0:0:0: [sda] Write Protect is off
> > sd 0:0:1:0: [sdb] Write Protect is off
> > sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't 
> > support DPO or FUA
> > sd 0:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't 
> > support DPO or FUA
> > sd 0:0:0:0: [sda] Preferred minimum I/O size 512 bytes
> > sd 0:0:1:0: [sdb] Preferred minimum I/O size 512 bytes
> > sd 0:0:0:0: [sda] Attached SCSI disk
> > sd 0:0:1:0: [sdb] Attached SCSI disk
> > "
> >
> > I am not sure whether this is the correct fix, or whether this should
> > be a controller specific quirk instead, considering how this is likely
> > a legacy controller driver.
>
> pci_enable_msi() switches from pin-based interrupts to MSI. So currently 
> the driver relies on pin-based. As such, I would be more inclined to 
> quirk the driver for this controller.

Indeed.

I'll send a V2 with the quirk and return value check when time permits, 
considering there seem to be few users, I don't think there is much urgency.

Thanks !