On Fri, Jun 19, 2015 at 08:40:23AM +0200, Hannes Reinecke wrote:
> Having a list here implies that 'se_lun' can have _several_
> se_dev_entry structure attached to it, which I found rather curious.
>
> Can you give me an example where this might be the case?
> Or can we replace the list with a sim
On Thu, Jun 18, 2015 at 11:43:42AM +0200, Hannes Reinecke wrote:
> When LUNs are mapped with a demo-mode initiator we're missing
> the 'write_protect' attribute to set a LUN read-only.
I don't think it's a good idea as-is. The target core clearly
differenciates between demo mode and production mo
On Thu, Jun 18, 2015 at 11:43:41AM +0200, Hannes Reinecke wrote:
> Strictly speaking SPC doesn't require READ CAPACITY and friends
> to be supported while in the port is in standby.
But it does allow it. We should always aim to implement the best
possible behavior instead of aiming for the worst.
What's the benefit of the SAS transport class writeout? I honestly
always saw tcm_loop as a simple loopback driver, with the different
transport IDs in the PR code as a gimmick. Note that vhost and
xen-blkback copies that style and I did plan to consolidate it
in common code.
--
To unsubscribe fr
Hi Nic,
having done the patch to export 'write_protect' for demo-mode LUNs
I've came across one puzzling item:
struct se_lun uses a list to refer to the underlying se_dev_entry
structures. Which I found rather curious, as from my understanding
'se_lun' is the structure for the mapped LUN (ie the
Hi Mike,
I am unaware of your talk with Sony about this issue. Anyways, I will
leave it for Sony to follow it through.
Thanks.
-Minh
On Thu, Jun 18, 2015 at 11:16 PM, Mike Christie wrote:
> On 6/18/15, 8:09 PM, Minh Tran wrote:
>>
>> From: Minh Duc Tran
>>
>> This blocking is ok if we use soft
On 6/18/15, 8:09 PM, Minh Tran wrote:
From: Minh Duc Tran
This blocking is ok if we use software iscsi or iser where each
connection has a separate host. In the case of hw iscsi offload, one
host could have hundreds of connections and some connections may have
IOs running which makes host->hos
From: Minh Duc Tran
This blocking is ok if we use software iscsi or iser where each
connection has a separate host. In the case of hw iscsi offload, one
host could have hundreds of connections and some connections may have
IOs running which makes host->host_busy is always TRUE. Another
problem
On 06/18/15 08:50, Sony John wrote:
We had logged in to the same target through two NIC interfaces. There
were 2 iSCSI-Session and multipath -ll showed the details fine.
The moment we issue logout command on both the session the below
kernel panic happens. If multipath is disabled there is no pa
On 06/18/2015 09:06 AM, Sreekanth Reddy wrote:
> On Thu, Jun 18, 2015 at 5:40 PM, Joe Lawrence
> wrote:
>> On 06/16/2015 01:37 AM, Sreekanth Reddy wrote:
>>> Created a thread using alloc_ordered_workqueue() API in order to process
>>> the works from firmware Work-queue sequentially instead of
>>>
> "Tom" == Tom Yan writes:
Tom> No I put it in the wrong way. What I meant was "sd vs md". For
Tom> example, couldn't the scsi disk driver bind the value it reads from
Tom> the VPD to another variable instead of "optimal i/o size", so that
Tom> this value would be exclusively for RAID (and ot
Dan,
You had noted three concerns covering: mutex_unlock, decode sense data, and a
goto label issue, that were detected during
your static checker run.
I have patches that address these issues.
I am thinking that I need to post these three patches linux-scsi.
Is that correct?
Thanks,
Don Br
Hi,
Any review comments on this patch. please let us known if any changes are
required.
Thanks,
-Raj P.
-Original Message-
From: Rajinikanth Pandurangan
Sent: Wednesday, June 10, 2015 6:42 PM
To: jbottom...@parallels.com; linux-scsi@vger.kernel.org
Cc: aacr...@pmc-sierra.com; Harry Yan
Hi All,
We had logged in to the same target through two NIC interfaces. There
were 2 iSCSI-Session and multipath -ll showed the details fine.
The moment we issue logout command on both the session the below
kernel panic happens. If multipath is disabled there is no panic and
everything works fine
Recently wikipedia announced to secure access to the servers.
Now all http access re-route to https.
Signed-off-by: Masanari Iida
---
Documentation/DocBook/scsi.tmpl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/DocBook/scsi.tmpl b/Documentation/DocBook/scsi.t
On 06/18/2015 01:40 PM, Chris Boot wrote:
> On 18/06/15 10:43, Hannes Reinecke wrote:
>> Strictly speaking SPC doesn't require READ CAPACITY and friends
>> to be supported while in the port is in standby.
>
> Hi Hannes,
>
> I'd really rather this didn't go away. Yes, strictly speaking SPC
> doesn
> -Original Message-
> From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
> Sent: Thursday, June 04, 2015 9:48 AM
> To: Don Brace
> Cc: James E.J. Bottomley; iss_storage...@hp.com; dl Team ESD Storage Dev
> Support; linux-scsi@vger.kernel.org; kernel-janit...@vger.kernel.org
> Subject: [
> -Original Message-
> From: walter harms [mailto:wha...@bfs.de]
> Sent: Thursday, June 04, 2015 10:23 AM
> To: Dan Carpenter
> Cc: Don Brace; James E.J. Bottomley; iss_storage...@hp.com; dl Team ESD
> Storage Dev Support; linux-scsi@vger.kernel.org; kernel-
> janit...@vger.kernel.org
> Sub
On Thu, Jun 18, 2015 at 5:40 PM, Joe Lawrence wrote:
> On 06/16/2015 01:37 AM, Sreekanth Reddy wrote:
>> Created a thread using alloc_ordered_workqueue() API in order to process
>> the works from firmware Work-queue sequentially instead of
>> create_singlethread_workqueue() API.
>>
>> Changes in v
On 06/16/2015 01:37 AM, Sreekanth Reddy wrote:
> Created a thread using alloc_ordered_workqueue() API in order to process
> the works from firmware Work-queue sequentially instead of
> create_singlethread_workqueue() API.
>
> Changes in v1:
> No need to check for backport compatibility in the
hi all:
is so far SCSI support security cdb out/in commands?
if YES, how could I trigger these 2 scsi commands?
Could I trigger these commands by usb devices?
appreciate your help in advance,
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to major
On 18/06/15 10:43, Hannes Reinecke wrote:
> Strictly speaking SPC doesn't require READ CAPACITY and friends
> to be supported while in the port is in standby.
Hi Hannes,
I'd really rather this didn't go away. Yes, strictly speaking SPC
doesn't require these commands but Linux in practice does, an
On Fri, Jun 12, 2015 at 03:12:16PM +0530, Sreekanth Reddy wrote:
> Removed the redundancy code while freeing the controller resources.
>
> Signed-off-by: Sreekanth Reddy
> ---
> drivers/scsi/mpt3sas/mpt3sas_base.c | 57
> +
> 1 file changed, 32 insertions(+),
On Fri, Jun 12, 2015 at 03:12:22PM +0530, Sreekanth Reddy wrote:
> Added the following Dell branding to the mpt3sas driver.
>
> "VendorID" "DeviceID" "SubsystemVendor ID" "SubsystemDevice ID" Dell
> Branding String
> 0x10000x0097 0x1028 0x1F46DELL
Hi,
Any review comments on this patch. please let us known if any changes
are required.
Thanks,
Sreekanth
On Mon, Mar 30, 2015 at 7:25 PM, Sreekanth Reddy
wrote:
> Driver initialization fails if driver tries to send IOC facts request message
> when the IOC is in reset or in a fault state.
>
>
Hi,
Any other review comments on this patch. please let us known if any
changes are required.
Thanks,
Sreekanth
On Fri, Jun 12, 2015 at 4:46 PM, Sreekanth Reddy
wrote:
> Thanks Johannes, we will take care of this point in our current
> on-development mpt2sas/mpt3sas merging activity.
>
>
> Than
Hi,
Any other review comments on this patch. please let us known if any
changes are required.
Thanks,
Sreekanth
On Fri, Jun 12, 2015 at 3:12 PM, Sreekanth Reddy
wrote:
> This Patch will provide more details of the devices such as slot number,
> enclosure logical id, enclosure level & connector
Hi,
Any review comments on this patch. please let us known if any changes
are required.
Thanks,
Sreekanth
On Fri, Jun 12, 2015 at 3:12 PM, Sreekanth Reddy
wrote:
> Add the following OEM's branding to the mpt3sas driver.
>
> "VendorID" "DeviceID" "SubsystemVendor ID" "SubsystemDevice ID" C
Hi,
Any review comments on this patch. please let us known if any changes
are required.
Thanks,
Sreekanth
On Fri, Jun 12, 2015 at 3:12 PM, Sreekanth Reddy
wrote:
> Added support for below customer specific brandings
>
> "VendorID" "DeviceID" "SubsystemVendor ID" "SubsystemDevice ID" Cisco
Hi,
Any other review comments on this patch. please let us known if any
changes are required.
Thanks,
Sreekanth
On Mon, Jun 15, 2015 at 4:18 PM, Johannes Thumshirn wrote:
> On Mon, Jun 15, 2015 at 03:56:56PM +0530, Sreekanth Reddy wrote:
>> On Fri, Jun 12, 2015 at 6:10 PM, Johannes Thumshirn
Hi,
Any review comments on this patch. please let us known if any changes
are required.
Thanks,
Sreekanth
On Mon, Jun 15, 2015 at 5:30 PM, Sreekanth Reddy
wrote:
> On Mon, Jun 15, 2015 at 5:23 PM, Johannes Thumshirn
> wrote:
>> On Mon, Jun 15, 2015 at 04:41:56PM +0530, Sreekanth Reddy wrote:
Hi Nic,
As tcm_loop claims to be a SAS HBA I thought it a good idea to
hook it into the SAS transport class, so that we have the entire
(virtual) SAS topology in sysfs now.
And even lsscsi is happy:
# lsscsi -H -t
[10]tcm_loopback sas:0x6001405cc9332c5a
# lsscsi -t
[10:0:0:0] disksas:0
If tcm_loop emulates a SAS HBA it should hook into the SAS
transport class, too.
Signed-off-by: Hannes Reinecke
---
drivers/target/loopback/tcm_loop.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/target/loopback/tcm_loop.c
b/drivers/target/loopbac
Strictly speaking SPC doesn't require READ CAPACITY and friends
to be supported while in the port is in standby.
Signed-off-by: Hannes Reinecke
---
drivers/target/target_core_alua.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/target/target_core_alua.c
b/drivers/target/ta
Setting the transport status to 'online' needs to rescan the
target, as some devices might have been added while the transport
has been offline.
Signed-off-by: Hannes Reinecke
---
drivers/target/loopback/tcm_loop.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/target/loopb
When LUNs are mapped with a demo-mode initiator we're missing
the 'write_protect' attribute to set a LUN read-only.
Signed-off-by: Hannes Reinecke
---
drivers/target/target_core_device.c | 27 ++
drivers/target/target_core_fabric_configfs.c | 42 +
tcm_loop is able to emulate several protocols, so remove last
vestigies of the SAS protocol.
Signed-off-by: Hannes Reinecke
---
drivers/target/loopback/tcm_loop.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/target/loopback/tcm_loop.c
b/drivers/t
As tcm_loop emulates a SAS HBA it should not only
attach to the SAS transport template but also
populate the SAS device hierarchy.
Signed-off-by: Hannes Reinecke
---
drivers/target/loopback/tcm_loop.c | 139 -
drivers/target/loopback/tcm_loop.h | 3 +
2 file
Whenever a LUN is being assigned we should be sending out an
Power-On/Reset UA.
Signed-off-by: Hannes Reinecke
---
drivers/target/target_core_device.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/target/target_core_device.c
b/drivers/target/targe
If the virtual SAS link is set to 'offline' we should be
queueing an I_T_NEXUS_LOSS_OCCURRED UA.
Signed-off-by: Hannes Reinecke
---
drivers/target/loopback/tcm_loop.c | 5 +
drivers/target/target_core_tpg.c| 17 +
include/target/target_core_fabric.h | 1 +
3 files chan
On Tue, Jun 16, 2015 at 11:05:24AM +0530, Sreekanth Reddy wrote:
> For any SCSI command, if the driver receives
> IOC status = SCSI_IOC_TERMINATED and log info = 0x32010081 then
> that command will be completed with DID_RESET host status.
>
> The definition of this log info value is
> "Virtual IO
41 matches
Mail list logo
