Problem Adding Transport Class support to fusion

Problem Adding Transport Class support to fusion

[James Bottomley]

I thought I'd look into this, since it seems to be relatively simple:
you get the parameters from the device config page0 and set them via
device config page1 as I read the driver.

However, this appears to be where my fusion card runs into difficulty.
Debugging the header setup I get this:

mptbase: ioc1: Headers: 0: version 0 length 0
mptbase: ioc1: Headers: 1: version 3 length 4

The driver seems to think this is valid, but if it occurs, there's no
way to get the parameters or run domain validation.  Is this correct?
There are classes of fusion card for which we simply cannot obtain
transport data? 

Or is there a work around that's not coded into the driver?

James

RE: Problem Adding Transport Class support to fusion

[Moore, Eric Dean]

I suspect your using dated firmware. Try /proc/mpt/summary,
and check FwRev.

The "Headers: 0" is SPI Device Page 0, which is returning
the negotiated parameters.  

With my card, I have newer mpi version 4 for "Headers: 0",
your on version 0, which is strange.

Here is what I get.
> mptbase: ioc1: Headers: 0: version 4 length 3
> mptbase: ioc1: Headers: 1: version 5 length 4

Also, have you remembered our cards support RAID?  We kick
of DV when a drive is replaced failed drive in a mirror. That
is kicked off when fw sends ASYC event saying that the
driver must to DV on that hidden phys disk.

FYI - I'm getting ready to post SAS support for split drivers design.  
I prefer that we push out generic DV support after we get the 
SAS updates in, and some other bits of FC transport support 
that have been waiting in the wings for several months.

Eric Moore
LSI Logic

On Monday, May 30, 2005 3:56 PM, James Bottomley wrote:
> 
> I thought I'd look into this, since it seems to be relatively simple:
> you get the parameters from the device config page0 and set them via
> device config page1 as I read the driver.
> 
> However, this appears to be where my fusion card runs into difficulty.
> Debugging the header setup I get this:
> 
> mptbase: ioc1: Headers: 0: version 0 length 0
> mptbase: ioc1: Headers: 1: version 3 length 4
> 
> The driver seems to think this is valid, but if it occurs, there's no
> way to get the parameters or run domain validation.  Is this correct?
> There are classes of fusion card for which we simply cannot obtain
> transport data? 
> 
> Or is there a work around that's not coded into the driver?
> 
> James
> 
> 

RE: Problem Adding Transport Class support to fusion

[James Bottomley]

On Tue, 2005-05-31 at 10:25 -0600, Moore, Eric Dean wrote:
> I suspect your using dated firmware. Try /proc/mpt/summary,
> and check FwRev.

Yes, that was it: the fw revision was 1.0.4.0

Updating to 1.3.39.0 allowed me to get at Page 0.

Are there many cards in the field like this?

> Also, have you remembered our cards support RAID?  We kick
> of DV when a drive is replaced failed drive in a mirror. That
> is kicked off when fw sends ASYC event saying that the
> driver must to DV on that hidden phys disk.

Yes, we had a non-attachment scheme that Christoph suggested for the
components of the RAID devices.

> FYI - I'm getting ready to post SAS support for split drivers design.  
> I prefer that we push out generic DV support after we get the 
> SAS updates in, and some other bits of FC transport support 
> that have been waiting in the wings for several months.

Well, this is more driven by me ... I need to get the generic DV working
on u320, and the 1030 is the only u320 SCSI card I have to try it with.

Thanks,

James

RE: Problem Adding Transport Class support to fusion

[James Bottomley]

Well ... I seem to have got parameter getting and setting working just
about OK (modulo a few coupling issues).

The fusion driver seems to have quite a big event subsystem.  Is there
an event that will report a device transfer agreement change? (without
this it's a bit difficult to keep track of where the device and the
fusion core are with negotiation)

Thanks,

James

RE: Problem Adding Transport Class support to fusion

[Moore, Eric Dean]

There doesn't appear to be any aync message return
after negotiation mentioned on the mpi spec.

Look at mptscsih_doDv to see how dv nego parameters
are beeing maintained between target/initiator.
SPI Device page0/1 are read/written here.
The hd->Targets[] structure is repository of nego params.

This function was coded prior to my time on this driver, and I
haven't spent too much time trying to decipher it.

Eric Moore

On Tuesday, May 31, 2005 11:41 AM, James Bottomley wrote:
> 
> 
> Well ... I seem to have got parameter getting and setting working just
> about OK (modulo a few coupling issues).
> 
> The fusion driver seems to have quite a big event subsystem.  Is there
> an event that will report a device transfer agreement change? (without
> this it's a bit difficult to keep track of where the device and the
> fusion core are with negotiation)
> 
> Thanks,
> 
> James
> 
>