aix7xxx driver 5.2.4/5.2.0 vs. 6.2.5 with onboard aic7896/97 Ultra2 controller

aix7xxx driver 5.2.4/5.2.0 vs. 6.2.5 with onboard aic7896/97 Ultra2 controller

[Dimitrios P. Bouras]

Hello all,

I have recently switched from kernel version 2.2.20 to 2.4.18. The
problem I've had is with the new aic7xxx driver. In short, it seems
to have the same (possibly reasonable but, in effect, undesirable)
behavior as the SCSI-BIOS for the onboard aic7896/97 Ultra2 controller
on my Gigabyte GA-6BXDU motherboard: it fails to enable the full 80
mb/s transfer rate on my 2 hard-drives, as well as 20 mb/s and 10 mb/s
on my cdrom and cd recorder respectively. The old driver works like a
charm. Similarly the older Adaptec BIOS detected all four devices
correctly, but I had to upgrade when I installed a Coppermine processor.
I am currently forced to use the old driver under 2.4.18, but would like
to resolve this problem.

Driver initialization output messages follow.

-----------------------------
The old aic7xxx driver says:
-----------------------------

SCSI subsystem driver Revision: 1.00
(scsi0) <Adaptec AIC-7896/7 Ultra2 SCSI host adapter> found at PCI 0/12/0
(scsi0) Wide Channel A, SCSI ID=7, 32/255 SCBs
(scsi0) Downloading sequencer code... 393 instructions downloaded
(scsi1) <Adaptec AIC-7896/7 Ultra2 SCSI host adapter> found at PCI 0/12/1
(scsi1) Wide Channel B, SCSI ID=7, 32/255 SCBs
(scsi1) Downloading sequencer code... 393 instructions downloaded
scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.4/5.2.0
        <Adaptec AIC-7896/7 Ultra2 SCSI host adapter>
scsi1 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.4/5.2.0
        <Adaptec AIC-7896/7 Ultra2 SCSI host adapter>
   Vendor: SEAGATE   Model: ST39175LW         Rev: 0001
   Type:   Direct-Access                      ANSI SCSI revision: 02
   Vendor: IBM       Model: DPSS-309170N      Rev: S96H
   Type:   Direct-Access                      ANSI SCSI revision: 03
   Vendor: PLEXTOR   Model: CD-ROM PX-40TS    Rev: 1.00
   Type:   CD-ROM                             ANSI SCSI revision: 02
   Vendor: PLEXTOR   Model: CD-R   PX-R820T   Rev: 1.03
   Type:   CD-ROM                             ANSI SCSI revision: 02
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
Attached scsi disk sdb at scsi0, channel 0, id 3, lun 0
(scsi0:0:0:0) Synchronous at 80.0 Mbyte/sec, offset 15.
SCSI device sda: 17783240 512-byte hdwr sectors (9105 MB)
  sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 sda8 >
(scsi0:0:3:0) Synchronous at 80.0 Mbyte/sec, offset 63.
SCSI device sdb: 17916240 512-byte hdwr sectors (9173 MB)
  sdb: sdb1 sdb2
Attached scsi CD-ROM sr0 at scsi1, channel 0, id 3, lun 0
Attached scsi CD-ROM sr1 at scsi1, channel 0, id 4, lun 0
(scsi1:0:3:0) Synchronous at 20.0 Mbyte/sec, offset 15.
sr0: scsi-1 drive
Uniform CD-ROM driver Revision: 3.12
(scsi1:0:4:0) Synchronous at 10.0 Mbyte/sec, offset 8.
sr1: scsi3-mmc drive: 20x/20x writer cd/rw xa/form2 cdda tray

------------------------------------------------
The new aic7xxx driver says (verbose messages):
------------------------------------------------

<6>SCSI subsystem driver Revision: 1.00
<6>PCI: Found IRQ 11 for device 00:0c.0
<6>PCI: Sharing IRQ 11 with 00:0c.1
<4>ahc_pci:0:12:0: Reading SEEPROM...done.
<4>ahc_pci:0:12:0: Manual LVD Termination
<4>ahc_pci:0:12:0: BIOS eeprom is present
<4>ahc_pci:0:12:0: Secondary High byte termination Enabled
<4>ahc_pci:0:12:0: Secondary Low byte termination Enabled
<4>ahc_pci:0:12:0: Primary Low Byte termination Enabled
<4>ahc_pci:0:12:0: Primary High Byte termination Enabled
<4>ahc_pci:0:12:0: Downloading Sequencer Program... 416 instructions downloaded
<6>PCI: Found IRQ 11 for device 00:0c.1
<6>PCI: Sharing IRQ 11 with 00:0c.0
<4>ahc_pci:0:12:1: Reading SEEPROM...done.
<4>ahc_pci:0:12:1: Manual LVD Termination
<4>ahc_pci:0:12:1: BIOS eeprom is present
<4>ahc_pci:0:12:1: Secondary High byte termination Enabled
<4>ahc_pci:0:12:1: Secondary Low byte termination Enabled
<4>ahc_pci:0:12:1: Primary Low Byte termination Enabled
<4>ahc_pci:0:12:1: Primary High Byte termination Enabled
<4>ahc_pci:0:12:1: Downloading Sequencer Program... 416 instructions downloaded
<6>scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.5
<4>        <Adaptec aic7896/97 Ultra2 SCSI adapter>
<4>        aic7896/97: Ultra2 Wide Channel A, SCSI Id=7, 32/253 SCBs
<4>
<6>scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.5
<4>        <Adaptec aic7896/97 Ultra2 SCSI adapter>
<4>        aic7896/97: Ultra2 Wide Channel B, SCSI Id=7, 32/253 SCBs
<4>
<4>  Vendor: SEAGATE   Model: ST39175LW         Rev: 0001
<4>  Type:   Direct-Access                      ANSI SCSI revision: 02
<4>  Vendor: IBM       Model: DPSS-309170N      Rev: S96H
<4>  Type:   Direct-Access                      ANSI SCSI revision: 03
<4>(scsi0:A:0): 3.300MB/s transfers
<4>scsi0:A:0:0: Tagged Queuing enabled.  Depth 253
<4>(scsi0:A:3): 3.300MB/s transfers
<4>scsi0:A:3:0: Tagged Queuing enabled.  Depth 253
<4>  Vendor: PLEXTOR   Model: CD-ROM PX-40TS    Rev: 1.00
<4>  Type:   CD-ROM                             ANSI SCSI revision: 02
<4>  Vendor: PLEXTOR   Model: CD-R   PX-R820T   Rev: 1.03
<4>  Type:   CD-ROM                             ANSI SCSI revision: 02
<4>Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
<4>Attached scsi disk sdb at scsi0, channel 0, id 3, lun 0
<4>(scsi0:A:0:0): Sending WDTR 1
<4>(scsi0:A:0:0): Received WDTR 1 filtered to 1
<4>(scsi0:A:0): 6.600MB/s transfers (16bit)
<4>scsi0: target 0 using 16bit transfers
<4>(scsi0:A:0:0): Sending SDTR period 2b, offset 7f
<4>(scsi0:A:0:0): Received SDTR period 2b, offset f
<4>     Filtered to period 2b, offset f
<4>(scsi0:A:0): 11.626MB/s transfers (5.813MHz, offset 15, 16bit)
<4>scsi0: target 0 synchronous at 5.7MHz, offset = 0xf
<4>(scsi0:A:0:0): Sending WDTR 1
<4>(scsi0:A:0:0): Received WDTR 1 filtered to 1
<4>(scsi0:A:0): 6.600MB/s transfers (16bit)
<4>scsi0: target 0 using asynchronous transfers
<4>(scsi0:A:0:0): Sending SDTR period 2b, offset f
<4>(scsi0:A:0:0): Received SDTR period 2b, offset f
<4>     Filtered to period 2b, offset f
<4>(scsi0:A:0): 11.626MB/s transfers (5.813MHz, offset 15, 16bit)
<4>scsi0: target 0 synchronous at 5.7MHz, offset = 0xf
<4>SCSI device sda: 17783240 512-byte hdwr sectors (9105 MB)
<6>Partition check:
<6> sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 sda8 >
<4>(scsi0:A:3:0): Sending PPR bus_width 1, period 2b, offset 7f, ppr_options 0
<4>(scsi0:A:3:0): Received PPR width 1, period 2b, offset 3f,options 0
<4>     Filtered to width 1, period 2b, offset 3f, options 0
<4>(scsi0:A:3): 6.600MB/s transfers (16bit)
<4>scsi0: target 3 using 16bit transfers
<4>(scsi0:A:3): 11.626MB/s transfers (5.813MHz, offset 63, 16bit)
<4>scsi0: target 3 synchronous at 5.7MHz, offset = 0x3f
<4>(scsi0:A:3:0): Sending PPR bus_width 1, period 2b, offset 3f, ppr_options 0
<4>(scsi0:A:3:0): Received PPR width 1, period 2b, offset 3f,options 0
<4>     Filtered to width 1, period 2b, offset 3f, options 0
<4>SCSI device sdb: 17916240 512-byte hdwr sectors (9173 MB)
<6> sdb: sdb1 sdb2
<4>Attached scsi CD-ROM sr0 at scsi1, channel 0, id 3, lun 0
<4>Attached scsi CD-ROM sr1 at scsi1, channel 0, id 4, lun 0
<4>(scsi1:A:3:0): Sending SDTR period 2b, offset 7f
<4>(scsi1:A:3:0): Received SDTR period 2b, offset f
<4>     Filtered to period 2b, offset f
<4>(scsi1:A:3): 5.813MB/s transfers (5.813MHz, offset 15)
<4>scsi1: target 3 synchronous at 5.7MHz, offset = 0xf
<4>(scsi1:A:3:0): Sending SDTR period 2b, offset f
<4>(scsi1:A:3:0): Received SDTR period 2b, offset f
<4>     Filtered to period 2b, offset f
<4>(scsi1:A:3:0): Sending SDTR period 2b, offset f
<4>(scsi1:A:3:0): Received SDTR period 2b, offset f
<4>     Filtered to period 2b, offset f
<4>sr0: scsi-1 drive
<6>Uniform CD-ROM driver Revision: 3.12
<4>(scsi1:A:4:0): Sending SDTR period 2b, offset 7f
<4>(scsi1:A:4:0): Received SDTR period 32, offset 8
<4>     Filtered to period 32, offset 8
<4>(scsi1:A:4): 5.000MB/s transfers (5.000MHz, offset 8)
<4>scsi1: target 4 synchronous at 5.0MHz, offset = 0x8
<4>(scsi1:A:4:0): Sending SDTR period 32, offset 8
<4>(scsi1:A:4:0): Received SDTR period 32, offset 8
<4>     Filtered to period 32, offset 8
<4>sr1: scsi3-mmc drive: 20x/20x writer cd/rw xa/form2 cdda tray


I can't make sense of the termination config detected by the new
driver, and I suspect that this is at least part of the problem.
The onboard controller is 2-channel, ch-A with 2 LVD drives attached,
and ch-B with the 2 SE devices (cd-rom, cd-rec). I have tried to
force the termination using the "aic7xxx=override_term:0x2C" option
which corresponds to the same setting as that programmed via the BIOS,
but to no avail.

Any help is greatly appreciated.
With best regards from (cloudy but warm today at ~27C) Athens,

Dimitri

-- 
+-------------------------+-------------------------------------------+
| Dimitrios P. Bouras     | Voice: +30 10 895-6380 or +30 10 895-3552 |
| 27 El. Venizelou St.    | E-Mail: dbouras@hol.gr, d.bouras@ieee.org |
| GR-16673 Athens, GREECE |    Web: http://users.hol.gr/~dbouras      |
+-------------------------+-------------------------------------------+
     "There is hopeful symbolism in the fact that flags do not wave
      in a vacuum."                             -- Arthur C. Clarke

Re: aix7xxx driver 5.2.4/5.2.0 vs. 6.2.5 with onboard aic7896/97 Ultra2 controller

[Justin T. Gibbs]

>Hello all,
>
>I have recently switched from kernel version 2.2.20 to 2.4.18. The
>problem I've had is with the new aic7xxx driver. In short, it seems
>to have the same (possibly reasonable but, in effect, undesirable)
>behavior as the SCSI-BIOS for the onboard aic7896/97 Ultra2 controller
>on my Gigabyte GA-6BXDU motherboard: it fails to enable the full 80
>mb/s transfer rate on my 2 hard-drives, as well as 20 mb/s and 10 mb/s
>on my cdrom and cd recorder respectively. The old driver works like a
>charm. Similarly the older Adaptec BIOS detected all four devices
>correctly, but I had to upgrade when I installed a Coppermine processor.
>I am currently forced to use the old driver under 2.4.18, but would like
>to resolve this problem.

Go into the SCSI-Select BIOS option for each channel.  Set some speed
other than the fastest speed for all devices.  Save the result.  Go
back into SCSI-Select and select the fastest speed.  The serial eeprom
will now have the correct values and the driver should honor them.

The old driver works around this issue by treating a valid but slow
sync rate as the fastest rate.  This avoids this particular issue,
but prevents the user from setting such a slow rate should it be
needed.

--
Justin

Re: aix7xxx driver 5.2.4/5.2.0 vs. 6.2.5 with onboard aic7896/97 Ultra2 controller

[Doug Ledford]

On Tue, May 07, 2002 at 08:31:18AM -0600, Justin T. Gibbs wrote:
> The old driver works around this issue by treating a valid but slow
> sync rate as the fastest rate.

Not intentionally.  If that's why my driver is getting the higher rate 
then it's a bug in the driver.  It was never intended to ignore slow speed 
settings in the serial eeprom.

Ahhh...I know what it is...there were, back in the day when the 7895 was 
new, some BIOS versions that used odd combinations for slow speeds vs. 
high speeds, so there are a few specific instances of things in the driver 
that would cause a particular low speed to get bumped to a higher speed.  
At the time, the problem machines were showing up as 10MB/s when they were 
suppossed to be 20 or 40MB/s.  So, this particular BIOS may have left 
around the same type of speed encoding as those older trouble machines.  
I'd be interested to know if changing the speed and saving it, then 
changing it back and saving it does solve the problem.

-- 
  Doug Ledford <dledford@redhat.com>     919-754-3700 x44233
         Red Hat, Inc. 
         1801 Varsity Dr.
         Raleigh, NC 27606
  

Re: aix7xxx driver 5.2.4/5.2.0 vs. 6.2.5 with onboard aic7896/97 Ultra2 controller

[Dimitrios P. Bouras]

Justin T. Gibbs wrote:

> 
> Go into the SCSI-Select BIOS option for each channel.  Set some speed
> other than the fastest speed for all devices.  Save the result.  Go
> back into SCSI-Select and select the fastest speed.


Doug Ledford wrote:
 >
 > I'd be interested to know if changing the speed and saving it, then
 > changing it back and saving it does solve the problem.

  Yup, it did the trick all right! I set the speed for all devices
  to 20 mb/s and then back to 80 mb/s. Now the speed settings when
  using driver v2.6.5 are the same as when using v5.2.4/5.2.0.

  Many thanks for the help.
  Regards,

  Dimitri

Task Sets in SCSI and Linux

[Michael Heinz]

Okay,

 From perusing the source code it appears to me that the Linux SCSI 
layers do not take advantage of SCSI task sets. Is that correct?

I want to make sure I'm right before I go to my boss and tell him to 
stop telling me I'm "behind" on the task management line of his PERT 
chart...

:-P

Re: Task Sets in SCSI and Linux

[James Bottomley]

mheinz@infiniconsys.com said:
>  From perusing the source code it appears to me that the Linux SCSI
> layers do not take advantage of SCSI task sets. Is that correct? 

Could you elaborate on what you mean by "task set"?  SCSI 3 defines a task 
simply as "work to be performed by the logical unit in the form of a command 
or a group of linked commands".  This basically means the I_T_L or I_T_L_Q 
nexus of scsi2, however scsi3 expands this for multi-ported devices.  "task 
set" usually just means the outstanding tasks on a given logical unit, and as 
such it's really a target concept although the initiator must know how to 
track outstanding tasks correctly.

If by "take advantage of SCSI task sets" you mean use tagged tasks to get 
multiple outstanding tasks on a logical unit, the answer is yes but it depends 
on the low level driver implementation.

James Bottomley

Re: Task Sets in SCSI and Linux

[Matthew Jacob]

> 
> Could you elaborate on what you mean by "task set"?  SCSI 3 defines a task 
> simply as "work to be performed by the logical unit in the form of a command 
> or a group of linked commands".  This basically means the I_T_L or I_T_L_Q 
> nexus of scsi2, however scsi3 expands this for multi-ported devices.  "task 
> set" usually just means the outstanding tasks on a given logical unit, and as 
> such it's really a target concept although the initiator must know how to 
> track outstanding tasks correctly.

You can issue an FCP CMND IU with ABORT TASK SET as part of the task
management functions. It aborts all tasks (tagged commands) at the specified
lun for that initiator.

Consider it a 'bulk abort tag' operation.


At any rate, the answer is that Linux itself doesn't support this level of
granularity of aborting, as the sequence of error recovery for the midlayer is
(IIRC)

	abort tag -> reset device -> reset bus

for each timed out command. Individual HBA drivers may or may not support
this.

Re: Task Sets in SCSI and Linux

[Matthew Jacob]

> 
> 	abort tag -> reset device -> reset bus
> 
> for each timed out command. Individual HBA drivers may or may not support
> this.

Sorry- I meant to say

"Individual HBA drivers may or may not support the finer grained level of task
manangement"

Re: Task Sets in SCSI and Linux

[Michael Heinz]

On Wednesday, May 8, 2002, at 12:34 PM, James Bottomley wrote:
>
>
> If by "take advantage of SCSI task sets" you mean use tagged tasks to 
> get
> multiple outstanding tasks on a logical unit, the answer is yes but it 
> depends
> on the low level driver implementation.
>
> James Bottomley
>
>
>

James,

You confused me with this - my testing with 2.4 seems to indicate that 
SCSI won't queue up more than one command per LUN (that is, it waits for 
one command to complete before issuing the next). How can I tell it to 
do otherwise? (It allows parallel commands, as long as they are going to 
different LUNs). I didn't see anything in the SHT to indicate otherwise.

Re: Task Sets in SCSI and Linux

[Kurt Garloff]

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

Hi Michael,

On Wed, May 08, 2002 at 01:22:31PM -0400, Michael Heinz wrote:
> You confused me with this - my testing with 2.4 seems to indicate that 
> SCSI won't queue up more than one command per LUN (that is, it waits for 
> one command to complete before issuing the next). How can I tell it to 
> do otherwise? (It allows parallel commands, as long as they are going to 
> different LUNs). I didn't see anything in the SHT to indicate otherwise.

Your host adapter driver and your device need to support Tagged Command
Queueing and it needs to be enabled. The Linux SCSI layer will make use of
it. 

Regards,
-- 
Kurt Garloff                   <kurt@garloff.de>         [Eindhoven, NL]
Physics: Plasma simulations    <K.Garloff@TUE.NL>     [TU Eindhoven, NL]
Linux: SCSI, Security          <garloff@suse.de>    [SuSE Nuernberg, DE]
 (See mail header or public key servers for PGP2 and GPG public keys.)

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