Re: [AIC7xxx] tree things to report
Emmanuel Fusté wrote: Hello, What you should do here is: - hook up a serial cable and re-route console messages to that - Switch off syslog (as this might block if the SCSI bus frozen) - Enable scsi debugging (Error, Timeout, Scan, and Midlayer is sufficient) and start cdrwtools. - Send me the log from the serial console. Ok, I've got logs with netconsole after swapping my Ethernet card with another one. Grand. Well done, son. The logs have been very instructive. Again we're hitting this 'two commands per lun' problem. For historic reasons the aic7xxx and aic79xx driver accepted two commands per luns, as they implemented their internal queueing and could hold the second command on the queue. With later versions I've removed this internal queueing and relied on the block-layer for this. But this also means we can only accept one command per lun. Please try the attached patch and see if it helps. James, I know that the aic7xxx has some 'next_queued_hscb' pointer which might be utilized for this sort of thing. But I didn't really figure out how this thing is supposed to work nor how we could utilize it. So I figured that the added complexity is not really worth it. Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage [EMAIL PROTECTED] +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) Allow only a single command per lun for aic7xxx With the conversion to use transport classes we also removed the internal queueing from the driver. Hence the existing hack of accepting two commands per lun and just holding this other one internally is no longer valid. Signed-off-by: Hannes Reinecke [EMAIL PROTECTED] diff --git a/drivers/scsi/aic7xxx/aic79xx_osm.c b/drivers/scsi/aic7xxx/aic79xx_osm.c index 6054881..df8a3b2 100644 --- a/drivers/scsi/aic7xxx/aic79xx_osm.c +++ b/drivers/scsi/aic7xxx/aic79xx_osm.c @@ -775,7 +775,7 @@ struct scsi_host_template aic79xx_driver .can_queue = AHD_MAX_QUEUE, .this_id= -1, .max_sectors= 8192, - .cmd_per_lun= 2, + .cmd_per_lun= 1, .use_clustering = ENABLE_CLUSTERING, .slave_alloc= ahd_linux_slave_alloc, .slave_configure= ahd_linux_slave_configure, diff --git a/drivers/scsi/aic7xxx/aic7xxx_osm.c b/drivers/scsi/aic7xxx/aic7xxx_osm.c index 660f26e..e6b87b9 100644 --- a/drivers/scsi/aic7xxx/aic7xxx_osm.c +++ b/drivers/scsi/aic7xxx/aic7xxx_osm.c @@ -755,7 +755,7 @@ struct scsi_host_template aic7xxx_driver .can_queue = AHC_MAX_QUEUE, .this_id= -1, .max_sectors= 8192, - .cmd_per_lun= 2, + .cmd_per_lun= 1, .use_clustering = ENABLE_CLUSTERING, .slave_alloc= ahc_linux_slave_alloc, .slave_configure= ahc_linux_slave_configure,
Re: [patch 6/7] ps3: ROM Storage Driver
[Note that all scsi lldds should go to linux-scsi]
+config PS3_ROM
+ tristate PS3 ROM Storage Driver
+ depends on PPC_PS3 BLK_DEV_SR
+ select PS3_STORAGE
+ default y
please don't put any default y statements in.
+#define DEVICE_NAME ps3rom
+
+#define BOUNCE_SIZE (64*1024)
+
+#define PS3ROM_MAX_SECTORS (BOUNCE_SIZE / CD_FRAMESIZE)
+
+#define LV1_STORAGE_SEND_ATAPI_COMMAND (1)
+
+
+struct ps3rom_private {
+ spinlock_t lock;
+ struct task_struct *thread;
+ struct Scsi_Host *host;
+ struct scsi_cmnd *cmd;
+ void (*scsi_done)(struct scsi_cmnd *);
+};
+#define ps3rom_priv(dev) ((dev)-sbd.core.driver_data)
+/*
+ * to position parameter
+ */
+enum {
+ NOT_AVAIL = -1,
+ USE_SRB_10 = -2,
+ USE_SRB_6 = -3,
+ USE_CDDA_FRAME_RAW = -4
+};
none of these seem to be used at all in the driver.
+
+#ifdef DEBUG
+static const char *scsi_command(unsigned char cmd)
+{
+ switch (cmd) {
+ case TEST_UNIT_READY: return
TEST_UNIT_READY/GPCMD_TEST_UNIT_READY;
+ case REZERO_UNIT: return REZERO_UNIT;
+ case REQUEST_SENSE: return
REQUEST_SENSE/GPCMD_REQUEST_SENSE;
...
this kind of things shouldn't be in a low level driver. Either keep it
in your out of tree debug patches or if you feel adventurous send a
patch to linux-scsi that implements it in drivers/scsi/constant.c which
has debug code for other protocol-level scsi constants.
+static int ps3rom_slave_alloc(struct scsi_device *scsi_dev)
+{
+ struct ps3_storage_device *dev;
+
+ dev = (struct ps3_storage_device *)scsi_dev-host-hostdata[0];
+
+ dev_dbg(dev-sbd.core, %s:%u: id %u, lun %u, channel %u\n, __func__,
+ __LINE__, scsi_dev-id, scsi_dev-lun, scsi_dev-channel);
+
+ scsi_dev-hostdata = dev;
This seems rather pointless. The scsi_device has a pointer to the
host, so every access to scsi_dev-hostdata can simply be replaced
by an access through the host.
+static int ps3rom_slave_configure(struct scsi_device *scsi_dev)
+{
+ struct ps3_storage_device *dev = scsi_dev-hostdata;
+
+ dev_dbg(dev-sbd.core, %s:%u: id %u, lun %u, channel %u\n, __func__,
+ __LINE__, scsi_dev-id, scsi_dev-lun, scsi_dev-channel);
+
+ /*
+ * ATAPI SFF8020 devices use MODE_SENSE_10,
+ * so we can prohibit MODE_SENSE_6
+ */
+ scsi_dev-use_10_for_ms = 1;
+
+ return 0;
+}
+
+static void ps3rom_slave_destroy(struct scsi_device *scsi_dev)
+{
+}
No need to implement an empty method here.
+static int ps3rom_queuecommand(struct scsi_cmnd *cmd,
+void (*done)(struct scsi_cmnd *))
+{
+ struct ps3_storage_device *dev = cmd-device-hostdata;
+ struct ps3rom_private *priv = ps3rom_priv(dev);
+
+ dev_dbg(dev-sbd.core, %s:%u: command 0x%02x (%s)\n, __func__,
+ __LINE__, cmd-cmnd[0], scsi_command(cmd-cmnd[0]));
+
+ spin_lock_irq(priv-lock);
+ if (priv-cmd) {
+ /* no more than one can be processed */
+ dev_err(dev-sbd.core, %s:%u: more than 1 command queued\n,
+ __func__, __LINE__);
+ spin_unlock_irq(priv-lock);
+ return SCSI_MLQUEUE_HOST_BUSY;
+ }
Just set can_queue to 1 in the host template and the midlayer will take
care of this.
+
+ // FIXME Prevalidate commands?
+ priv-cmd = cmd;
+ priv-scsi_done = done;
No need to keep your own scsi_done pointer. What you should do instead
in queuecommand is to set the scsi_done pointer in the scsi_cmnd here
and just use it later.
+ spin_unlock_irq(priv-lock);
+ wake_up_process(priv-thread);
Offloading every I/O to a thread is very bad for I/O performance.
Why do you need this?
+ return 0;
+}
+
+/*
+ * copy data from device into scatter/gather buffer
+ */
+static int fill_from_dev_buffer(struct scsi_cmnd *cmd, const void *buf,
+ int buflen)
+{
+ int k, req_len, act_len, len, active;
+ void *kaddr;
+ struct scatterlist *sgpnt;
+
+ if (!cmd-request_bufflen)
+ return 0;
+
+ if (!cmd-request_buffer)
+ return DID_ERROR 16;
+
+ if (cmd-sc_data_direction != DMA_BIDIRECTIONAL
+ cmd-sc_data_direction != DMA_FROM_DEVICE)
+ return DID_ERROR 16;
+
+ if (!cmd-use_sg) {
+ req_len = cmd-request_bufflen;
+ act_len = min(req_len, buflen);
+ memcpy(cmd-request_buffer, buf, act_len);
+ cmd-resid = req_len - act_len;
+ return 0;
+ }
This is never true anymore.
+
+ sgpnt = cmd-request_buffer;
+ active = 1;
+ for (k = 0, req_len = 0, act_len = 0; k cmd-use_sg; ++k, ++sgpnt) {
+ if (active) {
+ kaddr = kmap_atomic(sgpnt-page, KM_USER0);
+
Re: [patch 6/7] ps3: ROM Storage Driver
On Tue, 29 May 2007, Christoph Hellwig wrote:
[Note that all scsi lldds should go to linux-scsi]
I'll Cc linux-scsi next time.
+ sgpnt = cmd-request_buffer;
+ active = 1;
+ for (k = 0, req_len = 0, act_len = 0; k cmd-use_sg; ++k, ++sgpnt) {
+ if (active) {
+ kaddr = kmap_atomic(sgpnt-page, KM_USER0);
+ if (!kaddr)
+ return DID_ERROR 16;
+ len = sgpnt-length;
+ if ((req_len + len) buflen) {
+ active = 0;
+ len = buflen - req_len;
+ }
+ memcpy(kaddr + sgpnt-offset, buf + req_len, len);
+ kunmap_atomic(kaddr, KM_USER0);
+ act_len += len;
+ }
+ req_len += sgpnt-length;
+ }
+ cmd-resid = req_len - act_len;
This looks very inefficient. Just set sg_tablesize of your driver
to 1 to avoid getting mutiple segments.
The disadvantage of setting sg_tablesize = 1 is that the driver will get small
requests (PAGE_SIZE) most of the time, which is very bad for performance.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- Sony Network and Software Technology Center Europe (NSCE)
[EMAIL PROTECTED] --- The Corporate Village, Da Vincilaan 7-D1
Voice +32-2-7008453 Fax +32-2-7008622 B-1935 Zaventem, Belgium
-
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 6/7] ps3: ROM Storage Driver
On Tue, 2007-05-29 at 13:11 +0200, Geert Uytterhoeven wrote: This looks very inefficient. Just set sg_tablesize of your driver to 1 to avoid getting mutiple segments. The disadvantage of setting sg_tablesize = 1 is that the driver will get small requests (PAGE_SIZE) most of the time, which is very bad for performance. And the joke is that not only the HW can do scatter gather but you also have an iommu ... 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
cciss broken with 2.6.22-rc2
Hi Mike, with the latest git snapshot the cciss driver hangs during initialisation. Enabling debug output I get: cciss0: 0x3230 at PCI :06:00.0 IRQ 4338 using DAC Sending cff - down to controller cciss: FIFO Empty read cciss: Read cff0 back from board Sending cff - down to controller cciss: FIFO Empty read cciss: Read cff2 back from board LUN Data -- Sending cff - down to controller cciss: FIFO Empty read cciss: Read cff0 back from board blocks= 286677120 block_size= 512 Sending cff - down to controller cciss: FIFO Empty read cciss: Read cff2 back from board heads=255, sectors=32, cylinders=35132 Sending 5103000 - down to controller and then the machine hangs. I'll try to investigate, but as I'm no expert in cciss my results might be limited. Looks like one of your recent fixes broke it; 2.6.21 worked fine. Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage [EMAIL PROTECTED] +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) - 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/3] zfcp: IO stall after path checker changes
From: Michael Loehr [EMAIL PROTECTED] Devices corresponding to a deleted unit are never freed. This has the effect that slave_destroy is never called and zfcp 'thinks' that this unit is still registered. This patch changes the zfcp behaviour the way that the rport and sdev are not deleted anymore. The host is set to block on 'offline'. Host online is only removing the blocked status and everything works as expected again. Signed-off-by: Michael Loehr [EMAIL PROTECTED] Signed-off-by: Swen Schillig [EMAIL PROTECTED] --- drivers/s390/scsi/zfcp_aux.c |1 + drivers/s390/scsi/zfcp_ccw.c |5 + drivers/s390/scsi/zfcp_scsi.c |3 +++ 3 files changed, 5 insertions(+), 4 deletions(-) Index: linux_jb_patched/drivers/s390/scsi/zfcp_aux.c === --- linux_jb_patched.orig/drivers/s390/scsi/zfcp_aux.c +++ linux_jb_patched/drivers/s390/scsi/zfcp_aux.c @@ -1127,6 +1127,7 @@ zfcp_adapter_dequeue(struct zfcp_adapter int retval = 0; unsigned long flags; + zfcp_adapter_scsi_unregister(adapter); device_unregister(adapter-generic_services); zfcp_sysfs_adapter_remove_files(adapter-ccw_device-dev); dev_set_drvdata(adapter-ccw_device-dev, NULL); Index: linux_jb_patched/drivers/s390/scsi/zfcp_ccw.c === --- linux_jb_patched.orig/drivers/s390/scsi/zfcp_ccw.c +++ linux_jb_patched/drivers/s390/scsi/zfcp_ccw.c @@ -189,9 +189,7 @@ zfcp_ccw_set_online(struct ccw_device *c * @ccw_device: pointer to belonging ccw device * * This function gets called by the common i/o layer and sets an adapter - * into state offline. Setting an fcp device offline means that it will be - * unregistered from the SCSI stack and that the adapter will be shut down - * asynchronously. + * into state offline. */ static int zfcp_ccw_set_offline(struct ccw_device *ccw_device) @@ -202,7 +200,6 @@ zfcp_ccw_set_offline(struct ccw_device * adapter = dev_get_drvdata(ccw_device-dev); zfcp_erp_adapter_shutdown(adapter, 0); zfcp_erp_wait(adapter); - zfcp_adapter_scsi_unregister(adapter); zfcp_erp_thread_kill(adapter); zfcp_adapter_debug_unregister(adapter); up(zfcp_data.config_sema); Index: linux_jb_patched/drivers/s390/scsi/zfcp_scsi.c === --- linux_jb_patched.orig/drivers/s390/scsi/zfcp_scsi.c +++ linux_jb_patched/drivers/s390/scsi/zfcp_scsi.c @@ -569,6 +569,9 @@ zfcp_adapter_scsi_register(struct zfcp_a int retval = 0; static unsigned int unique_id = 0; + if (adapter-scsi_host) + goto out; + /* register adapter as SCSI host with mid layer of SCSI stack */ adapter-scsi_host = scsi_host_alloc(zfcp_data.scsi_host_template, sizeof (struct zfcp_adapter *)); - 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 2/3] zfcp: clear adapter status flags during adapter shutdown
From: Volker Sameske [EMAIL PROTECTED]
zfcp: clear adapter status flags during adapter shutdown
In some cases we did not reset some adapter status flags properly.
This patch clears these flags during FCP adapter shutdown.
Signed-off-by: Volker Sameske [EMAIL PROTECTED]
Signed-off-by: Swen Schillig [EMAIL PROTECTED]
---
drivers/s390/scsi/zfcp_erp.c |7 +++
1 file changed, 7 insertions(+)
Index: linux_jb_patched/drivers/s390/scsi/zfcp_erp.c
===
--- linux_jb_patched.orig/drivers/s390/scsi/zfcp_erp.c
+++ linux_jb_patched/drivers/s390/scsi/zfcp_erp.c
@@ -1986,6 +1986,10 @@ zfcp_erp_adapter_strategy_generic(struct
failed_openfcp:
zfcp_close_fsf(erp_action-adapter);
failed_qdio:
+ atomic_clear_mask(ZFCP_STATUS_ADAPTER_XCONFIG_OK |
+ ZFCP_STATUS_ADAPTER_LINK_UNPLUGGED |
+ ZFCP_STATUS_ADAPTER_XPORT_OK,
+ erp_action-adapter-status);
out:
return retval;
}
@@ -2167,6 +2171,9 @@ zfcp_erp_adapter_strategy_open_fsf_xconf
sleep *= 2;
}
+ atomic_clear_mask(ZFCP_STATUS_ADAPTER_HOST_CON_INIT,
+ adapter-status);
+
if (!atomic_test_mask(ZFCP_STATUS_ADAPTER_XCONFIG_OK,
adapter-status)) {
ZFCP_LOG_INFO(error: exchange of configuration data for
-
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 3/3] zfcp: Don't report device as LUN 0 to SCSI stack
From: Christof Schmitt [EMAIL PROTECTED]
zfcp reported units to the SCSI stack starting
with number 0. LUN 0 reported to the SCSI stack is usually
not the FCP LUN 0. When scanning for devices,
the SCSI stack tried to issue a REPORT LUN command to LUN 0.
The current design for zfcp does not want the SCSI stack to scan
for devices, since they are configured explicitly via sysfs.
This patch changes the numbering to always start with LUN 1 and therefore
prevent the SCSI stack sending REPORT LUN command.
Signed-off-by: Christof Schmitt [EMAIL PROTECTED]
Signed-off-by: Swen Schillig [EMAIL PROTECTED]
---
drivers/s390/scsi/zfcp_aux.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: linux_jb_patched/drivers/s390/scsi/zfcp_aux.c
===
--- linux_jb_patched.orig/drivers/s390/scsi/zfcp_aux.c
+++ linux_jb_patched/drivers/s390/scsi/zfcp_aux.c
@@ -864,7 +864,8 @@ zfcp_unit_enqueue(struct zfcp_port *port
zfcp_unit_get(unit);
- scsi_lun = 0;
+ /* Don't report LUN 0 to prevent the REPORT LUNS command from SCSI. */
+ scsi_lun = 1;
found = 0;
write_lock_irq(zfcp_data.config_lock);
list_for_each_entry(tmp_unit, port-unit_list_head, list) {
-
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/3] zfcp: IO stall after path checker changes
James I just saw that I posted this patch on 9th already, but todays git pull from your tree didn't show the inclusion of this one (and another patch posted the same day). Event though it's reported in your summary from the 26 ! If I'm to quick then I'm sorry for sending it twice, if there's any other reason for this patch to not be included please let me know. Thanks Swen On Tuesday 29 May 2007 15:29, Swen Schillig wrote: From: Michael Loehr [EMAIL PROTECTED] Devices corresponding to a deleted unit are never freed. This has the effect that slave_destroy is never called and zfcp 'thinks' that this unit is still registered. This patch changes the zfcp behaviour the way that the rport and sdev are not deleted anymore. The host is set to block on 'offline'. Host online is only removing the blocked status and everything works as expected again. Signed-off-by: Michael Loehr [EMAIL PROTECTED] Signed-off-by: Swen Schillig [EMAIL PROTECTED] --- drivers/s390/scsi/zfcp_aux.c |1 + drivers/s390/scsi/zfcp_ccw.c |5 + drivers/s390/scsi/zfcp_scsi.c |3 +++ 3 files changed, 5 insertions(+), 4 deletions(-) Index: linux_jb_patched/drivers/s390/scsi/zfcp_aux.c === --- linux_jb_patched.orig/drivers/s390/scsi/zfcp_aux.c +++ linux_jb_patched/drivers/s390/scsi/zfcp_aux.c @@ -1127,6 +1127,7 @@ zfcp_adapter_dequeue(struct zfcp_adapter int retval = 0; unsigned long flags; + zfcp_adapter_scsi_unregister(adapter); device_unregister(adapter-generic_services); zfcp_sysfs_adapter_remove_files(adapter-ccw_device-dev); dev_set_drvdata(adapter-ccw_device-dev, NULL); Index: linux_jb_patched/drivers/s390/scsi/zfcp_ccw.c === --- linux_jb_patched.orig/drivers/s390/scsi/zfcp_ccw.c +++ linux_jb_patched/drivers/s390/scsi/zfcp_ccw.c @@ -189,9 +189,7 @@ zfcp_ccw_set_online(struct ccw_device *c * @ccw_device: pointer to belonging ccw device * * This function gets called by the common i/o layer and sets an adapter - * into state offline. Setting an fcp device offline means that it will be - * unregistered from the SCSI stack and that the adapter will be shut down - * asynchronously. + * into state offline. */ static int zfcp_ccw_set_offline(struct ccw_device *ccw_device) @@ -202,7 +200,6 @@ zfcp_ccw_set_offline(struct ccw_device * adapter = dev_get_drvdata(ccw_device-dev); zfcp_erp_adapter_shutdown(adapter, 0); zfcp_erp_wait(adapter); - zfcp_adapter_scsi_unregister(adapter); zfcp_erp_thread_kill(adapter); zfcp_adapter_debug_unregister(adapter); up(zfcp_data.config_sema); Index: linux_jb_patched/drivers/s390/scsi/zfcp_scsi.c === --- linux_jb_patched.orig/drivers/s390/scsi/zfcp_scsi.c +++ linux_jb_patched/drivers/s390/scsi/zfcp_scsi.c @@ -569,6 +569,9 @@ zfcp_adapter_scsi_register(struct zfcp_a int retval = 0; static unsigned int unique_id = 0; + if (adapter-scsi_host) + goto out; + /* register adapter as SCSI host with mid layer of SCSI stack */ adapter-scsi_host = scsi_host_alloc(zfcp_data.scsi_host_template, sizeof (struct zfcp_adapter *)); - 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: cciss broken with 2.6.22-rc2
-Original Message-
From: Hannes Reinecke [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 29, 2007 7:01 AM
To: Miller, Mike (OS Dev); SCSI Mailing List
Subject: cciss broken with 2.6.22-rc2
Hi Mike,
with the latest git snapshot the cciss driver hangs during
initialisation. Enabling debug output I get:
cciss0: 0x3230 at PCI :06:00.0 IRQ 4338 using DAC
Sending cff - down to controller
cciss: FIFO Empty read
cciss: Read cff0 back from board
Sending cff - down to controller
cciss: FIFO Empty read
cciss: Read cff2 back from board
LUN Data
--
Sending cff - down to controller
cciss: FIFO Empty read
cciss: Read cff0 back from board
blocks= 286677120 block_size= 512
Sending cff - down to controller
cciss: FIFO Empty read
cciss: Read cff2 back from board
heads=255, sectors=32, cylinders=35132
Sending 5103000 - down to controller
and then the machine hangs.
I'll try to investigate, but as I'm no expert in cciss my
results might be limited.
Looks like one of your recent fixes broke it; 2.6.21 worked fine.
Hannes,
Actually, it was someone else who broke the driver by making changes in msi.c.
This patch fixes the hang:
From: Mike Miller (OS Dev) [EMAIL PROTECTED] writes:
Found what seems the problem with our vectors being listed backward. In
drivers/pci/msi.c we should be using list_add_tail rather than list_add to
preserve the ordering across various kernels. Please consider this for
inclusion.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c index 0e67723..d74975d 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -333,7 +333,7 @@ static int msi_capability_init(struct pci_dev *dev)
msi_mask_bits_reg(pos, is_64bit_address(control)),
maskbits);
}
- list_add(entry-list, dev-msi_list);
+ list_add_tail(entry-list, dev-msi_list);
/* Configure MSI capability structure */
ret = arch_setup_msi_irqs(dev, 1, PCI_CAP_ID_MSI); @@ -404,7 +404,7 @@
static int msix_capability_init(struct pci_dev *dev,
entry-dev = dev;
entry-mask_base = base;
- list_add(entry-list, dev-msi_list);
+ list_add_tail(entry-list, dev-msi_list);
}
ret = arch_setup_msi_irqs(dev, nvec, PCI_CAP_ID_MSIX);
This patch fixes an Oops during rmmod:
Signed-off-by: Mike Miller [EMAIL PROTECTED]
Signed-off-by: Chase Maupin [EMAIL PROTECTED]
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c index e01380b..6632150 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -558,12 +558,12 @@ static int msi_free_irqs(struct pci_dev* dev)
list_for_each_entry_safe(entry, tmp, dev-msi_list, list) {
if (entry-msi_attrib.type == PCI_CAP_ID_MSIX) {
- if (list_is_last(entry-list, dev-msi_list))
- iounmap(entry-mask_base);
-
writel(1, entry-mask_base + entry-msi_attrib.entry_nr
* PCI_MSIX_ENTRY_SIZE
+ PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET);
+
+ if (list_is_last(entry-list, dev-msi_list))
+ iounmap(entry-mask_base);
}
list_del(entry-list);
kfree(entry);
WARNING: These patches may suffer from wordwrap as they are coming from my
microsucks email client.
We found and fixed these late last week. So I hope they make into Linus' git
tree ASAP.
Thanks,
mikem
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
[EMAIL PROTECTED] +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
-
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/3] zfcp: IO stall after path checker changes
On Tue, 2007-05-29 at 15:55 +0200, Swen Schillig wrote: I just saw that I posted this patch on 9th already, but todays git pull from your tree didn't show the inclusion of this one (and another patch posted the same day). Event though it's reported in your summary from the 26 ! If I'm to quick then I'm sorry for sending it twice, if there's any other reason for this patch to not be included please let me know. Sorry ... must have missed it. I'll add it to rc-fixes (unfortunately I need linus to pull before I can push into this tree, so there'll be a slight delay). 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 1/3] zfcp: IO stall after path checker changes
On Tue, 2007-05-29 at 10:51 -0500, James Bottomley wrote: On Tue, 2007-05-29 at 15:55 +0200, Swen Schillig wrote: I just saw that I posted this patch on 9th already, but todays git pull from your tree didn't show the inclusion of this one (and another patch posted the same day). Event though it's reported in your summary from the 26 ! If I'm to quick then I'm sorry for sending it twice, if there's any other reason for this patch to not be included please let me know. Sorry ... must have missed it. I'll add it to rc-fixes (unfortunately I need linus to pull before I can push into this tree, so there'll be a slight delay). Actually, forget that; this is it, isn't it? http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-rc-fixes-2.6.git;a=commit;h=9f28745a6b554fdd6b0dbc9856077701a55f9569 In which case it's awaiting a pull into Linus' tree head. 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 6/7] ps3: ROM Storage Driver
On Tue, 29 May 2007, Christoph Hellwig wrote:
+/*
+ * copy data from device into scatter/gather buffer
+ */
+static int fill_from_dev_buffer(struct scsi_cmnd *cmd, const void *buf,
+ int buflen)
+{
+ int k, req_len, act_len, len, active;
+ void *kaddr;
+ struct scatterlist *sgpnt;
+
+ if (!cmd-request_bufflen)
+ return 0;
+
+ if (!cmd-request_buffer)
+ return DID_ERROR 16;
+
+ if (cmd-sc_data_direction != DMA_BIDIRECTIONAL
+ cmd-sc_data_direction != DMA_FROM_DEVICE)
+ return DID_ERROR 16;
+
+ if (!cmd-use_sg) {
+ req_len = cmd-request_bufflen;
+ act_len = min(req_len, buflen);
+ memcpy(cmd-request_buffer, buf, act_len);
+ cmd-resid = req_len - act_len;
+ return 0;
+ }
This is never true anymore.
Just to be sure: all four if-cases or only the last one?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- Sony Network and Software Technology Center Europe (NSCE)
[EMAIL PROTECTED] --- The Corporate Village, Da Vincilaan 7-D1
Voice +32-2-7008453 Fax +32-2-7008622 B-1935 Zaventem, Belgium
-
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] SCSI: add cpu cache flushes after kmapping and modifying a page
What ever became of the following patch? I have enclosed the incremental
aacraid version of this patch to permit closure if the following was
rejected because of another portion.
This attached aacraid specific portion of the patch is against current
scsi-misc-2.6.
ObligatoryDisclaimer: Please accept my condolences regarding Outlook's
handling of patch content.
Signed-off-by: Mark Salyzyn [EMAIL PROTECTED]
Sincerely -- Mark Salyzyn
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tejun Heo
Sent: Saturday, June 03, 2006 11:41 PM
To: Jens Axboe; James Bottomley; Dave Miller; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; Guennadi Liakhovetski; [EMAIL PROTECTED];
lkml; [EMAIL PROTECTED]; linux-scsi@vger.kernel.org;
[EMAIL PROTECTED]
Cc: Tejun Heo
Subject: [PATCH 4/5] SCSI: add cpu cache flushes after kmapping and
modifying a page
Add calls to flush_kernel_dcache_page() after CPU has kmapped and
modified a page. This fixes PIO cache coherency bugs on architectures
with aliased caches.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
---
drivers/scsi/3w-9xxx.c|1 +
drivers/scsi/3w-.c|1 +
drivers/scsi/aacraid/aachba.c |4 +++-
drivers/scsi/ide-scsi.c |1 +
drivers/scsi/ips.c|2 ++
drivers/scsi/iscsi_tcp.c |1 +
drivers/scsi/megaraid.c |2 ++
drivers/scsi/qlogicpti.c |1 +
drivers/scsi/scsi_debug.c |1 +
drivers/scsi/scsi_lib.c |1 +
10 files changed, 14 insertions(+), 1 deletions(-)
9b4bdd1409efb726d4a6561a4f7e2aff878ab4f4
diff --git a/drivers/scsi/3w-9xxx.c b/drivers/scsi/3w-9xxx.c
index caeb6d2..172f16b 100644
--- a/drivers/scsi/3w-9xxx.c
+++ b/drivers/scsi/3w-9xxx.c
@@ -1948,6 +1948,7 @@ static void twa_scsiop_execute_scsi_comp
local_irq_save(flags);
buf = kmap_atomic(sg-page, KM_IRQ0) +
sg-offset;
memcpy(buf,
tw_dev-generic_buffer_virt[request_id], sg-length);
+ flush_kernel_dcache_page(kmap_atomic_to_page(buf
- sg-offset));
kunmap_atomic(buf - sg-offset, KM_IRQ0);
local_irq_restore(flags);
}
diff --git a/drivers/scsi/3w-.c b/drivers/scsi/3w-.c
index e8e41e6..8449551 100644
--- a/drivers/scsi/3w-.c
+++ b/drivers/scsi/3w-.c
@@ -1527,6 +1527,7 @@ static void tw_transfer_internal(TW_Devi
struct scatterlist *sg;
sg = (struct scatterlist *)cmd-request_buffer;
+ flush_kernel_dcache_page(kmap_atomic_to_page(buf -
sg-offset));
kunmap_atomic(buf - sg-offset, KM_IRQ0);
local_irq_restore(flags);
}
diff --git a/drivers/scsi/aacraid/aachba.c
b/drivers/scsi/aacraid/aachba.c
index 642a3b4..b7c00b8 100644
--- a/drivers/scsi/aacraid/aachba.c
+++ b/drivers/scsi/aacraid/aachba.c
@@ -376,8 +376,10 @@ static void aac_internal_transfer(struct
memcpy(buf + offset, data, transfer_len - offset);
- if (scsicmd-use_sg)
+ if (scsicmd-use_sg) {
+ flush_kernel_dcache_page(kmap_atomic_to_page(buf -
sg-offset));
kunmap_atomic(buf - sg-offset, KM_IRQ0);
+ }
}
diff --git a/drivers/scsi/ide-scsi.c b/drivers/scsi/ide-scsi.c
index 39b760a..9c28b95 100644
--- a/drivers/scsi/ide-scsi.c
+++ b/drivers/scsi/ide-scsi.c
@@ -189,6 +189,7 @@ static void idescsi_input_buffers (ide_d
pc-sg-offset;
drive-hwif-atapi_input_bytes(drive,
buf + pc-b_count,
count);
+ flush_kernel_dcache_page(kmap_atomic_to_page(buf
- pc-sg-offset));
kunmap_atomic(buf - pc-sg-offset, KM_IRQ0);
local_irq_restore(flags);
} else {
diff --git a/drivers/scsi/ips.c b/drivers/scsi/ips.c
index a4c0b04..29eb3f0 100644
--- a/drivers/scsi/ips.c
+++ b/drivers/scsi/ips.c
@@ -3682,6 +3682,8 @@ ips_scmd_buf_write(Scsi_Cmnd * scmd, voi
local_irq_save(flags);
buffer = kmap_atomic(sg[i].page, KM_IRQ0) +
sg[i].offset;
memcpy(buffer, cdata[xfer_cnt], min_cnt);
+flush_kernel_dcache_page(
+kmap_atomic_to_page(buffer -
sg[i].offset));
kunmap_atomic(buffer - sg[i].offset, KM_IRQ0);
local_irq_restore(flags);
diff --git a/drivers/scsi/iscsi_tcp.c b/drivers/scsi/iscsi_tcp.c
index 2068b66..ae9784c 100644
--- a/drivers/scsi/iscsi_tcp.c
+++ b/drivers/scsi/iscsi_tcp.c
@@ -945,6 +945,7 @@ static int iscsi_scsi_data_in(struct isc
dest = kmap_atomic(sg[i].page, KM_SOFTIRQ0);
rc = iscsi_ctask_copy(conn, ctask, dest + sg[i].offset,
sg[i].length, offset);
+
Re: Patch added to scsi-pending-2.6: [SCSI] libsas: convert to use the data buffer accessors
On Sun, May 27, 2007 at 05:37:43PM +, James Bottomley wrote: [SCSI] libsas: convert to use the data buffer accessors snip This patch is pending because it requires ACKs from: Darrick J. Wong [EMAIL PROTECTED] ACK. --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
[PATCH 1/1] ibmvscsi: Changeable queue depth
Adds support for a changeable queue depth to ibmvscsi.
Signed-off-by: Brian King [EMAIL PROTECTED]
---
linux-2.6-bjking1/drivers/scsi/ibmvscsi/ibmvscsi.c | 15 +++
1 file changed, 15 insertions(+)
diff -puN drivers/scsi/ibmvscsi/ibmvscsi.c~ibmvscsi_change_q_depth
drivers/scsi/ibmvscsi/ibmvscsi.c
--- linux-2.6/drivers/scsi/ibmvscsi/ibmvscsi.c~ibmvscsi_change_q_depth
2007-05-29 09:31:43.0 -0500
+++ linux-2.6-bjking1/drivers/scsi/ibmvscsi/ibmvscsi.c 2007-05-29
09:31:43.0 -0500
@@ -1375,6 +1375,20 @@ static int ibmvscsi_slave_configure(stru
return 0;
}
+/**
+ * ibmvscsi_change_queue_depth - Change the device's queue depth
+ * @sdev: scsi device struct
+ * @qdepth:depth to set
+ *
+ * Return value:
+ * actual depth set
+ **/
+static int ibmvscsi_change_queue_depth(struct scsi_device *sdev, int qdepth)
+{
+ scsi_adjust_queue_depth(sdev, 0, qdepth);
+ return sdev-queue_depth;
+}
+
/*
* sysfs attributes
*/
@@ -1521,6 +1535,7 @@ static struct scsi_host_template driver_
.eh_abort_handler = ibmvscsi_eh_abort_handler,
.eh_device_reset_handler = ibmvscsi_eh_device_reset_handler,
.slave_configure = ibmvscsi_slave_configure,
+ .change_queue_depth = ibmvscsi_change_queue_depth,
.cmd_per_lun = 16,
.can_queue = IBMVSCSI_MAX_REQUESTS_DEFAULT,
.this_id = -1,
_
-
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] ibmvscsi: Changeable queue depth
On Tue, 2007-05-29 at 13:00 -0500, Brian King wrote:
Adds support for a changeable queue depth to ibmvscsi.
Signed-off-by: Brian King [EMAIL PROTECTED]
---
linux-2.6-bjking1/drivers/scsi/ibmvscsi/ibmvscsi.c | 15 +++
1 file changed, 15 insertions(+)
diff -puN drivers/scsi/ibmvscsi/ibmvscsi.c~ibmvscsi_change_q_depth
drivers/scsi/ibmvscsi/ibmvscsi.c
--- linux-2.6/drivers/scsi/ibmvscsi/ibmvscsi.c~ibmvscsi_change_q_depth
2007-05-29 09:31:43.0 -0500
+++ linux-2.6-bjking1/drivers/scsi/ibmvscsi/ibmvscsi.c2007-05-29
09:31:43.0 -0500
@@ -1375,6 +1375,20 @@ static int ibmvscsi_slave_configure(stru
return 0;
}
+/**
+ * ibmvscsi_change_queue_depth - Change the device's queue depth
+ * @sdev:scsi device struct
+ * @qdepth: depth to set
+ *
+ * Return value:
+ * actual depth set
+ **/
+static int ibmvscsi_change_queue_depth(struct scsi_device *sdev, int qdepth)
+{
+ scsi_adjust_queue_depth(sdev, 0, qdepth);
Don't you want to check this against some system limit ... or will the
driver cope just fine when the user sets it to machine infinity and we
diligently try blasting away at it through the queuecommand() routine?
The usual limit, if you have variable queues ... is the maximum the
device could ever accept ... although some people adjust that downwards
because of device starvation fears.
+ return sdev-queue_depth;
+}
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
[PATCH 1/1] ibmvscsi: Changeable queue depth
Adds support for a changeable queue depth to ibmvscsi.
Signed-off-by: Brian King [EMAIL PROTECTED]
---
James Bottomley wrote:
Don't you want to check this against some system limit ... or will the
driver cope just fine when the user sets it to machine infinity and we
diligently try blasting away at it through the queuecommand() routine?
The usual limit, if you have variable queues ... is the maximum the
device could ever accept ... although some people adjust that downwards
because of device starvation fears.
There isn't anything coming back from the VIO server to indicate what this
max value is for the LUN, so we have to use an arbitrary value. I chose 64
since its generally the max queue depth supported by a single disk supported
on pSeries. Here is an updated patch.
-Brian
---
linux-2.6-bjking1/drivers/scsi/ibmvscsi/ibmvscsi.c | 18 ++
linux-2.6-bjking1/drivers/scsi/ibmvscsi/ibmvscsi.h |1 +
2 files changed, 19 insertions(+)
diff -puN drivers/scsi/ibmvscsi/ibmvscsi.c~ibmvscsi_change_q_depth
drivers/scsi/ibmvscsi/ibmvscsi.c
--- linux-2.6/drivers/scsi/ibmvscsi/ibmvscsi.c~ibmvscsi_change_q_depth
2007-05-29 12:57:20.0 -0500
+++ linux-2.6-bjking1/drivers/scsi/ibmvscsi/ibmvscsi.c 2007-05-29
15:27:23.0 -0500
@@ -1375,6 +1375,23 @@ static int ibmvscsi_slave_configure(stru
return 0;
}
+/**
+ * ibmvscsi_change_queue_depth - Change the device's queue depth
+ * @sdev: scsi device struct
+ * @qdepth:depth to set
+ *
+ * Return value:
+ * actual depth set
+ **/
+static int ibmvscsi_change_queue_depth(struct scsi_device *sdev, int qdepth)
+{
+ if (qdepth IBMVSCSI_MAX_CMDS_PER_LUN)
+ qdepth = IBMVSCSI_MAX_CMDS_PER_LUN;
+
+ scsi_adjust_queue_depth(sdev, 0, qdepth);
+ return sdev-queue_depth;
+}
+
/*
* sysfs attributes
*/
@@ -1521,6 +1538,7 @@ static struct scsi_host_template driver_
.eh_abort_handler = ibmvscsi_eh_abort_handler,
.eh_device_reset_handler = ibmvscsi_eh_device_reset_handler,
.slave_configure = ibmvscsi_slave_configure,
+ .change_queue_depth = ibmvscsi_change_queue_depth,
.cmd_per_lun = 16,
.can_queue = IBMVSCSI_MAX_REQUESTS_DEFAULT,
.this_id = -1,
diff -puN drivers/scsi/ibmvscsi/ibmvscsi.h~ibmvscsi_change_q_depth
drivers/scsi/ibmvscsi/ibmvscsi.h
--- linux-2.6/drivers/scsi/ibmvscsi/ibmvscsi.h~ibmvscsi_change_q_depth
2007-05-29 15:25:24.0 -0500
+++ linux-2.6-bjking1/drivers/scsi/ibmvscsi/ibmvscsi.h 2007-05-29
15:29:11.0 -0500
@@ -45,6 +45,7 @@ struct Scsi_Host;
#define MAX_INDIRECT_BUFS 10
#define IBMVSCSI_MAX_REQUESTS_DEFAULT 100
+#define IBMVSCSI_MAX_CMDS_PER_LUN 64
/*
* Data Structures
_
-
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: [AIC7xxx] tree things to report
Grand. Well done, son. The logs have been very instructive. Again we're hitting this 'two commands per lun' problem. For historic reasons the aic7xxx and aic79xx driver accepted two commands per luns, as they implemented their internal queueing and could hold the second command on the queue. With later versions I've removed this internal queueing and relied on the block-layer for this. But this also means we can only accept one command per lun. Please try the attached patch and see if it helps. James, I know that the aic7xxx has some 'next_queued_hscb' pointer which might be utilized for this sort of thing. But I didn't really figure out how this thing is supposed to work nor how we could utilize it. So I figured that the added complexity is not really worth it. Hi, Some news: I tried the patch and I still get this sort of instant bus freeze with difficult recovery. But there is some interesting new things too: First log: standard boot, netconsole start, echo 32767 /proc/sys/dev/scsi/scsi ; cdrwtool -t4 -d/dev/sr0 -q === scsi bus crash - lot of log - Kernel Bug. Second log: standard boot , init 1 to go into single user mode, echo 32767 /proc/sys/dev/scsi/scsi ; cdrwtool -t4 -d/dev/sr0 -q Bus crash, recovery, cdrwtool command crash, get the shell back. Remount root-fs read-only to suppress completely sd 0:0:0:0 activity. cdrwtool -t4 -d/dev/sr0 -q Lots of recovery logs and blablabla your cd will be completely erased blablablapress y to continue !!! Y enter - writer led start to blink, formating is running But ~30s later, driver recovery or scsi timeout or midlayer timeout (I don't know) is kicking, device is reseted, stopping the disc formating. sniff. cdrwtool report udf filesystem structure initialization but all is discarded by the driver or the midlayer. cdrwtool exit. last log: without reboot: cdrwtool -t4 -d/dev/sr0 -q bus freeze, lots of log, cdrwtool command crash ... All that I could say with my limited understanding of the big picture and what I previously saw: - The aic7xxx recovery path is still very fragile and unable to recover from problems under scsi bus activity. Perhaps the port of your previous work on this path from aic79xx could help. - It seems that the commands send by cdrwtool which confuse the driver are commands to sense the properties of the inserted media and not the formating command itself. - The first part: commands which crash the scsi bus before the begin of the media format was not happening before the big driver change (before 2.6.14). - The second part: formating interrupted because driver recovery kicked in was already happening with 2.6.13 and the recovery already fail and never recover - Perhaps to worsen all of this, cdrwtool is very crude with my old yamaha cdwriter and help to trigger a chain of worst case events which expose lots of bugs/unhanded cases. (cdrwtool bugs/writer firmware bugs/aic7xxx bugs .). Hope this could help. The positive thing is that now with the help of Francois Romieu I could use my old pcnet32 card to get the logs ;-) Best regards, Emmanuel. --- Créez votre adresse électronique [EMAIL PROTECTED] 1 Go d'espace de stockage, anti-spam et anti-virus intégrés. log.rafale-new-1.gz Description: application/gzip log.rafale-new-2.gz Description: application/gzip log.rafale-new-3.gz Description: application/gzip
RE: [PATCH] fix for BZ 8426 - massive slowdown on SCSI CD/DVDdrive connected to mptspi driver
On Tuesday, May 22, 2007 3:27 PM, James Bottomley wrote: On Tue, 2007-05-22 at 14:25 -0600, Doug Chapman wrote: Eric, Sorry to bother you on this again, I realize you are very busy. From our off-list email and from your comments to Chip Coldwell in redhat BZ 225177 it sounded like you were prepared to ACK this. Any chance you could send your official ACK so this can be committed? much appreciated, Actually I'd like a little analysis of why first, please Eric. It seems to me, with the current wrong ordering in the initialisation results in a large queue depth being given to the DVD (which are habitually very low queue depth ... or even untagged beasts). So does the slowdown result from the fusion accepting N commands for the DVD and then rejecting N-1 of them resulting in ping pong between the mid-layer and driver? If so, we probably want to fix the command throttling in the driver. James - Sorry, for delay, somehow I missed this email. I approve the patch that was submitted by Doug Chapman. Here is the reasoning: The DVD device that Doug is using is either a SCSI_1 device, or it doesn't support Q-tags. The problem is the driver is setting the Queue depth to 32, when it should of been 1. With the queue depth set larger than one, this device doesn't work properly. This bug came about when I reorganized some spi functions by moving them from mptscsih.c over to mptspi.c. When I did that, there were some flags not set correctly in mptscsih_change_queue_depth. The function that sets these flags is mptspi_setTargetNegoParms.Prior to reorganizing the code, I was calling mptscsi_setTargetNegoParms before I set the queue depth, the current code does it after.If you accept this patch, then it sets the flags properly. 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
Re: Patch added to scsi-pending-2.6: [SCSI] ipr: convert to use the data buffer accessors
Acked-by: Brian King [EMAIL PROTECTED] James Bottomley wrote: Your commit: [SCSI] ipr: convert to use the data buffer accessors - remove the unnecessary map_single path. - convert to use the new accessors for the sg lists and the parameters. Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED] Cc: Brian King [EMAIL PROTECTED] Signed-off-by: James Bottomley [EMAIL PROTECTED] has been added to the pending SCSI tree You can find it here: http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-pending-2.6.git;a=commit;h=7e9f7162968845324e123180b0d8bea8f93f6ef5 Please note the scsi-misc-2.6 tree will rebase, so this URL may not be permanent. You will get another email if the tree rebases. This patch is pending because it requires ACKs from: Brian King [EMAIL PROTECTED] If those are received it may be moved into one of the upstream SCSI queues James Bottomley P.S. If you find this email unwanted, set up a procmail rule junking on the header: X-Git-Tree: SCSI -- Brian King Linux on Power Virtualization IBM Linux Technology Center - 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] fix for BZ 8426 - massive slowdown on SCSI CD/DVDdrive connected to mptspi driver
On Tue, 2007-05-29 at 15:40 -0600, Moore, Eric wrote: On Tuesday, May 22, 2007 3:27 PM, James Bottomley wrote: On Tue, 2007-05-22 at 14:25 -0600, Doug Chapman wrote: Eric, Sorry to bother you on this again, I realize you are very busy. From our off-list email and from your comments to Chip Coldwell in redhat BZ 225177 it sounded like you were prepared to ACK this. Any chance you could send your official ACK so this can be committed? much appreciated, Actually I'd like a little analysis of why first, please Eric. It seems to me, with the current wrong ordering in the initialisation results in a large queue depth being given to the DVD (which are habitually very low queue depth ... or even untagged beasts). So does the slowdown result from the fusion accepting N commands for the DVD and then rejecting N-1 of them resulting in ping pong between the mid-layer and driver? If so, we probably want to fix the command throttling in the driver. James - Sorry, for delay, somehow I missed this email. I approve the patch that was submitted by Doug Chapman. Here is the reasoning: The DVD device that Doug is using is either a SCSI_1 device, or it doesn't support Q-tags. The problem is the driver is setting the Queue depth to 32, when it should of been 1. With the queue depth set larger than one, this device doesn't work properly. The device is presumably returning BUSY when you try to send a second command when it's already processing the first ... that should be propagated back to the mid-layer causing it to throttle the queue ... it seems this wasn't happening for some reason to get such a massive slowdown. Is this a more generic problem in the fusion or is it a simple issue only affecting the untagged case? This bug came about when I reorganized some spi functions by moving them from mptscsih.c over to mptspi.c. When I did that, there were some flags not set correctly in mptscsih_change_queue_depth. The function that sets these flags is mptspi_setTargetNegoParms.Prior to reorganizing the code, I was calling mptscsi_setTargetNegoParms before I set the queue depth, the current code does it after.If you accept this patch, then it sets the flags properly. 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] fix for BZ 8426 - massive slowdown on SCSI CD/DVDdriveconnected to mptspi driver
On Tuesday, May 29, 2007 4:03 PM, James Bottomley wrote: The device is presumably returning BUSY when you try to send a second command when it's already processing the first ... that should be propagated back to the mid-layer causing it to throttle the queue ... it seems this wasn't happening for some reason to get such a massive slowdown. Is this a more generic problem in the fusion or is it a simple issue only affecting the untagged case? Right, probably SELECTION_TIMEOUT. Or command timeout with error handling threads getting called. Either way, the customer hasn't provided a dmesg log or scsi bus trace, so we don't know for sure. But is this analysis really required? Dont' you think the driver should return that it doens't support queued commands when sdev-tagged_supported (look at scsi_scan.c function scsi_add_lun) is set to zero? It appears that is what other drivers in the kernel tree do.When I reorganized the code in a patch I provided back in February, I moved analyzing the sdev-tagged_supported flag to after I set the queue depth, not before. 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
RE: [patch 1/1] scsi: cover up bugs^W^W^WFix up compiler warnings in megaraid driver
Hello Andrew, The email-id [EMAIL PROTECTED] is the alias for driver developers for MegaRAID product. This id includes my name. Recently I submitted patch to update the MAINTAINERS to add this id. Regards, Sumant -Original Message- From: Andrew Morton [mailto:[EMAIL PROTECTED] Sent: Friday, May 25, 2007 2:46 PM To: Patro, Sumant Cc: [EMAIL PROTECTED]; linux-scsi@vger.kernel.org; [EMAIL PROTECTED] Subject: Re: [patch 1/1] scsi: cover up bugs^W^W^WFix up compiler warnings in megaraid driver On Fri, 25 May 2007 14:28:19 -0600 Patro, Sumant [EMAIL PROTECTED] wrote: Ack. Thanks. While we're here... box:/usr/src/25 grep -i lsi MAINTAINERS LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI) M: [EMAIL PROTECTED] M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] W: http://www.lsilogic.com/support LSILOGIC/SYMBIOS/NCR 53C8XX and 53C1010 PCI-SCSI drivers W: http://megaraid.lsilogic.com USB KAWASAKI LSI DRIVER M: [EMAIL PROTECTED] box:/usr/src/25 grep -i sumant MAINTAINERS box:/usr/src/25 Could I ask that you review the MAINTAINERS file and ensure that all appropriate lsil developers are appropriately mentioned and that all drivers which lsil look after have the appropriate entries? Thanks. - 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: kexec and aacraid broken
On Tue, 29 May 2007 18:59:32 -0700 Yinghai Lu [EMAIL PROTECTED] wrote: latest tree, can not use kexec to load 2.6.22-rc3 at least. got: AAC0: adapter kernel panic'd fffd AAC0: adapter kernel failed to start, init status=0 One of the two diffs below, I guess. Please do a `patch -R -p1' of this email and retest? but can load 2.6.21.3 Michal, can you please add this to the regression list? commit 9e4d4a5d71d673901d9c1df5146ce545c2cc0cc0 Author: Salyzyn, Mark [EMAIL PROTECTED] Date: Tue May 1 11:43:06 2007 -0400 [SCSI] aacraid: superfluous adapter reset for IBM 8 series ServeRAID controllers The kexec patch introduced a superfluous (and otherwise inert) reset of some adapters. The register can have a hardware default value that has zeros for the undefined interrupts. This patch refines the test of the interrupt enable register to focus on only the interrupts that affect the driver in order to detect if an incomplete shutdown of the Adapter had occurred (kdump). Signed-off-by: Mark Salyzyn [EMAIL PROTECTED] Signed-off-by: James Bottomley [EMAIL PROTECTED] diff --git a/drivers/scsi/aacraid/rx.c b/drivers/scsi/aacraid/rx.c index b6ee3c0..291cd14 100644 --- a/drivers/scsi/aacraid/rx.c +++ b/drivers/scsi/aacraid/rx.c @@ -542,7 +542,7 @@ int _aac_rx_init(struct aac_dev *dev) dev-a_ops.adapter_sync_cmd = rx_sync_cmd; dev-a_ops.adapter_enable_int = aac_rx_disable_interrupt; dev-OIMR = status = rx_readb (dev, MUnit.OIMR); - if status 0xff) != 0xff) || reset_devices) + if status 0x0c) != 0x0c) || reset_devices) !aac_rx_restart_adapter(dev, 0)) ++restart; /* commit a5694ec545a880f9d23463fddc894f5096cc68fa Author: Salyzyn, Mark [EMAIL PROTECTED] Date: Mon Apr 30 13:22:24 2007 -0400 [SCSI] aacraid: kexec fix (reset interrupt handler) Another layer on this onion also discovered by Duane, the interrupt enable handler also needed to be set ... The interrupt enable was called from within the synchronous command handler. Signed-off-by: Mark Salyzyn [EMAIL PROTECTED] Signed-off-by: James Bottomley [EMAIL PROTECTED] diff --git a/drivers/scsi/aacraid/rx.c b/drivers/scsi/aacraid/rx.c index 0c71315..b6ee3c0 100644 --- a/drivers/scsi/aacraid/rx.c +++ b/drivers/scsi/aacraid/rx.c @@ -539,6 +539,8 @@ int _aac_rx_init(struct aac_dev *dev) } /* Failure to reset here is an option ... */ + dev-a_ops.adapter_sync_cmd = rx_sync_cmd; + dev-a_ops.adapter_enable_int = aac_rx_disable_interrupt; dev-OIMR = status = rx_readb (dev, MUnit.OIMR); if status 0xff) != 0xff) || reset_devices) !aac_rx_restart_adapter(dev, 0)) - 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
