svn+ssh://vlnb@svn.code.sf.net/p/scst/svn/trunk
........
r5955 | bvassche | 2014-12-22 05:10:41 -0800 (Mon, 22 Dec 2014) | 1 line
Update for kernel 3.18
........
r5959 | bvassche | 2015-01-06 05:25:28 -0800 (Tue, 06 Jan 2015) | 1 line
scst_calc_block_shift: Log block shift and sector size upon mismatch
........
r5960 | bvassche | 2015-01-07 01:20:06 -0800 (Wed, 07 Jan 2015) | 4 lines
scst_local: Fix unique per session sas address
Signed-off-by: Sebastian Herbszt <herbszt@gmx.de>
........
r5961 | bvassche | 2015-01-09 04:23:25 -0800 (Fri, 09 Jan 2015) | 4 lines
scst_sysfs: return EINVAL on too big LUN
Signed-off-by: Sebastian Herbszt <herbszt@gmx.de>
........
r5965 | bvassche | 2015-01-13 00:55:46 -0800 (Tue, 13 Jan 2015) | 68 lines
qla2x00t: Copy entire SCST sense buffer to q2x ctio
There seems to be a bug in passing sense information to QLA HBAs, where
the last 2 bytes of the sense data (ASC, ASCQ) are not copied to the low
level sense buffer.
We encountered this in ESX, which relies on these 2 bytes to parse the
MISCOMPARE sense code (0xE1, 0x1D, 0x00).
Bellow is a simple test to recreate this issue, but during vMotion
operations (where VMs are moved from one host to another), this may
cause the operation to fail leaving the VM in an inconsistent state.
The test I ran to verify that we are indeed missing the bytes is the
following:
1. Create a SCST based device
2. Expose the device to 2 ESX hosts
3. Format the device as VMFS5, create a test directory
4. From both hosts, I start writing to this directory (no VMs involved,
just write normal files)
At this stage, both ESX hosts try to take access to the directory.
The VMFS filesystem contains a per-directory lock which is managed by
COMPARE AND WRITE command.
Each ESX will attempt to change the VMFS lock location from unlocked to
locked to create the new file.
Obviously there are bound to be failures (which are equivalent to
programming locking conflicts), these are reported by the MISCOMPARE
sense code.
Upon these MISCOMPARE errors, the host will re-try taking the lock until
it succeeds, and will then proceed to perform the write operation on the
directory.
Due to the bug in copying the sense buffer from the SCST core to the QLA
ctio, instead of the full sense code, only the key (0xE) is sent, and
ESX does not know how to handle it resulting in IO error.
Here are the errors as they appear on the command line:
/vmfs/volumes/54a297c4-ca5af1cc-7f94-002219d20f28/ats_test #
./open_close_test-esx2.sh
./open_close_test-esx2.sh: line 8: can't create
ats_fileoptest-esx2_1.txt: Input/output error
./open_close_test-esx2.sh: line 8: can't create
ats_fileoptest-esx2_21.txt: Input/output error
./open_close_test-esx2.sh: line 8: can't create
ats_fileoptest-esx2_110.txt: Input/output error
./open_close_test-esx2.sh: line 8: can't create
ats_fileoptest-esx2_111.txt: Input/output error
In the /var/log/vmkernel.log, we can see that the sense information is
missing (0xE, 0x0, 0x0) instead of (0xE, 0x1D, 0x0).
2014-12-30T12:13:20.714Z cpu6:33519)ScsiDeviceIO: 2338:
Cmd(0x412e84f957c0) 0x89, CmdSN 0x234d from world 519051 to dev
"eui.0024f400d5020007" failed H:0x0 D:0x2 P:0x0 Valid sense data: 0xe 0x0 0x0.
2014-12-30T12:13:20.766Z cpu6:33519)ScsiDeviceIO: 2338:
Cmd(0x412e84f91d00) 0x89, CmdSN 0x2350 from world 519051 to dev
"eui.0024f400d5020007" failed H:0x0 D:0x2 P:0x0 Valid sense data: 0xe 0x0 0x0.
2014-12-30T12:13:20.766Z cpu6:33519)ScsiDeviceIO: 2338:
Cmd(0x412e80449fc0) 0x89, CmdSN 0x234f from world 519051 to dev
"eui.0024f400d5020007" failed H:0x0 D:0x2 P:0x0 Valid sense data: 0xe 0x0 0x0.
This patch fixes this issue, the test will run without a problem with the
fix (no IO errors, all the files are properly written to the directory).
Signed-off-by: Shahar Salzman <shahar.salzman@kaminario.com>
Reviewed-by: Eran Mann <eran.mann@kaminario.com>
[bvanassche: simplified implementation]
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
........
git-svn-id: http://svn.code.sf.net/p/scst/svn/branches/3.0.x@6110 d57e44dd-8a1f-0410-8b47-8ef2f437770f
Assign one major number per thread pool instead of as many major
numbers as there are threads in a thread pool. Do not increment
'major' if thread pool allocation fails. Micro-optimize
iscsi_threads_pool_get() by eliminating the assignment to 'fn'
and the write via snprintf() into name[].
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@5520 d57e44dd-8a1f-0410-8b47-8ef2f437770f
Fix the following checkpatch 3.14 warning:
Unnecessary parentheses - maybe == should be = ?
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@5435 d57e44dd-8a1f-0410-8b47-8ef2f437770f
May be not completed, because this kernel has too many internal issues
reported after enabling "Kernel hacking" config options
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@5163 d57e44dd-8a1f-0410-8b47-8ef2f437770f
The following procfs-related changes have been included in kernel 3.10:
- The PDE() macro has been removed from <linux/proc_fs.h>.
- The create_proc_entry() function has been removed.
- The proc_info field has been removed from struct scsi_host_template.
Unbreak the procfs build for kernel versions >= 3.10
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@5148 d57e44dd-8a1f-0410-8b47-8ef2f437770f
Avoid that sparse complains about a local symbol not having been declared
static (scst_pool_dep_map and scst_conn_dep_map). Also avoid that sparse
reports these two variables as unused in the procfs build.
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@5110 d57e44dd-8a1f-0410-8b47-8ef2f437770f
the timeout value. The problem is that if commands were started at
00:00:05 and 00:00:10 and the timeout value was 15 seconds and the
first command completed ok, then conn_rsp_timer_fn would have run
at 00:00:20 and rescheduled the next conn_rsp_timer_fn run for 15
secs from that time (00:00:35). But, we would have wanted to check on
the second command at 15 secs after its write_start time which is
00:00:25.
This patch has us reschedule the next conn_rsp_timer_fn run for
the req's write_start time + its timeout.
Signed-off-by: Mike Christie <michaelc@cs.wisc.edu>
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@5093 d57e44dd-8a1f-0410-8b47-8ef2f437770f
1. If we have a nop in flight then we do not really need to send
more to test if the other side is still there. Either that nop
will timeout and conn will be dropped or it will complete
and last_rcv_time will be updated.
2. We are sending nop-ins every nop_in_interval seconds, but if
we got a data half way in to the window, then when conn_nop_in_delayed_work_fn
is run it was scheduling the next check to be nop_in_interval more
seconds. With the current settings this could end up with us waiting
59 secs before sending a nop and about 130 secs for it to timeout, when
at 61 it should be timing out and getting cleaned up already. This patch
has us take into account when the last time we got data to try and
reschedule the next nop check closer to nop_in_interval from that time.
Signed-off-by: Mike Christie <michaelc@cs.wisc.edu>
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@5092 d57e44dd-8a1f-0410-8b47-8ef2f437770f
when a command/data is in the process of being sent. The snd
buffer space goes to zero and sendpage returns -EAGAIN. We then
wait for space to open. If space never opens then the cmd rsp timer
fires and the session/connection is dropped.
During that time we could try to send a nop as a ping, but it
is stuck behind that other command that got EAGAIN and we are
waiting for space to open to send them. We would expect the
nop in timer to fire before the cmd rsp timer, but it cannot
becuase the nop is sitting in the internal iscsi-scst queue.
This patch just has us start the timer ont he nop in right
away.
Signed-off-by: Mike Christie <michaelc@cs.wisc.edu>
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@5091 d57e44dd-8a1f-0410-8b47-8ef2f437770f
This patch does not change any functionality other than the message
printed when it takes more than one second before the completion is
signalled.
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@5086 d57e44dd-8a1f-0410-8b47-8ef2f437770f
