Re: getting I/O errors in super_written()...any ideas what would cause this?
On Tue, 2012-12-04 at 16:00 -0600, Chris Friesen wrote: > As another data point, it looks like we may be doing a SEND DIAGNOSTIC > command specifying the default self-test in addition to the background > short self-test. This seems a bit risky and excessive to me, but > apparently the guy that wrote it is no longer with the company. This is a really bad idea. A lot of disks go out to lunch until the diagnostics complete (the same goes for SMART diagnostics). This means that if you do diagnostics on a running device, the drivers start to get timeouts on commands which are queued waiting for diagnostics to complete ... if those go over the standard SCSI timeouts, we'll start to try error recovery and likely have the disaster you see above. > What is the recommended method for monitoring disks on a system that > is likely to go a long time between boots? Do we avoid any in-service > testing and just monitor the SMART data and only test it if something > actually goes wrong? Or should we intentionally drop a disk out of the > array and test it? (The downside of that is that we lose > redundancy since we only have 2 disks.) What do you mean by "monitoring" ... as in what are you looking for? To make sure the disk is healthy and responding, a simple test unit ready works. To look at other parameters, read the mode pages. Anything that actively causes the disk to go out and check something is a bad idea in a running environment. Only do this if you can quiesce the I/O before starting the active diagnostic (or drop the disk from the array as you suggest). To be honest, though, modern disks do a whole host of diagnostics as they write data just to check that it is safely committed, so passive monitoring should be fine. James -- 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 1/2] megaraid: fix BUG_ON() from incorrect use of delayed work
On Tue, Dec 4, 2012 at 4:54 PM, Tejun Heo wrote:
> @@ -5190,7 +5188,7 @@ static void
> megasas_aen_polling(struct work_struct *work)
> {
> struct megasas_aen_event *ev =
> - container_of(work, struct megasas_aen_event, hotplug_work);
> + container_of(work, struct megasas_aen_event,
> hotplug_work.work);
> struct megasas_instance *instance = ev->instance;
> union megasas_evt_class_locale class_locale;
> struct Scsi_Host *host;
-megasas_aen_polling(struct work_struct *work)
+megasas_aen_polling(struct delayed_work *work)
Not really sure. Just asking?
--nX
--
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 1/2] megaraid: fix BUG_ON() from incorrect use of delayed work
On Wed, Dec 5, 2012 at 12:02 PM, Daniel Vacek wrote:
> On Tue, Dec 4, 2012 at 4:54 PM, Tejun Heo wrote:
>> @@ -5190,7 +5188,7 @@ static void
>> megasas_aen_polling(struct work_struct *work)
>> {
>> struct megasas_aen_event *ev =
>> - container_of(work, struct megasas_aen_event, hotplug_work);
>> + container_of(work, struct megasas_aen_event,
>> hotplug_work.work);
>> struct megasas_instance *instance = ev->instance;
>> union megasas_evt_class_locale class_locale;
>> struct Scsi_Host *host;
>
> -megasas_aen_polling(struct work_struct *work)
> +megasas_aen_polling(struct delayed_work *work)
>
> Not really sure. Just asking?
Never mind, it's ok. Now I get it. Sorry for the buzz.
--nX
--
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: getting I/O errors in super_written()...any ideas what would cause this?
On 12/05/2012 04:20 AM, James Bottomley wrote: On Tue, 2012-12-04 at 16:00 -0600, Chris Friesen wrote: As another data point, it looks like we may be doing a SEND DIAGNOSTIC command specifying the default self-test in addition to the background short self-test. This seems a bit risky and excessive to me, but apparently the guy that wrote it is no longer with the company. This is a really bad idea. A lot of disks go out to lunch until the diagnostics complete (the same goes for SMART diagnostics). This means that if you do diagnostics on a running device, the drivers start to get timeouts on commands which are queued waiting for diagnostics to complete ... if those go over the standard SCSI timeouts, we'll start to try error recovery and likely have the disaster you see above. What is the recommended method for monitoring disks on a system that is likely to go a long time between boots? Do we avoid any in-service testing and just monitor the SMART data and only test it if something actually goes wrong? Or should we intentionally drop a disk out of the array and test it? (The downside of that is that we lose redundancy since we only have 2 disks.) What do you mean by "monitoring" ... as in what are you looking for? To make sure the disk is healthy and responding, a simple test unit ready works. To look at other parameters, read the mode pages. Anything that actively causes the disk to go out and check something is a bad idea in a running environment. Only do this if you can quiesce the I/O before starting the active diagnostic (or drop the disk from the array as you suggest). To be honest, though, modern disks do a whole host of diagnostics as they write data just to check that it is safely committed, so passive monitoring should be fine. James I don't think that the basic stat gathering (smartctl -a ) has this kind of impact, but am worried about the running of the diagnostics, ric -- 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: getting I/O errors in super_written()...any ideas what would cause this?
On Wed, 2012-12-05 at 06:41 -0500, Ric Wheeler wrote: > I don't think that the basic stat gathering (smartctl -a ) has this kind > of > impact, but am worried about the running of the diagnostics, Right, that's what I was trying to say above. Anything that just reads existing data is fine. Anything that causes the disk to go off and test things to gather data is likely to cause I/O errors due to timeouts. James -- 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] scsi_ram: a RAM-based SCSI driver
From: "Kirill A. Shutemov"
This driver is intended to run as fast as possible, hence the options to
discard writes and reads. It's designed to let us find latency issues
elsewhere in the storage stack (eg filesystem, block layer, scsi layer).
There are a few different options, controlled through module parameters.
The sector size and disc capacity are load-time parameters, but the
parameters affecting performance are tweakable at runtime.
By default, it'll allocate half a gigabyte of RAM to use as a ramdisc;
you can change this with the `capacity' module parameter.
Signed-off-by: Matthew Wilcox
Signed-off-by: Tim Chen
[kirill.shutemov@: use vmalloc for scsi_ram_data_array, dummy MODE SENSE
handler]
Signed-off-by: Kirill A. Shutemov
---
drivers/scsi/Kconfig| 10 +
drivers/scsi/Makefile | 1 +
drivers/scsi/scsi_ram.c | 639
3 files changed, 650 insertions(+)
create mode 100644 drivers/scsi/scsi_ram.c
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 142f632..01d782b 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -1530,6 +1530,16 @@ config SCSI_DEBUG
information. This driver is primarily of use to those testing the
SCSI and block subsystems. If unsure, say N.
+config SCSI_RAM
+ tristate "SCSI RAM-based host"
+ depends on SCSI
+ help
+ This driver simulates a host adapter with one disc attached.
+ The primary purpose of this driver is for performance testing
+ of the fs/block/scsi stack; as such it attempts to simulate a
+ disc which is as fast as RAM. If you are unsure how to answer
+ this question, say N.
+
config SCSI_MESH
tristate "MESH (Power Mac internal SCSI) support"
depends on PPC32 && PPC_PMAC && SCSI
diff --git a/drivers/scsi/Makefile b/drivers/scsi/Makefile
index b607ba4..108386e 100644
--- a/drivers/scsi/Makefile
+++ b/drivers/scsi/Makefile
@@ -160,6 +160,7 @@ obj-$(CONFIG_SCSI_OSD_INITIATOR) += osd/
# This goes last, so that "real" scsi devices probe earlier
obj-$(CONFIG_SCSI_DEBUG) += scsi_debug.o
+obj-$(CONFIG_SCSI_RAM) += scsi_ram.o
scsi_mod-y += scsi.o hosts.o scsi_ioctl.o constants.o \
scsicam.o scsi_error.o scsi_lib.o
diff --git a/drivers/scsi/scsi_ram.c b/drivers/scsi/scsi_ram.c
new file mode 100644
index 000..e8ee061
--- /dev/null
+++ b/drivers/scsi/scsi_ram.c
@@ -0,0 +1,639 @@
+/*
+ * scsi_ram.c - A RAM-based SCSI driver for Linux.
+ *
+ * This driver is intended to run as fast as possible, hence the options
+ * to discard writes and reads.
+ * By default, it'll allocate half a gigabyte of RAM to use as a ramdisc;
+ * you can change this with the `capacity' module parameter.
+ *
+ * (C) Copyright 2012 Intel Corporation
+ * Author: Matthew Wilcox
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; version 2
+ * of the License.
+ */
+
+#undef DEBUG
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Matthew Wilcox ");
+
+#define DRV_NAME "scsi_ram"
+
+static unsigned int sector_size = 512;
+module_param(sector_size, uint, 0444);
+MODULE_PARM_DESC(sector_size, "Size of sectors");
+
+static unsigned int capacity = 1024 * 1024;
+module_param(capacity, uint, 0444);
+MODULE_PARM_DESC(capacity, "Number of logical blocks in device");
+
+static int throw_away_writes;
+module_param(throw_away_writes, int, 0644);
+MODULE_PARM_DESC(throw_away_writes, "Discard all writes to the device");
+
+static int throw_away_reads;
+module_param(throw_away_reads, int, 0644);
+MODULE_PARM_DESC(throw_away_reads, "Don't actually read data from the device");
+
+static int use_thread = 1;
+module_param(use_thread, int, 0644);
+MODULE_PARM_DESC(use_thread, "Use a separate thread to do data accesses");
+
+static void copy_buffer(struct scsi_cmnd *cmnd, char *buf, int len)
+{
+ char *p;
+ struct scatterlist *sg;
+ int i;
+
+ scsi_for_each_sg(cmnd, sg, scsi_sg_count(cmnd), i) {
+ int tocopy = sg->length;
+ if (tocopy > len)
+ tocopy = len;
+
+ p = kmap_atomic(sg_page(sg));
+ memcpy(p + sg->offset, buf, tocopy);
+ kunmap_atomic(p);
+
+ len -= tocopy;
+ if (!len)
+ break;
+ buf += tocopy;
+ }
+
+ scsi_set_resid(cmnd, len);
+}
+
+static char inquiry[57] = {
+ 0, 0, 5, 0x22, 52, 0, 0, 0x0a, /* 0-7 */
+ 'L', 'i', 'n', 'u', 'x', ' ', ' ', ' ', /* 8-15 */
+ 'R', 'A', 'M', ' ', 'D', 'r', 'i', 'v', /* 16-23 */
+ 'e', ' ', '
Re: [PATCH 00/11] First pass at merging Bart's HA work
On Fri, Nov 30, 2012 at 4:21 AM, David Dillow wrote: [...] > Modulo a few style issues (braces around one line if branches, etc.) and > having three state variables vs one, I can live with everything up to > aabfa852acd27962 at git://github.com/bvanassche/linux.git#srp-ha. Those > two are small things that can be fixed later and are not worth holding > things up any further. > > I'll try to spend some time on the final four patches tomorrow afternoon. Dave, Bart My colleague Alex Turin tried today the bits as they appear in Roland's kernel.org tree / for-next branch up to commit fb57e1dbbd4 and here's some feedback Basically, what he did was connecting to a target, next take down the IB port on the initiator side, and issue some IOs (dd if=/dev/sdb of=/dev/null count=1) Our recollection of events from the logs (below) is the following 1. queued command get completion status 5 2. as part of error handling srp_reset_host() was called, 3. srp_reset_host() calls to srp_reconnect_target() which fails cause port is down. 4. srp_reconnect_target() on failure calls to srp_queue_remove_work() which sets target->status to SRP_TARGET_REMOVED. 5.srp_reset_host() called second time. it calls to srp_reconnect_target() but target->state == SRP_TARGET_REMOVED. srp_reconnect_target() checks if target->state != SRP_TARGET_LIVE and return -EAGAIN. This probably means that even after enabling port it will still fail to reconnect? Or. Dec 5 16:19:13 rsws42 kernel: scsi host7: ib_srp: failed send status 5 Dec 5 16:19:42 rsws42 kernel: scsi host7: SRP abort called Dec 5 16:19:42 rsws42 kernel: scsi host7: SRP reset_device called Dec 5 16:19:42 rsws42 kernel: scsi host7: ib_srp: SRP reset_host called Dec 5 16:19:43 rsws42 kernel: scsi host7: ib_srp: Got failed path rec status -110 Dec 5 16:19:43 rsws42 kernel: scsi host7: ib_srp: Path record query failed Dec 5 16:19:43 rsws42 kernel: scsi host7: ib_srp: reconnect failed (-110), removing target port. Dec 5 16:19:43 rsws42 kernel: sd 7:0:0:11: Device offlined - not ready after error recovery Dec 5 16:19:43 rsws42 kernel: sd 7:0:0:11: [sdb] Synchronizing SCSI cache Dec 5 16:20:45 rsws42 kernel: scsi host7: SRP abort called Dec 5 16:20:50 rsws42 kernel: scsi host7: SRP abort called Dec 5 16:21:05 rsws42 kernel: scsi host7: SRP abort called Dec 5 16:21:10 rsws42 kernel: scsi host7: SRP reset_device called Dec 5 16:21:15 rsws42 kernel: scsi host7: ib_srp: SRP reset_host called Dec 5 16:21:15 rsws42 kernel: sd 7:0:0:11: Device offlined - not ready after error recovery Dec 5 16:21:15 rsws42 kernel: sd 7:0:0:11: Device offlined - not ready after error recovery repeating part: Dec 5 16:22:17 rsws42 kernel: scsi host7: SRP abort called Dec 5 16:22:22 rsws42 kernel: scsi host7: SRP abort called Dec 5 16:22:37 rsws42 kernel: scsi host7: SRP abort called Dec 5 16:22:42 rsws42 kernel: scsi host7: SRP reset_device called Dec 5 16:22:47 rsws42 kernel: scsi host7: ib_srp: SRP reset_host called Dec 5 16:22:47 rsws42 kernel: sd 7:0:0:11: Device offlined - not ready after error recovery Dec 5 16:22:47 rsws42 kernel: sd 7:0:0:11: Device offlined - not ready after error recovery -- 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 00/11] First pass at merging Bart's HA work
On 12/05/12 19:23, Or Gerlitz wrote: On Fri, Nov 30, 2012 at 4:21 AM, David Dillow wrote: [...] Modulo a few style issues (braces around one line if branches, etc.) and having three state variables vs one, I can live with everything up to aabfa852acd27962 at git://github.com/bvanassche/linux.git#srp-ha. Those two are small things that can be fixed later and are not worth holding things up any further. I'll try to spend some time on the final four patches tomorrow afternoon. Dave, Bart My colleague Alex Turin tried today the bits as they appear in Roland's kernel.org tree / for-next branch up to commit fb57e1dbbd4 and here's some feedback Basically, what he did was connecting to a target, next take down the IB port on the initiator side, and issue some IOs (dd if=/dev/sdb of=/dev/null count=1) Our recollection of events from the logs (below) is the following 1. queued command get completion status 5 2. as part of error handling srp_reset_host() was called, 3. srp_reset_host() calls to srp_reconnect_target() which fails cause port is down. 4. srp_reconnect_target() on failure calls to srp_queue_remove_work() which sets target->status to SRP_TARGET_REMOVED. 5.srp_reset_host() called second time. it calls to srp_reconnect_target() but target->state == SRP_TARGET_REMOVED. srp_reconnect_target() checks if target->state != SRP_TARGET_LIVE and return -EAGAIN. This probably means that even after enabling port it will still fail to reconnect? Hello Or, The only way to make I/O work reliably if a failure can occur at the transport layer is to use multipathd on top of ib_srp. If a connection fails for some reason, then the SRP SCSI host will be removed after the SCSI error handler has finished with its error recovery strategy. And once the transport layer is operational again and srp_daemon detects that the initiator is no longer logged in srp_daemon will make ib_srp log in again. multipathd will then cause I/O to continue over the new path. 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 00/11] First pass at merging Bart's HA work
On 12/05/12 19:50, Bart Van Assche wrote: On 12/05/12 19:23, Or Gerlitz wrote: On Fri, Nov 30, 2012 at 4:21 AM, David Dillow wrote: [...] Modulo a few style issues (braces around one line if branches, etc.) and having three state variables vs one, I can live with everything up to aabfa852acd27962 at git://github.com/bvanassche/linux.git#srp-ha. Those two are small things that can be fixed later and are not worth holding things up any further. I'll try to spend some time on the final four patches tomorrow afternoon. Dave, Bart My colleague Alex Turin tried today the bits as they appear in Roland's kernel.org tree / for-next branch up to commit fb57e1dbbd4 and here's some feedback Basically, what he did was connecting to a target, next take down the IB port on the initiator side, and issue some IOs (dd if=/dev/sdb of=/dev/null count=1) Our recollection of events from the logs (below) is the following 1. queued command get completion status 5 2. as part of error handling srp_reset_host() was called, 3. srp_reset_host() calls to srp_reconnect_target() which fails cause port is down. 4. srp_reconnect_target() on failure calls to srp_queue_remove_work() which sets target->status to SRP_TARGET_REMOVED. 5.srp_reset_host() called second time. it calls to srp_reconnect_target() but target->state == SRP_TARGET_REMOVED. srp_reconnect_target() checks if target->state != SRP_TARGET_LIVE and return -EAGAIN. This probably means that even after enabling port it will still fail to reconnect? Hello Or, The only way to make I/O work reliably if a failure can occur at the transport layer is to use multipathd on top of ib_srp. If a connection fails for some reason, then the SRP SCSI host will be removed after the SCSI error handler has finished with its error recovery strategy. And once the transport layer is operational again and srp_daemon detects that the initiator is no longer logged in srp_daemon will make ib_srp log in again. multipathd will then cause I/O to continue over the new path. (replying to my own e-mail) Another possible approach would be to follow the FC model and to block I/O when a port goes down and to unblock I/O once I/O is again possible. Some time ago I had posted a patch that went somewhat in this direction and in which ib_srp tried to reconnect to a target repeatedly after a transport layer failure. That patch can be found here: http://www.mail-archive.com/linux-rdma@vger.kernel.org/msg10158.html 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
[PATCH 04/12] [SCSI] qla2xxx: Use standard PCIe Capability Link register field names
Use the standard #defines for PCIe Link Capability register fields
rather than bare numbers. This also uses the new PCI Express Capability
accessor rather than reading the capability directly.
Signed-off-by: Bjorn Helgaas
CC: Andrew Vasquez
CC: linux-dri...@qlogic.com
CC: "James E.J. Bottomley"
CC: linux-scsi@vger.kernel.org
---
drivers/scsi/qla2xxx/qla_os.c | 14 +-
1 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_os.c b/drivers/scsi/qla2xxx/qla_os.c
index d501bf5..b5d070f 100644
--- a/drivers/scsi/qla2xxx/qla_os.c
+++ b/drivers/scsi/qla2xxx/qla_os.c
@@ -480,18 +480,14 @@ qla24xx_pci_info_str(struct scsi_qla_host *vha, char *str)
static char *pci_bus_modes[] = { "33", "66", "100", "133", };
struct qla_hw_data *ha = vha->hw;
uint32_t pci_bus;
- int pcie_reg;
- pcie_reg = pci_pcie_cap(ha->pdev);
- if (pcie_reg) {
+ if (pci_is_pcie(ha->pdev)) {
char lwstr[6];
- uint16_t pcie_lstat, lspeed, lwidth;
+ uint32_t lstat, lspeed, lwidth;
- pcie_reg += PCI_EXP_LNKCAP;
- pci_read_config_word(ha->pdev, pcie_reg, &pcie_lstat);
- lspeed = pcie_lstat & (BIT_0 | BIT_1 | BIT_2 | BIT_3);
- lwidth = (pcie_lstat &
- (BIT_4 | BIT_5 | BIT_6 | BIT_7 | BIT_8 | BIT_9)) >> 4;
+ pcie_capability_read_dword(ha->pdev, PCI_EXP_LNKCAP, &lstat);
+ lspeed = lstat & PCI_EXP_LNKCAP_SLS;
+ lwidth = (lstat & PCI_EXP_LNKCAP_MLW) >> 4;
strcpy(str, "PCIe (");
if (lspeed == 1)
--
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 00/11] First pass at merging Bart's HA work
On Wed, Dec 5, 2012 at 8:50 PM, Bart Van Assche wrote: [...] > The only way to make I/O work reliably if a failure can occur at the > transport layer is to use multipathd on top of ib_srp. If a connection fails > for some reason, then the SRP SCSI host will be removed after the SCSI error > handler has finished with its error recovery strategy. And once the > transport layer is operational again and srp_daemon detects that the > initiator is no longer logged in srp_daemon will make ib_srp log in again. > multipathd will then cause I/O to continue over the new path. Claim basically understood and agreed however, does this also hold when the link is back again, that is can't SRP login via this single path also when there's no multipath on top? Or. -- 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
[Suggestion] drivers/target/sbp/ : set tport->tpg to NULL when clean up for failure.
Hello Maintainers:
in drivers/target/sbp/sbp_target.c:
tport->tpg must be NULL before process it in function sbp_make_tpg. (line
2185..2188)
tport->tpg assigned a ptr (line 2198)
if processing failed, not set tport->tpg = NULL (line 2208..2212, 2217..2221)
we have done: when free tport->tpg, set it to NULL (line 2233..2234)
is it valuable to let tport->tpg = NULL, when clean up for failure ?
Regards
gchen.
2168 static struct se_portal_group *sbp_make_tpg(
2169 struct se_wwn *wwn,
2170 struct config_group *group,
2171 const char *name)
2172 {
2173 struct sbp_tport *tport =
2174 container_of(wwn, struct sbp_tport, tport_wwn);
2175
2176 struct sbp_tpg *tpg;
2177 unsigned long tpgt;
2178 int ret;
2179
2180 if (strstr(name, "tpgt_") != name)
2181 return ERR_PTR(-EINVAL);
2182 if (kstrtoul(name + 5, 10, &tpgt) || tpgt > UINT_MAX)
2183 return ERR_PTR(-EINVAL);
2184
2185 if (tport->tpg) {
2186 pr_err("Only one TPG per Unit is possible.\n");
2187 return ERR_PTR(-EBUSY);
2188 }
2189
2190 tpg = kzalloc(sizeof(*tpg), GFP_KERNEL);
2191 if (!tpg) {
2192 pr_err("Unable to allocate struct sbp_tpg\n");
2193 return ERR_PTR(-ENOMEM);
2194 }
2195
2196 tpg->tport = tport;
2197 tpg->tport_tpgt = tpgt;
2198 tport->tpg = tpg;
2199
2200 /* default attribute values */
2201 tport->enable = 0;
2202 tport->directory_id = -1;
2203 tport->mgt_orb_timeout = 15;
2204 tport->max_reconnect_timeout = 5;
2205 tport->max_logins_per_lun = 1;
2206
2207 tport->mgt_agt = sbp_management_agent_register(tport);
2208 if (IS_ERR(tport->mgt_agt)) {
2209 ret = PTR_ERR(tport->mgt_agt);
2210 kfree(tpg);
2211 return ERR_PTR(ret);
2212 }
2213
2214 ret = core_tpg_register(&sbp_fabric_configfs->tf_ops, wwn,
2215 &tpg->se_tpg, (void *)tpg,
2216 TRANSPORT_TPG_TYPE_NORMAL);
2217 if (ret < 0) {
2218 sbp_management_agent_unregister(tport->mgt_agt);
2219 kfree(tpg);
2220 return ERR_PTR(ret);
2221 }
2223 return &tpg->se_tpg;
2224 }
2225
2226 static void sbp_drop_tpg(struct se_portal_group *se_tpg)
2227 {
2228 struct sbp_tpg *tpg = container_of(se_tpg, struct sbp_tpg, se_tpg);
2229 struct sbp_tport *tport = tpg->tport;
2230
2231 core_tpg_deregister(se_tpg);
2232 sbp_management_agent_unregister(tport->mgt_agt);
2233 tport->tpg = NULL;
2234 kfree(tpg);
2235 }
2236
--
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
