Re: Branch to use for most current Qlogic target code.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On Fri, 2012-02-10 at 20:25 -0800, Nicholas A. Bellinger wrote:
> On Thu, 2012-02-09 at 14:01 +0800, Jim Barber wrote:
> > On 9/02/2012 11:29 AM, Nicholas A. Bellinger wrote:
> 
> <SNIP>
> 
> > > You should still definitely *not* be seeing NON_EXISTENT_LUN errors
> > > after a session reset, regardless of the unsupported bits mentioned
> > > above.
> > > 
> > > What does your running qla2xxx configuration look like..?  Also, what
> > > lio-core.git HEAD is this with again..?
> > 
> > The errors I posted were encountered with a kernel compiled from the latest qla_tgt-3.3 HEAD.
> > The first entry of a 'git log' shows:
> > 
> > 	commit 7a4dc04b51cf01d5cea3332db61c0ac609b09b13
> > 	Author: Roland Dreier <roland@xxxxxxxxxxxxxxx>
> > 	Date:   Wed Jan 11 16:58:05 2012 -0800
> > 
> > For your question regarding what does my configuration look like, I'll give you what I think you might need (but I'm just guessing).
> > >From the targetcli command, an 'ls' at the root results in the following:
> > 
> 
> Hi again Jim,
> 
> Thanks for the additional information.  So looking at your configuration
> below, nothing appears out of the ordinary.
> 
> After looking the problem output from the previous email a bit more, one
> thing that is strange is the fact that all of the NON_EXISTENT_LUN are
> for LUN > 0, when only LUN=0 has been configured on the individual
> tcm_qla2xxx ports.    Really quite strange for the ESX client to start
> hammering new LUNs that aren't registered during TMR handling..
> 
> I've tried reproducing this case with unsupported TMRs with a normal
> Linux FC qla2xxx client, but I've not had any luck to reproduce a
> similar case thus far..  What I'm not sure about yet is if a single
> rejected ABORT is actually making ESX client blow up (instead of falling
> back to LUN_RESET for example), or if it's the locally generated events
> (eg: Unknown task mgmt fn 0xfffd) on the qla_target.c side not being
> handled that is causing the hard failure.
> 
> If at all possible, it would very be helpful to try to reproduce using
> ql2xextended_error_logging so that I can get a better idea of what's
> going on.  This is enabled at module load time with:
> 
>     modprobe qla2xxx ql2xextended_error_logging=0xffffff
> 
> Since you've mention it only seems to happen occasionally, you'll likely
> end up with gigs of logs with debug enabled.
> 
> I'm still looking at how to reproduce this case, so any more logs would
> be very helpful to that end.
> 

Hi Jim,

So with the patches from this morning to add support for TMR_ABORT_TASK,
I'd like you to try re-testing with ESXv5 client.

At this point I'm pretty sure the reason you are seeing ABORT_TASK is
because your backend device is taking a long time (> 30 secs) to return
outstanding I/O, causing SCSI timeouts on the FC initiator to fire..

In this scenario the explicit TMR_ABORT_TASK will wait for the
outstanding I/O descriptor in question to complete, before returning the
referenced tag with SAM_STAT_TASK_ABORTED, and completing TMR_ABORT_TASK
with TMR_FUNCTION_COMPLETE.

I've just pushed this series for testing into lio-core.git/master, so
please go ahead and pull at your earliest convience and retest with the
following master HEAD:

commit c851cb5a4043e11ae7844dc8a01d4787a4cc9573
Author: Nicholas Bellinger <nab@xxxxxxxxxxxxxxx>
Date:   Mon Feb 13 01:26:48 2012 -0800

    qla_target/tcm_qla2xxx: Fix TMR_ABORT_TASK with target mode usage

Also, I've added some debug code, so you should not have to run with
'modprobe qla2xxx ql2xextended_error_logging=0xffffff' anymore.

Thanks!

--nab




--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Linux SCSI]     [Kernel Newbies]     [Linux SCSI Target Infrastructure]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Photos]     [Yosemite]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

Add to Google Powered by Linux