Re: [PATCH 6/7] blk_end_request: remove/unexport end_that_request_*
On Wed, Sep 05 2007 at 2:13 +0300, Kiyoshi Ueda [EMAIL PROTECTED] wrote: Hi, On Tue, 4 Sep 2007 17:25:14 -0400, Halevy, Benny [EMAIL PROTECTED] wrote: We suspect we'll still need the extern entry points for handling the bidi request in the scsi_io_completion() path as we only want to call end_that_request_chunk on req-next_rq and never end_that_request_last. (see http://www.bhalevy.com/open-osd/download/linux-2.6.23-rc2_and_iscsi-iscsi-2007_08_09/0005-SCSI-bidi-support.patch) If this patch-set is merged, there may be other way to do that. For tricky drivers, special interface, blk_end_request_callback(), is added in the patch 5/7. (http://marc.info/?l=linux-kernelm=118860027714753w=2) Currently, only user of the interface is ide-cd (cdrom_newpc_intr()). It needs to call only end_that_request_first() too. With the patch 7/7, you can set your own handler in rq-end_io() to complete the request by your own way. Thanks, Kiyoshi Ueda That will not work, as I will have no means of releasing the BIOs of the bidi request, which can not use end_request(). I guess as Jens said it's OK to remove them now, and later we can just add end_that_request_first(), will be enough. Or we can patch end_request() to also call __end_that_request_first(req-next_rq) if not NULL. Jens which method do you prefer? I will adjust my patches accordingly. Thanks Boaz Harrosh - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] zfcp: add statistics and other zfcp related information to sysfs
On Monday 03 September 2007 14:40, Matthew Wilcox wrote: On Mon, Sep 03, 2007 at 02:16:21PM +0200, Swen Schillig wrote: /sys/bus/ccw/drivers/zfcp/0.0.1707 /* information for the virtual adapter */ statistic_services/ requests megabytes utilization seconds_active /* LUN specific info for channel- and fabric-latency */ 0x500507630300c562/0x401040a6/ read_latency write_latency cmd_latency Please comment if this would be an acceptable way to publish the additional information. This seems like it might be information that other adapters could, in theory, also provide. Maybe the first set of stats should be added to /sys/class/scsi_host/hostN/ and the second set to /sys/class/scsi_device/H:C:T:L/ ? The names of the individual files make sense to me. Matthew, thanks for your feedback. In the past we were trying a centralized and common approach a couple of times, with no success. Since we really need to have our data available soon, I'd prefer to start off with the proprietary location and make this data available to our customers. Anybody else some comments ? Otherwise I'll post the patch. Cheers Swen - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Fedora Core 5 Drivers
Hi, I am a newbie to Linux. We are installing Fedora Core 5, but unable to view the SCSI hard drives. We are using Dell Power Edge 1850 with on-board SCSI RAID. From my research, it requires the following drivers as the kernel is 2.6.18-1.2257.fc5smp, use the 'megaraid_mbox' and 'megaraid_mm' drivers. Where can I find these drivers, any help is appreciated? Thanks, D - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fedora Core 5 Drivers
On Wed, Sep 05, 2007 at 09:40:11AM -0400, Dev wrote: Hi, I am a newbie to Linux. We are installing Fedora Core 5, but unable to view the SCSI hard drives. We are using Dell Power Edge 1850 with on-board SCSI RAID. From my research, it requires the following drivers as the kernel is 2.6.18-1.2257.fc5smp, use the 'megaraid_mbox' and 'megaraid_mm' drivers. fedora 5 is quite *old* Where can I find these drivers, any help is appreciated? rebase on newer fedora and ask directly in fedora support channels. -- maks - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] blk_end_request: changing normal drivers
Hi Benny, Thank you for the comments. On Wed, 05 Sep 2007 10:45:54 +0300, Boaz Harrosh [EMAIL PROTECTED] wrote: On Sat, Sep 01 2007 at 1:42 +0300, Kiyoshi Ueda [EMAIL PROTECTED] wrote: arch/arm/plat-omap/mailbox.c|9 ++--- arch/um/drivers/ubd_kern.c | 10 +- block/elevator.c|4 ++-- block/ll_rw_blk.c | 15 +-- drivers/block/DAC960.c |6 ++ drivers/block/floppy.c |8 +++- drivers/block/lguest_blk.c |5 + drivers/block/nbd.c |4 +--- drivers/block/ps3disk.c |6 +- drivers/block/sunvdc.c |5 + drivers/block/sx8.c |4 +--- drivers/block/ub.c |4 ++-- drivers/block/viodasd.c |5 + drivers/block/xen-blkfront.c|5 ++--- drivers/cdrom/viocd.c |5 + drivers/ide/ide-cd.c|6 +++--- drivers/ide/ide-io.c| 22 +++--- drivers/message/i2o/i2o_block.c |8 ++-- drivers/mmc/card/block.c| 24 +--- drivers/mmc/card/queue.c|4 ++-- drivers/s390/block/dasd.c |4 +--- drivers/s390/char/tape_block.c |3 +-- drivers/scsi/ide-scsi.c |8 drivers/scsi/scsi_lib.c | 13 ++--- 24 files changed, 57 insertions(+), 130 deletions(-) Please Separate this patch to at least three patches. 1. Block layer - block/elevator.c block/ll_rw_blk.c 2. SCSI-ML - drivers/scsi/scsi_lib.c 3. Normal drivers, can also be separated into logical groups like scsi/block etc.. This is because these patches introduce conflicts to lots of queued work I have, and if you separate them it will help me with my giting. Also I think that this is logical. Block-layer and scsi_lib are not drivers, the Subject of the patch does not match. I see. OK, I will separate this patch for each driver so that driver maintainers and developers can apply them easily. Thanks, Kiyoshi Ueda - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] qla2xxx: add target mode support
On Sat, 01 Sep 2007, FUJITA Tomonori wrote: This adds target mode support to qla2xxx. With set ql2enable_target_mode module parameter to 1, the driver runs in target mode. By default, ql2enable_target_mode is set to 0, and the driver should work in initiator mode as before. The driver could support dual-mode in the future but it doesn't at the moment (we need to add dual-mode support tgt first). It is based on scst qla2xxx target mode driver. Mike converted the driver to use tgt long ago. I changed it to use the latest (mainline) version of qla2xxx driver and tgt, and also converted it to use fc transport class. Thanks for doing this. Some initial comments before a full review is complete, As was seen from the initiator updates needed for 24xx support, there are comparable changes needed in the area of target-mode support for 4gb and 8gb parts. Also, which ISPs and firmwares were exercised with this code? -- av - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] zfcp: add statistics and other zfcp relatedinformation to sysfs
From: Swen Schillig [EMAIL PROTECTED]
add statistics and other zfcp related information to sysfs
The zfcp adapter provides a variety of information which was never
published to the external world. This patch adds a few of those statistics
to the sysfs tree structure.
These are reflected in the following attributes
/sys/bus/ccw/drivers/zfcp/0.0.1707
/* information for the virtual adapter */
statistic_services/
requests
megabytes
utilization
seconds_active
/* LUN specific info for channel- and fabric-latency */
0x500507630300c562/0x401040a6/
read_latency
write_latency
cmd_latency
Signed-off-by: Swen Schillig [EMAIL PROTECTED]
---
drivers/s390/scsi/Makefile|2
drivers/s390/scsi/zfcp_aux.c | 30
drivers/s390/scsi/zfcp_def.h | 58 +
drivers/s390/scsi/zfcp_ext.h | 32 ++---
drivers/s390/scsi/zfcp_fsf.c |1
drivers/s390/scsi/zfcp_fsf.h | 29
drivers/s390/scsi/zfcp_qdio.c | 34 +
drivers/s390/scsi/zfcp_sysfs_statistics.c | 191 ++
drivers/s390/scsi/zfcp_sysfs_unit.c | 63 +
9 files changed, 394 insertions(+), 46 deletions(-)
Index: HEAD/drivers/s390/scsi/zfcp_def.h
===
--- HEAD.orig/drivers/s390/scsi/zfcp_def.h
+++ HEAD/drivers/s390/scsi/zfcp_def.h
@@ -1,23 +1,23 @@
-/*
+/*
* This file is part of the zfcp device driver for
* FCP adapters for IBM System z9 and zSeries.
*
* (C) Copyright IBM Corp. 2002, 2006
- *
- * 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; either version 2, or (at your option)
- * any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
- */
+ *
+ * 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; either version 2, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
#ifndef ZFCP_DEF_H
#define ZFCP_DEF_H
@@ -90,7 +90,7 @@ zfcp_address_to_sg(void *address, struct
#define ZFCP_DEVICE_TYPE0x1732
#define ZFCP_DEVICE_MODEL 0x03
#define ZFCP_DEVICE_MODEL_PRIV 0x04
-
+
/* allow as many chained SBALs as are supported by hardware */
#define ZFCP_MAX_SBALS_PER_REQ FSF_MAX_SBALS_PER_REQ
#define ZFCP_MAX_SBALS_PER_CT_REQ FSF_MAX_SBALS_PER_REQ
@@ -508,7 +508,7 @@ struct zfcp_rc_entry {
/*
* this allows removal of logging code by the preprocessor
- * (the most detailed log level still to be compiled in is specified,
+ * (the most detailed log level still to be compiled in is specified,
* higher log levels are removed)
*/
#define ZFCP_LOG_LEVEL_LIMIT ZFCP_LOG_LEVEL_TRACE
@@ -546,7 +546,7 @@ do { \
if (ZFCP_LOG_CHECK(level)) \
_ZFCP_LOG(fmt, ##args); \
} while (0)
-
+
#if ZFCP_LOG_LEVEL_LIMIT ZFCP_LOG_LEVEL_NORMAL
# define ZFCP_LOG_NORMAL(fmt, args...) do { } while (0)
#else
@@ -583,8 +583,8 @@ do { \
/*** ADAPTER/PORT/UNIT AND FSF_REQ STATUS FLAGS **/
-/*
- * Note, the leftmost status byte is common among adapter, port
+/*
+ * Note, the leftmost status byte is common among adapter, port
* and unit
*/
#define ZFCP_COMMON_FLAGS 0xfff0
@@ -868,6 +868,17 @@ struct zfcp_erp_action {
struct timer_list timer;
};
+struct latency_cont {
+ u32 channel;
+ u32 fabric;
+ u32 counter;
+};
+
+struct zfcp_latencies {
+ struct latency_cont read;
+ struct latency_cont write;
+ struct latency_cont cmd;
+};
struct zfcp_adapter {
struct list_headlist; /* list of adapters */
@@ -883,6 +894,7 @@ struct zfcp_adapter {
u32 adapter_features; /* FCP channel
Re: [PATCH 4/5] qla2xxx: add target mode support
On Wed, 5 Sep 2007 08:05:34 -0700 Andrew Vasquez [EMAIL PROTECTED] wrote: On Sat, 01 Sep 2007, FUJITA Tomonori wrote: This adds target mode support to qla2xxx. With set ql2enable_target_mode module parameter to 1, the driver runs in target mode. By default, ql2enable_target_mode is set to 0, and the driver should work in initiator mode as before. The driver could support dual-mode in the future but it doesn't at the moment (we need to add dual-mode support tgt first). It is based on scst qla2xxx target mode driver. Mike converted the driver to use tgt long ago. I changed it to use the latest (mainline) version of qla2xxx driver and tgt, and also converted it to use fc transport class. Thanks for doing this. Some initial comments before a full review is complete, As was seen from the initiator updates needed for 24xx support, there are comparable changes needed in the area of target-mode support for 4gb and 8gb parts. I see, thanks. I heard that 24xx firmware doesn't support target mode and I thought that I should not touch 24xx code. Not true? Also, which ISPs and firmwares were exercised with this code? qla2xxx :0a:02.0: QLogic Fibre Channel HBA Driver: 8.02.00-k2 QLogic QLA2340 - 133MHz PCI-X to 2Gb FC, Single Channel ISP2312: PCI-X (133 MHz) @ :0a:02.0 hdma-, host#=3, fw=3.03.20 IPX - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2][BNX2]: Add iSCSI support to BNX2 devices.
Michael Chan wrote: diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig index 6f2c71e..adcfbbc 100644 --- a/drivers/scsi/Kconfig +++ b/drivers/scsi/Kconfig @@ -1800,6 +1800,8 @@ config ZFCP called zfcp. If you want to compile it as a module, say M here and read file:Documentation/kbuild/modules.txt. +source drivers/scsi/bnx2i/Kconfig + config SCSI_SRP tristate SCSI RDMA Protocol helper library depends on SCSI PCI diff --git a/drivers/scsi/Makefile b/drivers/scsi/Makefile index 86a7ba7..65fe633 100644 --- a/drivers/scsi/Makefile +++ b/drivers/scsi/Makefile @@ -133,6 +133,7 @@ obj-$(CONFIG_SCSI_IBMVSCSIS)+= ibmvscsi/ obj-$(CONFIG_SCSI_HPTIOP) += hptiop.o obj-$(CONFIG_SCSI_STEX)+= stex.o obj-$(CONFIG_PS3_ROM) += ps3rom.o +obj-$(CONFIG_SCSI_BNX2_ISCSI) += bnx2i/ obj-$(CONFIG_ARM) += arm/ diff --git a/drivers/scsi/bnx2i/57xx_iscsi_constants.h b/drivers/scsi/bnx2i/57xx_iscsi_constants.h new file mode 100644 index 000..61f07f9 --- /dev/null +++ b/drivers/scsi/bnx2i/57xx_iscsi_constants.h @@ -0,0 +1,212 @@ +#ifndef __57XX_ISCSI_CONSTANTS_H_ +#define __57XX_ISCSI_CONSTANTS_H_ + +/** +* This file defines HSI constants for the iSCSI flows +*/ + +/* iSCSI request op codes */ +#define ISCSI_OPCODE_NOP_OUT (0 | 0x40) +#define ISCSI_OPCODE_SCSI_CMD (1) +#define ISCSI_OPCODE_TMF_REQUEST (2 | 0x40) +#define ISCSI_OPCODE_LOGIN_REQUEST (3 | 0x40) +#define ISCSI_OPCODE_TEXT_REQUEST (4 | 0x40) +#define ISCSI_OPCODE_DATA_OUT (5) +#define ISCSI_OPCODE_LOGOUT_REQUEST(6 | 0x00) +#define ISCSI_OPCODE_CLEANUP_REQUEST (7) What is ISCSI_OPCODE_CLEANUP_REQUEST? + +/* iSCSI response/messages op codes */ +#define ISCSI_OPCODE_NOP_IN(0x20) +#define ISCSI_OPCODE_SCSI_RESPONSE (0x21) +#define ISCSI_OPCODE_TMF_RESPONSE (0x22) +#define ISCSI_OPCODE_LOGIN_RESPONSE(0x23) +#define ISCSI_OPCODE_TEXT_RESPONSE (0x24) +#define ISCSI_OPCODE_DATA_IN (0x25) +#define ISCSI_OPCODE_LOGOUT_RESPONSE (0x26) +#define ISCSI_OPCODE_CLEANUP_RESPONSE (0x27) +#define ISCSI_OPCODE_R2T (0x31) +#define ISCSI_OPCODE_ASYNC_MSG (0x32) +#define ISCSI_OPCODE_REJECT(0x3f) +#define ISCSI_OPCODE_NOPOUT_LOCAL_COMPLETION (0) What does the LOCAL_COMPLETION on the nopout mean? + +/* iSCSI stages */ +#define ISCSI_STAGE_SECURITY_NEGOTIATION (0) +#define ISCSI_STAGE_LOGIN_OPERATIONAL_NEGOTIATION (1) +#define ISCSI_STAGE_FULL_FEATURE_PHASE (3) + +/* iSCSI parameter defaults */ +#define ISCSI_DEFAULT_HEADER_DIGEST(0) +#define ISCSI_DEFAULT_DATA_DIGEST (0) +#define ISCSI_DEFAULT_INITIAL_R2T (1) +#define ISCSI_DEFAULT_IMMEDIATE_DATA (1) +#define ISCSI_DEFAULT_MAX_PDU_LENGTH (0x2000) +#define ISCSI_DEFAULT_FIRST_BURST_LENGTH (0x1) +#define ISCSI_DEFAULT_MAX_BURST_LENGTH (0x4) +#define ISCSI_DEFAULT_MAX_OUTSTANDING_R2T (1) + +/* iSCSI parameter limits */ +#define ISCSI_MIN_VAL_MAX_PDU_LENGTH (0x200) +#define ISCSI_MAX_VAL_MAX_PDU_LENGTH (0xff) +#define ISCSI_MIN_VAL_BURST_LENGTH (0x200) +#define ISCSI_MAX_VAL_BURST_LENGTH (0xff) +#define ISCSI_MIN_VAL_MAX_OUTSTANDING_R2T (1) +#define ISCSI_MAX_VAL_MAX_OUTSTANDING_R2T (0xff) /* 0x1 according to RFC */ + +/* SCSI command response codes */ +#define ISCSI_SCSI_CMD_RESPONSE_CMD_COMPLETED (0x00) +#define ISCSI_SCSI_CMD_RESPONSE_TARGET_FAILURE (0x01) + +/* SCSI command status codes */ +#define ISCSI_SCSI_CMD_STATUS_GOOD (0x00) +#define ISCSI_SCSI_CMD_STATUS_CHECK_CONDITION (0x02) +#define ISCSI_SCSI_CMD_STATUS_INTERMIDIATE (0x10) + +/* TMF codes */ +#define ISCSI_TMF_ABORT_TASK (1) +#define ISCSI_TMF_LOGICAL_UNIT_RESET (5) + +/* TMF response codes */ +#define ISCSI_TMF_RESPONSE_FUNCTION_COMPLETE (0x00) +#define ISCSI_TMF_RESPONSE_TASK_DOESNT_EXIST (0x01) +#define ISCSI_TMF_RESPONSE_LUN_DOESNT_EXIST(0x02) +#define ISCSI_TMF_RESPONSE_TASK_STILL_ALLEGIANT(0x03) +#define ISCSI_TMF_RESPONSE_FUNCTION_NOT_SUPPORTED (0x05) +#define ISCSI_TMF_RESPONSE_FUNCTION_AUTHORIZATION_FAILED (0x06) +#define ISCSI_TMF_RESPONSE_FUNCTION_REJECTED (0xff) + +/* Logout reason codes */ +/*#define ISCSI_LOGOUT_REASON_CLOSE_CONNECTION (1) */ + +/* Logout response codes */ +#define ISCSI_LOGOUT_RESPONSE_CONNECTION_CLOSED (0) +#define ISCSI_LOGOUT_RESPONSE_CID_NOT_FOUND (1) +#define ISCSI_LOGOUT_RESPONSE_CLEANUP_FAILED (3) + +/* iSCSI task types */ +#define ISCSI_TASK_TYPE_READ(0) +#define ISCSI_TASK_TYPE_WRITE (1) +#define ISCSI_TASK_TYPE_MPATH (2) All of these iscsi code shoulds be in iscsi_proto.h or
[PATCH] aic94xx: fix smartctl utility problem
Fixed the problem that smartctl -a /dev/some_sata_disk -d ata does not
work on SATA device.
( The smartctl v5.38 does need -d ata option.)
The root cause is the aic94xx driver does not return ATA output register due
to performance reason.
The aic94xx need check ATA command which need ATA output register and turn
on internal flag to
enable firmware to return ATA output register to top layer.
It also add new ATA commands to ata.h sush as ATA_CMD_CHK_MEDIA_TYPE and
ATA_CMD_SMART.
Signed-off-by: Gilbert Wu [EMAIL PROTECTED]
diff -urN a/drivers/scsi/aic94xx/aic94xx_task.c
b/drivers/scsi/aic94xx/aic94xx_task.c
--- a/drivers/scsi/aic94xx/aic94xx_task.c 2007-09-04 14:55:57.0
-0700
+++ b/drivers/scsi/aic94xx/aic94xx_task.c 2007-09-05 14:55:45.0
-0700
@@ -25,6 +25,7 @@
*/
#include linux/spinlock.h
+#include linux/hdreg.h
#include aic94xx.h
#include aic94xx_sas.h
#include aic94xx_hwi.h
@@ -152,6 +153,22 @@
pci_unmap_sg(asd_ha-pcidev, task-scatter, task-num_scatter,
task-data_dir);
}
+static const struct ata_command_table {
+ u8 command;
+ u8 sub_command;
+} ata_command_tbl[] = {
+ {ATA_CMD_CHK_MEDIA_TYPE, 0},
+ {ATA_CMD_DEV_RESET, 0},
+ {ATA_CMD_EDD,0},
+ {ATA_CMD_IDLEIMMEDIATE, 0},
+ {ATA_CMD_READ_NATIVE_MAX,0},
+ {ATA_CMD_READ_NATIVE_MAX_EXT,0},
+ {ATA_CMD_SET_MAX,0},
+ {ATA_CMD_SET_MAX_EXT,0},
+ {ATA_CMD_SMART, SMART_STATUS},
+ {ATA_CMD_SMART, SMART_IMMEDIATE_OFFLINE},
+ {0,0} /* terminate list */
+};
/* -- Task complete tasklet -- */
@@ -253,6 +270,7 @@
break;
case TC_SSP_RESP:
case TC_ATA_RESP:
+ case TC_CSMI:
ts-resp = SAS_TASK_COMPLETE;
ts-stat = SAS_PROTO_RESPONSE;
asd_get_response_tasklet(ascb, dl);
@@ -375,6 +393,21 @@
/* -- ATA -- */
+int need_ata_output_reg(u8 command, u8 sub_command)
+{
+
+ int i;
+
+ for (i = 0; ata_command_tbl[i].command != 0 ; i++) {
+
+ if (ata_command_tbl[i].command == command
+ (!ata_command_tbl[i].sub_command ||
+ ata_command_tbl[i].sub_command == sub_command ))
+ return 1;
+ }
+ return 0;
+}
+
static int asd_build_ata_ascb(struct asd_ascb *ascb, struct sas_task *task,
gfp_t gfp_flags)
{
@@ -427,6 +460,9 @@
flags |= STP_AFFIL_POLICY;
scb-ata_task.flags = flags;
}
+ if
(need_ata_output_reg(scb-ata_task.fis.command,scb-ata_task.fis.features))
+ scb-ata_task.ata_flags|=CSMI_TASK;
+
ascb-tasklet_complete = asd_task_tasklet_complete;
if (likely(!task-ata_task.device_control_reg_update))
diff -urN a/include/linux/ata.h b/include/linux/ata.h
--- a/include/linux/ata.h 2007-09-04 14:48:44.0 -0700
+++ b/include/linux/ata.h 2007-09-04 19:28:05.0 -0700
@@ -175,6 +175,8 @@
ATA_CMD_READ_LOG_EXT= 0x2f,
ATA_CMD_PMP_READ= 0xE4,
ATA_CMD_PMP_WRITE = 0xE8,
+ ATA_CMD_CHK_MEDIA_TYPE = 0xD1,
+ ATA_CMD_SMART = 0xB0,
/* READ_LOG_EXT pages */
ATA_LOG_SATA_NCQ= 0x10,
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] aic94xx: Add new PCI ID for ASC58300
Add new HBA PCI ID (0x416) for ASC58300 which has eight port SAS and
SATA PCI-X 133MHz low profile host bus adapter with two mini SAS 4x
external connectors.
Signed-off-by: Gilbert Wu [EMAIL PROTECTED]
diff -urN a/drivers/scsi/aic94xx/aic94xx_hwi.h
b/drivers/scsi/aic94xx/aic94xx_hwi.h
--- a/drivers/scsi/aic94xx/aic94xx_hwi.h2007-09-04 15:23:22.0
-0700
+++ b/drivers/scsi/aic94xx/aic94xx_hwi.h2007-09-05 15:44:57.0
-0700
@@ -40,18 +40,6 @@
#define ASD_MAX_PHYS 8
#define ASD_PCBA_SN_SIZE 12
-/* Those are to be further named properly, the RAZORx part, and
- * subsequently included in include/linux/pci_ids.h.
- */
-#define PCI_DEVICE_ID_ADAPTEC2_RAZOR10 0x410
-#define PCI_DEVICE_ID_ADAPTEC2_RAZOR12 0x412
-#define PCI_DEVICE_ID_ADAPTEC2_RAZOR1E 0x41E
-#define PCI_DEVICE_ID_ADAPTEC2_RAZOR1F 0x41F
-#define PCI_DEVICE_ID_ADAPTEC2_RAZOR30 0x430
-#define PCI_DEVICE_ID_ADAPTEC2_RAZOR32 0x432
-#define PCI_DEVICE_ID_ADAPTEC2_RAZOR3E 0x43E
-#define PCI_DEVICE_ID_ADAPTEC2_RAZOR3F 0x43F
-
struct asd_ha_addrspace {
void __iomem *addr;
unsigned long start; /* pci resource start */
diff -urN a/drivers/scsi/aic94xx/aic94xx_init.c
b/drivers/scsi/aic94xx/aic94xx_init.c
--- a/drivers/scsi/aic94xx/aic94xx_init.c 2007-09-04 15:23:14.0
-0700
+++ b/drivers/scsi/aic94xx/aic94xx_init.c 2007-09-04 15:24:03.0
-0700
@@ -829,22 +829,15 @@
};
static const struct pci_device_id aic94xx_pci_table[] __devinitdata = {
- {PCI_DEVICE(PCI_VENDOR_ID_ADAPTEC2, PCI_DEVICE_ID_ADAPTEC2_RAZOR10),
-0, 0, 1},
- {PCI_DEVICE(PCI_VENDOR_ID_ADAPTEC2, PCI_DEVICE_ID_ADAPTEC2_RAZOR12),
-0, 0, 1},
- {PCI_DEVICE(PCI_VENDOR_ID_ADAPTEC2, PCI_DEVICE_ID_ADAPTEC2_RAZOR1E),
-0, 0, 1},
- {PCI_DEVICE(PCI_VENDOR_ID_ADAPTEC2, PCI_DEVICE_ID_ADAPTEC2_RAZOR1F),
-0, 0, 1},
- {PCI_DEVICE(PCI_VENDOR_ID_ADAPTEC2, PCI_DEVICE_ID_ADAPTEC2_RAZOR30),
-0, 0, 2},
- {PCI_DEVICE(PCI_VENDOR_ID_ADAPTEC2, PCI_DEVICE_ID_ADAPTEC2_RAZOR32),
-0, 0, 2},
- {PCI_DEVICE(PCI_VENDOR_ID_ADAPTEC2, PCI_DEVICE_ID_ADAPTEC2_RAZOR3E),
-0, 0, 2},
- {PCI_DEVICE(PCI_VENDOR_ID_ADAPTEC2, PCI_DEVICE_ID_ADAPTEC2_RAZOR3F),
-0, 0, 2},
+ {PCI_DEVICE(PCI_VENDOR_ID_ADAPTEC2, 0x410),0, 0, 1},
+ {PCI_DEVICE(PCI_VENDOR_ID_ADAPTEC2, 0x412),0, 0, 1},
+ {PCI_DEVICE(PCI_VENDOR_ID_ADAPTEC2, 0x416),0, 0, 1},
+ {PCI_DEVICE(PCI_VENDOR_ID_ADAPTEC2, 0x41E),0, 0, 1},
+ {PCI_DEVICE(PCI_VENDOR_ID_ADAPTEC2, 0x41F),0, 0, 1},
+ {PCI_DEVICE(PCI_VENDOR_ID_ADAPTEC2, 0x430),0, 0, 2},
+ {PCI_DEVICE(PCI_VENDOR_ID_ADAPTEC2, 0x432),0, 0, 2},
+ {PCI_DEVICE(PCI_VENDOR_ID_ADAPTEC2, 0x43E),0, 0, 2},
+ {PCI_DEVICE(PCI_VENDOR_ID_ADAPTEC2, 0x43F),0, 0, 2},
{}
};
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2][BNX2]: Add iSCSI support to BNX2 devices.
On Wed, 2007-09-05 at 13:34 -0500, Mike Christie wrote:
Michael Chan wrote:
+* This file defines HSI constants for the iSCSI flows
+*/
+
+/* iSCSI request op codes */
+#define ISCSI_OPCODE_NOP_OUT (0 | 0x40)
+#define ISCSI_OPCODE_SCSI_CMD (1)
+#define ISCSI_OPCODE_TMF_REQUEST (2 | 0x40)
+#define ISCSI_OPCODE_LOGIN_REQUEST (3 | 0x40)
+#define ISCSI_OPCODE_TEXT_REQUEST (4 | 0x40)
+#define ISCSI_OPCODE_DATA_OUT (5)
+#define ISCSI_OPCODE_LOGOUT_REQUEST(6 | 0x00)
+#define ISCSI_OPCODE_CLEANUP_REQUEST (7)
What is ISCSI_OPCODE_CLEANUP_REQUEST?
This is a local message between iSCSI driver and the firmware to cleanup
iSCSI task resources held by chip. This operation is required to reclaim
SCSI command related resources after the TMF response is received for a
task and before it is completed to SCSI-ML
+
+/* iSCSI response/messages op codes */
+#define ISCSI_OPCODE_NOP_IN(0x20)
+#define ISCSI_OPCODE_SCSI_RESPONSE (0x21)
+#define ISCSI_OPCODE_TMF_RESPONSE (0x22)
+#define ISCSI_OPCODE_LOGIN_RESPONSE(0x23)
+#define ISCSI_OPCODE_TEXT_RESPONSE (0x24)
+#define ISCSI_OPCODE_DATA_IN (0x25)
+#define ISCSI_OPCODE_LOGOUT_RESPONSE (0x26)
+#define ISCSI_OPCODE_CLEANUP_RESPONSE (0x27)
+#define ISCSI_OPCODE_R2T (0x31)
+#define ISCSI_OPCODE_ASYNC_MSG (0x32)
+#define ISCSI_OPCODE_REJECT(0x3f)
+#define ISCSI_OPCODE_NOPOUT_LOCAL_COMPLETION (0)
What does the LOCAL_COMPLETION on the nopout mean?
This is the completion notification for NOPOUT pdus which does not
involve response from the target. Following two NOPOUTs are classified
under this -
1. Initiator's proactive nopout with ITT=0x
2. Initiator's response to target nopin with TTT != 0x
+
+/* iSCSI stages */
+#define ISCSI_STAGE_SECURITY_NEGOTIATION (0)
+#define ISCSI_STAGE_LOGIN_OPERATIONAL_NEGOTIATION (1)
+#define ISCSI_STAGE_FULL_FEATURE_PHASE (3)
+/* Logout response codes */
+#define ISCSI_LOGOUT_RESPONSE_CONNECTION_CLOSED (0)
+#define ISCSI_LOGOUT_RESPONSE_CID_NOT_FOUND (1)
+#define ISCSI_LOGOUT_RESPONSE_CLEANUP_FAILED (3)
+
+/* iSCSI task types */
+#define ISCSI_TASK_TYPE_READ(0)
+#define ISCSI_TASK_TYPE_WRITE (1)
+#define ISCSI_TASK_TYPE_MPATH (2)
All of these iscsi code shoulds be in iscsi_proto.h or should be added
there.
This is a very tricky proposal as this header file is automatically
generated by a well defined process and is shared between various driver
supporting multiple platform/OS and the firmware. If it is not of a big
issue I would like to keep it the way it is.
+
+#endif
diff --git a/drivers/scsi/bnx2i/bnx2i_hwi.c b/drivers/scsi/bnx2i/bnx2i_hwi.c
new file mode 100644
index 000..b74a93c
--- /dev/null
+++ b/drivers/scsi/bnx2i/bnx2i_hwi.c
@@ -0,0 +1,1977 @@
+
+ if (tmf_cqe-response == ISCSI_TMF_RSP_COMPLETE) {
+ if (aborted_cmd-scsi_cmd) {
+ aborted_cmd-scsi_cmd-result = DID_ABORT 16;
+ aborted_cmd-scsi_cmd-resid =
should use resid wrappers throughout driver.
+ aborted_cmd-scsi_cmd-request_bufflen;
Should use bufflen wrappers throught driver.
Will look into this.
+ cmd-cmd_state = ISCSI_CMD_STATE_INITIATED;
+ sc-SCp.ptr = (char *) cmd;
+
+ if (cmd-req.itt != ITT_INVALID_SIGNATURE) {
+ bnx2i_send_iscsi_scsicmd(conn, cmd);
+ list_add_tail(cmd-link, sess-active_cmds);
+ sess-num_active_cmds++;
+ }
+ return 0;
+
+iscsi_win_closed:
+cmd_not_accepted:
+ return SCSI_MLQUEUE_HOST_BUSY;
+
+dev_not_found:
+ sc-sense_buffer[0] = 0x70;
+ sc-sense_buffer[2] = NOT_READY;
+ sc-sense_buffer[7] = 0x6;
+ sc-sense_buffer[12] = 0x08;
+ sc-sense_buffer[13] = 0x00;
do not fake sense and do not face sense and set a host byte of
DID_NO_CONNECT. DID_NO_CONNECT is fine.
ok, thanks.
+ sc-result = (DID_NO_CONNECT 16);
+ sc-resid = sc-request_bufflen;
+ sc-scsi_done(sc);
+ return 0;
+}
+
+
+
+/*
+ * TMF request timeout handler
+ */
+static void bnx2i_iscsi_tmf_timer(unsigned long data)
+{
+ struct bnx2i_cmd *cmd = (struct bnx2i_cmd *) data;
+
+ printk(KERN_ALERT TMF timer: abort failed, cmd 0x%p\n, cmd);
+ cmd-cmd_state = ISCSI_CMD_STATE_TMF_TIMEOUT;
+ cmd-conn-sess-recovery_state = ISCSI_SESS_RECOVERY_OPEN_ISCSI;
+ iscsi_conn_error(cmd-conn-cls_conn, ISCSI_ERR_CONN_FAILED);
+}
+
+
+/*
+ * initiate command abort process by requesting CNIC to send
+ * an iSCSI TMF request to target
+ */
+static int bnx2i_initiate_abort_cmd(struct
[PATCH] fusion -mm bits : Kconfig menuconfig objects, use kzalloc in mptctl, fix mem leaks, kill redundant memset
James - These fusion patchs from -mm can be merged into scsi-misc. Here is a
single patch containing all four changes.
Changeset:
[patch 08/30] Use menuconfig objects: Fusion
http://marc.info/?l=linux-scsim=118678275800902w=2
[patch 26/30] drivers/message/fusion/mptctl.c: mostly kmalloc + memset
conversion to kzalloc
http://marc.info/?l=linux-scsim=118678346112881w=2
[patch 27/30] mpt-fusion: fix two potential mem leaks
http://marc.info/?l=linux-scsim=118678345904954w=2
[patch 30/30] message/fusion: remove redundant memset
http://marc.info/?l=linux-scsim=118678345816541w=2
Signed-off-by: Eric Moore [EMAIL PROTECTED]
diff --git a/drivers/message/fusion/Kconfig b/drivers/message/fusion/Kconfig
index 3c44a2f..9b87c2f 100644
--- a/drivers/message/fusion/Kconfig
+++ b/drivers/message/fusion/Kconfig
@@ -1,15 +1,19 @@
-menu Fusion MPT device support
+menuconfig FUSION
+ bool Fusion MPT device support
depends on PCI
+ ---help---
+ Say Y here to get to see options for Fusion Message
+ Passing Technology (MPT) drivers.
+ This option alone does not add any kernel code.
+
+ If you say N, all options in this submenu will be skipped and disabled.
-config FUSION
- bool
- default n
+if FUSION
config FUSION_SPI
tristate Fusion MPT ScsiHost drivers for SPI
depends on PCI SCSI
- select FUSION
select SCSI_SPI_ATTRS
---help---
SCSI HOST support for a parallel SCSI host adapters.
@@ -25,7 +29,6 @@ config FUSION_SPI
config FUSION_FC
tristate Fusion MPT ScsiHost drivers for FC
depends on PCI SCSI
- select FUSION
select SCSI_FC_ATTRS
---help---
SCSI HOST support for a Fiber Channel host adapters.
@@ -43,7 +46,6 @@ config FUSION_FC
config FUSION_SAS
tristate Fusion MPT ScsiHost drivers for SAS
depends on PCI SCSI
- select FUSION
select SCSI_SAS_ATTRS
---help---
SCSI HOST support for a SAS host adapters.
@@ -57,7 +59,6 @@ config FUSION_SAS
config FUSION_MAX_SGE
int Maximum number of scatter gather entries (16 - 128)
- depends on FUSION
default 128
range 16 128
help
@@ -117,4 +118,4 @@ config FUSION_LOGGING
There are various debug levels that an be found in the source:
file:drivers/message/fusion/mptdebug.h
-endmenu
+endif # FUSION
diff --git a/drivers/message/fusion/mptbase.c b/drivers/message/fusion/mptbase.c
index 22cb0f8..635defd 100644
--- a/drivers/message/fusion/mptbase.c
+++ b/drivers/message/fusion/mptbase.c
@@ -1458,18 +1458,18 @@ mpt_attach(struct pci_dev *pdev, const s
struct proc_dir_entry *dent, *ent;
#endif
+ if (mpt_debug_level)
+ printk(KERN_INFO MYNAM : mpt_debug_level=%xh\n,
mpt_debug_level);
+
+ if (pci_enable_device(pdev))
+ return r;
+
ioc = kzalloc(sizeof(MPT_ADAPTER), GFP_ATOMIC);
if (ioc == NULL) {
printk(KERN_ERR MYNAM : ERROR - Insufficient memory to add
adapter!\n);
return -ENOMEM;
}
-
ioc-debug_level = mpt_debug_level;
- if (mpt_debug_level)
- printk(KERN_INFO MYNAM : mpt_debug_level=%xh\n,
mpt_debug_level);
-
- if (pci_enable_device(pdev))
- return r;
dinitprintk(ioc, printk(KERN_WARNING MYNAM : mpt_adapter_install\n));
@@ -1478,6 +1478,7 @@ mpt_attach(struct pci_dev *pdev, const s
: 64 BIT PCI BUS DMA ADDRESSING SUPPORTED\n));
} else if (pci_set_dma_mask(pdev, DMA_32BIT_MASK)) {
printk(KERN_WARNING MYNAM : 32 BIT PCI BUS DMA ADDRESSING NOT
SUPPORTED\n);
+ kfree(ioc);
return r;
}
diff --git a/drivers/message/fusion/mptctl.c b/drivers/message/fusion/mptctl.c
index b9618f4..12dfa2e 100644
--- a/drivers/message/fusion/mptctl.c
+++ b/drivers/message/fusion/mptctl.c
@@ -977,10 +977,9 @@ kbuf_alloc_2_sgl(int bytes, u32 sgdir, i
* structures for the SG elements.
*/
i = MAX_SGL_BYTES / 8;
- buflist = kmalloc(i, GFP_USER);
- if (buflist == NULL)
+ buflist = kzalloc(i, GFP_USER);
+ if (!buflist)
return NULL;
- memset(buflist, 0, i);
buflist_ent = 0;
/* Allocate a single block of memory to store the sg elements and
@@ -1379,13 +1378,12 @@ mptctl_gettargetinfo (unsigned long arg)
* 15- 8: Bus Number
* 7- 0: Target ID
*/
- pmem = kmalloc(numBytes, GFP_KERNEL);
- if (pmem == NULL) {
+ pmem = kzalloc(numBytes, GFP_KERNEL);
+ if (!pmem) {
printk(KERN_ERR %s::mptctl_gettargetinfo() @%d - no memory
available!\n,
__FILE__, __LINE__);
return -ENOMEM;
}
- memset(pmem, 0, numBytes);
pdata = (int *) pmem;
/* Get number
RE: [PATCH -mm] mpt fusion: Shut up uninitialized variable warnings
On Sunday, September 02, 2007 2:20 PM, Satyam Sharma wrote: drivers/message/fusion/mptctl.c: In function 'mptctl_mpt_command': drivers/message/fusion/mptctl.c:1764: warning: 'bufIn.len' may be used uninitialized in this function drivers/message/fusion/mptctl.c:1765: warning: 'bufOut.len' may be used uninitialized in this function come because gcc gets confused by some goto statements in above function. The warnings have been verified to be bogus, however, the function does initialize these later (after the offending goto's) in the function anyway. So let's move those initializations to top of function, thereby also shutting up these warnings. Signed-off-by: Satyam Sharma [EMAIL PROTECTED] ACK, this patch is fine. However the patch needs posting to lsml. Eric - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
