Re: Merging se_dev_entry and se_lun?
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 simple pointer or even merge both? Each initiator has it's own dev entry. What might make sense with the new list-based dev entry handling is to merge the se_lun_acl and se_dev_entry, but it would be a fair amount of work. -- 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/majordomo-info.html
Re: [PATCH 8/8] target: display 'write_protect' attribute for demo-mode LUNs
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 mode read only, and some drivers already expose attributes for these. I have a big series in progress to clean the mess around this area up. So for now please don't add anything here, it should become much simpler after my changes, and I might be able to incorporate something like this after the main series. -- 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/majordomo-info.html
Re: [PATCH 7/8] target_core_alua: disallow READ_CAPACITY when in standby
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. -- 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/majordomo-info.html
Re: [PATCH 0/8] tcm_loop updates
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 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/majordomo-info.html
Merging se_dev_entry and se_lun?
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 LUN visible to the initiator) and 'se_dev_entry' is the underlying physical device as visible to the LUN. As such I would have expected a 1:1 relationship between both, ie a simple pointer from se_lun to se_dev_entry. 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 simple pointer or even merge both? Reason I'm asking is the lun_access / dev_flags field; it really looks like it being a duplicate (I would judge 'write_protect' to be a property of the mapped LUN, and not of the underlying device), but in either case having it in both places requires a synchronisation between both, as for demo-mode LUNs we can only change it via se_lun, and for others we have to change it via the se_dev_entry. Cheers, Hannes -- Dr. Hannes ReineckezSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- 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/majordomo-info.html
Re: problem: connection teardown is always blocked because host is busy doing work on other connections
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 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 is the host_lock taken here is disruptive to other >> connections' EH paths. Wouldn't using target_busy a better choice >> here? >> > > Do you talk to John :) I had told him to do that a couple days ago when you > guys emailed me about this offlist. > > However, I think Christoph wants to remove target_busy so you need to think > of something else. I think you could take the session eh_mutex in the > libiscsi session and conn teardown functions and rely on refcounting and > state checks in the eh callouts. -- 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/majordomo-info.html
Re: problem: connection teardown is always blocked because host is busy doing work on other connections
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->host_busy is always TRUE. Another problem is the host_lock taken here is disruptive to other connections' EH paths. Wouldn't using target_busy a better choice here? Do you talk to John :) I had told him to do that a couple days ago when you guys emailed me about this offlist. However, I think Christoph wants to remove target_busy so you need to think of something else. I think you could take the session eh_mutex in the libiscsi session and conn teardown functions and rely on refcounting and state checks in the eh callouts. -- 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/majordomo-info.html
problem: connection teardown is always blocked because host is busy doing work on other connections
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 is the host_lock taken here is disruptive to other
connections' EH paths. Wouldn't using target_busy a better choice
here?
void iscsi_conn_teardown(struct iscsi_cls_conn *cls_conn)
{
.
...
/*
* Block until all in-progress commands for this connection
* time out or fail.
*/
for (;;) {
spin_lock_irqsave(session->host->host_lock, flags);
if (!atomic_read(&session->host->host_busy)) { /* OK
for ERL == 0 */
spin_unlock_irqrestore(session->host->host_lock, flags);
break;
}
spin_unlock_irqrestore(session->host->host_lock, flags);
msleep_interruptible(500);
iscsi_conn_printk(KERN_INFO, conn, "iscsi conn_destroy(): "
"host_busy %d host_failed %d\n",
atomic_read(&session->host->host_busy),
session->host->host_failed);
/*
* force eh_abort() to unblock
*/
wake_up(&conn->ehwait);
}
--
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/majordomo-info.html
Re: OOPS: While logging out of iSCSI Session when MultiPath is Enabled
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 panic and everything works fine. A similar issue had been reported some time ago on the dm-devel mailing list but should already have been fixed in a later v4.1 rc version. Please retest with v4.1-rc8 or later. Thanks, Bart. -- 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/majordomo-info.html
Re: [PATCH 17/20 v1] [SCSI] mpt3sas: Use alloc_ordered_workqueue() API instead of create_singlethread_workqueue() API
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
>>> create_singlethread_workqueue() API.
>>>
>>> Changes in v1:
>>> No need to check for backport compatibility in the upstream kernel.
>>> so removing the else section where driver use
>>> create_singlethread_workqueue() API if alloc_ordered_workqueue() API is
>>> not defined, This else section is not required since in the latest upstream
>>> kernel this alloc_ordered_workqueue() API is always defined.
>>>
>>> Signed-off-by: Sreekanth Reddy
>>> ---
>>> drivers/scsi/mpt3sas/mpt3sas_scsih.c | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
>>> b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
>>> index b848458..7e5926c 100644
>>> --- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
>>> +++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
>>> @@ -8085,8 +8085,8 @@ _scsih_probe(struct pci_dev *pdev, const struct
>>> pci_device_id *id)
>>> /* event thread */
>>> snprintf(ioc->firmware_event_name, sizeof(ioc->firmware_event_name),
>>> "fw_event%d", ioc->id);
>>> - ioc->firmware_event_thread = create_singlethread_workqueue(
>>> - ioc->firmware_event_name);
>>> + ioc->firmware_event_thread = alloc_ordered_workqueue(
>>> + ioc->firmware_event_name, WQ_MEM_RECLAIM);
>>> if (!ioc->firmware_event_thread) {
>>> pr_err(MPT3SAS_FMT "failure at %s:%d/%s()!\n",
>>> ioc->name, __FILE__, __LINE__, __func__);
>>>
>>
>> Hi Sreekanth,
>>
>> Is this change still needed after e09c2c2954684 workqueue: apply
>> __WQ_ORDERED to create_singlethread_workqueue() ? (3.17+)
>
> I won't say that it is compulsory required, but I feel it is better if
> these changes are included. since initially we thought that thread
> created by using create_singlethread_workqueue() will process the
> works sequentially but in-between it has broken and then it is fixed
> by Tejun. So I thought it is better to directly use the
> alloc_ordered_workqueue() as create_singlethead_workqueue() API also
> invoked the same API.
Ok, I was just wondering if maybe create_singlethread_workqueue was
fixed after this patch was initially written. Since it's effectively
the same...
Reviewed-by: Joe Lawrence
Regards,
-- Joe
--
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/majordomo-info.html
Re: optimal io size / custom alignment
> "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 other virtual Tom> devices)? Who says that RAID is a virtual device? Hardware RAID controllers as well as SAS, iSCSI and Fibre Channel disk arrays all use the Block Limits VPD to communicate their preferred I/O size and alignment to us. As do enterprise disk drives. We deal with broken devices by blacklisting them. I suggest you try to find a way we can reliably identify your UAS devices. If there is a common pattern, we can entertain adding a workaround. -- Martin K. Petersen Oracle Linux Engineering -- 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/majordomo-info.html
hpsa static checker issues
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 Brace -- 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/majordomo-info.html
RE: [Patch V2 5/9] [SCSI] aacraid: Tune response path if IsFastPath bit set
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 Yang; Mahesh Rajashekhara; Rich Bono; Achim
Leubner; Murthy Bhat; Rajinikanth Pandurangan
Subject: [Patch V2 5/9] [SCSI] aacraid: Tune response path if IsFastPath bit set
From: Rajinikanth Pandurangan
Description:
If 'IsFastPath' bit is set, then response path assumes no error
and skips error check.
Signed-off-by: Rajinikanth Pandurangan
---
drivers/scsi/aacraid/aachba.c | 259 ++
1 file changed, 137 insertions(+), 122 deletions(-)
diff --git a/drivers/scsi/aacraid/aachba.c b/drivers/scsi/aacraid/aachba.c
index fe59b00..864e9f6 100644
--- a/drivers/scsi/aacraid/aachba.c
+++ b/drivers/scsi/aacraid/aachba.c
@@ -2977,11 +2977,16 @@ static void aac_srb_callback(void *context, struct fib
* fibptr)
return;
BUG_ON(fibptr == NULL);
-
dev = fibptr->dev;
- srbreply = (struct aac_srb_reply *) fib_data(fibptr);
+ scsi_dma_unmap(scsicmd);
+ /* expose physical device if expose_physicald flag is on */
+ if (scsicmd->cmnd[0] == INQUIRY && !(scsicmd->cmnd[1] & 0x01)
+ && expose_physicals > 0)
+ aac_expose_phy_device(scsicmd);
+
+ srbreply = (struct aac_srb_reply *) fib_data(fibptr);
scsicmd->sense_buffer[0] = '\0'; /* Initialize sense valid flag to
false */
if (fibptr->flags & FIB_CONTEXT_FLAG_FASTRESP) { @@ -2994,147 +2999,157
@@ static void aac_srb_callback(void *context, struct fib * fibptr)
*/
scsi_set_resid(scsicmd, scsi_bufflen(scsicmd)
- le32_to_cpu(srbreply->data_xfer_length));
- }
-
- scsi_dma_unmap(scsicmd);
-
- /* expose physical device if expose_physicald flag is on */
- if (scsicmd->cmnd[0] == INQUIRY && !(scsicmd->cmnd[1] & 0x01)
- && expose_physicals > 0)
- aac_expose_phy_device(scsicmd);
+ /*
+* First check the fib status
+*/
- /*
-* First check the fib status
-*/
+ if (le32_to_cpu(srbreply->status) != ST_OK) {
+ int len;
- if (le32_to_cpu(srbreply->status) != ST_OK){
- int len;
- printk(KERN_WARNING "aac_srb_callback: srb failed, status =
%d\n", le32_to_cpu(srbreply->status));
- len = min_t(u32, le32_to_cpu(srbreply->sense_data_size),
- SCSI_SENSE_BUFFERSIZE);
- scsicmd->result = DID_ERROR << 16 | COMMAND_COMPLETE << 8 |
SAM_STAT_CHECK_CONDITION;
- memcpy(scsicmd->sense_buffer, srbreply->sense_data, len);
- }
+ printk(KERN_WARNING "aac_srb_callback: srb failed,
status = %d\n", le32_to_cpu(srbreply->status));
+ len = min_t(u32, le32_to_cpu(srbreply->sense_data_size),
+ SCSI_SENSE_BUFFERSIZE);
+ scsicmd->result = DID_ERROR << 16
+ | COMMAND_COMPLETE << 8
+ | SAM_STAT_CHECK_CONDITION;
+ memcpy(scsicmd->sense_buffer,
+ srbreply->sense_data, len);
+ }
- /*
-* Next check the srb status
-*/
- switch( (le32_to_cpu(srbreply->srb_status))&0x3f){
- case SRB_STATUS_ERROR_RECOVERY:
- case SRB_STATUS_PENDING:
- case SRB_STATUS_SUCCESS:
- scsicmd->result = DID_OK << 16 | COMMAND_COMPLETE << 8;
- break;
- case SRB_STATUS_DATA_OVERRUN:
- switch(scsicmd->cmnd[0]){
- case READ_6:
- case WRITE_6:
- case READ_10:
- case WRITE_10:
- case READ_12:
- case WRITE_12:
- case READ_16:
- case WRITE_16:
- if (le32_to_cpu(srbreply->data_xfer_length) <
scsicmd->underflow) {
- printk(KERN_WARNING"aacraid: SCSI CMD
underflow\n");
- } else {
- printk(KERN_WARNING"aacraid: SCSI CMD Data
Overrun\n");
+ /*
+* Next check the srb status
+*/
+ switch ((le32_to_cpu(srbreply->srb_status))&0x3f) {
+ case SRB_STATUS_ERROR_RECOVERY:
+ case SRB_STATUS_PENDING:
+ case SRB_STATUS_SUCCESS:
+ scsicmd->result = DID_OK << 16 | COMMAND_COMPLETE << 8;
+ break;
+ case SRB_STATUS_DATA_OVERRUN:
+ switch (scsicmd->cmn
OOPS: While logging out of iSCSI Session when MultiPath is Enabled
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. [ 1529.694046] scsi host7: iSCSI Initiator over TCP/IP [ 1529.788683] scsi host8: iSCSI Initiator over TCP/IP [ 1529.841938] scsi 7:0:0:0: Direct-Access LIO-ORG RAMDISK-MCP 4.0 PQ: 0 ANSI: 5 [ 1529.842682] scsi 8:0:0:0: Direct-Access LIO-ORG RAMDISK-MCP 4.0 PQ: 0 ANSI: 5 [ 1529.849382] scsi 8:0:0:0: alua: supports implicit and explicit TPGS [ 1529.851972] scsi 8:0:0:0: alua: port group 00 rel port 01 [ 1529.852416] scsi 8:0:0:0: alua: port group 00 state A non-preferred supports TOlUSNA [ 1529.852420] scsi 8:0:0:0: alua: Attached [ 1529.855782] sd 8:0:0:0: [sde] 81920 512-byte logical blocks: (41.9 MB/40.0 MiB) [ 1529.858529] sd 8:0:0:0: [sde] Write Protect is off [ 1529.859297] sd 8:0:0:0: [sde] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ 1529.877955] sd 8:0:0:0: [sde] Attached SCSI disk [ 1529.917020] scsi 7:0:0:0: alua: supports implicit and explicit TPGS [ 1529.924986] scsi 7:0:0:0: alua: port group 00 rel port 01 [ 1529.931488] scsi 7:0:0:0: alua: port group 00 state A non-preferred supports TOlUSNA [ 1529.940149] scsi 7:0:0:0: alua: Attached [ 1529.946403] sd 7:0:0:0: [sdf] 81920 512-byte logical blocks: (41.9 MB/40.0 MiB) [ 1529.956420] sd 7:0:0:0: [sdf] Write Protect is off [ 1529.962453] sd 7:0:0:0: [sdf] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ 1529.984070] sd 7:0:0:0: [sdf] Attached SCSI disk [ 1530.072851] device-mapper: multipath service-time: version 0.2.0 loaded [ 1547.063600] sd 8:0:0:0: alua: Detached [ 1547.063652] sd 7:0:0:0: alua: Detached [ 1547.159188] device-mapper: multipath: Failing path 8:64. [ 1547.166336] blk_update_request: I/O error, dev dm-0, sector 81792 [ 1547.173291] BUG: unable to handle kernel NULL pointer dereference at 0138 [ 1547.182134] IP: [] free_rq_clone+0x29/0xb0 [dm_mod] [ 1547.189407] PGD 0 [ 1547.191682] Oops: [#1] SMP [ 1547.195335] Modules linked in: dm_service_time iscsi_tcp libiscsi_tcp xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 tun ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw iptable_filter ip_tables xprtrdma sunrpc ib_isert iscsi_target_mod ib_iser ib_srpt target_core_mod ib_srp scsi_transport_srp ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm x86_pkg_temp_thermal intel_powerclamp ib_sa ib_mad coretemp kvm_intel kvm ocrdma dm_mirror ib_core ib_addr crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel dm_region_hash aesni_intel dm_log lrw gf128mul be2iscsi iTCO_wdt glue_helper ablk_helper sb_edac iTCO_vendor_support edac_core cryptd ipmi_devintf mei_me lpc_ich iscsi_boot_sysfs ipmi_si mei pcspkr mfd_core dcdbas libiscsi scsi_transport_iscsi shpchp wmi ipmi_msghandler acpi_pad acpi_power_meter dm_multipath dm_mod uinput ext4 mbcache jbd2 mgag200 syscopyarea sysfillrect sysimgblt i2c_algo_bit drm_kms_helper sd_mod ttm drm be2net tg3 vxlan ptp ip6_udp_tunnel i2c_core megaraid_sas udp_tunnel pps_core [ 1547.332744] CPU: 6 PID: 52 Comm: ksoftirqd/6 Not tainted 4.1.0-rc1+ #8 [ 1547.340083] Hardware name: Dell Inc. PowerEdge R720/0X6H47, BIOS 2.0.15 07/29/2013 [ 1547.348593] task: 880236372dc0 ti: 8802363a4000 task.ti: 8802363a4000 [ 1547.357009] RIP: 0010:[] [] free_rq_clone+0x29/0xb0 [dm_mod] [ 1547.367007] RSP: 0018:8802363a7ce8 EFLAGS: 00010292 [ 1547.372978] RAX: RBX: 880034e0d9e0 RCX: [ 1547.381007] RDX: RSI: ea0008d5d500 RDI: [ 1547.389033] RBP: 8802363a7d08 R08: 880235755800 R09: 000180200010 [ 1547.397053] R10: 0001 R11: R12: 880034f3d230 [ 1547.405074] R13: 880233ba2000 R14: 880233ba2000 R15: [ 1547.413103] FS: () GS:8802378c() knlGS: [ 1547.422206] CS: 0010 DS: ES: CR0: 80050033 [ 1547.428663] CR2: 0138 CR3: 01a9e000 CR4: 000407e0 [ 1547.436684] Stack: [ 1547.438944] 880236372dc0 fffb 880034e0d9e0 880034e0d870 [ 1547.447303] 8802363a7d48 a0095187 8802363a7d38 880034e0d8e8 [ 1547.455663] 880034e0d870 8802363a7d60 0100 [ 1547.464019] Call Trace: [ 1547.466784] [] dm_softirq_done+0x137/0x250 [dm_mod] [ 1547.474117] [] blk_done_softirq+0x98/0xc0 [
[PATCH] Doc: Docbook: Change wikipedia's URL from http to https in scsi.tmpl
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.tmpl index 324b534..4b9b9b2 100644 --- a/Documentation/DocBook/scsi.tmpl +++ b/Documentation/DocBook/scsi.tmpl @@ -81,7 +81,7 @@ SAS, Fibre Channel, FireWire, and ATAPI devices. SCSI packets are also commonly exchanged over Infiniband, I20, TCP/IP -(iSCSI), even +(iSCSI), even Parallel ports. -- 2.4.4.408.g16da57c -- 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/majordomo-info.html
Re: [PATCH 7/8] target_core_alua: disallow READ_CAPACITY when in standby
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't require these commands but Linux in practice does, and ISTR this > was added at my request too. > > We need it on our storage setups to prevent the Linux SCSI stack from > exploding. If this is removed here, they'll start exploding again until > the fix goes in and the initiators are updated. > This was exactly why I added it, so that one could go about and fix the linux SCSI stack :-) > Could this please be kept as an option or something? > Yeah, I see what I can do. Cheers, Hannes -- Dr. Hannes ReineckezSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- 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/majordomo-info.html
RE: [patch] hpsa: fix an sprintf() overflow in the reset handler
> -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: [patch] hpsa: fix an sprintf() overflow in the reset handler
>
> The string "cmd %d RESET FAILED, new lockup detected" is not quite
> large enough so the sprintf() will overflow. I have increased the size
> of the buffer and also changed the sprintf calls to snprintf.
>
> Fixes: 73153fe533bc ('hpsa: use block layer tag for command allocation')
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
> index 1dafeb4..cab4e98 100644
> --- a/drivers/scsi/hpsa.c
> +++ b/drivers/scsi/hpsa.c
> @@ -5104,7 +5104,7 @@ static int hpsa_eh_device_reset_handler(struct
> scsi_cmnd *scsicmd)
> int rc;
> struct ctlr_info *h;
> struct hpsa_scsi_dev_t *dev;
> - char msg[40];
> + char msg[48];
>
> /* find the controller to which the command to be aborted was sent */
> h = sdev_to_hba(scsicmd->device);
> @@ -5122,16 +5122,18 @@ static int hpsa_eh_device_reset_handler(struct
> scsi_cmnd *scsicmd)
>
> /* if controller locked up, we can guarantee command won't complete
> */
> if (lockup_detected(h)) {
> - sprintf(msg, "cmd %d RESET FAILED, lockup detected",
> - hpsa_get_cmd_index(scsicmd));
> + snprintf(msg, sizeof(msg),
> + "cmd %d RESET FAILED, lockup detected",
> + hpsa_get_cmd_index(scsicmd));
> hpsa_show_dev_msg(KERN_WARNING, h, dev, msg);
> return FAILED;
> }
>
> /* this reset request might be the result of a lockup; check */
> if (detect_controller_lockup(h)) {
> - sprintf(msg, "cmd %d RESET FAILED, new lockup detected",
> - hpsa_get_cmd_index(scsicmd));
> + snprintf(msg, sizeof(msg),
> + "cmd %d RESET FAILED, new lockup detected",
> + hpsa_get_cmd_index(scsicmd));
> hpsa_show_dev_msg(KERN_WARNING, h, dev, msg);
> return FAILED;
> }
> @@ -5145,7 +5147,8 @@ static int hpsa_eh_device_reset_handler(struct
> scsi_cmnd *scsicmd)
> /* send a reset to the SCSI LUN which the command was sent to */
> rc = hpsa_do_reset(h, dev, dev->scsi3addr, HPSA_RESET_TYPE_LUN,
> DEFAULT_REPLY_QUEUE);
> - sprintf(msg, "reset %s", rc == 0 ? "completed successfully" : "failed");
> + snprintf(msg, sizeof(msg), "reset %s",
> + rc == 0 ? "completed successfully" : "failed");
> hpsa_show_dev_msg(KERN_WARNING, h, dev, msg);
> return rc == 0 ? SUCCESS : FAILED;
> }
Signed-off-by: Don Brace
--
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/majordomo-info.html
RE: [patch] hpsa: fix an sprintf() overflow in the reset handler
> -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
> Subject: Re: [patch] hpsa: fix an sprintf() overflow in the reset handler
>
>
>
> Am 04.06.2015 16:47, schrieb Dan Carpenter:
> > The string "cmd %d RESET FAILED, new lockup detected" is not quite
> > large enough so the sprintf() will overflow. I have increased the size
> > of the buffer and also changed the sprintf calls to snprintf.
> >
> > Fixes: 73153fe533bc ('hpsa: use block layer tag for command allocation')
> > Signed-off-by: Dan Carpenter
> >
> > diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
> > index 1dafeb4..cab4e98 100644
> > --- a/drivers/scsi/hpsa.c
> > +++ b/drivers/scsi/hpsa.c
> > @@ -5104,7 +5104,7 @@ static int hpsa_eh_device_reset_handler(struct
> scsi_cmnd *scsicmd)
> > int rc;
> > struct ctlr_info *h;
> > struct hpsa_scsi_dev_t *dev;
> > - char msg[40];
> > + char msg[48];
> >
> > /* find the controller to which the command to be aborted was sent */
> > h = sdev_to_hba(scsicmd->device);
> > @@ -5122,16 +5122,18 @@ static int hpsa_eh_device_reset_handler(struct
> scsi_cmnd *scsicmd)
> >
> > /* if controller locked up, we can guarantee command won't complete
> */
> > if (lockup_detected(h)) {
> > - sprintf(msg, "cmd %d RESET FAILED, lockup detected",
> > - hpsa_get_cmd_index(scsicmd));
> > + snprintf(msg, sizeof(msg),
> > +"cmd %d RESET FAILED, lockup detected",
> > +hpsa_get_cmd_index(scsicmd));
> > hpsa_show_dev_msg(KERN_WARNING, h, dev, msg);
> > return FAILED;
> > }
> >
> > /* this reset request might be the result of a lockup; check */
> > if (detect_controller_lockup(h)) {
> > - sprintf(msg, "cmd %d RESET FAILED, new lockup detected",
> > - hpsa_get_cmd_index(scsicmd));
> > + snprintf(msg, sizeof(msg),
> > +"cmd %d RESET FAILED, new lockup detected",
> > +hpsa_get_cmd_index(scsicmd));
> > hpsa_show_dev_msg(KERN_WARNING, h, dev, msg);
> > return FAILED;
> > }
> > @@ -5145,7 +5147,8 @@ static int hpsa_eh_device_reset_handler(struct
> scsi_cmnd *scsicmd)
> > /* send a reset to the SCSI LUN which the command was sent to */
> > rc = hpsa_do_reset(h, dev, dev->scsi3addr, HPSA_RESET_TYPE_LUN,
> >DEFAULT_REPLY_QUEUE);
> > - sprintf(msg, "reset %s", rc == 0 ? "completed successfully" : "failed");
> > + snprintf(msg, sizeof(msg), "reset %s",
> > +rc == 0 ? "completed successfully" : "failed");
> > hpsa_show_dev_msg(KERN_WARNING, h, dev, msg);
> > return rc == 0 ? SUCCESS : FAILED;
> > }
>
>
> there is something called dev_printk_emit() what seems the varg version of
> dev_printk()
> (what is behind psa_show_dev_msg()) maybe it would be better to redefine the
> interface
> to use varargs ?
>
> Its up to the maintainer to decide, i do not know how often
> hpsa_show_dev_msg is actualy used.
>
> just my 2 cents,
> wh
>
Thanks. I'll check into this and add it in as an update if necessary.
--
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/majordomo-info.html
Re: [PATCH 17/20 v1] [SCSI] mpt3sas: Use alloc_ordered_workqueue() API instead of create_singlethread_workqueue() API
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 v1:
>> No need to check for backport compatibility in the upstream kernel.
>> so removing the else section where driver use
>> create_singlethread_workqueue() API if alloc_ordered_workqueue() API is
>> not defined, This else section is not required since in the latest upstream
>> kernel this alloc_ordered_workqueue() API is always defined.
>>
>> Signed-off-by: Sreekanth Reddy
>> ---
>> drivers/scsi/mpt3sas/mpt3sas_scsih.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
>> b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
>> index b848458..7e5926c 100644
>> --- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
>> +++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
>> @@ -8085,8 +8085,8 @@ _scsih_probe(struct pci_dev *pdev, const struct
>> pci_device_id *id)
>> /* event thread */
>> snprintf(ioc->firmware_event_name, sizeof(ioc->firmware_event_name),
>> "fw_event%d", ioc->id);
>> - ioc->firmware_event_thread = create_singlethread_workqueue(
>> - ioc->firmware_event_name);
>> + ioc->firmware_event_thread = alloc_ordered_workqueue(
>> + ioc->firmware_event_name, WQ_MEM_RECLAIM);
>> if (!ioc->firmware_event_thread) {
>> pr_err(MPT3SAS_FMT "failure at %s:%d/%s()!\n",
>> ioc->name, __FILE__, __LINE__, __func__);
>>
>
> Hi Sreekanth,
>
> Is this change still needed after e09c2c2954684 workqueue: apply
> __WQ_ORDERED to create_singlethread_workqueue() ? (3.17+)
I won't say that it is compulsory required, but I feel it is better if
these changes are included. since initially we thought that thread
created by using create_singlethread_workqueue() will process the
works sequentially but in-between it has broken and then it is fixed
by Tejun. So I thought it is better to directly use the
alloc_ordered_workqueue() as create_singlethead_workqueue() API also
invoked the same API.
>
> In upstream, this change looks cosmetic (unless Tejun has a preference
> for one over the other), but maybe converting to alloc_ordered_workqueue
> keeps your in house version in closer sync?
>
> Thanks,
>
> -- Joe
--
Regards,
Sreekanth
--
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/majordomo-info.html
Re: [PATCH 17/20 v1] [SCSI] mpt3sas: Use alloc_ordered_workqueue() API instead of create_singlethread_workqueue() API
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 upstream kernel.
> so removing the else section where driver use
> create_singlethread_workqueue() API if alloc_ordered_workqueue() API is
> not defined, This else section is not required since in the latest upstream
> kernel this alloc_ordered_workqueue() API is always defined.
>
> Signed-off-by: Sreekanth Reddy
> ---
> drivers/scsi/mpt3sas/mpt3sas_scsih.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> index b848458..7e5926c 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> +++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> @@ -8085,8 +8085,8 @@ _scsih_probe(struct pci_dev *pdev, const struct
> pci_device_id *id)
> /* event thread */
> snprintf(ioc->firmware_event_name, sizeof(ioc->firmware_event_name),
> "fw_event%d", ioc->id);
> - ioc->firmware_event_thread = create_singlethread_workqueue(
> - ioc->firmware_event_name);
> + ioc->firmware_event_thread = alloc_ordered_workqueue(
> + ioc->firmware_event_name, WQ_MEM_RECLAIM);
> if (!ioc->firmware_event_thread) {
> pr_err(MPT3SAS_FMT "failure at %s:%d/%s()!\n",
> ioc->name, __FILE__, __LINE__, __func__);
>
Hi Sreekanth,
Is this change still needed after e09c2c2954684 workqueue: apply
__WQ_ORDERED to create_singlethread_workqueue() ? (3.17+)
In upstream, this change looks cosmetic (unless Tejun has a preference
for one over the other), but maybe converting to alloc_ordered_workqueue
keeps your in house version in closer sync?
Thanks,
-- Joe
--
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/majordomo-info.html
some question about scsi cdb security code
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/8] target_core_alua: disallow READ_CAPACITY when in standby
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, and ISTR this
was added at my request too.
We need it on our storage setups to prevent the Linux SCSI stack from
exploding. If this is removed here, they'll start exploding again until
the fix goes in and the initiators are updated.
Could this please be kept as an option or something?
Cheers,
Chris
> 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/target_core_alua.c
> index edaf1b9..a62e58b 100644
> --- a/drivers/target/target_core_alua.c
> +++ b/drivers/target/target_core_alua.c
> @@ -561,16 +561,7 @@ static inline int core_alua_state_standby(
> case REPORT_LUNS:
> case RECEIVE_DIAGNOSTIC:
> case SEND_DIAGNOSTIC:
> - case READ_CAPACITY:
> return 0;
> - case SERVICE_ACTION_IN_16:
> - switch (cdb[1] & 0x1f) {
> - case SAI_READ_CAPACITY_16:
> - return 0;
> - default:
> - set_ascq(cmd, ASCQ_04H_ALUA_TG_PT_STANDBY);
> - return 1;
> - }
> case MAINTENANCE_IN:
> switch (cdb[1] & 0x1f) {
> case MI_REPORT_TARGET_PGS:
>
--
Chris Boot
bo...@bootc.net
--
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/majordomo-info.html
Re: [PATCH 04/20] [SCSI] mpt3sas: Remove redundancy code while freeing the controller resources.
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(+), 25 deletions(-)
>
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
> b/drivers/scsi/mpt3sas/mpt3sas_base.c
> index ce57320..32b86bf 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_base.c
> +++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
> @@ -1798,6 +1798,36 @@ _base_enable_msix(struct MPT3SAS_ADAPTER *ioc)
> }
>
> /**
> + * mpt3sas_base_unmap_resources - free controller resources
> + * @ioc: per adapter object
> + */
> +void
> +mpt3sas_base_unmap_resources(struct MPT3SAS_ADAPTER *ioc)
> +{
> + struct pci_dev *pdev = ioc->pdev;
> +
> + dexitprintk(ioc, printk(MPT3SAS_FMT "%s\n",
> + ioc->name, __func__));
> +
> + _base_free_irq(ioc);
> + _base_disable_msix(ioc);
> +
> + if (ioc->msix96_vector)
> + kfree(ioc->replyPostRegisterIndex);
> +
> + if (ioc->chip_phys) {
> + iounmap(ioc->chip);
> + ioc->chip_phys = 0;
> + }
> +
> + if (pci_is_enabled(pdev)) {
> + pci_release_selected_regions(ioc->pdev, ioc->bars);
> + pci_disable_pcie_error_reporting(pdev);
> + pci_disable_device(pdev);
> + }
> +}
> +
> +/**
> * mpt3sas_base_map_resources - map in controller resources (io/irq/memap)
> * @ioc: per adapter object
> *
> @@ -1925,14 +1955,7 @@ mpt3sas_base_map_resources(struct MPT3SAS_ADAPTER *ioc)
> return 0;
>
> out_fail:
> - if (ioc->chip_phys)
> - iounmap(ioc->chip);
> - ioc->chip_phys = 0;
> - pci_release_selected_regions(ioc->pdev, ioc->bars);
> - pci_disable_pcie_error_reporting(pdev);
> - pci_disable_device(pdev);
> - if (ioc->msix96_vector)
> - kfree(ioc->replyPostRegisterIndex);
> + mpt3sas_base_unmap_resources(ioc);
> return r;
> }
>
> @@ -4667,8 +4690,6 @@ _base_make_ioc_operational(struct MPT3SAS_ADAPTER *ioc,
> int sleep_flag)
> void
> mpt3sas_base_free_resources(struct MPT3SAS_ADAPTER *ioc)
> {
> - struct pci_dev *pdev = ioc->pdev;
> -
> dexitprintk(ioc, pr_info(MPT3SAS_FMT "%s\n", ioc->name,
> __func__));
>
> @@ -4679,21 +4700,7 @@ mpt3sas_base_free_resources(struct MPT3SAS_ADAPTER
> *ioc)
> ioc->shost_recovery = 0;
> }
>
> - _base_free_irq(ioc);
> - _base_disable_msix(ioc);
> -
> - if (ioc->msix96_vector)
> - kfree(ioc->replyPostRegisterIndex);
> -
> - if (ioc->chip_phys && ioc->chip)
> - iounmap(ioc->chip);
> - ioc->chip_phys = 0;
> -
> - if (pci_is_enabled(pdev)) {
> - pci_release_selected_regions(ioc->pdev, ioc->bars);
> - pci_disable_pcie_error_reporting(pdev);
> - pci_disable_device(pdev);
> - }
> + mpt3sas_base_unmap_resources(ioc);
> return;
> }
>
> --
> 2.0.2
>
> --
> 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/majordomo-info.html
Reviewed-by: Johannes Thumshirn
--
Johannes Thumshirn Storage
jthumsh...@suse.de +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
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/majordomo-info.html
Re: [PATCH 10/20] [SCSI] mpt3sas: Add branding string support for OEM's HBA
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
> 12Gbps HBA
>
> Signed-off-by: Sreekanth Reddy
> ---
> drivers/scsi/mpt3sas/mpt3sas_base.c | 36
> drivers/scsi/mpt3sas/mpt3sas_base.h | 11 +++
> 2 files changed, 47 insertions(+)
>
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
> b/drivers/scsi/mpt3sas/mpt3sas_base.c
> index 6739c0a..db362cb 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_base.c
> +++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
> @@ -2345,6 +2345,41 @@ _base_display_intel_branding(struct MPT3SAS_ADAPTER
> *ioc)
>
>
> /**
> + * _base_display_dell_branding - Display branding string
> + * @ioc: per adapter object
> + *
> + * Return nothing.
> + */
> +static void
> +_base_display_dell_branding(struct MPT3SAS_ADAPTER *ioc)
> +{
> + if (ioc->pdev->subsystem_vendor != PCI_VENDOR_ID_DELL)
> + return;
> +
> + switch (ioc->pdev->device) {
> + case MPI25_MFGPAGE_DEVID_SAS3008:
> + switch (ioc->pdev->subsystem_device) {
> + case MPT3SAS_DELL_12G_HBA_SSDID:
> + pr_info(MPT3SAS_FMT "%s\n", ioc->name,
> + MPT3SAS_DELL_12G_HBA_BRANDING);
> + break;
> + default:
> + pr_info(MPT3SAS_FMT
> +"Dell 12Gbps HBA: Subsystem ID: 0x%X\n", ioc->name,
> +ioc->pdev->subsystem_device);
> + break;
> + }
> + break;
> + default:
> + pr_info(MPT3SAS_FMT
> + "Dell 12Gbps HBA: Subsystem ID: 0x%X\n", ioc->name,
> + ioc->pdev->subsystem_device);
> + break;
> + }
> +}
> +
> +
> +/**
> * _base_display_ioc_capabilities - Disply IOC's capabilities.
> * @ioc: per adapter object
> *
> @@ -2374,6 +2409,7 @@ _base_display_ioc_capabilities(struct MPT3SAS_ADAPTER
> *ioc)
> bios_version & 0x00FF);
>
> _base_display_intel_branding(ioc);
> + _base_display_dell_branding(ioc);
>
> pr_info(MPT3SAS_FMT "Protocol=(", ioc->name);
>
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h
> b/drivers/scsi/mpt3sas/mpt3sas_base.h
> index 2318ef8..c4780c7 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_base.h
> +++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
> @@ -152,6 +152,17 @@
> #define MPT3SAS_INTEL_RS3UC080_SSDID0x3524
>
> /*
> + * Dell HBA branding
> + */
> +#define MPT3SAS_DELL_12G_HBA_BRANDING \
> + "Dell 12Gbps HBA"
> +
> +/*
> + * Dell HBA SSDIDs
> + */
> +#define MPT3SAS_DELL_12G_HBA_SSDID 0x1F46
> +
> +/*
> * status bits for ioc->diag_buffer_status
> */
> #define MPT3_DIAG_BUFFER_IS_REGISTERED (0x01)
> --
> 2.0.2
>
> --
> 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/majordomo-info.html
Reviewed-by: Johannes Thumshirn
--
Johannes Thumshirn Storage
jthumsh...@suse.de +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
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/majordomo-info.html
Re: [PATCH 02/20] [SCSI] mpt3sas: Get IOC_FACTS information using handshake protocol only after HBA card gets into READY or Operational state.
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.
>
> This patch will make sure that
> 1.Driver to send IOC facts request message only if HBA is in operational or
> ready state.
> 2.If IOC is in fault state, a diagnostic reset would be issued.
> 3.If IOC is in reset state then driver will wait for 10 seconds to exit out
> of reset state.
>If the HBA continues to be in reset state, then the HBA wouldn't be
> claimed by the driver.
>
> Signed-off-by: Sreekanth Reddy
> ---
> drivers/scsi/mpt3sas/mpt3sas_base.c | 65
> +
> 1 file changed, 65 insertions(+)
>
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
> b/drivers/scsi/mpt3sas/mpt3sas_base.c
> index c13a365..ce57320 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_base.c
> +++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
> @@ -3169,6 +3169,9 @@ _base_wait_on_iocstate(struct MPT3SAS_ADAPTER *ioc, u32
> ioc_state, int timeout,
> * Notes: MPI2_HIS_IOC2SYS_DB_STATUS - set to one when IOC writes to
> doorbell.
> */
> static int
> +_base_diag_reset(struct MPT3SAS_ADAPTER *ioc, int sleep_flag);
> +
> +static int
> _base_wait_for_doorbell_int(struct MPT3SAS_ADAPTER *ioc, int timeout,
> int sleep_flag)
> {
> @@ -3711,6 +3714,61 @@ _base_get_port_facts(struct MPT3SAS_ADAPTER *ioc, int
> port, int sleep_flag)
> }
>
> /**
> + * _base_wait_for_iocstate - Wait until the card is in READY or OPERATIONAL
> + * @ioc: per adapter object
> + * @timeout:
> + * @sleep_flag: CAN_SLEEP or NO_SLEEP
> + *
> + * Returns 0 for success, non-zero for failure.
> + */
> +static int
> +_base_wait_for_iocstate(struct MPT3SAS_ADAPTER *ioc, int timeout,
> + int sleep_flag)
> +{
> + u32 ioc_state;
> + int rc;
> +
> + dinitprintk(ioc, printk(MPT3SAS_FMT "%s\n", ioc->name,
> + __func__));
> +
> + if (ioc->pci_error_recovery)
> + return 0;
> +
> + ioc_state = mpt3sas_base_get_iocstate(ioc, 0);
> + dhsprintk(ioc, printk(MPT3SAS_FMT "%s: ioc_state(0x%08x)\n",
> + ioc->name, __func__, ioc_state));
> +
> + if (((ioc_state & MPI2_IOC_STATE_MASK) == MPI2_IOC_STATE_READY) ||
> + (ioc_state & MPI2_IOC_STATE_MASK) == MPI2_IOC_STATE_OPERATIONAL)
> + return 0;
> +
> + if (ioc_state & MPI2_DOORBELL_USED) {
> + dhsprintk(ioc, printk(MPT3SAS_FMT
> + "unexpected doorbell active!\n", ioc->name));
> + goto issue_diag_reset;
> + }
> +
> + if ((ioc_state & MPI2_IOC_STATE_MASK) == MPI2_IOC_STATE_FAULT) {
> + mpt3sas_base_fault_info(ioc, ioc_state &
> + MPI2_DOORBELL_DATA_MASK);
> + goto issue_diag_reset;
> + }
> +
> + ioc_state = _base_wait_on_iocstate(ioc, MPI2_IOC_STATE_READY,
> + timeout, sleep_flag);
> + if (ioc_state) {
> + dfailprintk(ioc, printk(MPT3SAS_FMT
> + "%s: failed going to ready state (ioc_state=0x%x)\n",
> + ioc->name, __func__, ioc_state));
> + return -EFAULT;
> + }
> +
> + issue_diag_reset:
> + rc = _base_diag_reset(ioc, sleep_flag);
> + return rc;
> +}
> +
> +/**
> * _base_get_ioc_facts - obtain ioc facts reply and save in ioc
> * @ioc: per adapter object
> * @sleep_flag: CAN_SLEEP or NO_SLEEP
> @@ -3728,6 +3786,13 @@ _base_get_ioc_facts(struct MPT3SAS_ADAPTER *ioc, int
> sleep_flag)
> dinitprintk(ioc, pr_info(MPT3SAS_FMT "%s\n", ioc->name,
> __func__));
>
> + r = _base_wait_for_iocstate(ioc, 10, sleep_flag);
> + if (r) {
> + dfailprintk(ioc, printk(MPT3SAS_FMT
> + "%s: failed getting to correct state\n",
> + ioc->name, __func__));
> + return r;
> + }
> mpi_reply_sz = sizeof(Mpi2IOCFactsReply_t);
> mpi_request_sz = sizeof(Mpi2IOCFactsRequest_t);
> memset(&mpi_request, 0, mpi_request_sz);
> --
> 2.0.2
>
--
Regards,
Sreekanth
--
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/majordomo-info.html
Re: [PATCH 01/20] [SCSI] mpt3sas: Added Combined Reply Queue feature to extend up-to 96 MSIX vector support
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.
>
>
> Thanks,
> Sreekanth
>
> On Fri, Jun 12, 2015 at 4:39 PM, Johannes Thumshirn
> wrote:
>> On Fri, Jun 12, 2015 at 03:12:13PM +0530, Sreekanth Reddy wrote:
>>> In this patch, increased the number of MSIX vector support for SAS3 C0 HBAs
>>> to up-to 96.
>>>
>>> Following are changes that are done in this patch
>>> 1. Support this feature only for SAS3 C0 cards and also only when reply
>>> post free queue count is greater than 8.
>>> 2. Instead of using single ReplyPostHostIndex system interface, here 12
>>> ReplyPostHostIndex system interfaces are used. reply post free queues
>>> numbered from 0 to 7 use the first ReplyPostHostIndex system interface to
>>> update its corresponding ReplyPostHostIndex values, reply post free queues
>>> numbered from 8 to 15 will use the second ReplyPostHostIndex system
>>> interface and so on. These 12 ReplyPostHostIndex system interfaces address
>>> are saved in the array replyPostRegisterIndex[].
>>> 3. Update the ReplyPostHostIndex value of corresponding reply post free
>>> queue in the (its msix_index/8)th entry of replyPostRegisterIndex[] array
>>> after processing the reply post descriptor.
>>>
>>> Signed-off-by: Sreekanth Reddy
>>> ---
>>> drivers/scsi/mpt3sas/mpt3sas_base.c | 70
>>> +
>>> drivers/scsi/mpt3sas/mpt3sas_base.h | 7 +++-
>>> 2 files changed, 69 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
>>> b/drivers/scsi/mpt3sas/mpt3sas_base.c
>>> index 14a781b..c13a365 100644
>>> --- a/drivers/scsi/mpt3sas/mpt3sas_base.c
>>> +++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
>>> @@ -83,7 +83,7 @@ static int msix_disable = -1;
>>> module_param(msix_disable, int, 0);
>>> MODULE_PARM_DESC(msix_disable, " disable msix routed interrupts
>>> (default=0)");
>>>
>>> -static int max_msix_vectors = 8;
>>> +static int max_msix_vectors = -1;
>>> module_param(max_msix_vectors, int, 0);
>>> MODULE_PARM_DESC(max_msix_vectors,
>>> " max msix vectors - (default=8)");
>>
>> When changing the default value, please also update the description
>> reflecting
>> this change.
>>
>>> @@ -1009,8 +1009,15 @@ _base_interrupt(int irq, void *bus_id)
>>> }
>>>
>>> wmb();
>>> - writel(reply_q->reply_post_host_index | (msix_index <<
>>> - MPI2_RPHI_MSIX_INDEX_SHIFT), &ioc->chip->ReplyPostHostIndex);
>>> + if (ioc->msix96_vector) {
>>> + writel(reply_q->reply_post_host_index | ((msix_index & 7) <<
>>> + MPI2_RPHI_MSIX_INDEX_SHIFT),
>>> + ioc->replyPostRegisterIndex[msix_index/8]);
>>> + } else {
>>> + writel(reply_q->reply_post_host_index | (msix_index <<
>>> + MPI2_RPHI_MSIX_INDEX_SHIFT),
>>> + &ioc->chip->ReplyPostHostIndex);
>>> + }
>>> atomic_dec(&reply_q->busy);
>>> return IRQ_HANDLED;
>>> }
>>> @@ -1560,8 +1567,6 @@ _base_check_enable_msix(struct MPT3SAS_ADAPTER *ioc)
>>>
>>> pci_read_config_word(ioc->pdev, base + 2, &message_control);
>>> ioc->msix_vector_count = (message_control & 0x3FF) + 1;
>>> - if (ioc->msix_vector_count > 8)
>>> - ioc->msix_vector_count = 8;
>>> dinitprintk(ioc, pr_info(MPT3SAS_FMT
>>> "msix is supported, vector_count(%d)\n",
>>> ioc->name, ioc->msix_vector_count));
>>> @@ -1880,6 +1885,31 @@ mpt3sas_base_map_resources(struct MPT3SAS_ADAPTER
>>> *ioc)
>>> if (r)
>>> goto out_fail;
>>>
>>> + /* Use the Combined reply queue feature only for SAS3 C0 HBAs and
>>> + * also only when reply queue count is greater than 8
>>> + */
>>> + if (ioc->msix96_vector && ioc->reply_queue_count > 8) {
>>> + /* If this is an 96 vector supported device,
>>> + set up ReplyPostIndex addresses */
>>> + ioc->replyPostRegisterIndex = kcalloc(12,
>>> + sizeof(resource_size_t *), GFP_KERNEL);
>>> + if (!ioc->replyPostRegisterIndex) {
>>> + dfailprintk(ioc, printk(MPT3SAS_FMT
>>> + "allocation for reply Post Register Index
>>> failed!!!\n",
>>> +
>>> ioc->name));
>>> + r = -ENOMEM;
>>> + goto out_fail;
>>> + }
>>> +
>>> + for (i = 0; i < 12; i++) {
>>> + ioc->replyPostRegisterIndex[i] = (resource_size_t *)
>>> + ((u8 *)&ioc->chip->Doorbell +
>>> + MPI25_SUP_REPLY_POST_HOST_INDEX_OFFSET +
>>> + (i * 0x10));
>>> +
Re: [PATCH 06/20] [SCSI] mpt3sas: Provides the physical location of sas drives
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 name in the following
> scenarios,
>
> - When end device is added in the topology,
> - When the end device is removed from the setup,
> - When the SCSI mid layer issues TASK ABORT/ DEVICE RESET/ TARGET RESET
> during error handling,
> - When any command to the device fails with Sense key Hardware error or
> Medium error or Unit Attention,
> - When firmware returns device error or device not ready status for the end
> device,
> - When a Predicted fault is detected on an end device.
>
> This information can be used by the user to identify the location of the
> desired drive in the topology.
>
> Driver will get these information by reading the sas device page0.
>
> Signed-off-by: Sreekanth Reddy
> ---
> drivers/scsi/mpt3sas/mpt3sas_base.h | 2 +
> drivers/scsi/mpt3sas/mpt3sas_scsih.c | 238
> +--
> 2 files changed, 201 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h
> b/drivers/scsi/mpt3sas/mpt3sas_base.h
> index b79ad4f..293ad23 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_base.h
> +++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
> @@ -317,6 +317,8 @@ struct _sas_device {
> u8 fast_path;
> u8 pfa_led_on;
> u8 pend_sas_rphy_add;
> + u8 enclosure_level;
> + u8 connector_name[4];
> };
>
> /**
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> index d457dba..64dd90b 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> +++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> @@ -585,6 +585,22 @@ _scsih_sas_device_remove(struct MPT3SAS_ADAPTER *ioc,
>
> if (!sas_device)
> return;
> + pr_info(MPT3SAS_FMT
> + "removing handle(0x%04x), sas_addr(0x%016llx)\n",
> + ioc->name, sas_device->handle,
> + (unsigned long long) sas_device->sas_address);
> +
> + if (sas_device->enclosure_handle != 0)
> + pr_info(MPT3SAS_FMT
> + "removing enclosure logical id(0x%016llx), slot(%d)\n",
> + ioc->name, (unsigned long long)
> + sas_device->enclosure_logical_id, sas_device->slot);
> +
> + if (sas_device->connector_name[0] != '\0')
> + pr_info(MPT3SAS_FMT
> + "removing enclosure level(0x%04x), connector name( %s)\n",
> + ioc->name, sas_device->enclosure_level,
> + sas_device->connector_name);
>
> spin_lock_irqsave(&ioc->sas_device_lock, flags);
> list_del(&sas_device->list);
> @@ -663,6 +679,18 @@ _scsih_sas_device_add(struct MPT3SAS_ADAPTER *ioc,
> ioc->name, __func__, sas_device->handle,
> (unsigned long long)sas_device->sas_address));
>
> + if (sas_device->enclosure_handle != 0)
> + dewtprintk(ioc, pr_info(MPT3SAS_FMT
> + "%s: enclosure logical id(0x%016llx), slot( %d)\n",
> + ioc->name, __func__, (unsigned long long)
> + sas_device->enclosure_logical_id, sas_device->slot));
> +
> + if (sas_device->connector_name[0] != '\0')
> + dewtprintk(ioc, pr_info(MPT3SAS_FMT
> + "%s: enclosure level(0x%04x), connector name( %s)\n",
> + ioc->name, __func__,
> + sas_device->enclosure_level, sas_device->connector_name));
> +
> spin_lock_irqsave(&ioc->sas_device_lock, flags);
> list_add_tail(&sas_device->list, &ioc->sas_device_list);
> spin_unlock_irqrestore(&ioc->sas_device_lock, flags);
> @@ -704,6 +732,18 @@ _scsih_sas_device_init_add(struct MPT3SAS_ADAPTER *ioc,
> __func__, sas_device->handle,
> (unsigned long long)sas_device->sas_address));
>
> + if (sas_device->enclosure_handle != 0)
> + dewtprintk(ioc, pr_info(MPT3SAS_FMT
> + "%s: enclosure logical id(0x%016llx), slot( %d)\n",
> + ioc->name, __func__, (unsigned long long)
> + sas_device->enclosure_logical_id, sas_device->slot));
> +
> + if (sas_device->connector_name[0] != '\0')
> + dewtprintk(ioc, pr_info(MPT3SAS_FMT
> + "%s: enclosure level(0x%04x), connector name( %s)\n",
> + ioc->name, __func__, sas_device->enclosure_level,
> + sas_device->connector_name));
> +
> spin_lock_irqsave(&ioc->sas_device_lock, flags);
> list_add_tail(&sas_device->list, &ioc->sas_device_init_list);
> _scsih_determine_boot_device(ioc, sas_device, 0);
> @@ -1772,10 +1812,16 @@ _scsih_slave_configure(struct scsi_device *sdev)
> "sas_a
Re: [PATCH 11/20] [SCSI] mpt3sas: Add branding string support for OEM custom HBA
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" Cisco
> Branding String
> 0x1000 0x97 SVID = 0x1137 0x014C Cisco
> 9300-8E 12G SAS HBA
>
> Signed-off-by: Sreekanth Reddy
> ---
> drivers/scsi/mpt3sas/mpt3sas_base.c | 34 ++
> drivers/scsi/mpt3sas/mpt3sas_base.h | 11 +++
> 2 files changed, 45 insertions(+)
>
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
> b/drivers/scsi/mpt3sas/mpt3sas_base.c
> index db362cb..267e489 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_base.c
> +++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
> @@ -2378,6 +2378,39 @@ _base_display_dell_branding(struct MPT3SAS_ADAPTER
> *ioc)
> }
> }
>
> +/**
> + * _base_display_cisco_branding - Display branding string
> + * @ioc: per adapter object
> + *
> + * Return nothing.
> + */
> +static void
> +_base_display_cisco_branding(struct MPT3SAS_ADAPTER *ioc)
> +{
> + if (ioc->pdev->subsystem_vendor != PCI_VENDOR_ID_CISCO)
> + return;
> +
> + switch (ioc->pdev->device) {
> + case MPI25_MFGPAGE_DEVID_SAS3008:
> + switch (ioc->pdev->subsystem_device) {
> + case MPT3SAS_CISCO_12G_HBA_SSDID:
> + pr_info(MPT3SAS_FMT "%s\n", ioc->name,
> + MPT3SAS_CISCO_12G_HBA_BRANDING);
> + break;
> + default:
> + pr_info(MPT3SAS_FMT
> + "Cisco 12Gbps SAS HBA: Subsystem ID: 0x%X\n",
> + ioc->name, ioc->pdev->subsystem_device);
> + break;
> + }
> + break;
> + default:
> +pr_info(MPT3SAS_FMT
> + "Cisco 12Gbps SAS HBA: Subsystem ID: 0x%X\n",
> + ioc->name, ioc->pdev->subsystem_device);
> + break;
> + }
> +}
>
> /**
> * _base_display_ioc_capabilities - Disply IOC's capabilities.
> @@ -2410,6 +2443,7 @@ _base_display_ioc_capabilities(struct MPT3SAS_ADAPTER
> *ioc)
>
> _base_display_intel_branding(ioc);
> _base_display_dell_branding(ioc);
> + _base_display_cisco_branding(ioc);
>
> pr_info(MPT3SAS_FMT "Protocol=(", ioc->name);
>
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h
> b/drivers/scsi/mpt3sas/mpt3sas_base.h
> index c4780c7..7cdbc65 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_base.h
> +++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
> @@ -163,6 +163,17 @@
> #define MPT3SAS_DELL_12G_HBA_SSDID 0x1F46
>
> /*
> + * Cisco HBA branding
> + */
> +#define MPT3SAS_CISCO_12G_HBA_BRANDING \
> + "Cisco 9300-8E 12G SAS HBA"
> +
> +/*
> + * Cisco HBA SSSDIDs
> + */
> + #define MPT3SAS_CISCO_12G_HBA_SSDID 0x14C
> +
> +/*
> * status bits for ioc->diag_buffer_status
> */
> #define MPT3_DIAG_BUFFER_IS_REGISTERED (0x01)
> --
> 2.0.2
>
--
Regards,
Sreekanth
--
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/majordomo-info.html
Re: [PATCH 16/20] [SCSI] mpt3sas: Added support for customer specific branding
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
> Branding String
> 0x1000 0x97 0x1137 0x154 Cisco
> 9300-8i 12Gbps SAS HBA
> 0x1000 0x97 0x1137 0x155 Cisco
> 12G Modular SAS Pass through Controller
> 0x1000 0x97 0x1137 0x156 UCS
> C3X60 12G SAS Pass through Controller
>
> Signed-off-by: Sreekanth Reddy
> ---
> drivers/scsi/mpt3sas/mpt3sas_base.c | 29 +++--
> drivers/scsi/mpt3sas/mpt3sas_base.h | 16
> 2 files changed, 39 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
> b/drivers/scsi/mpt3sas/mpt3sas_base.c
> index 0b26c8d..2f2c331 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_base.c
> +++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
> @@ -2393,9 +2393,17 @@ _base_display_cisco_branding(struct MPT3SAS_ADAPTER
> *ioc)
> switch (ioc->pdev->device) {
> case MPI25_MFGPAGE_DEVID_SAS3008:
> switch (ioc->pdev->subsystem_device) {
> - case MPT3SAS_CISCO_12G_HBA_SSDID:
> + case MPT3SAS_CISCO_12G_8E_HBA_SSDID:
> pr_info(MPT3SAS_FMT "%s\n", ioc->name,
> - MPT3SAS_CISCO_12G_HBA_BRANDING);
> + MPT3SAS_CISCO_12G_8E_HBA_BRANDING);
> + break;
> + case MPT3SAS_CISCO_12G_8I_HBA_SSDID:
> + pr_info(MPT3SAS_FMT "%s\n", ioc->name,
> + MPT3SAS_CISCO_12G_8I_HBA_BRANDING);
> + break;
> + case MPT3SAS_CISCO_12G_AVILA_HBA_SSDID:
> + pr_info(MPT3SAS_FMT "%s\n", ioc->name,
> + MPT3SAS_CISCO_12G_AVILA_HBA_BRANDING);
> break;
> default:
> pr_info(MPT3SAS_FMT
> @@ -2404,6 +2412,23 @@ _base_display_cisco_branding(struct MPT3SAS_ADAPTER
> *ioc)
> break;
> }
> break;
> + case MPI25_MFGPAGE_DEVID_SAS3108_1:
> + switch (ioc->pdev->subsystem_device) {
> + case MPT3SAS_CISCO_12G_AVILA_HBA_SSDID:
> + pr_info(MPT3SAS_FMT "%s\n", ioc->name,
> + MPT3SAS_CISCO_12G_AVILA_HBA_BRANDING);
> + break;
> + case MPT3SAS_CISCO_12G_COLUSA_MEZZANINE_HBA_SSDID:
> + pr_info(MPT3SAS_FMT "%s\n", ioc->name,
> + MPT3SAS_CISCO_12G_COLUSA_MEZZANINE_HBA_BRANDING);
> + break;
> + default:
> + pr_info(MPT3SAS_FMT
> +"Cisco 12Gbps SAS HBA: Subsystem ID: 0x%X\n",
> +ioc->name, ioc->pdev->subsystem_device);
> + break;
> + }
> + break;
> default:
> pr_info(MPT3SAS_FMT
> "Cisco 12Gbps SAS HBA: Subsystem ID: 0x%X\n",
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h
> b/drivers/scsi/mpt3sas/mpt3sas_base.h
> index a89c752..b97039b 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_base.h
> +++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
> @@ -165,13 +165,21 @@
> /*
> * Cisco HBA branding
> */
> -#define MPT3SAS_CISCO_12G_HBA_BRANDING \
> - "Cisco 9300-8E 12G SAS HBA"
> -
> +#define MPT3SAS_CISCO_12G_8E_HBA_BRANDING \
> + "Cisco 9300-8E 12G SAS HBA"
> +#define MPT3SAS_CISCO_12G_8I_HBA_BRANDING \
> + "Cisco 9300-8i 12G SAS HBA"
> +#define MPT3SAS_CISCO_12G_AVILA_HBA_BRANDING \
> + "Cisco 12G Modular SAS Pass through Controller"
> +#define MPT3SAS_CISCO_12G_COLUSA_MEZZANINE_HBA_BRANDING\
> + "UCS C3X60 12G SAS Pass through Controller"
> /*
> * Cisco HBA SSSDIDs
> */
> - #define MPT3SAS_CISCO_12G_HBA_SSDID 0x14C
> +#define MPT3SAS_CISCO_12G_8E_HBA_SSDID 0x14C
> +#define MPT3SAS_CISCO_12G_8I_HBA_SSDID 0x154
> +#define MPT3SAS_CISCO_12G_AVILA_HBA_SSDID 0x155
> +#define MPT3SAS_CISCO_12G_COLUSA_MEZZANINE_HBA_SSDID 0x156
>
> /*
> * status bits for ioc->diag_buffer_status
> --
> 2.0.2
>
--
Regards,
Sreekanth
--
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/majordomo-info.html
Re: [PATCH 04/20] [SCSI] mpt3sas: Remove redundancy code while freeing the controller resources.
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 >> wrote: >> > On Fri, Jun 12, 2015 at 05:48:56PM +0530, Sreekanth Reddy wrote: >> >> On Fri, Jun 12, 2015 at 4:58 PM, Johannes Thumshirn >> >> wrote: >> >> > 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 >> >> >> + >> > [...] >> >> >> + _base_free_irq(ioc); >> >> >> + _base_disable_msix(ioc); >> >> >> + >> >> >> + if (ioc->msix96_vector) >> >> >> + kfree(ioc->replyPostRegisterIndex); >> >> > >> >> > kfree() already checks for zero or a NULL pointer. >> >> >> >> Sorry Johannes, I didn't get you. If I understand this correctly, you >> >> are suggesting to check for NULL pointer before calling kree() API as >> >> shown below, >> >> >> >> if (ioc->msix96_vector && (ioc->replyPostRegisterIndex != NULL)) >> >> kfree(ioc->replyPostRegisterIndex); >> > >> > Correct me if I'm wrong, but I thought you don't need the if >> > (ioc->msix96_vector) before the kfree(). ioc->replyPostRegisterIndex >> > should be >> > NULL if ioc->msix96_vector is 0, as far as I can see. >> > >> > In _scsih_probe() you have: >> > shost = scsi_host_alloc(&scsih_driver_template, >> > sizeof(struct MPT3SAS_ADAPTER)); >> > if (!shost) >> >return -ENODEV; >> > >> > /* init local params */ >> > ioc = shost_priv(shost); >> > >> > and scsi_host_alloc() does a kzalloc() for shost. >> > >> > so ioc->replyPortRegisterIndex is NULL. >> > >> > Or am I thinking wrong here? >> >> Yes, ioc->replyPostRegisterIndex will be NULL if ioc->msix96_vector is 0, >> We have added this checks as a precautionary. since calling this >> function (i.e kfree()) on memory not previously allocated with >> kmalloc(), or on memory which has already been freed, may results in >> very bad things, such as freeing memory belonging to another part of >> the kernel. >> > > OK, then please leave it in. > >> > >> >> >> >> Regards, >> >> Sreekanth >> > >> > -- >> > Johannes Thumshirn Storage >> > jthumsh...@suse.de +49 911 74053 689 >> > SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg >> > GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton >> > HRB 21284 (AG Nürnberg) >> >> >> >> -- >> >> Regards, >> Sreekanth > > -- > Johannes Thumshirn Storage > jthumsh...@suse.de +49 911 74053 689 > SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg > GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton > HRB 21284 (AG Nürnberg) -- Regards, Sreekanth -- 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/majordomo-info.html
Re: [PATCH 10/20] [SCSI] mpt3sas: Add branding string support for OEM's HBA
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:
>>> On Mon, Jun 15, 2015 at 3:16 PM, Johannes Thumshirn
>>> wrote:
>>> > 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 0x1F46
>>> >> DELL 12Gbps HBA
>>> >>
>>> >> Signed-off-by: Sreekanth Reddy
>>> >> ---
>>> >> drivers/scsi/mpt3sas/mpt3sas_base.c | 36
>>> >>
>>> >> drivers/scsi/mpt3sas/mpt3sas_base.h | 11 +++
>>> >> 2 files changed, 47 insertions(+)
>>> >>
>>> >> diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
>>> >> b/drivers/scsi/mpt3sas/mpt3sas_base.c
>>> >> index 6739c0a..db362cb 100644
>>> >> --- a/drivers/scsi/mpt3sas/mpt3sas_base.c
>>> >> +++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
>>> >> @@ -2345,6 +2345,41 @@ _base_display_intel_branding(struct
>>> >> MPT3SAS_ADAPTER *ioc)
>>> >>
>>> >>
>>> >> /**
>>> >> + * _base_display_dell_branding - Display branding string
>>> >> + * @ioc: per adapter object
>>> >> + *
>>> >> + * Return nothing.
>>> >> + */
>>> >> +static void
>>> >> +_base_display_dell_branding(struct MPT3SAS_ADAPTER *ioc)
>>> >> +{
>>> >> + if (ioc->pdev->subsystem_vendor != PCI_VENDOR_ID_DELL)
>>> >> + return;
>>> >> +
>>> >> + switch (ioc->pdev->device) {
>>> >> + case MPI25_MFGPAGE_DEVID_SAS3008:
>>> >> + switch (ioc->pdev->subsystem_device) {
>>> >> + case MPT3SAS_DELL_12G_HBA_SSDID:
>>> >> + pr_info(MPT3SAS_FMT "%s\n", ioc->name,
>>> >> + MPT3SAS_DELL_12G_HBA_BRANDING);
>>> >> + break;
>>> >> + default:
>>> >> + pr_info(MPT3SAS_FMT
>>> >> +"Dell 12Gbps HBA: Subsystem ID: 0x%X\n",
>>> >> ioc->name,
>>> >> +ioc->pdev->subsystem_device);
>>> >> + break;
>>> >> + }
>>> >> + break;
>>> >> + default:
>>> >> + pr_info(MPT3SAS_FMT
>>> >> + "Dell 12Gbps HBA: Subsystem ID: 0x%X\n", ioc->name,
>>> >> + ioc->pdev->subsystem_device);
>>> >> + break;
>>> >> + }
>>> >> +}
>>> >> +
>>> >> +
>>> >> +/**
>>> >> * _base_display_ioc_capabilities - Disply IOC's capabilities.
>>> >> * @ioc: per adapter object
>>> >> *
>>> >> @@ -2374,6 +2409,7 @@ _base_display_ioc_capabilities(struct
>>> >> MPT3SAS_ADAPTER *ioc)
>>> >> bios_version & 0x00FF);
>>> >>
>>> >> _base_display_intel_branding(ioc);
>>> >> + _base_display_dell_branding(ioc);
>>> >>
>>> >> pr_info(MPT3SAS_FMT "Protocol=(", ioc->name);
>>> >>
>>> >> diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h
>>> >> b/drivers/scsi/mpt3sas/mpt3sas_base.h
>>> >> index 2318ef8..c4780c7 100644
>>> >> --- a/drivers/scsi/mpt3sas/mpt3sas_base.h
>>> >> +++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
>>> >> @@ -152,6 +152,17 @@
>>> >> #define MPT3SAS_INTEL_RS3UC080_SSDID0x3524
>>> >>
>>> >> /*
>>> >> + * Dell HBA branding
>>> >> + */
>>> >> +#define MPT3SAS_DELL_12G_HBA_BRANDING \
>>> >> + "Dell 12Gbps HBA"
>>> >> +
>>> >> +/*
>>> >> + * Dell HBA SSDIDs
>>> >> + */
>>> >> +#define MPT3SAS_DELL_12G_HBA_SSDID 0x1F46
>>> >> +
>>> >> +/*
>>> >> * status bits for ioc->diag_buffer_status
>>> >> */
>>> >> #define MPT3_DIAG_BUFFER_IS_REGISTERED (0x01)
>>> >> --
>>> >> 2.0.2
>>> >>
>>> >> --
>>> >> 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/majordomo-info.html
>>> >
>>> > This might be something you might consider re-organizing for your
>>> > code-base
>>> > merge as well, as it leads to a lot of code duplication the more OEMs you
>>> > have.
>>>
>>> May I know which hunk of this patch may leads to code duplication for
>>> more OEMs we add? Whether declaring individual function for each OEMs
>>> leads to this code duplication.
>>
>> Hi Sreekanth,
>>
>> In
>> [PATCH 11/20] [SCSI] mpt3sas: Add branding string support for OEM custom HBA
>> you add _base_display_cisco_branding(). In
>> [PATCH 10/20] [SCSI] mpt3sas: Add branding string support for OEM's HBA
>> you add _base_display_dell_branding(). You already have
>> _base_display_intel_branding().
>>
>> Each of them follows the pattern:
>> 1) Check if it is a OEM device for XXX
>> 2) Check witch OEM device for XXX it is
>> 3) Display a string based on that specific OEM device
>> 4) Return
>
> Johannes,
>
> Thanks fo
[PATCH 0/8] tcm_loop updates
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:0x6001405e41925ad3 /dev/sdf [10:0:1:0] disksas:0x6001405e41925ad3 /dev/sdg I've also included some pending fixes / updates I did for LIO target, mostly done to reproduce issues I've been facing: - Disallow READ CAPACITY in standby This is a long-standing issue with the linux SCSI stack and multipathing, both assuming that READ CAPACITY will always succeed. With that patch we can finally debug and fix this. - Export the 'write_protect' attribute for demo-mode LUNs - Some more UAs to be issued As usual, reviews and comments are welcome. Hannes Reinecke (8): tcm_loop: Hook into SAS transport class tcm_loop: Add SAS transport topology tcm_loop: Remove SAS vestigies tcm_loop: Send I_T_NEXUS_LOSS_OCCURRED UA tcm_loop: Rescan SCSI target on transport online target: Issue Power-On/Reset UA upon LUN instantiation target_core_alua: disallow READ_CAPACITY when in standby target: display 'write_protect' attribute for demo-mode LUNs drivers/target/loopback/tcm_loop.c | 186 +++ drivers/target/loopback/tcm_loop.h | 3 + drivers/target/target_core_alua.c| 9 -- drivers/target/target_core_device.c | 43 ++- drivers/target/target_core_fabric_configfs.c | 42 ++ drivers/target/target_core_internal.h| 1 + drivers/target/target_core_tpg.c | 17 +++ include/target/target_core_fabric.h | 1 + 8 files changed, 261 insertions(+), 41 deletions(-) -- 1.8.5.2 -- 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/majordomo-info.html
[PATCH 1/8] tcm_loop: Hook into SAS transport class
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/loopback/tcm_loop.c
index a556bde..45ae3e4 100644
--- a/drivers/target/loopback/tcm_loop.c
+++ b/drivers/target/loopback/tcm_loop.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
@@ -42,7 +43,7 @@
static struct workqueue_struct *tcm_loop_workqueue;
static struct kmem_cache *tcm_loop_cmd_cache;
-
+static struct scsi_transport_template *tcm_loop_sas_transport_template;
static int tcm_loop_hba_no_cnt;
static int tcm_loop_queue_status(struct se_cmd *se_cmd);
@@ -360,6 +361,9 @@ static int tcm_loop_slave_alloc(struct scsi_device *sd)
return 0;
}
+struct sas_function_template tcm_loop_sas_transport_functions = {
+};
+
static struct scsi_host_template tcm_loop_driver_template = {
.show_info = tcm_loop_show_info,
.proc_name = "tcm_loopback",
@@ -408,6 +412,8 @@ static int tcm_loop_driver_probe(struct device *dev)
sh->max_lun = 0;
sh->max_channel = 0;
sh->max_cmd_len = SCSI_MAX_VARLEN_CDB_SIZE;
+ if (tl_hba->tl_proto_id == SCSI_PROTOCOL_SAS)
+ sh->transportt = tcm_loop_sas_transport_template;
host_prot = SHOST_DIF_TYPE1_PROTECTION | SHOST_DIF_TYPE2_PROTECTION |
SHOST_DIF_TYPE3_PROTECTION | SHOST_DIX_TYPE1_PROTECTION |
@@ -1290,8 +1296,15 @@ static int __init tcm_loop_fabric_init(void)
if (ret)
goto out_release_core_bus;
+ tcm_loop_sas_transport_template =
+ sas_attach_transport(&tcm_loop_sas_transport_functions);
+ if (!tcm_loop_sas_transport_template)
+ goto out_unregister_template;
+
return 0;
+out_unregister_template:
+ target_unregister_template(&loop_ops);
out_release_core_bus:
tcm_loop_release_core_bus();
out_destroy_cache:
@@ -1304,6 +1317,7 @@ out:
static void __exit tcm_loop_fabric_exit(void)
{
+ sas_release_transport(tcm_loop_sas_transport_template);
target_unregister_template(&loop_ops);
tcm_loop_release_core_bus();
kmem_cache_destroy(tcm_loop_cmd_cache);
--
1.8.5.2
--
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/majordomo-info.html
[PATCH 7/8] target_core_alua: disallow READ_CAPACITY when in standby
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/target_core_alua.c
index edaf1b9..a62e58b 100644
--- a/drivers/target/target_core_alua.c
+++ b/drivers/target/target_core_alua.c
@@ -561,16 +561,7 @@ static inline int core_alua_state_standby(
case REPORT_LUNS:
case RECEIVE_DIAGNOSTIC:
case SEND_DIAGNOSTIC:
- case READ_CAPACITY:
return 0;
- case SERVICE_ACTION_IN_16:
- switch (cdb[1] & 0x1f) {
- case SAI_READ_CAPACITY_16:
- return 0;
- default:
- set_ascq(cmd, ASCQ_04H_ALUA_TG_PT_STANDBY);
- return 1;
- }
case MAINTENANCE_IN:
switch (cdb[1] & 0x1f) {
case MI_REPORT_TARGET_PGS:
--
1.8.5.2
--
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/majordomo-info.html
[PATCH 5/8] tcm_loop: Rescan SCSI target on transport online
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/loopback/tcm_loop.c
b/drivers/target/loopback/tcm_loop.c
index 6c724dd..7db31f3 100644
--- a/drivers/target/loopback/tcm_loop.c
+++ b/drivers/target/loopback/tcm_loop.c
@@ -1082,7 +1082,16 @@ static ssize_t tcm_loop_tpg_store_transport_status(
struct tcm_loop_tpg, tl_se_tpg);
if (!strncmp(page, "online", 6)) {
+ int status = tl_tpg->tl_transport_status;
+
tl_tpg->tl_transport_status = TCM_TRANSPORT_ONLINE;
+ if (status != tl_tpg->tl_transport_status &&
+ tl_tpg->tl_hba->tl_proto_id == SCSI_PROTOCOL_SAS) {
+ struct sas_rphy *rphy = tl_tpg->sas_rphy;
+
+ scsi_scan_target(&rphy->dev, 0, rphy->scsi_target_id,
+SCAN_WILD_CARD, 0);
+ }
return count;
}
if (!strncmp(page, "offline", 7)) {
--
1.8.5.2
--
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/majordomo-info.html
[PATCH 8/8] target: display 'write_protect' attribute for demo-mode LUNs
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
drivers/target/target_core_internal.h| 1 +
3 files changed, 70 insertions(+)
diff --git a/drivers/target/target_core_device.c
b/drivers/target/target_core_device.c
index 88d6070..3e17070 100644
--- a/drivers/target/target_core_device.c
+++ b/drivers/target/target_core_device.c
@@ -271,6 +271,33 @@ void core_update_device_list_access(
mutex_unlock(&nacl->lun_entry_mutex);
}
+void core_update_lun_access(
+ struct se_lun *lun,
+ u32 lun_access)
+{
+ struct se_dev_entry *deve;
+
+ if (lun_access == TRANSPORT_LUNFLAGS_READ_ONLY) {
+ lun->lun_access &= ~TRANSPORT_LUNFLAGS_READ_WRITE;
+ lun->lun_access |= TRANSPORT_LUNFLAGS_READ_ONLY;
+ } else {
+ lun->lun_access &= ~TRANSPORT_LUNFLAGS_READ_ONLY;
+ lun->lun_access |= TRANSPORT_LUNFLAGS_READ_WRITE;
+ }
+
+ spin_lock_bh(&lun->lun_deve_lock);
+ list_for_each_entry(deve, &lun->lun_deve_list, lun_link) {
+ if (lun_access & TRANSPORT_LUNFLAGS_READ_WRITE) {
+ deve->lun_flags &= ~TRANSPORT_LUNFLAGS_READ_ONLY;
+ deve->lun_flags |= TRANSPORT_LUNFLAGS_READ_WRITE;
+ } else {
+ deve->lun_flags &= ~TRANSPORT_LUNFLAGS_READ_WRITE;
+ deve->lun_flags |= TRANSPORT_LUNFLAGS_READ_ONLY;
+ }
+ }
+ spin_unlock_bh(&lun->lun_deve_lock);
+}
+
/*
* Called with rcu_read_lock or nacl->device_list_lock held.
*/
diff --git a/drivers/target/target_core_fabric_configfs.c
b/drivers/target/target_core_fabric_configfs.c
index 6cfee59..299b4b5 100644
--- a/drivers/target/target_core_fabric_configfs.c
+++ b/drivers/target/target_core_fabric_configfs.c
@@ -726,12 +726,54 @@ static ssize_t
target_fabric_port_store_attr_alua_tg_pt_write_md(
TCM_PORT_ATTR(alua_tg_pt_write_md, S_IRUGO | S_IWUSR);
+static ssize_t target_fabric_port_show_attr_write_protect(
+ struct se_lun *lun,
+ char *page)
+{
+ ssize_t len = 0;
+
+ if (!lun || !lun->lun_se_dev)
+ return -ENODEV;
+
+ len = sprintf(page, "%d\n",
+ (lun->lun_access & TRANSPORT_LUNFLAGS_READ_ONLY) ? 1 : 0);
+
+ return len;
+}
+
+static ssize_t target_fabric_port_store_attr_write_protect(
+ struct se_lun *lun,
+ const char *page,
+ size_t count)
+{
+ unsigned long op;
+ int ret;
+
+ if (!lun || !lun->lun_se_dev)
+ return -ENODEV;
+
+ ret = kstrtoul(page, 0, &op);
+ if (ret)
+ return ret;
+
+ if ((op != 1) && (op != 0))
+ return -EINVAL;
+
+ core_update_lun_access(lun, (op) ?
+ TRANSPORT_LUNFLAGS_READ_ONLY :
+ TRANSPORT_LUNFLAGS_READ_WRITE);
+
+ return count;
+
+}
+TCM_PORT_ATTR(write_protect, S_IRUGO | S_IWUSR);
static struct configfs_attribute *target_fabric_port_attrs[] = {
&target_fabric_port_alua_tg_pt_gp.attr,
&target_fabric_port_alua_tg_pt_offline.attr,
&target_fabric_port_alua_tg_pt_status.attr,
&target_fabric_port_alua_tg_pt_write_md.attr,
+ &target_fabric_port_write_protect.attr,
NULL,
};
diff --git a/drivers/target/target_core_internal.h
b/drivers/target/target_core_internal.h
index 5111789..69a57a4 100644
--- a/drivers/target/target_core_internal.h
+++ b/drivers/target/target_core_internal.h
@@ -36,6 +36,7 @@ void core_clear_lun_from_tpg(struct se_lun *, struct
se_portal_group *);
intcore_dev_add_lun(struct se_portal_group *, struct se_device *,
struct se_lun *lun);
void core_dev_del_lun(struct se_portal_group *, struct se_lun *);
+void core_update_lun_access(struct se_lun *, u32);
struct se_lun_acl *core_dev_init_initiator_node_lun_acl(struct se_portal_group
*,
struct se_node_acl *, u64, int *);
intcore_dev_add_initiator_node_lun_acl(struct se_portal_group *,
--
1.8.5.2
--
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/majordomo-info.html
[PATCH 3/8] tcm_loop: Remove SAS vestigies
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/target/loopback/tcm_loop.c
index 7d436db..d77caf5 100644
--- a/drivers/target/loopback/tcm_loop.c
+++ b/drivers/target/loopback/tcm_loop.c
@@ -535,7 +535,7 @@ static inline struct tcm_loop_tpg *tl_tpg(struct
se_portal_group *se_tpg)
static char *tcm_loop_get_endpoint_wwn(struct se_portal_group *se_tpg)
{
/*
-* Return the passed NAA identifier for the SAS Target Port
+* Return the passed NAA identifier for the Target Port
*/
return &tl_tpg(se_tpg)->tl_hba->tl_wwn_address[0];
}
@@ -864,7 +864,7 @@ static int tcm_loop_make_nexus(
transport_free_session(tl_nexus->se_sess);
goto out;
}
- /* Now, register the SAS I_T Nexus as active. */
+ /* Now, register the I_T Nexus as active. */
transport_register_session(se_tpg, tl_nexus->se_sess->se_node_acl,
tl_nexus->se_sess, tl_nexus);
tl_tpg->tl_nexus = tl_nexus;
@@ -937,7 +937,7 @@ static int tcm_loop_drop_nexus(
" %s Initiator Port: %s\n", tcm_loop_dump_proto_id(tpg->tl_hba),
tl_nexus->se_sess->se_node_acl->initiatorname);
/*
-* Release the SCSI I_T Nexus to the emulated SAS Target Port
+* Release the SCSI I_T Nexus to the emulated Target Port
*/
transport_deregister_session(tl_nexus->se_sess);
tpg->tl_nexus = NULL;
@@ -1130,7 +1130,7 @@ static struct se_portal_group *tcm_loop_make_naa_tpg(
tl_tpg->tl_hba = tl_hba;
tl_tpg->tl_tpgt = tpgt;
/*
-* Register the tl_tpg as a emulated SAS TCM Target Endpoint
+* Register the tl_tpg as a emulated TCM Target Endpoint
*/
ret = core_tpg_register(wwn, &tl_tpg->tl_se_tpg, tl_hba->tl_proto_id);
if (ret < 0)
@@ -1201,7 +1201,7 @@ static void tcm_loop_drop_naa_tpg(
sas_rphy_delete(tl_tpg->sas_rphy);
/*
-* Release the I_T Nexus for the Virtual SAS link if present
+* Release the I_T Nexus for the Virtual target link if present
*/
tcm_loop_drop_nexus(tl_tpg);
@@ -1216,7 +1216,7 @@ static void tcm_loop_drop_naa_tpg(
}
/*
-* Deregister the tl_tpg as a emulated SAS TCM Target Endpoint
+* Deregister the tl_tpg as a emulated TCM Target Endpoint
*/
core_tpg_deregister(se_tpg);
@@ -1310,8 +1310,9 @@ static void tcm_loop_drop_scsi_hba(
struct tcm_loop_hba, tl_hba_wwn);
pr_debug("TCM_Loop_ConfigFS: Deallocating emulated Target"
- " SAS Address: %s at Linux/SCSI Host ID: %d\n",
- tl_hba->tl_wwn_address, tl_hba->sh->host_no);
+ " %s Address: %s at Linux/SCSI Host ID: %d\n",
+ tcm_loop_dump_proto_id(tl_hba), tl_hba->tl_wwn_address,
+ tl_hba->sh->host_no);
/*
* Call device_unregister() on the original tl_hba->dev.
* tcm_loop_fabric_scsi.c:tcm_loop_release_adapter() will
--
1.8.5.2
--
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/majordomo-info.html
[PATCH 2/8] tcm_loop: Add SAS transport topology
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 files changed, 125 insertions(+), 17 deletions(-)
diff --git a/drivers/target/loopback/tcm_loop.c
b/drivers/target/loopback/tcm_loop.c
index 45ae3e4..7d436db 100644
--- a/drivers/target/loopback/tcm_loop.c
+++ b/drivers/target/loopback/tcm_loop.c
@@ -439,6 +439,9 @@ static int tcm_loop_driver_remove(struct device *dev)
tl_hba = to_tcm_loop_hba(dev);
sh = tl_hba->sh;
+ if (tl_hba->tl_proto_id == SCSI_PROTOCOL_SAS)
+ sas_remove_host(sh);
+
scsi_remove_host(sh);
scsi_host_put(sh);
return 0;
@@ -729,10 +732,18 @@ static int tcm_loop_port_link(
struct tcm_loop_hba *tl_hba = tl_tpg->tl_hba;
atomic_inc_mb(&tl_tpg->tl_tpg_port_count);
- /*
-* Add Linux/SCSI struct scsi_device by HCTL
-*/
- scsi_add_device(tl_hba->sh, 0, tl_tpg->tl_tpgt, lun->unpacked_lun);
+ if (tl_hba->tl_proto_id != SCSI_PROTOCOL_SAS) {
+ /*
+* Add Linux/SCSI struct scsi_device by HCTL
+*/
+ scsi_add_device(tl_hba->sh, 0,
+ tl_tpg->tl_tpgt, lun->unpacked_lun);
+ } else {
+ struct sas_rphy *rphy = tl_tpg->sas_rphy;
+
+ scsi_scan_target(&rphy->dev, 0, rphy->scsi_target_id,
+lun->unpacked_lun, 0);
+ }
pr_debug("TCM_Loop_ConfigFS: Port Link Successful\n");
return 0;
@@ -749,19 +760,21 @@ static void tcm_loop_port_unlink(
tl_tpg = container_of(se_tpg, struct tcm_loop_tpg, tl_se_tpg);
tl_hba = tl_tpg->tl_hba;
- sd = scsi_device_lookup(tl_hba->sh, 0, tl_tpg->tl_tpgt,
- se_lun->unpacked_lun);
- if (!sd) {
- pr_err("Unable to locate struct scsi_device for %d:%d:"
- "%llu\n", 0, tl_tpg->tl_tpgt, se_lun->unpacked_lun);
- return;
+ if (tl_hba->tl_proto_id != SCSI_PROTOCOL_SAS) {
+ sd = scsi_device_lookup(tl_hba->sh, 0, tl_tpg->tl_tpgt,
+ se_lun->unpacked_lun);
+ if (!sd) {
+ pr_err("Unable to locate struct scsi_device for %d:%d:"
+ "%llu\n", 0, tl_tpg->tl_tpgt,
+ se_lun->unpacked_lun);
+ return;
+ }
+ /*
+* Remove Linux/SCSI struct scsi_device by HCTL
+*/
+ scsi_remove_device(sd);
+ scsi_device_put(sd);
}
- /*
-* Remove Linux/SCSI struct scsi_device by HCTL
-*/
- scsi_remove_device(sd);
- scsi_device_put(sd);
-
atomic_dec_mb(&tl_tpg->tl_tpg_port_count);
pr_debug("TCM_Loop_ConfigFS: Port Unlink Successful\n");
@@ -858,6 +871,33 @@ static int tcm_loop_make_nexus(
pr_debug("TCM_Loop_ConfigFS: Established I_T Nexus to emulated"
" %s Initiator Port: %s\n", tcm_loop_dump_proto_id(tl_hba),
name);
+
+ if (tl_hba->tl_proto_id == SCSI_PROTOCOL_SAS) {
+ struct Scsi_Host *sh = tl_hba->sh;
+ u64 sas_address;
+
+ if (kstrtoull(name, 16, &sas_address)) {
+ pr_err("Invalid SAS address %s\n", name);
+ return -ENODEV;
+ }
+ tl_nexus->sas_phy = sas_phy_alloc(&sh->shost_gendev,
+ tl_tpg->tl_tpgt);
+ if (!tl_nexus->sas_phy) {
+ pr_err("Unable to allocate SAS host phy\n");
+ return -ENOMEM;
+ }
+ tl_nexus->sas_phy->identify.sas_address = sas_address;
+ tl_nexus->sas_phy->identify.phy_identifier = 0;
+ tl_nexus->sas_phy->identify.device_type = SAS_END_DEVICE;
+ tl_nexus->sas_phy->identify.initiator_port_protocols =
SAS_PROTOCOL_STP|SAS_PROTOCOL_SMP;
+ if (sas_phy_add(tl_nexus->sas_phy)) {
+ sas_phy_free(tl_nexus->sas_phy);
+ tl_nexus->sas_phy = NULL;
+ pr_err("Unable to add SAS host phy\n");
+ return -ENODEV;
+ }
+ sas_port_add_phy(tl_tpg->sas_port, tl_nexus->sas_phy);
+ }
return 0;
out:
@@ -886,6 +926,13 @@ static int tcm_loop_drop_nexus(
return -EPERM;
}
+ if (tl_nexus->sas_phy) {
+ sas_port_delete_phy(tpg->sas_port, tl_nexus->sas_phy);
+ sas_phy_delete(tl_nexus->sas_phy);
+ sas_phy_free(tl_nexus->sas_phy);
+ tl_n
[PATCH 6/8] target: Issue Power-On/Reset UA upon LUN instantiation
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/target_core_device.c
index 52676a0..88d6070 100644
--- a/drivers/target/target_core_device.c
+++ b/drivers/target/target_core_device.c
@@ -363,9 +363,11 @@ int core_enable_device_list_for_node(
rcu_read_lock();
hlist_for_each_entry_rcu(tmp, &nacl->lun_entry_hlist, link) {
if (tmp == new)
- continue;
- core_scsi3_ua_allocate(tmp, 0x3F,
- ASCQ_3FH_REPORTED_LUNS_DATA_HAS_CHANGED);
+ core_scsi3_ua_allocate(tmp, 0x29,
+
ASCQ_29H_POWER_ON_RESET_OR_BUS_DEVICE_RESET_OCCURED);
+ else
+ core_scsi3_ua_allocate(tmp, 0x3F,
+
ASCQ_3FH_REPORTED_LUNS_DATA_HAS_CHANGED);
}
rcu_read_unlock();
@@ -385,9 +387,11 @@ int core_enable_device_list_for_node(
rcu_read_lock();
hlist_for_each_entry_rcu(tmp, &nacl->lun_entry_hlist, link) {
if (tmp == new)
- continue;
- core_scsi3_ua_allocate(tmp, 0x3F,
- ASCQ_3FH_REPORTED_LUNS_DATA_HAS_CHANGED);
+ core_scsi3_ua_allocate(tmp, 0x29,
+
ASCQ_29H_POWER_ON_RESET_OR_BUS_DEVICE_RESET_OCCURED);
+ else
+ core_scsi3_ua_allocate(tmp, 0x3F,
+ ASCQ_3FH_REPORTED_LUNS_DATA_HAS_CHANGED);
}
rcu_read_unlock();
return 0;
--
1.8.5.2
--
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/majordomo-info.html
[PATCH 4/8] tcm_loop: Send I_T_NEXUS_LOSS_OCCURRED UA
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 changed, 23 insertions(+)
diff --git a/drivers/target/loopback/tcm_loop.c
b/drivers/target/loopback/tcm_loop.c
index d77caf5..6c724dd 100644
--- a/drivers/target/loopback/tcm_loop.c
+++ b/drivers/target/loopback/tcm_loop.c
@@ -1087,6 +1087,11 @@ static ssize_t tcm_loop_tpg_store_transport_status(
}
if (!strncmp(page, "offline", 7)) {
tl_tpg->tl_transport_status = TCM_TRANSPORT_OFFLINE;
+ if (tl_tpg->tl_nexus) {
+ struct se_session *tl_sess = tl_tpg->tl_nexus->se_sess;
+
+ core_allocate_nexus_loss_ua(tl_sess->se_node_acl);
+ }
return count;
}
return -EINVAL;
diff --git a/drivers/target/target_core_tpg.c b/drivers/target/target_core_tpg.c
index aa39bc8..94c531e 100644
--- a/drivers/target/target_core_tpg.c
+++ b/drivers/target/target_core_tpg.c
@@ -43,6 +43,7 @@
#include "target_core_internal.h"
#include "target_core_alua.h"
#include "target_core_pr.h"
+#include "target_core_ua.h"
extern struct se_device *g_lun0_dev;
@@ -85,6 +86,22 @@ struct se_node_acl *core_tpg_get_initiator_node_acl(
}
EXPORT_SYMBOL(core_tpg_get_initiator_node_acl);
+void core_allocate_nexus_loss_ua(
+ struct se_node_acl *nacl)
+{
+ struct se_dev_entry *deve;
+
+ if (!nacl)
+ return;
+
+ rcu_read_lock();
+ hlist_for_each_entry_rcu(deve, &nacl->lun_entry_hlist, link)
+ core_scsi3_ua_allocate(deve, 0x29,
+ ASCQ_29H_NEXUS_LOSS_OCCURRED);
+ rcu_read_unlock();
+}
+EXPORT_SYMBOL(core_allocate_nexus_loss_ua);
+
/* core_tpg_add_node_to_devs():
*
*
diff --git a/include/target/target_core_fabric.h
b/include/target/target_core_fabric.h
index 18afef9..69355fe 100644
--- a/include/target/target_core_fabric.h
+++ b/include/target/target_core_fabric.h
@@ -152,6 +152,7 @@ int transport_generic_handle_tmr(struct se_cmd *);
void transport_generic_request_failure(struct se_cmd *, sense_reason_t);
void __target_execute_cmd(struct se_cmd *);
inttransport_lookup_tmr_lun(struct se_cmd *, u64);
+void core_allocate_nexus_loss_ua(struct se_node_acl *acl);
struct se_node_acl *core_tpg_get_initiator_node_acl(struct se_portal_group
*tpg,
unsigned char *);
--
1.8.5.2
--
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/majordomo-info.html
Re: [PATCH 14/20 v1] [SCSI] mpt3sas: Complete the SCSI command with DID_RESET status for log_info value 0x0x32010081
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 has failed and has to be retried".
>
> Firmware will provide this log info value with IOC Status
> "SCSI_IOC_TERMINATED", whenever a drive (with is a part of a volume)
> is pulled and pushed back within some minimal delay.
> With this log info value, firmware informs the driver to retry the
> failed IO command infinite times, so to provide some time for the
> firmware to discover the reinserted drive successfully instated of
> just retrying failed command for five times(doesn't giving enough
> time for firmware to complete the drive discovery) and failing the
> IO permanently even though drive came back successfully.
>
> Changes in v1:
>Defined macro VIRTUAL_IO_FAILED_RETRY for magic a value 0x32010081
>
> Signed-off-by: Sreekanth Reddy
> ---
> drivers/scsi/mpt3sas/mpt3sas_base.h | 2 ++
> drivers/scsi/mpt3sas/mpt3sas_scsih.c | 3 +++
> 2 files changed, 5 insertions(+)
>
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h
> b/drivers/scsi/mpt3sas/mpt3sas_base.h
> index 0ffe763..f3f79be 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_base.h
> +++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
> @@ -203,6 +203,8 @@
> #define MFG10_GF0_SSD_DATA_SCRUB_DISABLE (0x0008)
> #define MFG10_GF0_SINGLE_DRIVE_R0 (0x0010)
>
> +#define VIRTUAL_IO_FAILED_RETRY (0x32010081)
> +
> /* OEM Specific Flags will come from OEM specific header files */
> struct Mpi2ManufacturingPage10_t {
> MPI2_CONFIG_PAGE_HEADER Header; /* 00h */
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> index 7060c8b..7587f77 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> +++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> @@ -4302,6 +4302,9 @@ _scsih_io_done(struct MPT3SAS_ADAPTER *ioc, u16 smid,
> u8 msix_index, u32 reply)
> scmd->device->expecting_cc_ua = 1;
> }
> break;
> + } else if (log_info == VIRTUAL_IO_FAILED_RETRY) {
> + scmd->result = DID_RESET << 16;
> + break;
> }
> scmd->result = DID_SOFT_ERROR << 16;
> break;
> --
> 2.0.2
>
Reviewed-by: Johannes Thumshirn
--
Johannes Thumshirn Storage
jthumsh...@suse.de +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
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/majordomo-info.html
