On 05/03/2013 21:52, Nicholas A. Bellinger wrote:
> Hi Chris,
>
> On Sun, 2013-03-03 at 13:49 +0000, Chris Boot wrote:
>> Hi all,
>>
>> When creating a new target port in targetcli (/qla2xxx create
>> 21:0x:...), and I have nothing plugged-in to the port, the creation
>> process takes quite some time. After a few seconds, the kernel prints
>> a message saying "Cable is unplugged...". So far so good.
>>
> AFAIK the delay is expected here when no physical link is detected.
Yes, I expected the delay at this point.
>> It seems that when the target is created, it comes up in the 'enabled'
>> state, regardless of me having set 'auto_enable_tpgt=false'. Running
>> 'disable' from targetcli seems to try to bring the link up again
>> ("Performing ISP error recovery" then "Cable is unplugged...") and the
>> target remains in the enabled state.
>>
> Running 'disable' from targetcli will perform:
>
> echo 0 > /sys/kernel/config/target/qla2xxx/$FC_WWPN/$TPGT/enable
>
> that will effectively disable target mode on the $FC_WWPN port in
> question, regardless of what else (LUNs, ACLs) are configured.
>
> Target mode is only re-enabled at the HW level for the port with:
>
> echo 1 > /sys/kernel/config/target/qla2xxx/$FC_WWPN/$TPGT/enable
I can't easily perform this test again now, maybe I can do it later this
weekend. From memory, though, running 'disable' in targetcli _or_
running 'echo 0 >
/sys/kernel/config/target/qla2xxx/$FC_WWPN/$TPGT/enable' both indeed
have the same effect.
>> If I then add LUNs and ACLs to the target, everything appears OK, but
>> plugging the target port into an initiator gives odd behaviour. The
>> initiator spends a very long time scanning the target and eventually
>> times out and finds no LUNs. The only way to get the port working
>> again is to save the configuration and reboot the target server, which
>> is very frustrating.
>>
> Can you double check the value of ../qla2xxx/$FC_WWPN/$TPGT/enable when
> this happens..? From the description above it sounds like your
> explicitly disabling target mode on the port.
Again, from memory, after doing a 'disable' or 'echo 0 > .../enable'
results in the 'enable' file still returning value 1. I also seem to
remember, when trying to unload the qla2xxx module, getting odd
behaviour and OOPSes - though I would want to double check this. I had
the same behaviour with two qla2xxx HBAs (one 2460 and one 2464).
>> I'm using targetcli as found in Debian wheezy with kernel 3.8.0,
>> though I have had this problem for a little while now...
>>
> For reference, can you provide the HBAs that your reproducing with..?
>
> Also, a target side log with
>
> modprobe qla2xxx ql2xextended_error_logging=0x7fffffff
>
> would be helpful as well.
I'll see if I can get enough hardware and time together to test this
over the weekend to confirm everything I said above and gather the logs
with the error logging enabled. I'll keep you posted.
Cheers,
Chris
--
Chris Boot
bootc@xxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
