On 3/29/2014 3:53 AM, Quinn Tran wrote:
+
+if (dev->dev_attrib.pi_prot_type) {
+uint32_t cap[] = { 0,
+ TARGET_DIF_TYPE1_PROTECTION,
+ TARGET_DIF_TYPE2_PROTECTION,
+ TARGET_DIF_TYPE3_PROTECTI
Answer in line.
Regards,
Quinn Tran
On 3/28/14 5:05 PM, "sagi grimberg" wrote:
>On 3/29/2014 2:05 AM, Quinn Tran wrote:
>> Check lower layer/HW support of T10-dif capability.
>> When the LUN is linked between the underlining fabric
>> and back end device, the Protection Type(1,2,3) is
>> che
On 3/29/2014 2:48 AM, Quinn Tran wrote:
+Sagi
+Martin
Thanks Quinn!
Already had a look.
Regards,
Quinn Tran
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordo
On 3/29/2014 2:05 AM, Quinn Tran wrote:
Ram disk is allocating 8x more space than required for diff data.
For large RAM disk test, there is small potential for memory
starvation.
Signed-off-by: Nicholas Bellinger
Signed-off-by: Giridhar Malavali
---
drivers/target/target_core_rd.c | 6 +-
On 3/29/2014 2:05 AM, Quinn Tran wrote:
This patch is borrow code from
commit 0f5e2ec46dd64579c0770f3822764f94db4fa465
Author: Nicholas Bellinger
Date: Sat Jan 18 09:32:56 2014 +
target/file: Add DIF protection init/format support
This patch adds support for DIF protection ini
On 3/29/2014 2:05 AM, Quinn Tran wrote:
Set Protection Type(1,2,3) capabilities, Guarg type (CRC/IPchksm)
capabilities bits to let TCM core knows of HW/fabric capabilities.
Signed-off-by: Nicholas Bellinger
Signed-off-by: Giridhar Malavali
---
drivers/scsi/qla2xxx/tcm_qla2xxx.c | 23
On 3/29/2014 2:05 AM, Quinn Tran wrote:
Check lower layer/HW support of T10-dif capability.
When the LUN is linked between the underlining fabric
and back end device, the Protection Type(1,2,3) is
check against each other to make sure both side are
capable of supporting the same protection settin
+Sagi
+Martin
Regards,
Quinn Tran
On 3/28/14 4:05 PM, "Quinn Tran" wrote:
>Nicholas,
>
>Per our conversation at LSF, the following are the patch set
>of bug fix/tweak found during T10-Dif testing and add ability
>for QLogic FC driver to register with TCM its T10-PI capabilities.
>
>As for th
Set Protection Type(1,2,3) capabilities, Guarg type (CRC/IPchksm)
capabilities bits to let TCM core knows of HW/fabric capabilities.
Signed-off-by: Nicholas Bellinger
Signed-off-by: Giridhar Malavali
---
drivers/scsi/qla2xxx/tcm_qla2xxx.c | 23 +++
drivers/scsi/qla2xxx/tcm_q
Nicholas,
Per our conversation at LSF, the following are the patch set
of bug fix/tweak found during T10-Dif testing and add ability
for QLogic FC driver to register with TCM its T10-PI capabilities.
As for the rest of the other patches that does the actual
T10-Dif data movement, I will submit
Ram disk is allocating 8x more space than required for diff data.
For large RAM disk test, there is small potential for memory
starvation.
Signed-off-by: Nicholas Bellinger
Signed-off-by: Giridhar Malavali
---
drivers/target/target_core_rd.c | 6 +-
1 file changed, 5 insertions(+), 1 deleti
This patch is borrow code from
commit 0f5e2ec46dd64579c0770f3822764f94db4fa465
Author: Nicholas Bellinger
Date: Sat Jan 18 09:32:56 2014 +
target/file: Add DIF protection init/format support
This patch adds support for DIF protection init/format support into
the FILEIO backend
Check lower layer/HW support of T10-dif capability.
When the LUN is linked between the underlining fabric
and back end device, the Protection Type(1,2,3) is
check against each other to make sure both side are
capable of supporting the same protection setting.
ln -s /sys/kernel/config/target/core/r
On Thu, 2014-03-20 at 15:49 -0400, Alan Stern wrote:
> On Thu, 20 Mar 2014, James Bottomley wrote:
>
> > On Thu, 2014-03-20 at 12:34 -0400, Alan Stern wrote:
> > > On Thu, 20 Mar 2014, James Bottomley wrote:
> > >
> > > > OK, so I think we have three things to do
> > > >
> > > > 1. Investig
On 3/28/2014 11:05 PM, Jens Axboe wrote:
On 03/28/2014 02:01 PM, Sagi Grimberg wrote:
No need for this variable anymore - blk_iopoll should always
be enabled. Also remove the user references to it.
I just removed the blk_iopoll_enabled condition from the user logic
but I don't have the faciliti
On 03/28/2014 02:01 PM, Sagi Grimberg wrote:
No need for this variable anymore - blk_iopoll should always
be enabled. Also remove the user references to it.
I just removed the blk_iopoll_enabled condition from the user logic
but I don't have the facilities to test that I didn't break be2iscsi
or
No need for this variable anymore - blk_iopoll should always
be enabled. Also remove the user references to it.
I just removed the blk_iopoll_enabled condition from the user logic
but I don't have the facilities to test that I didn't break be2iscsi
or ipr users, So I was hoping that Jayamohan & We
On Fri, 28 Mar 2014, James Bottomley wrote:
> This is a set of three patches we agreed to a while ago to eliminate a
> USB deadlock. I did rewrite the first patch, if it could be reviewed
> and tested.
I tested all three patches under the same conditions as before, and
they all worked correctly
> From: "Dr. Greg Wettstein"
> If there is an issue it would seem to be in the best interests of
> those of us committed to open-source storage solutions to understand
> and protect ourselves from the situation. There is a third saying
> which is important as well:
If the question is a legitima
We unconditionally execute scsi_eh_get_sense() to make sure all failed
commands that should have sense attached, do. However, the routine forgets
that some commands, because of the way they fail, will not have any sense code
... we should not bother them with a REQUEST_SENSE command. Fix this by
This is a set of three patches we agreed to a while ago to eliminate a
USB deadlock. I did rewrite the first patch, if it could be reviewed
and tested.
Thanks,
James
---
Alan Stern (1):
[SCSI] Fix command result state propagation
James Bottomley (2):
[SCSI] Fix abort state memory problem
From: Alan Stern
We're seeing a case where the contents of scmd->result isn't being reset after
a SCSI command encounters an error, is resubmitted, times out and then gets
handled. The error handler acts on the stale result of the previous error
instead of the timeout. Fix this by properly zero
The abort state is being stored persistently across commands, meaning if the
command times out a second time, the error handler thinks an abort is still
pending. Fix this by properly resetting the abort flag after the abort is
finished.
Signed-off-by: James Bottomley
---
drivers/scsi/scsi_error
On 03/28/2014 05:47 AM, Christoph Hellwig wrote:
On Fri, Mar 28, 2014 at 01:22:15AM -0700, Hannes Reinecke wrote:
Because there is no guarantee that pre-SCSI-3 devices (or devices
announcing to be pre-SCSI-3) will not allow to scan more than 256
devices.
Thinking of older Symmetrix here with the
On 03/27/2014 03:21 PM, Raphaël Bauduin wrote:
Hi,
I have these messages logged on 2 different servers (one production, one
stand-by) when using recent vanilla kernels.
I have found references to these logs, but this was supposedly
introduced in the 2.6.31 kernel.
However, running kernel 2.6.32
On Fri, Mar 28, 2014 at 01:22:15AM -0700, Hannes Reinecke wrote:
> Because there is no guarantee that pre-SCSI-3 devices (or devices
> announcing to be pre-SCSI-3) will not allow to scan more than 256
> devices.
> Thinking of older Symmetrix here with their weird 'SPC-3 masking as
> SCSI-2' habit.
Hello Jayamohan Kallickal,
The patch 1957aa7f6246: "[SCSI] be2iscsi: Fix handling timed out MBX
completion from FW" from Jan 29, 2014, leads to the following static
checker warning:
drivers/scsi/be2iscsi/be_main.c:5581 beiscsi_dev_probe()
error: memset() '&phba->ctrl.ptag_state[i]
The indenting here for "pr_info("\n");" is not correct. It's not part
of the if condition.
Also using pr_info() would put extra characters in the middle of the
line. I suppose that people could complain that pr_cont() is racy but
at least it's better than the original code.
Signed-off-by: Dan C
On 03/27/2014 07:49 AM, Christoph Hellwig wrote:
On Tue, Dec 10, 2013 at 12:05:12PM +0100, Hannes Reinecke wrote:
Sequential scan for more than 256 LUNs is very fragile as
LUNs might not be numbered sequentially after that point.
SAM revisions later than SCSI-3 impose a structure on
LUNs larger
Hello Hans de Goede,
The patch e36e64930cff: "uas: Use GFP_NOIO rather then GFP_ATOMIC
where possible" from Nov 7, 2013, leads to the following static
checker warning:
drivers/usb/storage/uas.c:806 uas_eh_task_mgmt()
error: scheduling with locks held: 'spin_lock:lock'
drivers/usb
30 matches
Mail list logo
