On 14/02/2012 6:28 AM, Nicholas A. Bellinger wrote: > 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 Thanks Nicholas. I'm building the new kernel as I type this and will install it the first chance I get. I'm not sure why my system might be taking a long time to return outstanding I/O. It is using a 3ware 9650SE RAID controller with the StorSave policy set to 'performance' with read cache off and write cache on. It uses a RAID-1 array for the operating system. It has a RAID-10 array made up of 8x 750GB 7200rpm SATA disks that are used exclusively by LIO. It's not enterprise class disk, but I wouldn't expect it to be too slow... Regards, ---------- Jim Barber DDI Health -- 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
