isp/qlogic reports controller SN instead of Logical Drive ID

[Matthew Jacob]

On 5/20/2010 4:18 AM, Andriy Kopystyansky wrote:
> Hi, people,
> I'm trying to launch a nice server on IBM Blade, and encountered 
> serious problem with multipath via Qlogic/ISP driver.
>
> I have IBM blade with two fibre channel adapters:
> isp0, isp1: <Qlogic ISP 2422 PCI FC-AL Adapter>
> Also i have storage IBM DS3400 with 2 FC-RAID controllers. Each 
> adapter has link to each FC-RAID.
>
> On the storage, I've created two logical disks (big disk 10G and small 
> one 6G), assigned to my blade,
> and sucessfully installed freebsd-8.0-amd64 on device da0.
> As expected, camcontrol shows da0-da7 devices (2 logical disks with 4 
> pathes to each one).
> camcontrol readcap reports da0, da2, da4, da6 - belongs to 10G drive
> and da1, da3, da5, da7 - has 6G.
> Then I tried to build multipath volume on da1,da3,da5,da7. End here 
> problem starts:
> camcontrol inquiry da0 -S reports SX80801049 (which is actually serial 
> number of raid controller at DS3400, not an ID of 10G volume)
> camcontrol inquiry da1 -S also reports SX80801049...
> camcontrol inquiry da2 -S reports serial of second RAID (instead of 
> the same ID as da0)...
> and so on...
> camcontrol inquiry da4 -S reports first RAID serial (fine, this one 
> through isp1).
>
> In logs a lot of "ILLEGAL REQUEST asc:94,1"   regarding da1, da2, da5, 
> da6.

It's not an HBA problem.

You have Santricity storage underlying.

1. Santricity does not assign volume serial numbers. You'll get the same 
serial numbers no matter what for each lun.

2. The 94,1 issue is "You don't own this path". You need to set AVT 
(auto volume transfer) with exclusion. This is a problem, because LSI 
f/w is all over the map on this. It's currently set up to expect some 
kind of RDAC driver on the host which will control failover (since this 
is not really an active-active device). See if setting the host type to 
LINUXAVT (type 7, I think) works for you. Don't know what tools come 
with IBM for this. And I don't know if modifiying NVSRAM bytes for your 
device will work the same as for the ones I've seen- this would be to 
modify it so that access to the first and last 1MB of each lun doesn't 
trigger an AVT event.