aic7xxx support for >2TB volumes?

aic7xxx support for >2TB volumes?

[Kilian CAVALOTTI]

Hi all, 

After some searching through newgroups and mailing lists, I haven't really 
found an answer to the question: is the aic7xxx driver capable of supporting 
larger than 2 terabytes volumes? I have read some success reports, but some 
failed attempts too...

I actually have an external RAID array, hosting a 6TB virtual disk, plugged on 
an Adaptec 39160 SCSI card. I'm using a 2.6.14 kernel, with  CONFIG_LBD=y, 
and thus, the aic7xxx (ver 7.0) module.

My dmesg show the following:

scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0
        <Adaptec 3960D Ultra160 SCSI adapter>
        aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
  Vendor: transtec  Model: T6100S16R1-D      Rev: 342J
  Type:   Direct-Access                      ANSI SCSI revision: 05
scsi1:A:0:0: Tagged Queuing enabled.  Depth 32
 target1:0:0: Beginning Domain Validation
 target1:0:0: wide asynchronous.
 target1:0:0: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 127)
 target1:0:0: Ending Domain Validation
sdb : very big device. try to use READ CAPACITY(16).
sdb : READ CAPACITY(16) failed.
sdb : status=0, message=00, host=5, driver=00
sdb : use 0xffffffff as device size
SCSI device sdb: 4294967296 512-byte hdwr sectors (2199023 MB)
SCSI device sdb: drive cache: write back
sdb : very big device. try to use READ CAPACITY(16).
sdb : READ CAPACITY(16) failed.
sdb : status=0, message=00, host=5, driver=00
sdb : use 0xffffffff as device size
SCSI device sdb: 4294967296 512-byte hdwr sectors (2199023 MB)
SCSI device sdb: drive cache: write back
 sdb: unknown partition table
Attached scsi disk sdb at scsi1, channel 0, id 0, lun 0
Attached scsi generic sg2 at scsi1, channel 0, id 0, lun 0,  type 0

Whatever the real size of the volume, it always give a "4294967296 512-byte 
hdwr sectors (2199023 MB)" device...

Is there a way to support a >2TB volume on this SCSI controler? I know I could 
split my volume in smaller ones and use LVM to reassemble them, but I'd like 
to avoid adding overhead to the storage stack, and keep it the simplest.

Thanks in advance for any hint/advice,
Best regards,

-- 
Kilian CAVALOTTI                      Administrateur réseaux et systèmes
UPMC / CNRS - LIP6 (C870)
8, rue du Capitaine Scott                          Tel. : 01 44 27 88 54
75015 Paris - France                               Fax. : 01 44 27 70 00
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: aic7xxx support for >2TB volumes?

[Douglas Gilbert]

Kilian CAVALOTTI wrote:
> Hi all, 
> 
> After some searching through newgroups and mailing lists, I haven't really 
> found an answer to the question: is the aic7xxx driver capable of supporting 
> larger than 2 terabytes volumes? I have read some success reports, but some 
> failed attempts too...
> 
> I actually have an external RAID array, hosting a 6TB virtual disk, plugged on 
> an Adaptec 39160 SCSI card. I'm using a 2.6.14 kernel, with  CONFIG_LBD=y, 
> and thus, the aic7xxx (ver 7.0) module.
> 
> My dmesg show the following:
> 
> scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0
>         <Adaptec 3960D Ultra160 SCSI adapter>
>         aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
>   Vendor: transtec  Model: T6100S16R1-D      Rev: 342J
>   Type:   Direct-Access                      ANSI SCSI revision: 05
> scsi1:A:0:0: Tagged Queuing enabled.  Depth 32
>  target1:0:0: Beginning Domain Validation
>  target1:0:0: wide asynchronous.
>  target1:0:0: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 127)
>  target1:0:0: Ending Domain Validation
> sdb : very big device. try to use READ CAPACITY(16).
> sdb : READ CAPACITY(16) failed.
> sdb : status=0, message=00, host=5, driver=00
> sdb : use 0xffffffff as device size
> SCSI device sdb: 4294967296 512-byte hdwr sectors (2199023 MB)
> SCSI device sdb: drive cache: write back
> sdb : very big device. try to use READ CAPACITY(16).
> sdb : READ CAPACITY(16) failed.
> sdb : status=0, message=00, host=5, driver=00
> sdb : use 0xffffffff as device size
> SCSI device sdb: 4294967296 512-byte hdwr sectors (2199023 MB)
> SCSI device sdb: drive cache: write back
>  sdb: unknown partition table
> Attached scsi disk sdb at scsi1, channel 0, id 0, lun 0
> Attached scsi generic sg2 at scsi1, channel 0, id 0, lun 0,  type 0
> 
> Whatever the real size of the volume, it always give a "4294967296 512-byte 
> hdwr sectors (2199023 MB)" device...
> 
> Is there a way to support a >2TB volume on this SCSI controler? I know I could 
> split my volume in smaller ones and use LVM to reassemble them, but I'd like 
> to avoid adding overhead to the storage stack, and keep it the simplest.

>From the above, it seems the problem is within the
"sdb" device. If it responds to a READ CAPACITY (10)
with a last lba of 0xffffffff (i.e. (2**32 - 1)) then
according to SBC-2 and SBC-3 that is flagging the
application client (i.e. the sd driver) to try a
READ CAPACITY (16) command. The larger READ CAPACITY (16)
has an eight byte (64 bit) last lba field.

>From the log output above, /dev/sdb seems to reject
the READ CAPACITY (16) command. I think that it is
unlikely that the aic7xxx driver is filtering out that
particular command (why should it?) and a simple grep
in that driver for READ_CAP finds no matches.

As an extra check of the linux sd driver you could fetch
sg3_utils, build it and try:
  sg_readcap -16 /dev/sdb

If that fails than I think you need to speak to the vendor
of /dev/sdb . Perhaps there is newer firmware.


Doug Gilbert

Re: aic7xxx support for >2TB volumes?

[Kilian CAVALOTTI]

First of all, thanks for highlighting this.

On Friday 18 November 2005 09:59, Douglas Gilbert wrote:
> From the log output above, /dev/sdb seems to reject
> the READ CAPACITY (16) command. I think that it is
> unlikely that the aic7xxx driver is filtering out that
> particular command (why should it?) and a simple grep
> in that driver for READ_CAP finds no matches.
>
> As an extra check of the linux sd driver you could fetch
> sg3_utils, build it and try:
>   sg_readcap -16 /dev/sdb

As expected:
# sg_readcap -v -16 /dev/sdb
    read capacity (16) cdb: 9e 10 00 00 00 00 00 00 00 00 00 00 00 20 00 00
READ CAPACITY 16 command error: Host_status=0x05 [DID_ABORT]

Moreover, I omitted to mention that point earlier, but the HBA BIOS does not 
correctly detect the volume size. It reports a "Capacity: 0MB"

> If that fails than I think you need to speak to the vendor
> of /dev/sdb . Perhaps there is newer firmware.

Sure, I contacted them, and they told me that currently, the only 
known-to-work-over-2TB HBA vendor was LSI Logic.
So I tried to plug the same external array on a U320 LSI Logic adapter (using 
the Fusion MPT kernel module), and it actually worked: 

ioc0: 53C1030: Capabilities={Initiator,Target}
scsi1 : ioc0: LSI53C1030, FwRev=01032300h, Ports=1, MaxQ=255, IRQ=23
ACPI: PCI Interrupt 0000:02:05.1[B] -> GSI 33 (level, low) -> IRQ 24
mptbase: Initiating ioc1 bringup
ioc1: 53C1030: Capabilities={Initiator,Target}
scsi2 : ioc1: LSI53C1030, FwRev=01032300h, Ports=1, MaxQ=255, IRQ=24
PCI: Enabling device 0000:06:02.0 (0000 -> 0003)
ACPI: PCI Interrupt 0000:06:02.0[A] -> GSI 96 (level, low) -> IRQ 25
mptbase: Initiating ioc2 bringup
ioc2: 53C1030: Capabilities={Initiator}
mptbase: Initiating ioc2 recovery
scsi3 : ioc2: LSI53C1030, FwRev=01011800h, Ports=1, MaxQ=222, IRQ=25
  Vendor: IFT       Model: A16U-G1410        Rev: 342J
  Type:   Direct-Access                      ANSI SCSI revision: 05
sdb : very big device. try to use READ CAPACITY(16).
SCSI device sdb: 12494209024 512-byte hdwr sectors (6397035 MB)
SCSI device sdb: drive cache: write back
sdb : very big device. try to use READ CAPACITY(16).
SCSI device sdb: 12494209024 512-byte hdwr sectors (6397035 MB)
SCSI device sdb: drive cache: write back
 sdb: sdb1
Attached scsi disk sdb at scsi3, channel 0, id 3, lun 0
Attached scsi generic sg2 at scsi3, channel 0, id 3, lun 0,  type 0
ACPI: PCI Interrupt 0000:06:02.1[B] -> GSI 97 (level, low) -> IRQ 26
mptbase: Initiating ioc3 bringup
ioc3: 53C1030: Capabilities={Initiator}
mptbase: Initiating ioc3 recovery

What I can't really understand is how a device could fail on a READ CAPACITY 
16 if plugged on an HBA, but work if plugged on another one... 

Best regards,

-- 
Kilian CAVALOTTI                      Administrateur réseaux et systèmes
UPMC / CNRS - LIP6 (C870)
8, rue du Capitaine Scott                          Tel. : 01 44 27 88 54
75015 Paris - France                               Fax. : 01 44 27 70 00
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: aic7xxx support for >2TB volumes?

[Brian King]

Kilian CAVALOTTI wrote:

> What I can't really understand is how a device could fail on a READ CAPACITY 
> 16 if plugged on an HBA, but work if plugged on another one... 

Looks to me like the aic7xxx driver does not change max_cmd_len from
the default of 12, so any 16 byte cdb gets failed back by scsi core.


-- 
Brian King
eServer Storage I/O
IBM Linux Technology Center

Re: aic7xxx support for >2TB volumes?

[Douglas Gilbert]

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

Brian King wrote:
> Kilian CAVALOTTI wrote:
> 
> 
>>What I can't really understand is how a device could fail on a READ CAPACITY 
>>16 if plugged on an HBA, but work if plugged on another one... 
> 
> 
> Looks to me like the aic7xxx driver does not change max_cmd_len from
> the default of 12, so any 16 byte cdb gets failed back by scsi core.

Indeed, the DID_ABORT on the READ CAPACITY(16) suggests
that the command is not making it out to the scsi bus.
Strange that in lk 2.6 the scsi subsystem still defaults
to a maximum of 12 byte scsi commands, unless overridden
by the LLD.

Perhaps Kilian could try the following patch (borrowed from
scsi_debug). The patch is against lk 2.6.15-rc1 but should
by widely applicable (unless the aic7... series really
does have a 12 byte limit). I will report back if this
patch has any adverse impact on "sg_readcap -16" which
should report: "illegal request/invalid command operation
code" on my hardware.

Doug Gilbert



[-- Attachment #2: aic2615rc1big.diff --]
[-- Type: text/x-patch, Size: 922 bytes --]

--- linux/drivers/scsi/aic7xxx/aic7xxx_osm.c	2005-11-15 13:15:26.000000000 +1000
+++ linux/drivers/scsi/aic7xxx/aic7xxx_osm.c2615rc1big	2005-11-19 08:45:08.000000000 +1000
@@ -637,6 +637,9 @@
 	if (bootverbose)
 		sdev_printk(KERN_INFO, sdev, "Slave Configure\n");
 
+        if (sdev->host->max_cmd_len < MAX_COMMAND_SIZE)
+                sdev->host->max_cmd_len = MAX_COMMAND_SIZE;
+
 	ahc_linux_device_queue_depth(sdev);
 
 	/* Initial Domain Validation */
--- linux/drivers/scsi/aic7xxx/aic79xx_osm.c	2005-11-15 13:15:26.000000000 +1000
+++ linux/drivers/scsi/aic7xxx/aic79xx_osm.c2615rc1big	2005-11-19 08:45:29.000000000 +1000
@@ -559,6 +559,9 @@
 	if (bootverbose)
 		sdev_printk(KERN_INFO, sdev, "Slave Configure\n");
 
+        if (sdev->host->max_cmd_len < MAX_COMMAND_SIZE)
+                sdev->host->max_cmd_len = MAX_COMMAND_SIZE;
+
 	ahd_linux_device_queue_depth(sdev);
 
 	/* Initial Domain Validation */

Re: aic7xxx support for >2TB volumes?

[Douglas Gilbert]

Here are the test results for that patch. They indicate
that the READ_CAPACITY(16) is getting to the disk (which
doesn't support it since its capacity is 18 GB).

# sg_readcap -16 -vv /dev/sdb
    read capacity (16) cdb: 9e 10 00 00 00 00 00 00 00 00 00 00 00 20 00 00
READ CAPACITY 16 command error: SCSI status: Check Condition
 Fixed format, current;  Sense key: Illegal Request
 Additional sense: Invalid command operation code
  Field replaceable unit code: 2
  Sense Key Specific: Error in Command byte 0 bit 7
 Raw sense data (in hex):
        70 00 05 00 00 00 00 0a  00 00 00 00 20 00 02 cf
        00 00
plus...: Driver_status=0x08 [DRIVER_SENSE, SUGGEST_OK]
READ CAPACITY (16) not supported

# lsscsi
[0:0:0:0]    disk    SEAGATE  ST318451LW       0003  /dev/sdb
[3:0:0:0]    disk    ATA      ST380013AS       3.18  /dev/sda

# lsscsi -H
[0]    aic7xxx
[1]    sym53c8xx
[2]    sym53c8xx
[3]    sata_sil


# lspci
....
00:0e.0 RAID bus controller: CMD Technology Inc Silicon Image SiI 3112 SATARaid Controller (rev 02)
00:0f.0 SCSI storage controller: Adaptec AIC-7892A U160/m (rev 02)
00:10.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1010 Ultra3 SCSI Adapter (rev 01)
00:10.1 SCSI storage controller: LSI Logic / Symbios Logic 53c1010 Ultra3 SCSI Adapter (rev 01)


BTW That adaptec controller is labelled "APD-29160N MAC".
My PC BIOS doesn't see it, so I can't boot of it, but
linux sees it ok. That makes it useful for testing ...

Doug Gilbert


Douglas Gilbert wrote:
> Brian King wrote:
> 
>>Kilian CAVALOTTI wrote:
>>
>>
>>
>>>What I can't really understand is how a device could fail on a READ CAPACITY 
>>>16 if plugged on an HBA, but work if plugged on another one... 
>>
>>
>>Looks to me like the aic7xxx driver does not change max_cmd_len from
>>the default of 12, so any 16 byte cdb gets failed back by scsi core.
> 
> 
> Indeed, the DID_ABORT on the READ CAPACITY(16) suggests
> that the command is not making it out to the scsi bus.
> Strange that in lk 2.6 the scsi subsystem still defaults
> to a maximum of 12 byte scsi commands, unless overridden
> by the LLD.
> 
> Perhaps Kilian could try the following patch (borrowed from
> scsi_debug). The patch is against lk 2.6.15-rc1 but should
> by widely applicable (unless the aic7... series really
> does have a 12 byte limit). I will report back if this
> patch has any adverse impact on "sg_readcap -16" which
> should report: "illegal request/invalid command operation
> code" on my hardware.
> 
> Doug Gilbert
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> --- linux/drivers/scsi/aic7xxx/aic7xxx_osm.c	2005-11-15 13:15:26.000000000 +1000
> +++ linux/drivers/scsi/aic7xxx/aic7xxx_osm.c2615rc1big	2005-11-19 08:45:08.000000000 +1000
> @@ -637,6 +637,9 @@
>  	if (bootverbose)
>  		sdev_printk(KERN_INFO, sdev, "Slave Configure\n");
>  
> +        if (sdev->host->max_cmd_len < MAX_COMMAND_SIZE)
> +                sdev->host->max_cmd_len = MAX_COMMAND_SIZE;
> +
>  	ahc_linux_device_queue_depth(sdev);
>  
>  	/* Initial Domain Validation */
> --- linux/drivers/scsi/aic7xxx/aic79xx_osm.c	2005-11-15 13:15:26.000000000 +1000
> +++ linux/drivers/scsi/aic7xxx/aic79xx_osm.c2615rc1big	2005-11-19 08:45:29.000000000 +1000
> @@ -559,6 +559,9 @@
>  	if (bootverbose)
>  		sdev_printk(KERN_INFO, sdev, "Slave Configure\n");
>  
> +        if (sdev->host->max_cmd_len < MAX_COMMAND_SIZE)
> +                sdev->host->max_cmd_len = MAX_COMMAND_SIZE;
> +
>  	ahd_linux_device_queue_depth(sdev);
>  
>  	/* Initial Domain Validation */

Re: aic7xxx support for >2TB volumes?

[Kilian CAVALOTTI]

On Saturday 19 November 2005 00:05, Douglas Gilbert wrote:
> Perhaps Kilian could try the following patch (borrowed from
> scsi_debug). The patch is against lk 2.6.15-rc1 but should
> by widely applicable (unless the aic7... series really
> does have a 12 byte limit). 

Well, I just downloaded a fresh 2.6.15-rc1 source tree from kernel.org, and, 
to my surprise, I can't apply your patch.

Talking about linux/drivers/scsi/aic7xxx/aic7xxx_osm.c, the only occurrence of 
	/* Initial Domain Validation */

is at line 736, and it's preceded by:
        if (bootverbose)
                printf("%s: Slave Configure %d\n", ahc_name(ahc), device->id);

        dev = ahc_linux_get_device(ahc, device->channel, device->id,
                                   device->lun);
        dev->scsi_device = device;

        ahc_linux_device_queue_depth(ahc, dev);

instead of:
	if (bootverbose)
                sdev_printk(KERN_INFO, sdev, "Slave Configure\n");
 
	ahc_linux_device_queue_depth(sdev);

in your patch.
So it seems functions have changed between your 2.6.15-rc1, and my 2.6.15-rc1, 
unless I missed something.

I nevertheless tried to apply your patch, but sdev and dev objects seems to be 
different, so I can't attibute host->max_cmd_len to the dev object. As you 
probably already understood, I'm not a kernel developer, and my C knowledge 
is far from being sufficient to handle changes myself. :)

Any hint?

Thanks and regards,

-- 
Kilian CAVALOTTI                      Administrateur réseaux et systèmes
UPMC / CNRS - LIP6 (C870)
8, rue du Capitaine Scott                          Tel. : 01 44 27 88 54
75015 Paris - France                               Fax. : 01 44 27 70 00
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: aic7xxx support for >2TB volumes?

[Kilian CAVALOTTI]

On Saturday 19 November 2005 02:32, Douglas Gilbert wrote:
> Here are the test results for that patch. They indicate
> that the READ_CAPACITY(16) is getting to the disk (which
> doesn't support it since its capacity is 18 GB).

So it seems promising. :)

FYI, I had reports from users who said to be able to use a >2TB external 
storage array (different vendor) with that same 39160 Adaptec HBA.

Here's part of their dmesg:
scsi4 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36
         <Adaptec 3960D Ultra160 SCSI adapter>
         aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
(scsi4:A:0): 160.000MB/s transfers (80.000MHz DT, offset 62, 16bit)
   Type:   Direct-Access                      ANSI SCSI revision: 03
scsi4:A:0:0: Tagged Queuing enabled.  Depth 4
SCSI device sdg: 2686132224 1024-byte hdwr sectors (2750599 MB)
SCSI device sdg: drive cache: write back
  sdg: unknown partition table
Attached scsi disk sdg at scsi4, channel 0, id 0, lun 0

The weird part is that the driver does not even seem to invoke READ 
CAPACITY(16) command, but directly succeed in getting device size.

To sum up my experiences so far:
--------------------|----------------|---------------|--------------------------
Ext. device (>2TB)  | HBA            | Driver	     | Result			
--------------------|----------------|---------------|--------------------------
Infortrend EonStore | Adaptec 39160  | aic7xxx       | READ CAPACITY(16) fails
A16U-G1410          |		     |               |
--------------------|----------------|---------------|--------------------------
Infortrend EonStore | LSI Logic U320 | mptbase       | READ CAPACITY(16)
A16U-G1410          |		     |               | success	
--------------------|----------------|---------------|--------------------------
Proware             | Adaptec 39160  | aic7xxx       | Direct success
--------------------|----------------|---------------|--------------------------

So it seems to come from both the external device and the aic7xxx driver,since 
the EonStore works with another HBA, and the aic7xxx works with another 
device...

It seems quite strange to me, but I hope gurus here will have a rational 
explanation. :)

Best regards,
-- 
Kilian CAVALOTTI                      Administrateur réseaux et systèmes
UPMC / CNRS - LIP6 (C870)
8, rue du Capitaine Scott                          Tel. : 01 44 27 88 54
75015 Paris - France                               Fax. : 01 44 27 70 00
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: aic7xxx support for >2TB volumes?

[Douglas Gilbert]

Kilian CAVALOTTI wrote:
> On Saturday 19 November 2005 02:32, Douglas Gilbert wrote:
> 
>>Here are the test results for that patch. They indicate
>>that the READ_CAPACITY(16) is getting to the disk (which
>>doesn't support it since its capacity is 18 GB).
> 
> 
> So it seems promising. :)
> 
> FYI, I had reports from users who said to be able to use a >2TB external 
> storage array (different vendor) with that same 39160 Adaptec HBA.
> 
> Here's part of their dmesg:
> scsi4 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36
>          <Adaptec 3960D Ultra160 SCSI adapter>
>          aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
> (scsi4:A:0): 160.000MB/s transfers (80.000MHz DT, offset 62, 16bit)
>    Type:   Direct-Access                      ANSI SCSI revision: 03
> scsi4:A:0:0: Tagged Queuing enabled.  Depth 4
> SCSI device sdg: 2686132224 1024-byte hdwr sectors (2750599 MB)

The READ CAPACITY (10) command can report a maximum size
of ((2**32 - 1) * blk_size) bytes. As shown above, /dev/sdg
is reporting a block (sector) size of 1024 rather than
the more normal 512 bytes that most production SCSI disks
use. With a 1024 byte block size, just under 4 TB can be
represented before READ CAPACITY (16) is needed.

> SCSI device sdg: drive cache: write back
>   sdg: unknown partition table
> Attached scsi disk sdg at scsi4, channel 0, id 0, lun 0
> 
> The weird part is that the driver does not even seem to invoke READ 
> CAPACITY(16) command, but directly succeed in getting device size.
> 
> To sum up my experiences so far:
> --------------------|----------------|---------------|--------------------------
> Ext. device (>2TB)  | HBA            | Driver	     | Result			
> --------------------|----------------|---------------|--------------------------
> Infortrend EonStore | Adaptec 39160  | aic7xxx       | READ CAPACITY(16) fails
> A16U-G1410          |		     |               |
> --------------------|----------------|---------------|--------------------------
> Infortrend EonStore | LSI Logic U320 | mptbase       | READ CAPACITY(16)
> A16U-G1410          |		     |               | success	
> --------------------|----------------|---------------|--------------------------
> Proware             | Adaptec 39160  | aic7xxx       | Direct success
> --------------------|----------------|---------------|--------------------------
> 
> So it seems to come from both the external device and the aic7xxx driver,since 
> the EonStore works with another HBA, and the aic7xxx works with another 
> device...
> 
> It seems quite strange to me, but I hope gurus here will have a rational 
> explanation. :)

I rechecked my patch and its seems correct for lk 2.6.15-rc1 .
Does 'head <kernel_src_dir>/Makefile' confirm the kernel
source version?

It is easy to apply by hand to drivers/scsi/aic7xxx/aic7xxx_osm.c
and drivers/scsi/aic7xxx/aic79xx_osm.c . Before the patch my
ahc_linux_slave_configure function starts like this:

static int
ahc_linux_slave_configure(struct scsi_device *sdev)
{
        struct  ahc_softc *ahc;

        ahc = *((struct ahc_softc **)sdev->host->hostdata);

        if (bootverbose)
                sdev_printk(KERN_INFO, sdev, "Slave Configure\n");

        ahc_linux_device_queue_depth(sdev);
.......

after the patch it looks like this:

static int
ahc_linux_slave_configure(struct scsi_device *sdev)
{
        struct  ahc_softc *ahc;

        ahc = *((struct ahc_softc **)sdev->host->hostdata);

        if (bootverbose)
                sdev_printk(KERN_INFO, sdev, "Slave Configure\n");

        if (sdev->host->max_cmd_len < MAX_COMMAND_SIZE)
                sdev->host->max_cmd_len = MAX_COMMAND_SIZE;

        ahc_linux_device_queue_depth(sdev);
.....

Those two extra line can probably be added to any
version of those drivers found in the lk 2.6 series.
The "sdev" may need to change to the appropriate
name.

Doug Gilbert

Re: aic7xxx support for >2TB volumes?

[Brian King]

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

Douglas Gilbert wrote:
> Perhaps Kilian could try the following patch (borrowed from
> scsi_debug). The patch is against lk 2.6.15-rc1 but should
> by widely applicable (unless the aic7... series really
> does have a 12 byte limit). I will report back if this
> patch has any adverse impact on "sg_readcap -16" which
> should report: "illegal request/invalid command operation
> code" on my hardware.

I don't think slave_configure is the right place to be modifying
a scsi_host attribute. How about this patch instead? Only compile
tested.



-- 
Brian King
eServer Storage I/O
IBM Linux Technology Center

[-- Attachment #2: aic7xxx_max_cmd_len.patch --]
[-- Type: text/x-patch, Size: 2603 bytes --]



Signed-off-by: Brian King <brking@us.ibm.com>
---

 drivers/scsi/aic7xxx/aic79xx.h     |    2 ++
 drivers/scsi/aic7xxx/aic79xx_osm.c |    1 +
 drivers/scsi/aic7xxx/aic7xxx.h     |    2 ++
 drivers/scsi/aic7xxx/aic7xxx_osm.c |    1 +
 4 files changed, 6 insertions(+)

diff -puN drivers/scsi/aic7xxx/aic79xx.h~aic7xxx_max_cmd_len drivers/scsi/aic7xxx/aic79xx.h
--- linux-2.6/drivers/scsi/aic7xxx/aic79xx.h~aic7xxx_max_cmd_len	2005-11-20 22:22:28.000000000 -0600
+++ linux-2.6-bjking1/drivers/scsi/aic7xxx/aic79xx.h	2005-11-20 22:22:28.000000000 -0600
@@ -201,6 +201,8 @@ do {								\
 /* Reset line assertion time in us */
 #define AHD_BUSRESET_DELAY	25
 
+#define AHD_MAX_CMD_LEN	16
+
 /******************* Chip Characteristics/Operating Settings  *****************/
 /*
  * Chip Type
diff -puN drivers/scsi/aic7xxx/aic79xx_osm.c~aic7xxx_max_cmd_len drivers/scsi/aic7xxx/aic79xx_osm.c
--- linux-2.6/drivers/scsi/aic7xxx/aic79xx_osm.c~aic7xxx_max_cmd_len	2005-11-20 22:22:28.000000000 -0600
+++ linux-2.6-bjking1/drivers/scsi/aic7xxx/aic79xx_osm.c	2005-11-20 22:22:28.000000000 -0600
@@ -1081,6 +1081,7 @@ ahd_linux_register_host(struct ahd_softc
 	host->max_id = (ahd->features & AHD_WIDE) ? 16 : 8;
 	host->max_lun = AHD_NUM_LUNS;
 	host->max_channel = 0;
+	host->max_cmd_len = AHD_MAX_CMD_LEN;
 	host->sg_tablesize = AHD_NSEG;
 	ahd_set_unit(ahd, ahd_linux_unit++);
 	sprintf(buf, "scsi%d", host->host_no);
diff -puN drivers/scsi/aic7xxx/aic7xxx.h~aic7xxx_max_cmd_len drivers/scsi/aic7xxx/aic7xxx.h
--- linux-2.6/drivers/scsi/aic7xxx/aic7xxx.h~aic7xxx_max_cmd_len	2005-11-20 22:22:28.000000000 -0600
+++ linux-2.6-bjking1/drivers/scsi/aic7xxx/aic7xxx.h	2005-11-20 22:22:28.000000000 -0600
@@ -181,6 +181,8 @@ struct seeprom_descriptor;
 /* Reset line assertion time in us */
 #define AHC_BUSRESET_DELAY	25
 
+#define AHC_MAX_CMD_LEN		16
+
 /******************* Chip Characteristics/Operating Settings  *****************/
 /*
  * Chip Type
diff -puN drivers/scsi/aic7xxx/aic7xxx_osm.c~aic7xxx_max_cmd_len drivers/scsi/aic7xxx/aic7xxx_osm.c
--- linux-2.6/drivers/scsi/aic7xxx/aic7xxx_osm.c~aic7xxx_max_cmd_len	2005-11-20 22:22:28.000000000 -0600
+++ linux-2.6-bjking1/drivers/scsi/aic7xxx/aic7xxx_osm.c	2005-11-20 22:22:28.000000000 -0600
@@ -1082,6 +1082,7 @@ ahc_linux_register_host(struct ahc_softc
 	host->max_id = (ahc->features & AHC_WIDE) ? 16 : 8;
 	host->max_lun = AHC_NUM_LUNS;
 	host->max_channel = (ahc->features & AHC_TWIN) ? 1 : 0;
+	host->max_cmd_len = AHC_MAX_CMD_LEN;
 	host->sg_tablesize = AHC_NSEG;
 	ahc_set_unit(ahc, ahc_linux_unit++);
 	sprintf(buf, "scsi%d", host->host_no);
_

Re: aic7xxx support for >2TB volumes?

[Kilian CAVALOTTI]

On Monday 21 November 2005 05:53, you wrote:
> I don't think slave_configure is the right place to be modifying
> a scsi_host attribute. How about this patch instead? Only compile
> tested.

Patch applied on 2.6.15-rc2, and gives no better result:

# sg_readcap -16 -vv /dev/sdb
    read capacity (16) cdb: 9e 10 00 00 00 00 00 00 00 00 00 00 00 20 00 00
READ CAPACITY 16 command error: Host_status=0x0b [DID_SOFT_ERROR]

dmesg output:
--------------------------------------------------------------------------
ACPI: PCI Interrupt 0000:05:04.0[A] -> GSI 106 (level, low) -> IRQ 25
scsi3 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0
        <Adaptec 3960D Ultra160 SCSI adapter>
        aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs

  Vendor: IFT       Model: A16U-G1410        Rev: 342J
  Type:   Direct-Access                      ANSI SCSI revision: 05
scsi3:A:4:0: Tagged Queuing enabled.  Depth 32
 target3:0:4: Beginning Domain Validation
 target3:0:4: wide asynchronous.
 target3:0:4: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 127)
 target3:0:4: Ending Domain Validation
sdc : very big device. try to use READ CAPACITY(16).
(scsi3:A:4:0): No or incomplete CDB sent to device.
(scsi3:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
(scsi3:A:4:0): Abort Tag Message Sent
(scsi3:A:4:0): SCB 3 - Abort Tag Completed.
(scsi3:A:4:0): No or incomplete CDB sent to device.
(scsi3:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
(scsi3:A:4:0): Abort Tag Message Sent
(scsi3:A:4:0): SCB 2 - Abort Tag Completed.
(scsi3:A:4:0): No or incomplete CDB sent to device.
(scsi3:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
(scsi3:A:4:0): Abort Tag Message Sent
(scsi3:A:4:0): SCB 3 - Abort Tag Completed.
(scsi3:A:4:0): No or incomplete CDB sent to device.
(scsi3:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
(scsi3:A:4:0): Abort Tag Message Sent
(scsi3:A:4:0): SCB 2 - Abort Tag Completed.
(scsi3:A:4:0): No or incomplete CDB sent to device.
(scsi3:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
(scsi3:A:4:0): Abort Tag Message Sent
(scsi3:A:4:0): SCB 3 - Abort Tag Completed.
(scsi3:A:4:0): No or incomplete CDB sent to device.
(scsi3:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
(scsi3:A:4:0): Abort Tag Message Sent
(scsi3:A:4:0): SCB 2 - Abort Tag Completed.
(scsi3:A:4:0): No or incomplete CDB sent to device.
(scsi3:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
(scsi3:A:4:0): Abort Tag Message Sent
(scsi3:A:4:0): SCB 3 - Abort Tag Completed.
(scsi3:A:4:0): No or incomplete CDB sent to device.
(scsi3:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
(scsi3:A:4:0): Abort Tag Message Sent
(scsi3:A:4:0): SCB 2 - Abort Tag Completed.
(scsi3:A:4:0): No or incomplete CDB sent to device.
(scsi3:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
(scsi3:A:4:0): Abort Tag Message Sent
(scsi3:A:4:0): SCB 3 - Abort Tag Completed.
sdc : READ CAPACITY(16) failed.
sdc : status=0, message=00, host=7, driver=00
sdc : use 0xffffffff as device size
SCSI device sdc: 4294967296 512-byte hdwr sectors (2199023 MB)
SCSI device sdc: drive cache: write back
sdc : very big device. try to use READ CAPACITY(16).
(scsi3:A:4:0): No or incomplete CDB sent to device.
(scsi3:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
(scsi3:A:4:0): Abort Tag Message Sent
(scsi3:A:4:0): SCB 2 - Abort Tag Completed.
(scsi3:A:4:0): No or incomplete CDB sent to device.
(scsi3:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
(scsi3:A:4:0): Abort Tag Message Sent
(scsi3:A:4:0): SCB 3 - Abort Tag Completed.
(scsi3:A:4:0): No or incomplete CDB sent to device.
(scsi3:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
(scsi3:A:4:0): Abort Tag Message Sent
(scsi3:A:4:0): SCB 2 - Abort Tag Completed.
(scsi3:A:4:0): No or incomplete CDB sent to device.
(scsi3:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
(scsi3:A:4:0): Abort Tag Message Sent
(scsi3:A:4:0): SCB 3 - Abort Tag Completed.
(scsi3:A:4:0): No or incomplete CDB sent to device.
(scsi3:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
(scsi3:A:4:0): Abort Tag Message Sent
(scsi3:A:4:0): SCB 2 - Abort Tag Completed.
(scsi3:A:4:0): No or incomplete CDB sent to device.
(scsi3:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
(scsi3:A:4:0): Abort Tag Message Sent
(scsi3:A:4:0): SCB 3 - Abort Tag Completed.
(scsi3:A:4:0): No or incomplete CDB sent to device.
(scsi3:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
(scsi3:A:4:0): Abort Tag Message Sent
(scsi3:A:4:0): SCB 2 - Abort Tag Completed.
(scsi3:A:4:0): No or incomplete CDB sent to device.
(scsi3:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
(scsi3:A:4:0): Abort Tag Message Sent
(scsi3:A:4:0): SCB 3 - Abort Tag Completed.
(scsi3:A:4:0): No or incomplete CDB sent to device.
(scsi3:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
(scsi3:A:4:0): Abort Tag Message Sent
(scsi3:A:4:0): SCB 2 - Abort Tag Completed.
sdc : READ CAPACITY(16) failed.
sdc : status=0, message=00, host=7, driver=00
sdc : use 0xffffffff as device size
SCSI device sdc: 4294967296 512-byte hdwr sectors (2199023 MB)
SCSI device sdc: drive cache: write back
 sdc: sdc1
sd 3:0:4:0: Attached scsi disk sdc
sd 3:0:4:0: Attached scsi generic sg3 type 0
--------------------------------------------------------------------------

Does this mean the HBA has an hardware limit?

Thanks and regards,

-- 
Kilian CAVALOTTI                      Administrateur réseaux et systèmes
UPMC / CNRS - LIP6 (C870)
8, rue du Capitaine Scott                          Tel. : 01 44 27 88 54
75015 Paris - France                               Fax. : 01 44 27 70 00
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: aic7xxx support for >2TB volumes?

[Kilian CAVALOTTI]

On Sunday 20 November 2005 02:33, Douglas Gilbert wrote:
> The READ CAPACITY (10) command can report a maximum size
> of ((2**32 - 1) * blk_size) bytes. As shown above, /dev/sdg
> is reporting a block (sector) size of 1024 rather than
> the more normal 512 bytes that most production SCSI disks
> use. With a 1024 byte block size, just under 4 TB can be
> represented before READ CAPACITY (16) is needed.

Understood.

> I rechecked my patch and its seems correct for lk 2.6.15-rc1 .
> Does 'head <kernel_src_dir>/Makefile' confirm the kernel
> source version?

# head /usr/src/linux-2.6.15-rc2/Makefile
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 15
EXTRAVERSION =-rc2
NAME=Affluent Albatross

> It is easy to apply by hand to drivers/scsi/aic7xxx/aic7xxx_osm.c
> and drivers/scsi/aic7xxx/aic79xx_osm.c . Before the patch my
> ahc_linux_slave_configure function starts like this:

Actually, what confused me is that aic79xx_osm.c has no 
ahc_linux_slave_configure function. Whatever, as I only use aic7xxx U160 
adapter, I modified aic7xxx_osm.c and gave it a try. But with no luck:

# sg_readcap -16 -vv /dev/sdc
    read capacity (16) cdb: 9e 10 00 00 00 00 00 00 00 00 00 00 00 20 00 00
READ CAPACITY 16 command error: Host_status=0x07 [DID_ERROR]

dmesg output:
--------------------------------------------------------------------------
ACPI: PCI Interrupt 0000:05:04.0[A] -> GSI 106 (level, low) -> IRQ 25
scsi5 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0
        <Adaptec 3960D Ultra160 SCSI adapter>
        aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs

  Vendor: IFT       Model: A16U-G1410        Rev: 342J
  Type:   Direct-Access                      ANSI SCSI revision: 05
scsi5:A:4:0: Tagged Queuing enabled.  Depth 32
 target5:0:4: Beginning Domain Validation
 target5:0:4: wide asynchronous.
 target5:0:4: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 127)
 target5:0:4: Ending Domain Validation
sdc : very big device. try to use READ CAPACITY(16).
(scsi5:A:4:0): No or incomplete CDB sent to device.
(scsi5:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
(scsi5:A:4:0): Abort Tag Message Sent
(scsi5:A:4:0): SCB 3 - Abort Tag Completed.
(scsi5:A:4:0): No or incomplete CDB sent to device.
(scsi5:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
(scsi5:A:4:0): Abort Tag Message Sent
(scsi5:A:4:0): SCB 2 - Abort Tag Completed.
(scsi5:A:4:0): No or incomplete CDB sent to device.
(scsi5:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
(scsi5:A:4:0): Abort Tag Message Sent
(scsi5:A:4:0): SCB 3 - Abort Tag Completed.
(scsi5:A:4:0): No or incomplete CDB sent to device.
(scsi5:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
(scsi5:A:4:0): Abort Tag Message Sent
(scsi5:A:4:0): SCB 2 - Abort Tag Completed.
(scsi5:A:4:0): No or incomplete CDB sent to device.
(scsi5:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
(scsi5:A:4:0): Abort Tag Message Sent
(scsi5:A:4:0): SCB 3 - Abort Tag Completed.
(scsi5:A:4:0): No or incomplete CDB sent to device.
(scsi5:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
(scsi5:A:4:0): Abort Tag Message Sent
(scsi5:A:4:0): SCB 2 - Abort Tag Completed.
(scsi5:A:4:0): No or incomplete CDB sent to device.
(scsi5:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
(scsi5:A:4:0): Abort Tag Message Sent
(scsi5:A:4:0): SCB 3 - Abort Tag Completed.
(scsi5:A:4:0): No or incomplete CDB sent to device.
(scsi5:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
(scsi5:A:4:0): Abort Tag Message Sent
(scsi5:A:4:0): SCB 2 - Abort Tag Completed.
(scsi5:A:4:0): No or incomplete CDB sent to device.
(scsi5:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
(scsi5:A:4:0): Abort Tag Message Sent
(scsi5:A:4:0): SCB 3 - Abort Tag Completed.
sdc : READ CAPACITY(16) failed.
sdc : status=0, message=00, host=7, driver=00
sdc : use 0xffffffff as device size
SCSI device sdc: 4294967296 512-byte hdwr sectors (2199023 MB)
SCSI device sdc: drive cache: write back
sdc : very big device. try to use READ CAPACITY(16).
(scsi5:A:4:0): No or incomplete CDB sent to device.
(scsi5:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
(scsi5:A:4:0): Abort Tag Message Sent
(scsi5:A:4:0): SCB 2 - Abort Tag Completed.
(scsi5:A:4:0): No or incomplete CDB sent to device.
(scsi5:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
(scsi5:A:4:0): Abort Tag Message Sent
(scsi5:A:4:0): SCB 3 - Abort Tag Completed.
(scsi5:A:4:0): No or incomplete CDB sent to device.
(scsi5:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
(scsi5:A:4:0): Abort Tag Message Sent
(scsi5:A:4:0): SCB 2 - Abort Tag Completed.
(scsi5:A:4:0): No or incomplete CDB sent to device.
(scsi5:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
(scsi5:A:4:0): Abort Tag Message Sent
(scsi5:A:4:0): SCB 3 - Abort Tag Completed.
(scsi5:A:4:0): No or incomplete CDB sent to device.
(scsi5:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
(scsi5:A:4:0): Abort Tag Message Sent
(scsi5:A:4:0): SCB 2 - Abort Tag Completed.
(scsi5:A:4:0): No or incomplete CDB sent to device.
(scsi5:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
(scsi5:A:4:0): Abort Tag Message Sent
(scsi5:A:4:0): SCB 3 - Abort Tag Completed.
(scsi5:A:4:0): No or incomplete CDB sent to device.
(scsi5:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
(scsi5:A:4:0): Abort Tag Message Sent
(scsi5:A:4:0): SCB 2 - Abort Tag Completed.
(scsi5:A:4:0): No or incomplete CDB sent to device.
(scsi5:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
(scsi5:A:4:0): Abort Tag Message Sent
(scsi5:A:4:0): SCB 3 - Abort Tag Completed.
(scsi5:A:4:0): No or incomplete CDB sent to device.
(scsi5:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
(scsi5:A:4:0): Abort Tag Message Sent
(scsi5:A:4:0): SCB 2 - Abort Tag Completed.
sdc : READ CAPACITY(16) failed.
sdc : status=0, message=00, host=7, driver=00
sdc : use 0xffffffff as device size
SCSI device sdc: 4294967296 512-byte hdwr sectors (2199023 MB)
SCSI device sdc: drive cache: write back
 sdc: sdc1
sd 5:0:4:0: Attached scsi disk sdc
sd 5:0:4:0: Attached scsi generic sg3 type 0
--------------------------------------------------------------------------

What's next? Throw the adapter out of the window? ;)

Thanks and regards,

-- 
Kilian CAVALOTTI                      Administrateur réseaux et systèmes
UPMC / CNRS - LIP6 (C870)
8, rue du Capitaine Scott                          Tel. : 01 44 27 88 54
75015 Paris - France                               Fax. : 01 44 27 70 00
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: aic7xxx support for >2TB volumes?

[Brian King]

Kilian CAVALOTTI wrote:
> On Monday 21 November 2005 05:53, you wrote:
> 
>>I don't think slave_configure is the right place to be modifying
>>a scsi_host attribute. How about this patch instead? Only compile
>>tested.
> 
> 
> Patch applied on 2.6.15-rc2, and gives no better result:
> 
> # sg_readcap -16 -vv /dev/sdb
>     read capacity (16) cdb: 9e 10 00 00 00 00 00 00 00 00 00 00 00 20 00 00
> READ CAPACITY 16 command error: Host_status=0x0b [DID_SOFT_ERROR]
> 
> dmesg output:
> --------------------------------------------------------------------------
> ACPI: PCI Interrupt 0000:05:04.0[A] -> GSI 106 (level, low) -> IRQ 25
> scsi3 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0
>         <Adaptec 3960D Ultra160 SCSI adapter>
>         aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
> 
>   Vendor: IFT       Model: A16U-G1410        Rev: 342J
>   Type:   Direct-Access                      ANSI SCSI revision: 05
> scsi3:A:4:0: Tagged Queuing enabled.  Depth 32
>  target3:0:4: Beginning Domain Validation
>  target3:0:4: wide asynchronous.
>  target3:0:4: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 127)
>  target3:0:4: Ending Domain Validation
> sdc : very big device. try to use READ CAPACITY(16).
> (scsi3:A:4:0): No or incomplete CDB sent to device.
> (scsi3:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
> (scsi3:A:4:0): Abort Tag Message Sent
> (scsi3:A:4:0): SCB 3 - Abort Tag Completed.
> (scsi3:A:4:0): No or incomplete CDB sent to device.
> (scsi3:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
> (scsi3:A:4:0): Abort Tag Message Sent
> (scsi3:A:4:0): SCB 2 - Abort Tag Completed.
> (scsi3:A:4:0): No or incomplete CDB sent to device.
> (scsi3:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
> (scsi3:A:4:0): Abort Tag Message Sent
> (scsi3:A:4:0): SCB 3 - Abort Tag Completed.
> (scsi3:A:4:0): No or incomplete CDB sent to device.
> (scsi3:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
> (scsi3:A:4:0): Abort Tag Message Sent
> (scsi3:A:4:0): SCB 2 - Abort Tag Completed.
> (scsi3:A:4:0): No or incomplete CDB sent to device.
> (scsi3:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
> (scsi3:A:4:0): Abort Tag Message Sent
> (scsi3:A:4:0): SCB 3 - Abort Tag Completed.
> (scsi3:A:4:0): No or incomplete CDB sent to device.
> (scsi3:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
> (scsi3:A:4:0): Abort Tag Message Sent
> (scsi3:A:4:0): SCB 2 - Abort Tag Completed.
> (scsi3:A:4:0): No or incomplete CDB sent to device.
> (scsi3:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
> (scsi3:A:4:0): Abort Tag Message Sent
> (scsi3:A:4:0): SCB 3 - Abort Tag Completed.
> (scsi3:A:4:0): No or incomplete CDB sent to device.
> (scsi3:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
> (scsi3:A:4:0): Abort Tag Message Sent
> (scsi3:A:4:0): SCB 2 - Abort Tag Completed.
> (scsi3:A:4:0): No or incomplete CDB sent to device.
> (scsi3:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
> (scsi3:A:4:0): Abort Tag Message Sent
> (scsi3:A:4:0): SCB 3 - Abort Tag Completed.
> sdc : READ CAPACITY(16) failed.
> sdc : status=0, message=00, host=7, driver=00
> sdc : use 0xffffffff as device size
> SCSI device sdc: 4294967296 512-byte hdwr sectors (2199023 MB)
> SCSI device sdc: drive cache: write back
> sdc : very big device. try to use READ CAPACITY(16).
> (scsi3:A:4:0): No or incomplete CDB sent to device.
> (scsi3:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
> (scsi3:A:4:0): Abort Tag Message Sent
> (scsi3:A:4:0): SCB 2 - Abort Tag Completed.
> (scsi3:A:4:0): No or incomplete CDB sent to device.
> (scsi3:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
> (scsi3:A:4:0): Abort Tag Message Sent
> (scsi3:A:4:0): SCB 3 - Abort Tag Completed.
> (scsi3:A:4:0): No or incomplete CDB sent to device.
> (scsi3:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
> (scsi3:A:4:0): Abort Tag Message Sent
> (scsi3:A:4:0): SCB 2 - Abort Tag Completed.
> (scsi3:A:4:0): No or incomplete CDB sent to device.
> (scsi3:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
> (scsi3:A:4:0): Abort Tag Message Sent
> (scsi3:A:4:0): SCB 3 - Abort Tag Completed.
> (scsi3:A:4:0): No or incomplete CDB sent to device.
> (scsi3:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
> (scsi3:A:4:0): Abort Tag Message Sent
> (scsi3:A:4:0): SCB 2 - Abort Tag Completed.
> (scsi3:A:4:0): No or incomplete CDB sent to device.
> (scsi3:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
> (scsi3:A:4:0): Abort Tag Message Sent
> (scsi3:A:4:0): SCB 3 - Abort Tag Completed.
> (scsi3:A:4:0): No or incomplete CDB sent to device.
> (scsi3:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
> (scsi3:A:4:0): Abort Tag Message Sent
> (scsi3:A:4:0): SCB 2 - Abort Tag Completed.
> (scsi3:A:4:0): No or incomplete CDB sent to device.
> (scsi3:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
> (scsi3:A:4:0): Abort Tag Message Sent
> (scsi3:A:4:0): SCB 3 - Abort Tag Completed.
> (scsi3:A:4:0): No or incomplete CDB sent to device.
> (scsi3:A:4:0): Protocol violation in Message-in phase.  Attempting to abort.
> (scsi3:A:4:0): Abort Tag Message Sent
> (scsi3:A:4:0): SCB 2 - Abort Tag Completed.
> sdc : READ CAPACITY(16) failed.
> sdc : status=0, message=00, host=7, driver=00
> sdc : use 0xffffffff as device size
> SCSI device sdc: 4294967296 512-byte hdwr sectors (2199023 MB)
> SCSI device sdc: drive cache: write back
>  sdc: sdc1
> sd 3:0:4:0: Attached scsi disk sdc
> sd 3:0:4:0: Attached scsi generic sg3 type 0
> --------------------------------------------------------------------------
> 
> Does this mean the HBA has an hardware limit?

Quite possibly. Looking at ahc_linux_run_command in aic7xxx_osm.c it appears
that commands with a cdb length of > 12 are sent to the adapter in a different way.
Perhaps this method does not work on the card you have. 


-- 
Brian King
eServer Storage I/O
IBM Linux Technology Center

Re: aic7xxx support for >2TB volumes?

[Kilian CAVALOTTI]

On Monday 21 November 2005 15:48, Brian King wrote:
> Quite possibly. Looking at ahc_linux_run_command in aic7xxx_osm.c it
> appears that commands with a cdb length of > 12 are sent to the adapter in
> a different way. 

Do you mean: ?
        hscb->cdb_len = cmd->cmd_len;
        if (hscb->cdb_len <= 12) {
                memcpy(hscb->shared_data.cdb, cmd->cmnd, hscb->cdb_len);
        } else {
                memcpy(hscb->cdb32, cmd->cmnd, hscb->cdb_len);
                scb->flags |= SCB_CDB32_PTR;
        }

> Perhaps this method does not work on the card you have. 

Isn't there a way to determine if the HBA has an hardware limitation, or the 
size of the max command length it accepts?

Regards,

-- 
Kilian CAVALOTTI                      Administrateur réseaux et systèmes
UPMC / CNRS - LIP6 (C870)
8, rue du Capitaine Scott                          Tel. : 01 44 27 88 54
75015 Paris - France                               Fax. : 01 44 27 70 00
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: aic7xxx support for >2TB volumes?

[Brian King]

Kilian CAVALOTTI wrote:
> On Monday 21 November 2005 15:48, Brian King wrote:
> 
>>Quite possibly. Looking at ahc_linux_run_command in aic7xxx_osm.c it
>>appears that commands with a cdb length of > 12 are sent to the adapter in
>>a different way. 
> 
> 
> Do you mean: ?
>         hscb->cdb_len = cmd->cmd_len;
>         if (hscb->cdb_len <= 12) {
>                 memcpy(hscb->shared_data.cdb, cmd->cmnd, hscb->cdb_len);
>         } else {
>                 memcpy(hscb->cdb32, cmd->cmnd, hscb->cdb_len);
>                 scb->flags |= SCB_CDB32_PTR;
>         }

Yes.

>>Perhaps this method does not work on the card you have. 
> 
> 
> Isn't there a way to determine if the HBA has an hardware limitation, or the 
> size of the max command length it accepts?

I've never seen a hardware spec for these adapters, so I can't really comment.
Hopefully someone else on the list can help on this one...


-- 
Brian King
eServer Storage I/O
IBM Linux Technology Center