Atto UL5D: negotiates only up to FAST-40 SCSI

Atto UL5D: negotiates only up to FAST-40 SCSI

[Sven Rudolph]

I try to use an Atto Dual-Channel Low-Profile PCIExpress SCSI HBA
(<http://www.attotech.com/ultra5Dlowpro.html>) with Linux (2.6.18.1,
2.6.19rc6).

(Atto provides a Linux driver on CD, but I prefer to use drivers
included in the vanilla Linux kernel. It looks like their driver does
not include all source code; but I might be wrong on this.)

According to lspci the card seems to include a vanilla Symbios Logic
1030 Chip (with an ATTO Vendor ID) and an Intel PCI-to-PCIExpress
bridge:


  09:00.0 PCI bridge: Intel Corporation 41210 [Lanai] Serial to Parallel PCI Bridge (A-Segment Bridge) (rev 09)
  09:00.2 PCI bridge: Intel Corporation 41210 [Lanai] Serial to Parallel PCI Bridge (B-Segment Bridge) (rev 09)
  0a:04.0 SCSI storage controller: Atto Technology Ultra320 SCSI Host Adapter (rev 08)
  0a:04.1 SCSI storage controller: Atto Technology Ultra320 SCSI Host Adapter (rev 08)

  09:00.0 0604: 8086:0340 (rev 09)
  09:00.2 0604: 8086:0341 (rev 09)
  0a:04.0 0100: 117c:0030 (rev 08)
  0a:04.1 0100: 117c:0030 (rev 08)


I added the new vendor ID to the fusion driver; with this kernel I can
access a hard disk attached to that controller:

diff -uprN linux-2.6.18.1-common/drivers/message/fusion/mptspi.c linux-2.6.18.1-atto/drivers/message/fusion/mptspi.c
--- linux-2.6.18.1-common/drivers/message/fusion/mptspi.c	2006-11-15 14:08:39.000000000 +0100
+++ linux-2.6.18.1-atto/drivers/message/fusion/mptspi.c	2006-11-15 14:09:17.000000000 +0100
@@ -775,6 +775,8 @@ static struct pci_device_id mptspi_pci_t
 		PCI_ANY_ID, PCI_ANY_ID },
 	{ PCI_VENDOR_ID_LSI_LOGIC, MPI_MANUFACTPAGE_DEVID_53C1035,
 		PCI_ANY_ID, PCI_ANY_ID },
+	{ PCI_VENDOR_ID_ATTO, MPI_MANUFACTPAGE_DEVID_53C1030,
+		PCI_ANY_ID, PCI_ANY_ID },
 	{0}	/* Terminating entry */
 };
 MODULE_DEVICE_TABLE(pci, mptspi_pci_table);
diff -uprN linux-2.6.18.1-common/include/linux/pci_ids.h linux-2.6.18.1-atto/include/linux/pci_ids.h
--- linux-2.6.18.1-common/include/linux/pci_ids.h	2006-10-14 05:34:03.000000000 +0200
+++ linux-2.6.18.1-atto/include/linux/pci_ids.h	2006-11-15 14:11:26.000000000 +0100
@@ -1440,6 +1440,8 @@
 #define PCI_DEVICE_ID_TOSHIBA_TC86C001_MISC	0x0108
 #define PCI_DEVICE_ID_TOSHIBA_SPIDER_NET 0x01b3
 
+#define PCI_VENDOR_ID_ATTO		0x117c
+
 #define PCI_VENDOR_ID_RICOH		0x1180
 #define PCI_DEVICE_ID_RICOH_RL5C465	0x0465
 #define PCI_DEVICE_ID_RICOH_RL5C466	0x0466


I tested this with Linux 2.6.19-rc6 too and it works.

Only remaining problem is that it does not negotiate transfer speeds
beyond FAST-40 (and does not negotiate WIDE transfers):


  Fusion MPT base driver 3.04.02
  Copyright (c) 1999-2005 LSI Logic Corporation
  Fusion MPT SPI Host driver 3.04.02
  ACPI: PCI Interrupt 0000:0a:04.0[A] -> GSI 16 (level, low) -> IRQ 16
  mptbase: Initiating ioc0 bringup
  ioc0: 53C1030: Capabilities={Initiator,Target}
  scsi1 : ioc0: LSI53C1030, FwRev=01032700h, Ports=1, MaxQ=255, IRQ=16
  scsi 1:0:3:0: Direct-Access     SEAGATE  ST3300007LC      7806 PQ: 0 ANSI: 3
   target1:0:3: Beginning Domain Validation
   target1:0:3: Domain Validation skipping write tests
   target1:0:3: Ending Domain Validation
   target1:0:3: FAST-40 SCSI 40.0 MB/s ST (25 ns, offset 63)
  SCSI device sdl: 585937500 512-byte hdwr sectors (300000 MB)
  sdl: Write Protect is off
  sdl: Mode Sense: ab 00 10 08
  SCSI device sdl: drive cache: write through w/ FUA
  SCSI device sdl: 585937500 512-byte hdwr sectors (300000 MB)
  sdl: Write Protect is off
  sdl: Mode Sense: ab 00 10 08
  SCSI device sdl: drive cache: write through w/ FUA
   sdl: unknown partition table
  sd 1:0:3:0: Attached scsi disk sdl
  scsi 1:0:8:0: Processor         QLogic   GEM359           1.10 PQ: 0 ANSI: 2
   target1:0:8: Beginning Domain Validation
   target1:0:8: Ending Domain Validation
   target1:0:8: asynchronous


I have no idea what causes this problem. Any suggestions where and how
I should look for more info?

	Sven

Re: Atto UL5D: negotiates only up to FAST-40 SCSI

[James Bottomley]

On Fri, 2006-11-17 at 12:21 +0100, Sven Rudolph wrote:
>   scsi 1:0:3:0: Direct-Access     SEAGATE  ST3300007LC      7806 PQ: 0
> ANSI: 3
>    target1:0:3: Beginning Domain Validation
>    target1:0:3: Domain Validation skipping write tests
>    target1:0:3: Ending Domain Validation
>    target1:0:3: FAST-40 SCSI 40.0 MB/s ST (25 ns, offset 63)

This is characteristic of the bus being in single ended mode, can you
execute

cat /sys/class/spi_host/host1/signalling

and see what it says.  If it returns SE, that's your problem.

>   scsi 1:0:8:0: Processor         QLogic   GEM359           1.10 PQ: 0
> ANSI: 2

This is a very old (circa 2000) processor.  Are you sure your storage
cage supports LVD?

James

Re: Atto UL5D: negotiates only up to FAST-40 SCSI

[Sven Rudolph]

James Bottomley <James.Bottomley@SteelEye.com> writes:

> On Fri, 2006-11-17 at 12:21 +0100, Sven Rudolph wrote:
>>   scsi 1:0:3:0: Direct-Access     SEAGATE  ST3300007LC      7806 PQ: 0
>> ANSI: 3
>>    target1:0:3: Beginning Domain Validation
>>    target1:0:3: Domain Validation skipping write tests
>>    target1:0:3: Ending Domain Validation
>>    target1:0:3: FAST-40 SCSI 40.0 MB/s ST (25 ns, offset 63)
>
> This is characteristic of the bus being in single ended mode, can you
> execute
>
> cat /sys/class/spi_host/host1/signalling
>
> and see what it says.  If it returns SE, that's your problem.

# cat /sys/class/spi_host/host1/signalling 
unknown

Irritating. But this result appears for other hosts/busses too. See
below.


>>   scsi 1:0:8:0: Processor         QLogic   GEM359           1.10 PQ: 0
>> ANSI: 2
>
> This is a very old (circa 2000) processor.  Are you sure your storage
> cage supports LVD?

I think so. It is a Fujitsu-Siemens Primergy SX30, which is the
Ultra320 version of the older S30 (up to Ultra160 only). The manual of
the S30 lists December 2000.

I connected this to a real LSI controller (LSI20320-R):

  0e:06.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 08)

  0e:06.0 0100: 1000:0030 (rev 08)

dmesg says:

  ACPI: PCI Interrupt 0000:0e:06.0[A] -> GSI 74 (level, low) -> IRQ 20
  mptbase: Initiating ioc2 bringup
  ioc2: 53C1030: Capabilities={Initiator}
  scsi3 : ioc2: LSI53C1030, FwRev=01030f00h, Ports=1, MaxQ=222, IRQ=20
  scsi 3:0:3:0: Direct-Access     SEAGATE  ST3300007LC      7806 PQ: 0 ANSI: 3
   target3:0:3: Beginning Domain Validation
   target3:0:3: Ending Domain Validation
   target3:0:3: FAST-160 WIDE SCSI 320.0 MB/s DT IU QAS RTI WRFLOW PCOMP (6.25 ns, offset 63)
  SCSI device sdl: 585937500 512-byte hdwr sectors (300000 MB)
  sdl: Write Protect is off
  sdl: Mode Sense: ab 00 10 08
  SCSI device sdl: drive cache: write through w/ FUA
  SCSI device sdl: 585937500 512-byte hdwr sectors (300000 MB)
  sdl: Write Protect is off
  sdl: Mode Sense: ab 00 10 08
  SCSI device sdl: drive cache: write through w/ FUA
   sdl: unknown partition table
  sd 3:0:3:0: Attached scsi disk sdl
  scsi 3:0:8:0: Processor         QLogic   GEM359           1.10 PQ: 0 ANSI: 2
   target3:0:8: Beginning Domain Validation
   target3:0:8: Ending Domain Validation
   target3:0:8: asynchronous

FAST-160 is detected when the same cable, storage cage and disk drive
are connected to the LSI controller, but on the Atto only FAST-40
appears. Does it make sense to try another SCSI cable?


# cat /var/log/dmesg| grep "scsi[0123] "
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0
scsi1 : ioc0: LSI53C1030, FwRev=01032700h, Ports=1, MaxQ=255, IRQ=16
scsi2 : ioc1: LSI53C1030, FwRev=01032700h, Ports=1, MaxQ=255, IRQ=17
scsi3 : ioc2: LSI53C1030, FwRev=01030f00h, Ports=1, MaxQ=222, IRQ=20
# cat /sys/class/spi_host/host*/signalling
LVD
unknown
unknown
unknown
#

(scsi1/scsi2 are the Atto channels, scsi3 is the LSI20320-R.)

Looks like this sysfs entry is only set by aic7xxx, but not by
mptfusion. Or am I missing some kernel config option?

Comparing the dmesg output the difference is that it says on the Atto:

  target1:0:3: Domain Validation skipping write tests

Might this be caused by either different PCI vendor IDs or some
differences in the controller firmware? Perhaps I should try the Atto
Linux driver just to make sure that it can do Ultra320?

	Sven

Re: Atto UL5D: negotiates only up to FAST-40 SCSI

[Sven Rudolph]

Sven Rudolph <Sven_Rudolph@drewag.de> writes:

> FAST-160 is detected when the same cable, storage cage and disk drive
> are connected to the LSI controller, but on the Atto only FAST-40
> appears. Does it make sense to try another SCSI cable?

Something I forgot to mention: I became aware of the problem when I
tried to read from (or write to (?)) three disks in parallel and the
sum of the transfer speeds was a bit below 40 MBytes/second when I ran
two disks and it was the nearly the same with three disks. The first
disk was the fastest in the three-disk test run, and the third was the
slowest. I suppose this is due to SCSI priority by SCSI ID. So I'm
quite sure that the bus really only runs in FAST-40 mode.

	Sven

Re: Atto UL5D: negotiates only up to FAST-40 SCSI

[James Bottomley]

On Fri, 2006-11-17 at 18:22 +0100, Sven Rudolph wrote:
> Something I forgot to mention: I became aware of the problem when I
> tried to read from (or write to (?)) three disks in parallel and the
> sum of the transfer speeds was a bit below 40 MBytes/second when I ran
> two disks and it was the nearly the same with three disks. The first
> disk was the fastest in the three-disk test run, and the third was the
> slowest. I suppose this is due to SCSI priority by SCSI ID. So I'm
> quite sure that the bus really only runs in FAST-40 mode.

OK ... I think there's something unusual about your actual card.  I
checked the specs and FAST-40 should be LVD.  The DV information
indicates that the device is also Narrow not wide, which implies either
it refused wide negotiation, or that the card wasn't able to set the
correct parameters.  You can try to set it manually with 

echo 1 > /sys/class/spi_transport/target1:0:3/width

then you have to do I/O to force the renegotiation (fdisk is good for
this) and then try and cat back the parameter.

You can also try to force it up to FAST-160 with

echo 6.25 > /sys/class/spi_transport/target1:0:3/period

and again force I/O with fdisk then cat the parameter back to see if it
took.

James

Re: Atto UL5D: negotiates only up to FAST-40 SCSI

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 5229 bytes --]

On Fri, 17 Nov 2006 12:21:32 +0100 Sven Rudolph wrote:

> I try to use an Atto Dual-Channel Low-Profile PCIExpress SCSI HBA
> (<http://www.attotech.com/ultra5Dlowpro.html>) with Linux (2.6.18.1,
> 2.6.19rc6).
>
> (Atto provides a Linux driver on CD, but I prefer to use drivers
> included in the vanilla Linux kernel. It looks like their driver does
> not include all source code; but I might be wrong on this.)

They also provide a patch for the mptspi driver (apparently made for
2.6.14):

http://www.attotech.com/software/secure/lnx_drv_epciu320_2.6.14-15.patch

This patch still applies to 2.6.18 with some fuzz, resulting in the
following changes:

diff --git a/drivers/message/fusion/lsi/mpi_cnfg.h b/drivers/message/fusion/lsi/mpi_cnfg.h
index 47e13e3..6cb9c21 100644
--- a/drivers/message/fusion/lsi/mpi_cnfg.h
+++ b/drivers/message/fusion/lsi/mpi_cnfg.h
@@ -1440,6 +1440,30 @@ typedef struct _CONFIG_PAGE_SCSI_PORT_2
 } CONFIG_PAGE_SCSI_PORT_2, MPI_POINTER PTR_CONFIG_PAGE_SCSI_PORT_2,
   SCSIPortPage2_t, MPI_POINTER pSCSIPortPage2_t;

+typedef struct _ATTO_DEVICE_INFO
+{
+  U8      Offset;                                     /* 00h */
+  U8      Period;                                     /* 01h */
+  U16     ATTOFlags;                                  /* 02h */
+} ATTO_DEVICE_INFO, MPI_POINTER PTR_ATTO_DEVICE_INFO,
+  ATTODeviceInfo_t, MPI_POINTER pATTODeviceInfo_t;
+
+#define ATTOFLAG_DISC     0x0001
+#define ATTOFLAG_TAGGED   0x0002
+#define ATTOFLAG_WIDE_ENB 0x0008
+#define ATTOFLAG_ID_ENB   0x0010
+#define ATTOFLAG_LUN_ENB  0x0060
+
+typedef struct _ATTO_CONFIG_PAGE_SCSI_PORT_2
+{
+  CONFIG_PAGE_HEADER  Header;                         /* 00h */
+  U16                 PortFlags;                      /* 04h */
+  U16                 Unused1;                        /* 06h */
+  U32                 Unused2;                        /* 08h */
+  ATTO_DEVICE_INFO    DeviceSettings[16];             /* 0Ch */
+} fATTO_CONFIG_PAGE_SCSI_PORT_2, MPI_POINTER PTR_ATTO_CONFIG_PAGE_SCSI_PORT_2,
+  ATTO_SCSIPortPage2_t, MPI_POINTER pATTO_SCSIPortPage2_t;
+
 #define MPI_SCSIPORTPAGE2_PAGEVERSION                       (0x02)

 /* PortFlags values */
diff --git a/drivers/message/fusion/mptbase.c b/drivers/message/fusion/mptbase.c
index 29d0635..6b47fb0 100644
--- a/drivers/message/fusion/mptbase.c
+++ b/drivers/message/fusion/mptbase.c
@@ -1357,6 +1357,7 @@ mpt_attach(struct pci_dev *pdev, const s
 		pci_disable_io_access(pdev);

 	sprintf(ioc->name, "ioc%d", ioc->id);
+	ioc->is_ATTO = (pdev->vendor == 0x117c);

 	spin_lock_init(&ioc->FreeQlock);

@@ -4607,6 +4608,37 @@ mpt_GetScsiPortSettings(MPT_ADAPTER *ioc
 				/* Nvram data is left with INVALID mark
 				 */
 				rc = 1;
+			} else if (ioc->is_ATTO) {
+			  /* This is an ATTO adapter, read Page2 accordingly
+			   */
+			  ATTO_SCSIPortPage2_t *pPP2 = (ATTO_SCSIPortPage2_t  *) pbuf;
+			  ATTODeviceInfo_t *pdevice = NULL;
+			  U16 ATTOFlags;
+
+			  /* Save the Port Page 2 data
+			   * (reformat into a 32bit quantity)
+			   */
+			  for (ii=0; ii < MPT_MAX_SCSI_DEVICES; ii++) {
+			    pdevice = &pPP2->DeviceSettings[ii];
+			    ATTOFlags = le16_to_cpu(pdevice->ATTOFlags);
+			    data = 0;
+
+			    /* Translate ATTO device flags to LSI format
+			     */
+			    if (ATTOFlags & ATTOFLAG_DISC)
+			      data |= (MPI_SCSIPORTPAGE2_DEVICE_DISCONNECT_ENABLE);
+			    if (ATTOFlags & ATTOFLAG_ID_ENB)
+			      data |= (MPI_SCSIPORTPAGE2_DEVICE_ID_SCAN_ENABLE);
+			    if (ATTOFlags & ATTOFLAG_LUN_ENB)
+			      data |= (MPI_SCSIPORTPAGE2_DEVICE_LUN_SCAN_ENABLE);
+			    if (ATTOFlags & ATTOFLAG_TAGGED)
+			      data |= (MPI_SCSIPORTPAGE2_DEVICE_TAG_QUEUE_ENABLE);
+			    if (!(ATTOFlags & ATTOFLAG_WIDE_ENB))
+			      data |= (MPI_SCSIPORTPAGE2_DEVICE_WIDE_DISABLE);
+
+			    data = (data << 16) | (pdevice->Period << 8) | 10;
+			    ioc->spi_data.nvram[ii] = data;
+			  }
 			} else {
 				SCSIPortPage2_t *pPP2 = (SCSIPortPage2_t  *) pbuf;
 				MpiDeviceInfo_t	*pdevice = NULL;
diff --git a/drivers/message/fusion/mptbase.h b/drivers/message/fusion/mptbase.h
index c537d71..dcf911a 100644
--- a/drivers/message/fusion/mptbase.h
+++ b/drivers/message/fusion/mptbase.h
@@ -601,6 +601,7 @@ typedef struct _MPT_ADAPTER
 	u16			 hs_reply[MPT_MAX_FRAME_SIZE/sizeof(u16)];
 	IOCFactsReply_t		 facts;
 	PortFactsReply_t	 pfacts[2];
+        int                      is_ATTO;
 	FCPortPage0_t		 fc_port_page0[2];
 	struct timer_list	 persist_timer;	/* persist table timer */
 	int			 persist_wait_done; /* persist completion flag */
diff --git a/drivers/message/fusion/mptspi.c b/drivers/message/fusion/mptspi.c
index e4cc3dd..3dc6193 100644
--- a/drivers/message/fusion/mptspi.c
+++ b/drivers/message/fusion/mptspi.c
@@ -775,6 +775,7 @@ static struct pci_device_id mptspi_pci_t
 		PCI_ANY_ID, PCI_ANY_ID },
 	{ PCI_VENDOR_ID_LSI_LOGIC, MPI_MANUFACTPAGE_DEVID_53C1035,
 		PCI_ANY_ID, PCI_ANY_ID },
+	{ 0x117c, 0x0030, PCI_ANY_ID, PCI_ANY_ID }, /* ATTO UL4D */
 	{0}	/* Terminating entry */
 };
 MODULE_DEVICE_TABLE(pci, mptspi_pci_table);


Apparently ATTO devices have a completely different NVRAM format -
maybe this causes the problem when a driver with just a PCI ID added
tries to interpret NVRAM data using the LSI format?

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Atto UL5D: negotiates only up to FAST-40 SCSI

[James Bottomley]

On Fri, 2006-11-17 at 22:35 +0300, Sergey Vlasov wrote:
> This patch still applies to 2.6.18 with some fuzz, resulting in the
> following changes:

That basically says the card doesn't use the same control flags as a
standard LSI meaning it's thoroughly confused about how the DV code is
asking it to negotiate.

James

Re: Atto UL5D: negotiates only up to FAST-40 SCSI

[Sven Rudolph]

Sergey Vlasov <vsu@altlinux.ru> writes:

> On Fri, 17 Nov 2006 12:21:32 +0100 Sven Rudolph wrote:
>
>> I try to use an Atto Dual-Channel Low-Profile PCIExpress SCSI HBA
>> (<http://www.attotech.com/ultra5Dlowpro.html>) with Linux (2.6.18.1,
>> 2.6.19rc6).
>>
>> (Atto provides a Linux driver on CD, but I prefer to use drivers
>> included in the vanilla Linux kernel. It looks like their driver does
>> not include all source code; but I might be wrong on this.)
>
> They also provide a patch for the mptspi driver (apparently made for
> 2.6.14):
>
> http://www.attotech.com/software/secure/lnx_drv_epciu320_2.6.14-15.patch

Thank you for finding this. This patch seems to work fine.

So we should teach Atto to submit this patch to the Linux kernel
instead of trying to roll their on driver? Or can this be implemented
without asking Atto?

Atto seems to prefer their own driver, they say on their web site:

  Linux Support for ExpressPCI. ATTO strongly recommends using the
  RedHat/SUSE driver for all installations. Linux support was
  previously provided for the 2.4 and 2.6 kernels via patches to the
  LSI Logic Fusion MPT driver. However, these patches are no longer
  supported. Release notes and installation instructions are included
  in the download packages.

      Red Hat/SUSE Linux driver v1.00 (File Size393KB) This driver is
      recommended for use with the Red Hat Linux Enterprise 3.x/4 and
      SUSE Linux Enterprise Server for x86, x64(AMD64, EM64T), and
      IA-64 (Itanium) systems.

      The following patches are available for those who prefer the older driver:

      Linux 2.4 Driver Patch for LSI Logic Fusion-MPT Driver v2.05.00
      (File Size 2.2KB) The LSI Logic Fusion-MPT Driver v2.05.00 can
      be downloaded here (File Size 23.4MB).

      Linux 2.6 Driver Patch for LSI Logic Fusion-MPT Driver (File
      Size 2.1KB)The LSI Logic Fusion-MPT Driver v3.01.xx is included
      with the Linux kernel.

> Apparently ATTO devices have a completely different NVRAM format -
> maybe this causes the problem when a driver with just a PCI ID added
> tries to interpret NVRAM data using the LSI format?

This explains the problem. It is even surprising that it worked at
all...

	Sven