CAM_NEW_TRAN

[Johannes.Kruger at nokia.com]

Hi Matthew.
Seeing you guys talking about the CAM_NEW_TRAN, I just want to mention
that I got the LSI1064 and LSI1064E to work with the mpt driver .. and
yes, I used the NEW CAM code.
So the background is that I took the mpt driver and ported it to a OS
that is the equivalent of FreeBSD-2.X.X with some alterations.
To make a long story short our OS needed more recent CAM code to work
with mpt.
So this is what I needed to do to make it (mpt) work (remember RAID-1
was slow in FreeBSD and the OS I was working on).

These are just hacks to give you some data:

1) In order for the RAID-1 volume to be probed in IOC Page 2, I had to
force the port to on first, otherwise the RAID personality would not
successfully probe the RAID-1 volume.
In the file mpt.c I changed:
if (portenable) {
to
if (1) {

2) Some changes in the Firmware:
- Port numbers in the PHY's was all 0 for Wide configs, so I made PHY0 a
0 and changed PHY1 from 0 to 1, Port setting in SAS IO Unit Page 1
- RAID Volume Page 0, IM VolumeSettings set to 0x5, IS VolumeSettings =
0x1
- ResyncRate set low = 0x2
- IOC Page 1 (Think these are needed for speed increase) from 15 MB/s to
32 MB/s
  - Doubled Coalescing Depth from 0x4 to 0x8
  - Halfed the CoalecingTimeout from 0x10 to 0x8
- Enabled NCQ (made a bit difference)
- Also, in one of the registers there is a setting to specify if it's
via expander or directly attached. Changed this to "directly attached"
via the SATA/SAS cables.

3) Works fine for SATA, then I tested SAS. I got 50-52 MB/s for SAS
drives running 7200rpm versus 30 MB/s for SATA at 4500rpm
It's small laptop size drives.
But ... when I remove the drives, and I re-insert it, I would get
"Invalidating pack" messages from the CAM code. Turns out that the SAS
drives takes a while to spin up.
It actually sounds like it's changing gears or something :-),
distinctive sound difference in a multistep spinup ... interesting. Have
to go read what the powerup sequence for SAS drives are.
So, for now I added a delay of 10 seconds if the volume flags indicates
failure and now the re-insert is fine.
I Might change this to a poll ... but I see there is some settings
regarding spinup delay and IOC report time before indicating the drive
presence, thant might work.

In function mpt_refresh_raid_data
----------------------- snippet -----------------------
.
.
        CONFIG_PAGE_RAID_VOL_0  *vol_pg;
        size_t len;
        int rv;
        int i;
        int settle = 10;    <############# ADDED THIS #######>
        u_int nonopt_volumes;
.
.
.
.
                if (vol_pg->VolumeStatus.State !=
                    MPI_RAIDVOL0_STATUS_STATE_OPTIMAL)
                        nonopt_volumes++;

                if ((mpt_vol->flags & MPT_RVF_UP2DATE) != 0)
                        continue;

################> ADDED PARTS BETWEEN IFDEF and defined it
<#######################
#ifdef SAS_SLOW_START
                if (mpt_vol->config_page->VolumeStatus.State ==
                    MPI_RAIDVOL0_STATUS_STATE_FAILED) {
                        printf("Waiting %d seconds for device to settle
",  
                            settle);
                        while (settle) {
                                settle--;
                                DELAY(1000000);
                                printf(".");
                        }
                        printf("\n");
                        mpt->raid_nonopt_volumes = nonopt_volumes;
                        return (0);
                }
#endif
                mpt_vol->flags |= MPT_RVF_UP2DATE;
----------------------- snippet -----------------------

Anyway, this is just some more data that can help, because I want this
to work well on FreeBSD.



Johan


-----Original Message-----
From: owner-freebsd-scsi at freebsd.org
[mailto:owner-freebsd-scsi at freebsd.org] 
Sent: Friday, October 27, 2006 2:15 PM
To: freebsd-scsi at freebsd.org
Subject: Re: CAM_NEW_TRAN



I can take on most of the work.

> mjacob at freebsd.org wrote:
>> 
>> Is there any reason to *not* proceed with CAM_NEW_TRAN and just bite
the 
>> bullet now and move ahead?
>> 
>
> I have no objection against it.
>
> Scott
>
_______________________________________________
freebsd-scsi at freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "freebsd-scsi-unsubscribe at freebsd.org"