Re: [PATCH 2/3] cciss: add support for blktrace
On Mon, Nov 19 2007, Mike Miller wrote: Patch 2 of 3 This patch adds support for the blktrace utility. Please consider this for inclusion. Seems there was already a call to blk_add_trace. This patch adds ifdef's and includes the header file. Signed-off-by: Mike Miller [EMAIL PROTECTED] diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c index 2ba5a89..61bc0f3 100644 --- a/drivers/block/cciss.c +++ b/drivers/block/cciss.c @@ -41,6 +41,10 @@ #include asm/uaccess.h #include asm/io.h +#ifdef CONFIG_BLK_DEV_IO_TRACE +#include linux/blktrace_api.h +#endif /* CONFIG_BLK_DEV_IO_TRACE */ + #include linux/dma-mapping.h #include linux/blkdev.h #include linux/genhd.h @@ -3013,7 +3017,9 @@ after_error_processing: } cmd-rq-data_len = 0; cmd-rq-completion_data = cmd; +#ifdef CONFIG_BLK_DEV_IO_TRACE blk_add_trace_rq(cmd-rq-q, cmd-rq, BLK_TA_COMPLETE); +#endif /* CONFIG_BLK_DEV_IO_TRACE */ blk_complete_request(cmd-rq); } Puzzled by this patch... What is it trying to achieve? -- Jens Axboe - 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: SCSI breakage on non-cache coherent architectures
On Tue, Nov 20, 2007 at 06:51:14AM +1100, Benjamin Herrenschmidt wrote: On Mon, 2007-11-19 at 00:38 -0800, David Miller wrote: From: Benjamin Herrenschmidt [EMAIL PROTECTED] Date: Mon, 19 Nov 2007 16:35:23 +1100 I'm not sure what is the best way to fix that. Internally, I've done some test whacking some cacheline_aligned in the scsi_cmnd data structure to verify I no longer get random SLAB corruption when using my USB but that significantly bloats the size of the structure on archs such as ppc64 that don't need it and have a large cache line size. Unfortunately, I don't think there's any existing Kconfig symbol or arch provided #define to tell us that we are on a non-coherent arch afaik that could be used to make that conditional. Another option would be to kmalloc the buffer (wasn't it the case before btw ?) but I suppose some people will scream at the idea due to how the command pools are done... You could make a dma_cacheline_aligned and use that. It seems pretty reasonable. I was thinking about that. What archs would need it ? arm, mips, what else ? older parisc Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessary a good idea.[ RFC1925, 2.3 ] - 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] Unify sysfs filenames for firmware version
Looking around sysfs in an attempt to pull out SCSI card firmware
versions I found 5 different filenames used to store the information.
Only one, fw_version, was used more than once. The patch below changes
the other drivers to use this filename too.
I suspect the same applies to other subsystem drivers as well. I'll look
at them assuming this patch is well received.
Signed-Off-By: Jonathan McDowell [EMAIL PROTECTED]
-
diff --git a/drivers/message/fusion/mptscsih.c
b/drivers/message/fusion/mptscsih.c
index 626bb3c..ae80d04 100644
--- a/drivers/message/fusion/mptscsih.c
+++ b/drivers/message/fusion/mptscsih.c
@@ -3307,7 +3307,7 @@ mptscsih_version_fw_show(struct class_device *cdev, char
*buf)
(ioc-facts.FWVersion.Word 0xFF00) 8,
ioc-facts.FWVersion.Word 0x00FF);
}
-static CLASS_DEVICE_ATTR(version_fw, S_IRUGO, mptscsih_version_fw_show, NULL);
+static CLASS_DEVICE_ATTR(fw_version, S_IRUGO, mptscsih_version_fw_show, NULL);
static ssize_t
mptscsih_version_bios_show(struct class_device *cdev, char *buf)
diff --git a/drivers/scsi/arcmsr/arcmsr_attr.c
b/drivers/scsi/arcmsr/arcmsr_attr.c
index 7d7b0a5..646f24c 100644
--- a/drivers/scsi/arcmsr/arcmsr_attr.c
+++ b/drivers/scsi/arcmsr/arcmsr_attr.c
@@ -352,7 +352,7 @@ static CLASS_DEVICE_ATTR(host_driver_posted_cmd, S_IRUGO,
arcmsr_attr_host_drive
static CLASS_DEVICE_ATTR(host_driver_reset, S_IRUGO,
arcmsr_attr_host_driver_reset, NULL);
static CLASS_DEVICE_ATTR(host_driver_abort, S_IRUGO,
arcmsr_attr_host_driver_abort, NULL);
static CLASS_DEVICE_ATTR(host_fw_model, S_IRUGO, arcmsr_attr_host_fw_model,
NULL);
-static CLASS_DEVICE_ATTR(host_fw_version, S_IRUGO,
arcmsr_attr_host_fw_version, NULL);
+static CLASS_DEVICE_ATTR(fw_version, S_IRUGO, arcmsr_attr_host_fw_version,
NULL);
static CLASS_DEVICE_ATTR(host_fw_request_len, S_IRUGO,
arcmsr_attr_host_fw_request_len, NULL);
static CLASS_DEVICE_ATTR(host_fw_numbers_queue, S_IRUGO,
arcmsr_attr_host_fw_numbers_queue, NULL);
static CLASS_DEVICE_ATTR(host_fw_sdram_size, S_IRUGO,
arcmsr_attr_host_fw_sdram_size, NULL);
diff --git a/drivers/scsi/hptiop.c b/drivers/scsi/hptiop.c
index 0844331..ed130ec 100644
--- a/drivers/scsi/hptiop.c
+++ b/drivers/scsi/hptiop.c
@@ -634,7 +634,7 @@ static struct class_device_attribute hptiop_attr_version = {
static struct class_device_attribute hptiop_attr_fw_version = {
.attr = {
- .name = firmware-version,
+ .name = fw_version,
.mode = S_IRUGO,
},
.show = hptiop_show_fw_version,
diff --git a/drivers/scsi/lpfc/lpfc_attr.c b/drivers/scsi/lpfc/lpfc_attr.c
index 80a1121..32b1d2f 100644
--- a/drivers/scsi/lpfc/lpfc_attr.c
+++ b/drivers/scsi/lpfc/lpfc_attr.c
@@ -888,7 +888,7 @@ static CLASS_DEVICE_ATTR(modeldesc, S_IRUGO,
lpfc_modeldesc_show, NULL);
static CLASS_DEVICE_ATTR(modelname, S_IRUGO, lpfc_modelname_show, NULL);
static CLASS_DEVICE_ATTR(programtype, S_IRUGO, lpfc_programtype_show, NULL);
static CLASS_DEVICE_ATTR(portnum, S_IRUGO, lpfc_vportnum_show, NULL);
-static CLASS_DEVICE_ATTR(fwrev, S_IRUGO, lpfc_fwrev_show, NULL);
+static CLASS_DEVICE_ATTR(fw_version, S_IRUGO, lpfc_fwrev_show, NULL);
static CLASS_DEVICE_ATTR(hdw, S_IRUGO, lpfc_hdw_show, NULL);
static CLASS_DEVICE_ATTR(state, S_IRUGO, lpfc_state_show, NULL);
static CLASS_DEVICE_ATTR(option_rom_version, S_IRUGO,
-
J.
--
Web [The World's most affectionate creature is a muddy dog.]
site: http:// [ ] Made by
www.earth.li/~noodles/ [ ] HuggieTag 0.0.23
-
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: SCSI breakage on non-cache coherent architectures
On Tue, 2007-11-20 at 09:29 +0100, Thomas Bogendoerfer wrote: On Tue, Nov 20, 2007 at 06:51:14AM +1100, Benjamin Herrenschmidt wrote: On Mon, 2007-11-19 at 00:38 -0800, David Miller wrote: From: Benjamin Herrenschmidt [EMAIL PROTECTED] Date: Mon, 19 Nov 2007 16:35:23 +1100 I'm not sure what is the best way to fix that. Internally, I've done some test whacking some cacheline_aligned in the scsi_cmnd data structure to verify I no longer get random SLAB corruption when using my USB but that significantly bloats the size of the structure on archs such as ppc64 that don't need it and have a large cache line size. Unfortunately, I don't think there's any existing Kconfig symbol or arch provided #define to tell us that we are on a non-coherent arch afaik that could be used to make that conditional. Another option would be to kmalloc the buffer (wasn't it the case before btw ?) but I suppose some people will scream at the idea due to how the command pools are done... You could make a dma_cacheline_aligned and use that. It seems pretty reasonable. I was thinking about that. What archs would need it ? arm, mips, what else ? older parisc Actually, we already established on IRC that the lasi700 driver doesn't need this, principally because the parisc architecture doesn't do an invalidate for DMA_FROM_DEVICE but a flush and invalidate (architecturally, if you read our manuals, even pdc is entitled to write back dirty lines, so it's not clear there's actually an invalidate instruction we can use). This is also one possible temporary fix for the other architectures if we can't get a different method to work nicely. James James - 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: SCSI dynamic power management
On Mon, 2007-11-19 at 14:16 -0500, Alan Stern wrote: On Mon, 19 Nov 2007, James Bottomley wrote: Here's how it will work: scsi_prep_state_check() will see that the device is in a suspended state (probably a substate of SDEV_QUIESCE). The return value will depend on the type of suspend: For manual suspend or system suspend, the routine simply returns BLKPREP_KILL. For autosuspend, the routine will submit a workqueue request to autoresume the device and will return BLKPREP_DEFER. The trick is somehow to allow the START-STOP UNIT commands get past this filter. Is this what the REQ_PREEMPT flag is intended for? Um, that model is pretty host centric ... we wouldn't be able to use that for power management of shared devices like SAS/SATA devices in an expander or FC devices. The basic problem with power management of external devices (whether shared or not) is that it's not just what the host did to them, it's also what the environment or administrator did to them. Well, think of this as idle-device management rather than power management. Sure ... but surely that's a subset of proper power management? It's no more host-centric than the existing code in sd_suspend(). When I mentioned sending START-STOP UNIT commands above, that was a bit sloppy. What the code would actually do is call the high-level driver's suspend method, which would then send the appropriate commands to the device. (Or maybe the code would simply call scsi_bus_suspend.) If sending START-STOP UNIT during a suspend is host-centric then sd_suspend() is already guilty. Ah, but if you look, sd_suspend by default doesn't do anything ... it has to be enabled on a per device basis by the manage_start_stop attribute ... that's precisely because we can't have the sd ULD idling a SAN device when others are trying to use it. Regarding this thread's original question, the best idea I've come up with so far is to store an extra flag in the scsi_device structure indicating that a suspend or resume transition is underway. When the flag is set, commands with REQ_PREEMPT would be accepted. If the device is suspended and the flag is clear, then commands would be delayed or killed in the prep function regardless of REQ_PREEMPT. This scheme could potentially let unwanted commands go through, but I haven't been able to think of anything more suitable. I don't understand why you want to do this. Power management is a layered issue on SCSI, divided (as always) into host, device and transport. The idle you're talking about is a pure device thing, so it can be managed by the ULD (and currently is). When a unit is stopped, it automatically returns correct NOT_READY sense to most commands. The sd_done post processing could decide to wake the device and retry or return an error without ever troubling the mid layer or even block for anything.All the hooks are already in sd, why does this now need to go into block (unless there's some longer scheme for incorporating the transport and other elements into this?) James - 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: SCSI dynamic power management
Am Dienstag 20 November 2007 schrieb James Bottomley: I don't understand why you want to do this. Power management is a layered issue on SCSI, divided (as always) into host, device and transport. The idle you're talking about is a pure device thing, so it can be managed by the ULD (and currently is). When a unit is stopped, The lower layers don't know how to correctly suspend a device. sd_suspend() may know how to do it. It would also mean the LLD having to detect idleness. Regards Oliver - 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 44/59] drivers/scsi: Add missing space
On Tue, 2007-11-20 at 10:39 +, Alistair John Strachan wrote:
On Tuesday 20 November 2007 01:53:31 Joe Perches wrote:
diff --git a/drivers/scsi/NCR_D700.c b/drivers/scsi/NCR_D700.c
index 9e64b21..99403a6 100644
--- a/drivers/scsi/NCR_D700.c
+++ b/drivers/scsi/NCR_D700.c
@@ -182,7 +182,7 @@ NCR_D700_probe_one(struct NCR_D700_private *p, int
siop, int irq,
hostdata = kzalloc(sizeof(*hostdata), GFP_KERNEL);
if (!hostdata) {
- printk(KERN_ERR NCR D700: SIOP%d: Failed to allocate host
+ printk(KERN_ERR NCR D700: SIOP%d: Failed to allocate host
data, detatching\n, siop);
return -ENOMEM;
}
If you're going to sneak in unrelated spelling/grammar changes, you might as
well do it unilaterally.
drivers/scsi/NCR_D700.c|4 ++--
drivers/scsi/aic7xxx_old.c |2 +-
drivers/scsi/dc395x.c |2 +-
drivers/scsi/hosts.c |2 +-
drivers/scsi/iscsi_tcp.c |6 +++---
drivers/scsi/scsi_proc.c |2 +-
drivers/scsi/scsi_scan.c |2 +-
7 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/scsi/NCR_D700.c b/drivers/scsi/NCR_D700.c
index 9e64b21..36281c5 100644
--- a/drivers/scsi/NCR_D700.c
+++ b/drivers/scsi/NCR_D700.c
@@ -182,8 +182,8 @@ NCR_D700_probe_one(struct NCR_D700_private *p, int siop,
int irq,
hostdata = kzalloc(sizeof(*hostdata), GFP_KERNEL);
if (!hostdata) {
- printk(KERN_ERR NCR D700: SIOP%d: Failed to allocate host
- data, detatching\n, siop);
+ printk(KERN_ERR NCR D700: SIOP%d: Failed to allocate host
+ data, detaching\n, siop);
return -ENOMEM;
}
diff --git a/drivers/scsi/aic7xxx_old.c b/drivers/scsi/aic7xxx_old.c
index 8f8db5f..c79a452 100644
--- a/drivers/scsi/aic7xxx_old.c
+++ b/drivers/scsi/aic7xxx_old.c
@@ -3716,7 +3716,7 @@ aic7xxx_pci_intr(struct aic7xxx_host *p)
pci_read_config_byte(p-pdev, PCI_STATUS + 1, status1);
if ( (status1 DPE) (aic7xxx_verbose VERBOSE_MINOR_ERROR) )
-printk(WARN_LEAD Data Parity Error during PCI address or PCI write
+printk(WARN_LEAD Data Parity Error during PCI address or PCI write
phase.\n, p-host_no, -1, -1, -1);
if ( (status1 SSE) (aic7xxx_verbose VERBOSE_MINOR_ERROR) )
printk(WARN_LEAD Signal System Error Detected\n, p-host_no,
diff --git a/drivers/scsi/dc395x.c b/drivers/scsi/dc395x.c
index a9def6e..f98747c 100644
--- a/drivers/scsi/dc395x.c
+++ b/drivers/scsi/dc395x.c
@@ -1520,7 +1520,7 @@ static u8 start_scsi(struct AdapterCtlBlk* acb, struct
DeviceCtlBlk* dcb,
}
#endif
if (acb-active_dcb) {
- dprintkl(KERN_DEBUG, start_scsi: (pid#%li) Attempt to start a
+ dprintkl(KERN_DEBUG, start_scsi: (pid#%li) Attempt to start a
command while another command (pid#%li) is active.,
srb-cmd-serial_number,
acb-active_dcb-active_srb ?
diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c
index 24271a8..b53f681 100644
--- a/drivers/scsi/hosts.c
+++ b/drivers/scsi/hosts.c
@@ -141,7 +141,7 @@ int scsi_host_set_state(struct Scsi_Host *shost, enum
scsi_host_state state)
illegal:
SCSI_LOG_ERROR_RECOVERY(1,
shost_printk(KERN_ERR, shost,
-Illegal host state transition
+Invalid host state transition
%s-%s\n,
scsi_host_state_name(oldstate),
scsi_host_state_name(state)));
diff --git a/drivers/scsi/iscsi_tcp.c b/drivers/scsi/iscsi_tcp.c
index 4bcf916..2e0d9a1 100644
--- a/drivers/scsi/iscsi_tcp.c
+++ b/drivers/scsi/iscsi_tcp.c
@@ -389,7 +389,7 @@ iscsi_r2t_rsp(struct iscsi_conn *conn, struct
iscsi_cmd_task *ctask)
}
if (r2t-data_length session-max_burst)
- debug_scsi(invalid R2T with data len %u and max burst %u.
+ debug_scsi(invalid R2T with data len %u and max burst %u.
Attempting to execute request.\n,
r2t-data_length, session-max_burst);
@@ -900,13 +900,13 @@ more:
memcpy(recv_digest, conn-data, sizeof(uint32_t));
if (recv_digest != tcp_conn-in.datadgst) {
- debug_tcp(iscsi_tcp: data digest error!
+ debug_tcp(iscsi_tcp: data digest error!
0x%x != 0x%x\n, recv_digest,
tcp_conn-in.datadgst);
iscsi_conn_failure(conn, ISCSI_ERR_DATA_DGST);
return 0;
} else {
- debug_tcp(iscsi_tcp: data digest match!
+ debug_tcp(iscsi_tcp: data digest match!
Re: [PATCH] Unify sysfs filenames for firmware version
The hearburn I have with these patches is that you are changing driver-specific
attributes, not common ones as enforced/requested by a subsystem. As such, you
are breaking a management interface for existing tools/scripts.
There's been a long-standing request to create common device attributes, such as
fw_version, but I don't think they ever made it into the kernel. Not only would
the names be consistent, but the location would be consistent as well.
I'd rather you took on that work, than proceed with these patches.
-- james s
Jonathan McDowell wrote:
Looking around sysfs in an attempt to pull out SCSI card firmware
versions I found 5 different filenames used to store the information.
Only one, fw_version, was used more than once. The patch below changes
the other drivers to use this filename too.
I suspect the same applies to other subsystem drivers as well. I'll look
at them assuming this patch is well received.
Signed-Off-By: Jonathan McDowell [EMAIL PROTECTED]
-
diff --git a/drivers/message/fusion/mptscsih.c
b/drivers/message/fusion/mptscsih.c
index 626bb3c..ae80d04 100644
--- a/drivers/message/fusion/mptscsih.c
+++ b/drivers/message/fusion/mptscsih.c
@@ -3307,7 +3307,7 @@ mptscsih_version_fw_show(struct class_device *cdev, char
*buf)
(ioc-facts.FWVersion.Word 0xFF00) 8,
ioc-facts.FWVersion.Word 0x00FF);
}
-static CLASS_DEVICE_ATTR(version_fw, S_IRUGO, mptscsih_version_fw_show, NULL);
+static CLASS_DEVICE_ATTR(fw_version, S_IRUGO, mptscsih_version_fw_show, NULL);
static ssize_t
mptscsih_version_bios_show(struct class_device *cdev, char *buf)
diff --git a/drivers/scsi/arcmsr/arcmsr_attr.c
b/drivers/scsi/arcmsr/arcmsr_attr.c
index 7d7b0a5..646f24c 100644
--- a/drivers/scsi/arcmsr/arcmsr_attr.c
+++ b/drivers/scsi/arcmsr/arcmsr_attr.c
@@ -352,7 +352,7 @@ static CLASS_DEVICE_ATTR(host_driver_posted_cmd, S_IRUGO,
arcmsr_attr_host_drive
static CLASS_DEVICE_ATTR(host_driver_reset, S_IRUGO,
arcmsr_attr_host_driver_reset, NULL);
static CLASS_DEVICE_ATTR(host_driver_abort, S_IRUGO,
arcmsr_attr_host_driver_abort, NULL);
static CLASS_DEVICE_ATTR(host_fw_model, S_IRUGO, arcmsr_attr_host_fw_model,
NULL);
-static CLASS_DEVICE_ATTR(host_fw_version, S_IRUGO,
arcmsr_attr_host_fw_version, NULL);
+static CLASS_DEVICE_ATTR(fw_version, S_IRUGO, arcmsr_attr_host_fw_version,
NULL);
static CLASS_DEVICE_ATTR(host_fw_request_len, S_IRUGO,
arcmsr_attr_host_fw_request_len, NULL);
static CLASS_DEVICE_ATTR(host_fw_numbers_queue, S_IRUGO,
arcmsr_attr_host_fw_numbers_queue, NULL);
static CLASS_DEVICE_ATTR(host_fw_sdram_size, S_IRUGO,
arcmsr_attr_host_fw_sdram_size, NULL);
diff --git a/drivers/scsi/hptiop.c b/drivers/scsi/hptiop.c
index 0844331..ed130ec 100644
--- a/drivers/scsi/hptiop.c
+++ b/drivers/scsi/hptiop.c
@@ -634,7 +634,7 @@ static struct class_device_attribute hptiop_attr_version = {
static struct class_device_attribute hptiop_attr_fw_version = {
.attr = {
- .name = firmware-version,
+ .name = fw_version,
.mode = S_IRUGO,
},
.show = hptiop_show_fw_version,
diff --git a/drivers/scsi/lpfc/lpfc_attr.c b/drivers/scsi/lpfc/lpfc_attr.c
index 80a1121..32b1d2f 100644
--- a/drivers/scsi/lpfc/lpfc_attr.c
+++ b/drivers/scsi/lpfc/lpfc_attr.c
@@ -888,7 +888,7 @@ static CLASS_DEVICE_ATTR(modeldesc, S_IRUGO,
lpfc_modeldesc_show, NULL);
static CLASS_DEVICE_ATTR(modelname, S_IRUGO, lpfc_modelname_show, NULL);
static CLASS_DEVICE_ATTR(programtype, S_IRUGO, lpfc_programtype_show, NULL);
static CLASS_DEVICE_ATTR(portnum, S_IRUGO, lpfc_vportnum_show, NULL);
-static CLASS_DEVICE_ATTR(fwrev, S_IRUGO, lpfc_fwrev_show, NULL);
+static CLASS_DEVICE_ATTR(fw_version, S_IRUGO, lpfc_fwrev_show, NULL);
static CLASS_DEVICE_ATTR(hdw, S_IRUGO, lpfc_hdw_show, NULL);
static CLASS_DEVICE_ATTR(state, S_IRUGO, lpfc_state_show, NULL);
static CLASS_DEVICE_ATTR(option_rom_version, S_IRUGO,
-
J.
-
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] Unify sysfs filenames for firmware version
On Tue, Nov 20, 2007 at 11:35:26AM -0500, James Smart wrote: The hearburn I have with these patches is that you are changing driver-specific attributes, not common ones as enforced/requested by a subsystem. As such, you are breaking a management interface for existing tools/scripts. Yes, that's true. Though at present we have the heartburn that anyone wanting to write a script to pull out firmware revisions has to know exactly where every driver stores this information. There's been a long-standing request to create common device attributes, such as fw_version, but I don't think they ever made it into the kernel. Not only would the names be consistent, but the location would be consistent as well. I'd rather you took on that work, than proceed with these patches. Do you have a pointer to previous discussion about this? A central device attribute does make more sense. It'd be nice to have uniform access to details like the driver version as well. Jonathan McDowell wrote: Looking around sysfs in an attempt to pull out SCSI card firmware versions I found 5 different filenames used to store the information. Only one, fw_version, was used more than once. The patch below changes the other drivers to use this filename too. I suspect the same applies to other subsystem drivers as well. I'll look at them assuming this patch is well received. J. -- You have a tendency to feel you are superior to most computers. This .sig brought to you by the letter U and the number 25 Product of the Republic of HuggieTag - 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: [Bugme-new] [Bug 9405] New: iSCSI does not implement ordering guarantees required by e.g. journaling filesystems
James Bottomley wrote: On Tue, 2007-11-20 at 19:15 +0300, Vladislav Bolkhovitin wrote: James Bottomley wrote: I'm not sure your conclusions necessarily follow your data. What was the reason for the TASK ABORTED (I'd guess QErr settings, right)? It was my desire/curiosity during tests of SCST (http://scst.sf.net), when it working with several initiators with different transports over the same set of devices, each of them having with TAS bit in the control mode page set. According to SAM, in this case TASK ABORTED status can be returned at any time, similarly to QUEUE FULL, i.e. IMHO such command just should be retried. But QUEUE FULL status handled well, but TASK ABORTED leads to filesystem corruption. So this is with a soft target implementation ... so it could be an ordering issue inside the target that's causing the filesystem corruption on error. Target offers no ordering guarantees for SIMPLE commands and frankly says that to initiator via QUEUE ALGORITHM MODIFIER value 1 in the control mode page. As we know, initiator doesn't use ORDERED tags (and it really doesn't use them according to the logs), so if it's an ordering issue, it's at the initiator's side. if you specifically set TAS=1 you're giving up the right to know what caused the command termination. With insufficient information, it's really unsafe to simply retry, which is why the mid layer just returns TASK ABORTED as an error. If you set TAS=0 we'll get a check condition/unit attention explaining what happened (usually commands cleared by another initiator) and we'll explicitly do the right thing based on the sense data. But having TAS=1 is legal, right? So it should be handled well. If TAS=0, TASK ABORTED can't be returned, it would be illegal. So, TASK ABORTED status can only be returned with TAS=1. One of my test suites has an initiator which randomly spits errors. I've yet to see it cause an error that an ext3 journal can't recover from. So, if there's a genuine problem we need a nice test case to pass to the filesystem people. If you need a clear testcase (IMHO, in this case it isn't needed, because it's clear without it), I can prepare a patch for SCST to randomly return TASK ABORTED status. You can get the latest version of SCST and the target drivers using SVN: $ svn co https://scst.svn.sourceforge.net/svnroot/scst James - 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 - 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: [Bugme-new] [Bug 9405] New: iSCSI does not implement ordering guarantees required by e.g. journaling filesystems
On Tue, 2007-11-20 at 20:17 +0300, Vladislav Bolkhovitin wrote: James Bottomley wrote: On Tue, 2007-11-20 at 19:15 +0300, Vladislav Bolkhovitin wrote: James Bottomley wrote: I'm not sure your conclusions necessarily follow your data. What was the reason for the TASK ABORTED (I'd guess QErr settings, right)? It was my desire/curiosity during tests of SCST (http://scst.sf.net), when it working with several initiators with different transports over the same set of devices, each of them having with TAS bit in the control mode page set. According to SAM, in this case TASK ABORTED status can be returned at any time, similarly to QUEUE FULL, i.e. IMHO such command just should be retried. But QUEUE FULL status handled well, but TASK ABORTED leads to filesystem corruption. So this is with a soft target implementation ... so it could be an ordering issue inside the target that's causing the filesystem corruption on error. Target offers no ordering guarantees for SIMPLE commands and frankly says that to initiator via QUEUE ALGORITHM MODIFIER value 1 in the control mode page. As we know, initiator doesn't use ORDERED tags (and it really doesn't use them according to the logs), so if it's an ordering issue, it's at the initiator's side. if you specifically set TAS=1 you're giving up the right to know what caused the command termination. With insufficient information, it's really unsafe to simply retry, which is why the mid layer just returns TASK ABORTED as an error. If you set TAS=0 we'll get a check condition/unit attention explaining what happened (usually commands cleared by another initiator) and we'll explicitly do the right thing based on the sense data. But having TAS=1 is legal, right? So it should be handled well. If TAS=0, TASK ABORTED can't be returned, it would be illegal. So, TASK ABORTED status can only be returned with TAS=1. Driving with your handbrake on is legal too ... that doesn't mean you should do it ... and it certainly doesn't give you a legitimate complaint against the manufacturer of your car for excessive brake pad wear. We handle TASK ABORTED as well as we can (by failing it). For better handling set TAS=0 and we'll handle the individual cases according to the sense codes. One of my test suites has an initiator which randomly spits errors. I've yet to see it cause an error that an ext3 journal can't recover from. So, if there's a genuine problem we need a nice test case to pass to the filesystem people. If you need a clear testcase (IMHO, in this case it isn't needed, because it's clear without it), I can prepare a patch for SCST to randomly return TASK ABORTED status. You can get the latest version of SCST and the target drivers using SVN: $ svn co https://scst.svn.sourceforge.net/svnroot/scst There's no real need to bother with setting all this up ... a simple initiator modification randomly to return TASK ABORTED should suffice. James - 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: [Bugme-new] [Bug 9405] New: iSCSI does not implement ordering guarantees required by e.g. journaling filesystems
On Tue, Nov 20, 2007 at 08:45:12PM +0300, Vladislav Bolkhovitin wrote: James Bottomley wrote: We handle TASK ABORTED as well as we can (by failing it). For better handling set TAS=0 and we'll handle the individual cases according to the sense codes. So, should I consider your words as you think that it's perfectly fine to corrupt file system for devices with TAS=1? Absolutely legal devices, repeat. Hence, in your opinion, no further investigation should be done? I don't know how you manage to read his words this way. I understand him to mean that the SCSI subsystem is doing the best in can under the somewhat misconfigured circumstances, and the problem lies in the FS not handling errors correctly. -- Intel are signing my paycheques ... these opinions are still mine Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. - 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: [Bugme-new] [Bug 9405] New: iSCSI does not implement ordering guarantees required by e.g. journaling filesystems
On Tue, 2007-11-20 at 20:45 +0300, Vladislav Bolkhovitin wrote: James Bottomley wrote: I'm not sure your conclusions necessarily follow your data. What was the reason for the TASK ABORTED (I'd guess QErr settings, right)? It was my desire/curiosity during tests of SCST (http://scst.sf.net), when it working with several initiators with different transports over the same set of devices, each of them having with TAS bit in the control mode page set. According to SAM, in this case TASK ABORTED status can be returned at any time, similarly to QUEUE FULL, i.e. IMHO such command just should be retried. But QUEUE FULL status handled well, but TASK ABORTED leads to filesystem corruption. So this is with a soft target implementation ... so it could be an ordering issue inside the target that's causing the filesystem corruption on error. Target offers no ordering guarantees for SIMPLE commands and frankly says that to initiator via QUEUE ALGORITHM MODIFIER value 1 in the control mode page. As we know, initiator doesn't use ORDERED tags (and it really doesn't use them according to the logs), so if it's an ordering issue, it's at the initiator's side. if you specifically set TAS=1 you're giving up the right to know what caused the command termination. With insufficient information, it's really unsafe to simply retry, which is why the mid layer just returns TASK ABORTED as an error. If you set TAS=0 we'll get a check condition/unit attention explaining what happened (usually commands cleared by another initiator) and we'll explicitly do the right thing based on the sense data. But having TAS=1 is legal, right? So it should be handled well. If TAS=0, TASK ABORTED can't be returned, it would be illegal. So, TASK ABORTED status can only be returned with TAS=1. Driving with your handbrake on is legal too ... that doesn't mean you should do it ... and it certainly doesn't give you a legitimate complaint against the manufacturer of your car for excessive brake pad wear. We handle TASK ABORTED as well as we can (by failing it). For better handling set TAS=0 and we'll handle the individual cases according to the sense codes. So, should I consider your words as you think that it's perfectly fine to corrupt file system for devices with TAS=1? Absolutely legal devices, repeat. Hence, in your opinion, no further investigation should be done? Logic wouldn't support such a conclusion. You have intertwined two issues 1. How should the mid layer handle TASK ABORTED. I think we've reached the point where returning I/O error is the best we can do, but if TAS=0 we could have used the sense data to do better. 2. Should a request I/O error cause corruption in ext3 that can't be recovered by a journal replay. I think the answer here is no, so there needs to be an easily reproducible test case to pass to the filesystem people. James - 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: [Bugme-new] [Bug 9405] New: iSCSI does not implement ordering guarantees required by e.g. journaling filesystems
James Bottomley wrote: I'm not sure your conclusions necessarily follow your data. What was the reason for the TASK ABORTED (I'd guess QErr settings, right)? It was my desire/curiosity during tests of SCST (http://scst.sf.net), when it working with several initiators with different transports over the same set of devices, each of them having with TAS bit in the control mode page set. According to SAM, in this case TASK ABORTED status can be returned at any time, similarly to QUEUE FULL, i.e. IMHO such command just should be retried. But QUEUE FULL status handled well, but TASK ABORTED leads to filesystem corruption. So this is with a soft target implementation ... so it could be an ordering issue inside the target that's causing the filesystem corruption on error. Target offers no ordering guarantees for SIMPLE commands and frankly says that to initiator via QUEUE ALGORITHM MODIFIER value 1 in the control mode page. As we know, initiator doesn't use ORDERED tags (and it really doesn't use them according to the logs), so if it's an ordering issue, it's at the initiator's side. if you specifically set TAS=1 you're giving up the right to know what caused the command termination. With insufficient information, it's really unsafe to simply retry, which is why the mid layer just returns TASK ABORTED as an error. If you set TAS=0 we'll get a check condition/unit attention explaining what happened (usually commands cleared by another initiator) and we'll explicitly do the right thing based on the sense data. But having TAS=1 is legal, right? So it should be handled well. If TAS=0, TASK ABORTED can't be returned, it would be illegal. So, TASK ABORTED status can only be returned with TAS=1. Driving with your handbrake on is legal too ... that doesn't mean you should do it ... and it certainly doesn't give you a legitimate complaint against the manufacturer of your car for excessive brake pad wear. We handle TASK ABORTED as well as we can (by failing it). For better handling set TAS=0 and we'll handle the individual cases according to the sense codes. So, should I consider your words as you think that it's perfectly fine to corrupt file system for devices with TAS=1? Absolutely legal devices, repeat. Hence, in your opinion, no further investigation should be done? One of my test suites has an initiator which randomly spits errors. I've yet to see it cause an error that an ext3 journal can't recover from. So, if there's a genuine problem we need a nice test case to pass to the filesystem people. If you need a clear testcase (IMHO, in this case it isn't needed, because it's clear without it), I can prepare a patch for SCST to randomly return TASK ABORTED status. You can get the latest version of SCST and the target drivers using SVN: $ svn co https://scst.svn.sourceforge.net/svnroot/scst There's no real need to bother with setting all this up ... a simple initiator modification randomly to return TASK ABORTED should suffice. Yes, you're right. Then, I suppose, Mike Christie should be the best person to do it? Vlad - 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] Unify sysfs filenames for firmware version
Jonathan McDowell sez: On Tue, Nov 20, 2007 at 11:35:26AM -0500, James Smart wrote: The hearburn I have with these patches is that you are changing driver-specific attributes, not common ones as enforced/requested by a subsystem. As such, you are breaking a management interface for existing tools/scripts. Yes, that's true. Though at present we have the heartburn that anyone wanting to write a script to pull out firmware revisions has to know exactly where every driver stores this information. The aacraid cards, which uses hba_monitor_version, hba_kernel_version and hba_bios_version for each piece does not fit into the single 'firmware revision' common ideal and were noticeably missing from this patch set. Fortunately (?), Adaptec has not bought into using sysfs for their management applications to pull these pieces and continues to pick them up directly by issuing ioctl pass-through calls to the card's firmware, so we have some leeway to change them to mold to a developing standard. The fact that sysfs is a developing standard will confirm the management application folks reasoning for shying away from sysfs ;-/ Sincerely -- Mark Salyzyn - 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: [Bugme-new] [Bug 9405] New: iSCSI does not implement ordering guarantees required by e.g. journaling filesystems
James Bottomley wrote: I'm not sure your conclusions necessarily follow your data. What was the reason for the TASK ABORTED (I'd guess QErr settings, right)? It was my desire/curiosity during tests of SCST (http://scst.sf.net), when it working with several initiators with different transports over the same set of devices, each of them having with TAS bit in the control mode page set. According to SAM, in this case TASK ABORTED status can be returned at any time, similarly to QUEUE FULL, i.e. IMHO such command just should be retried. But QUEUE FULL status handled well, but TASK ABORTED leads to filesystem corruption. So this is with a soft target implementation ... so it could be an ordering issue inside the target that's causing the filesystem corruption on error. Target offers no ordering guarantees for SIMPLE commands and frankly says that to initiator via QUEUE ALGORITHM MODIFIER value 1 in the control mode page. As we know, initiator doesn't use ORDERED tags (and it really doesn't use them according to the logs), so if it's an ordering issue, it's at the initiator's side. if you specifically set TAS=1 you're giving up the right to know what caused the command termination. With insufficient information, it's really unsafe to simply retry, which is why the mid layer just returns TASK ABORTED as an error. If you set TAS=0 we'll get a check condition/unit attention explaining what happened (usually commands cleared by another initiator) and we'll explicitly do the right thing based on the sense data. But having TAS=1 is legal, right? So it should be handled well. If TAS=0, TASK ABORTED can't be returned, it would be illegal. So, TASK ABORTED status can only be returned with TAS=1. Driving with your handbrake on is legal too ... that doesn't mean you should do it ... and it certainly doesn't give you a legitimate complaint against the manufacturer of your car for excessive brake pad wear. We handle TASK ABORTED as well as we can (by failing it). For better handling set TAS=0 and we'll handle the individual cases according to the sense codes. So, should I consider your words as you think that it's perfectly fine to corrupt file system for devices with TAS=1? Absolutely legal devices, repeat. Hence, in your opinion, no further investigation should be done? Logic wouldn't support such a conclusion. Sorry, lately I've got too many I won't bother, this is your problem style answers You have intertwined two issues 1. How should the mid layer handle TASK ABORTED. I think we've reached the point where returning I/O error is the best we can do, but if TAS=0 we could have used the sense data to do better. 2. Should a request I/O error cause corruption in ext3 that can't be recovered by a journal replay. I think the answer here is no, so there needs to be an easily reproducible test case to pass to the filesystem people. OK, I see you point. As I already wrote, I can assist only in testing here. James - 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 - 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: SCSI dynamic power management
On Tue, 20 Nov 2007, James Bottomley wrote: The main point I'm aiming for is to have the midlayer to inform the LLD when all the devices on a particular bus are idle. This is the wrong assumption ... the mid layer would provide an API to inform the transport. Transport and host are separate things. an 8 port SAS card could suspend a single phy and device while still processing the others. So what it sounds like you need is a transport API saying a given device has been suspended or is requested to be resumed? What than means for the host would be transport class policy, I think. Okay. I know little about the intricacies of these newer, more exotic transports; I'm pretty firmly rooted in the old SPI technology. Anyway, yes, I want an API to inform the transport and/or host adapter driver that either a given device or all devices on a bus has been suspended or requests to be resumed. For an 8-port SAS card the driver might want to know about each individual device; for a plain old SPI card the driver would care only about the entire bus. A little ... I think your wake on command idea above is policy rather than actual implementation ... so it would probably have to be selectable (either error or wake). Yes. That is already part of the USB dynamic PM implementation, and I would copy it for the SCSI implementation. There is a sysfs file (/sys/devices/.../power/level) to which the user can write three possible values: on means the device is permanently at full power; auto means the device is subject to autosuspend after an idle-timeout (the timeout value is stored in a separate sysfs file) with autoresume at the next I/O request; suspend means the device is permanently suspended and I/O requests will fail immediately. My intention was to add a couple of method pointers to the SCSI host_template structure, one for suspend notifications and one for resume notifications. Do you think this is the right way to do it, or is something more complex called for? Alan Stern - 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: SCSI breakage on non-cache coherent architectures
On Tue, 2007-11-20 at 14:14 +1100, Benjamin Herrenschmidt wrote: FYI, Here's what I have for the SCSI change. I haven't updated drivers to care for the new return code though, help appreciated with that as I don't know much about these drivers. It looks to me like the return problem could be solved by passing in the buffer to be used for sense; that way we can allocate it in hostdata at init time for all the drivers and scsi_error can allocate and free a page using GFP_KERNEL. James - 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] Unify sysfs filenames for firmware version
On Tue, Nov 20, 2007 at 12:49:49PM -0500, Salyzyn, Mark wrote: Jonathan McDowell sez: On Tue, Nov 20, 2007 at 11:35:26AM -0500, James Smart wrote: The hearburn I have with these patches is that you are changing driver-specific attributes, not common ones as enforced/requested by a subsystem. As such, you are breaking a management interface for existing tools/scripts. Yes, that's true. Though at present we have the heartburn that anyone wanting to write a script to pull out firmware revisions has to know exactly where every driver stores this information. The aacraid cards, which uses hba_monitor_version, hba_kernel_version and hba_bios_version for each piece does not fit into the single 'firmware revision' common ideal and were noticeably missing from this patch set. I mainly looked for mentions of firmware to try and work out which drivers were exporting this information in a single file. While I've used the aacraid cards in the past I think I agree with you that no 1 of those 3 pieces of information represents the firmware. Perhaps it could export a triplet though? Fortunately (?), Adaptec has not bought into using sysfs for their management applications to pull these pieces and continues to pick them up directly by issuing ioctl pass-through calls to the card's firmware, so we have some leeway to change them to mold to a developing standard. The fact that sysfs is a developing standard will confirm the management application folks reasoning for shying away from sysfs ;-/ Management stuff always seems to be tied to a single card. It's one of the things that puts me off hardware RAID. It would really rock if we could get as much as possible exported in the same fashion across cards, rather than having to cope with each individually (though I accept that accessing all details/features will probably always require some custom card knowledge). Do the management folks actually have some ideas about what sort of interface they'd like in sysfs? J. -- If I save time, when do I get it back? - 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: SCSI breakage on non-cache coherent architectures
Actually, we already established on IRC that the lasi700 driver doesn't need this, principally because the parisc architecture doesn't do an invalidate for DMA_FROM_DEVICE but a flush and invalidate (architecturally, if you read our manuals, even pdc is entitled to write back dirty lines, so it's not clear there's actually an invalidate instruction we can use). This is also one possible temporary fix for the other architectures if we can't get a different method to work nicely. I think doing a writeback and invalidate is a very fragile way to deal with DMA into the middle of a data structure. It may work OK for now, but you have to make sure forever into the future that no codepath anywhere else ever touches the cacheline that you're DMAing into while the DMA is pending. It just leaves a hidden trap that is too easy to step on, because the architectures that get pretty much all testing all have cache-coherent DMA. Reviving my ancient __dma_buffer patch seems far preferable to me. - R. - 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 1/1] scsi: megaraid_sas - Fix random failure of DCDB cmds with sense info
Sense buffer ptr data type in the ioctl path is reverted back to u32 *
for x86 and x86_64 as in previous versions of driver. For IA64 it will
be unsigned long *. Compile time flag added for ia64 for this.
Signed-off-by: Bo Yang [EMAIL PROTECTED]
---
Documentation/scsi/ChangeLog.megaraid_sas | 15 +++
drivers/scsi/megaraid/megaraid_sas.c | 14 ++
drivers/scsi/megaraid/megaraid_sas.h |6 +++---
3 files changed, 28 insertions(+), 7 deletions(-)
diff -rupN linux-2.6.22_orig/Documentation/scsi/ChangeLog.megaraid_sas
linux-2.6.22_new/Documentation/scsi/ChangeLog.megaraid_sas
--- linux-2.6.22_orig/Documentation/scsi/ChangeLog.megaraid_sas 2007-11-20
17:50:13.0 -0500
+++ linux-2.6.22_new/Documentation/scsi/ChangeLog.megaraid_sas 2007-11-20
21:37:16.0 -0500
@@ -1,3 +1,18 @@
+1 Release Date: Thur. Nov. 19 16:30:43 PST 2007 -
+ (emaild-id:[EMAIL PROTECTED])
+ Sumant Patro
+ Bo Yang
+
+2 Current Version : 00.00.03.17-RC1
+3 Older Version : 00.00.03.16
+
+1. Fix random failure of DCDB cmds with sense info.
+
+Fix: sense buffer ptr data type in the ioctl path is reverted back
+ to u32 * for x86, x86_64 as in previous versions of driver.
+ For IA64 it will be unsigned long *. Compile time flag added
+ for ia64 for this.
+
1 Release Date: Thur. Nov. 07 16:30:43 PST 2007 -
(emaild-id:[EMAIL PROTECTED])
Sumant Patro
diff -rupN linux-2.6.22_orig/drivers/scsi/megaraid/megaraid_sas.c
linux-2.6.22_new/drivers/scsi/megaraid/megaraid_sas.c
--- linux-2.6.22_orig/drivers/scsi/megaraid/megaraid_sas.c 2007-11-20
17:50:13.0 -0500
+++ linux-2.6.22_new/drivers/scsi/megaraid/megaraid_sas.c 2007-11-20
17:50:13.0 -0500
@@ -10,7 +10,7 @@
*2 of the License, or (at your option) any later version.
*
* FILE: megaraid_sas.c
- * Version : v00.00.03.16-rc1
+ * Version : v00.00.03.17-rc1
*
* Authors:
* (email-id : [EMAIL PROTECTED])
@@ -3020,10 +3020,16 @@ megasas_mgmt_fw_ioctl(struct megasas_ins
* sense buffer address
*/
sense_buff = (unsigned long *) ((unsigned long)ioc-frame.raw +
- ioc-sense_off);
-
- if (copy_to_user((void __user *)(unsigned long)(*sense_buff),
+ ioc-sense_off);
+ sense_ptr = (u32 *) ((unsigned long)ioc-frame.raw +
+ ioc-sense_off);
+#if defined(__ia64__)
+ if (copy_to_user((void __user *)((unsigned long)(*sense_buff)),
+ sense, ioc-sense_len)) {
+#else
+ if (copy_to_user((void __user *)((unsigned long)(*sense_ptr)),
sense, ioc-sense_len)) {
+#endif
printk(KERN_ERR megasas: Failed to copy out to user
sense data\n);
error = -EFAULT;
diff -rupN linux-2.6.22_orig/drivers/scsi/megaraid/megaraid_sas.h
linux-2.6.22_new/drivers/scsi/megaraid/megaraid_sas.h
--- linux-2.6.22_orig/drivers/scsi/megaraid/megaraid_sas.h 2007-11-20
17:50:13.0 -0500
+++ linux-2.6.22_new/drivers/scsi/megaraid/megaraid_sas.h 2007-11-20
17:50:13.0 -0500
@@ -18,9 +18,9 @@
/*
* MegaRAID SAS Driver meta data
*/
-#define MEGASAS_VERSION00.00.03.16-rc1
-#define MEGASAS_RELDATENov. 07, 2007
-#define MEGASAS_EXT_VERSIONThu. Nov. 07 10:09:32 PDT 2007
+#define MEGASAS_VERSION00.00.03.17-rc1
+#define MEGASAS_RELDATENov. 19, 2007
+#define MEGASAS_EXT_VERSIONMon. Nov. 19 10:09:32 PDT 2007
/*
* Device IDs
-
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 1/1] scsi: megaraid_sas - Fix random failure of DCDB cmds with sense info
On Wed, Nov 21, 2007 at 08:40:56AM +, bo yang wrote:
Sense buffer ptr data type in the ioctl path is reverted back to u32 *
for x86 and x86_64 as in previous versions of driver. For IA64 it will
be unsigned long *. Compile time flag added for ia64 for this.
This changelog tells us what you're doing, but not why you're doing it.
Why is it that ia64 is different from x86 and x86_64? What should other
architectures be doing? This patch really doesn't make any sense to me at
all; it should be doing the exact same thing on all three architectures.
Signed-off-by: Bo Yang [EMAIL PROTECTED]
---
Documentation/scsi/ChangeLog.megaraid_sas | 15 +++
drivers/scsi/megaraid/megaraid_sas.c | 14 ++
drivers/scsi/megaraid/megaraid_sas.h |6 +++---
3 files changed, 28 insertions(+), 7 deletions(-)
diff -rupN linux-2.6.22_orig/Documentation/scsi/ChangeLog.megaraid_sas
linux-2.6.22_new/Documentation/scsi/ChangeLog.megaraid_sas
--- linux-2.6.22_orig/Documentation/scsi/ChangeLog.megaraid_sas
2007-11-20 17:50:13.0 -0500
+++ linux-2.6.22_new/Documentation/scsi/ChangeLog.megaraid_sas
2007-11-20 21:37:16.0 -0500
@@ -1,3 +1,18 @@
+1 Release Date: Thur. Nov. 19 16:30:43 PST 2007 -
+ (emaild-id:[EMAIL PROTECTED])
+ Sumant Patro
+ Bo Yang
+
+2 Current Version : 00.00.03.17-RC1
+3 Older Version : 00.00.03.16
+
+1. Fix random failure of DCDB cmds with sense info.
+
+Fix: sense buffer ptr data type in the ioctl path is reverted back
+ to u32 * for x86, x86_64 as in previous versions of driver.
+ For IA64 it will be unsigned long *. Compile time flag added
+ for ia64 for this.
+
1 Release Date: Thur. Nov. 07 16:30:43 PST 2007 -
(emaild-id:[EMAIL PROTECTED])
Sumant Patro
diff -rupN linux-2.6.22_orig/drivers/scsi/megaraid/megaraid_sas.c
linux-2.6.22_new/drivers/scsi/megaraid/megaraid_sas.c
--- linux-2.6.22_orig/drivers/scsi/megaraid/megaraid_sas.c2007-11-20
17:50:13.0 -0500
+++ linux-2.6.22_new/drivers/scsi/megaraid/megaraid_sas.c 2007-11-20
17:50:13.0 -0500
@@ -10,7 +10,7 @@
* 2 of the License, or (at your option) any later version.
*
* FILE : megaraid_sas.c
- * Version : v00.00.03.16-rc1
+ * Version : v00.00.03.17-rc1
*
* Authors:
* (email-id : [EMAIL PROTECTED])
@@ -3020,10 +3020,16 @@ megasas_mgmt_fw_ioctl(struct megasas_ins
* sense buffer address
*/
sense_buff = (unsigned long *) ((unsigned long)ioc-frame.raw +
- ioc-sense_off);
-
- if (copy_to_user((void __user *)(unsigned long)(*sense_buff),
+ ioc-sense_off);
+ sense_ptr = (u32 *) ((unsigned long)ioc-frame.raw +
+ ioc-sense_off);
+#if defined(__ia64__)
+ if (copy_to_user((void __user *)((unsigned long)(*sense_buff)),
+ sense, ioc-sense_len)) {
+#else
+ if (copy_to_user((void __user *)((unsigned long)(*sense_ptr)),
sense, ioc-sense_len)) {
+#endif
printk(KERN_ERR megasas: Failed to copy out to user
sense data\n);
error = -EFAULT;
diff -rupN linux-2.6.22_orig/drivers/scsi/megaraid/megaraid_sas.h
linux-2.6.22_new/drivers/scsi/megaraid/megaraid_sas.h
--- linux-2.6.22_orig/drivers/scsi/megaraid/megaraid_sas.h2007-11-20
17:50:13.0 -0500
+++ linux-2.6.22_new/drivers/scsi/megaraid/megaraid_sas.h 2007-11-20
17:50:13.0 -0500
@@ -18,9 +18,9 @@
/*
* MegaRAID SAS Driver meta data
*/
-#define MEGASAS_VERSION 00.00.03.16-rc1
-#define MEGASAS_RELDATE Nov. 07, 2007
-#define MEGASAS_EXT_VERSION Thu. Nov. 07 10:09:32 PDT 2007
+#define MEGASAS_VERSION 00.00.03.17-rc1
+#define MEGASAS_RELDATE Nov. 19, 2007
+#define MEGASAS_EXT_VERSION Mon. Nov. 19 10:09:32 PDT 2007
/*
* Device IDs
-
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
--
Intel are signing my paycheques ... these opinions are still mine
Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step.
-
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] Unify sysfs filenames for firmware version
Jonathan McDowell [mailto:[EMAIL PROTECTED] sez: On Tue, Nov 20, 2007 at 12:49:49PM -0500, Salyzyn, Mark wrote: The aacraid cards, which uses hba_monitor_version, hba_kernel_version and hba_bios_version for each piece does not fit into the single 'firmware revision' common ideal While I've used the aacraid cards in the past I think I agree with you that no 1 of those 3 pieces of information represents the firmware. Perhaps it could export a triplet though? A single can be used in 99% of all cases, OEM or users can muck it up. I would 'vote' for hba_kernel_version == fw_version. Maybe add a companion standard for hba_bios_version == bios_version and hba_monitor_version == exec_version (executive_version) if other cards can supply such info ... Management stuff always seems to be tied to a single card. It's one of the things that puts me off hardware RAID. There are 113 cards this driver works for in concert. Maybe my tail feathers are showing ;- Do the management folks actually have some ideas about what sort of interface they'd like in sysfs? Simple answer: No Detailed answer (I digress): They love ioctls as a commonality across all operating systems and a pass-through to proprietary firmware portals: binary, bidirectional, atomic and freely formatted migrating structures that do not herd the cats into just one specification. These are all eventually presented as documented stable objects exported by a sizeable C++ StorLib(tm) library that provides the consistent interface that the OEMs and Adaptec use to the higher level install, event, GUI and CLI applications. Driver is only involved as a transport. Sincerely -- Mark Salyzyn - 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: SCSI breakage on non-cache coherent architectures
On Tue, 2007-11-20 at 12:05 -0800, Roland Dreier wrote: Actually, we already established on IRC that the lasi700 driver doesn't need this, principally because the parisc architecture doesn't do an invalidate for DMA_FROM_DEVICE but a flush and invalidate (architecturally, if you read our manuals, even pdc is entitled to write back dirty lines, so it's not clear there's actually an invalidate instruction we can use). This is also one possible temporary fix for the other architectures if we can't get a different method to work nicely. I think doing a writeback and invalidate is a very fragile way to deal with DMA into the middle of a data structure. It may work OK for now, but you have to make sure forever into the future that no codepath anywhere else ever touches the cacheline that you're DMAing into while the DMA is pending. It just leaves a hidden trap that is too easy to step on, because the architectures that get pretty much all testing all have cache-coherent DMA. Reviving my ancient __dma_buffer patch seems far preferable to me. We're talking about trying to fix this for 2.4; which is already at -rc3 ... Is an entire arch change for dma alignment really a merge candidate at this stage? James - 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: SCSI breakage on non-cache coherent architectures
On Tue, 2007-11-20 at 15:10 -0600, James Bottomley wrote: We're talking about trying to fix this for 2.4; which is already at -rc3 ... Is an entire arch change for dma alignment really a merge candidate at this stage? Well, as I said before... it's a matter of what seems to be the less likely to break something right ? On one side, I'm doing surgery on code I barely know, the scsi error handling, and now it seems I also have to fixup a handful of drivers that aren't the most obvious pieces of code around. On the other side, Roland proposal is basically just adding a macro that can be empty for everybody but a handful of archs, and stick it onto one field in one structure... The later has about 0 chances to actually break something or cause a regression. I wouldn't say that about the former. Now, I will see if I manage to fixup the NCR drivers to pass a pre-allocated buffer (USB storage I think can pass NULL as it's not calling prep in atomic context). But then, it complicates the matter because that means restore will have to know whether prep allocated the buffer or not, thus more fields to add to the save struct, it's getting messy, unless we decide -all- callers are responsible for the buffer allocation (hrm... maybe the best approach). Ben. - 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] Unify sysfs filenames for firmware version
Management stuff always seems to be tied to a single card. It's one of the things that puts me off hardware RAID. There are 113 cards this driver works for in concert. Maybe my tail feathers are showing ;- You might want to mention the card firmware in question run on 3 or 4 entirely different processors too Do the management folks actually have some ideas about what sort of interface they'd like in sysfs? Simple answer: No Detailed answer (I digress): Linuxy answer: Something like netlink Alan - 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: SCSI breakage on non-cache coherent architectures
On Wed, 2007-11-21 at 09:39 +1100, Benjamin Herrenschmidt wrote: On Tue, 2007-11-20 at 15:10 -0600, James Bottomley wrote: We're talking about trying to fix this for 2.4; which is already at -rc3 ... Is an entire arch change for dma alignment really a merge candidate at this stage? Well, as I said before... it's a matter of what seems to be the less likely to break something right ? On one side, I'm doing surgery on code I barely know, the scsi error handling, and now it seems I also have to fixup a handful of drivers that aren't the most obvious pieces of code around. On the other side, Roland proposal is basically just adding a macro that can be empty for everybody but a handful of archs, and stick it onto one field in one structure... Yes ... it's the getting arch owner agreement to send the patch that slightly worries me. The later has about 0 chances to actually break something or cause a regression. I wouldn't say that about the former. Now, I will see if I manage to fixup the NCR drivers to pass a pre-allocated buffer (USB storage I think can pass NULL as it's not calling prep in atomic context). But then, it complicates the matter because that means restore will have to know whether prep allocated the buffer or not, thus more fields to add to the save struct, it's getting messy, unless we decide -all- callers are responsible for the buffer allocation (hrm... maybe the best approach). Sorry, yes, that's what I was thinking ... identically to the way the struct scsi_eh_save is handled ... or indeed as an extra pointer field inside scsi_eh_save. James - 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
Linux-iSCSI.org JeOS i386 Packages Online!
Greetings all, After the release of JeOS yesterday, which is the Ubuntu based VM that is intended to be used a virtual appliance, I have gone ahead and generated the kernel and userspace builds for the Linux-iSCSI.org Target stack. The .debs are currently available from the iSCSI build cluster: http://linux-iscsi.org/builds/jeos/i386/ I will be adding a jeos/ubuntu repository shortly, and the actual downloadable demo LIO VM (which will be around 200 MB compressed) is planned to be released in the upcoming weeks. The current release is intended for developers of JeOS. Please stay tuned to http://Linux-iSCSI.org for more information. Enjoy! --nab - 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
