[patch 04/28] drivers/scsi/NCR5380.c: Replacing yield() with a better alternative
From: Amol Lad [EMAIL PROTECTED] Replaced yield() with cond_resched() Signed-off-by: Amol Lad [EMAIL PROTECTED] Acked-by: Alan Cox [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- drivers/scsi/NCR5380.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN drivers/scsi/NCR5380.c~drivers-scsi-ncr5380c-replacing-yield-with-a drivers/scsi/NCR5380.c --- a/drivers/scsi/NCR5380.c~drivers-scsi-ncr5380c-replacing-yield-with-a +++ a/drivers/scsi/NCR5380.c @@ -347,7 +347,7 @@ static int NCR5380_poll_politely(struct if((r bit) == val) return 0; if(!in_interrupt()) - yield(); + cond_resched(); else cpu_relax(); } _ - 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 07/28] scsi: cover up bugs^W^W^WFix up compiler warnings in megaraid driver
From: Martin Bligh [EMAIL PROTECTED]
Fix up compiler warnings in megaraid driver
[EMAIL PROTECTED]: build fix]
Signed-off-by: Martin J. Bligh [EMAIL PROTECTED]
Cc: James Bottomley [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/scsi/megaraid.c | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff -puN
drivers/scsi/megaraid.c~scsi-cover-up-bugs-fix-up-compiler-warnings-in-megaraid-driver
drivers/scsi/megaraid.c
---
a/drivers/scsi/megaraid.c~scsi-cover-up-bugs-fix-up-compiler-warnings-in-megaraid-driver
+++ a/drivers/scsi/megaraid.c
@@ -73,10 +73,14 @@ static unsigned short int max_mbox_busy_
module_param(max_mbox_busy_wait, ushort, 0);
MODULE_PARM_DESC(max_mbox_busy_wait, Maximum wait for mailbox in microseconds
if busy (default=MBOX_BUSY_WAIT=10));
-#define RDINDOOR(adapter) readl((adapter)-mmio_base + 0x20)
-#define RDOUTDOOR(adapter) readl((adapter)-mmio_base + 0x2C)
-#define WRINDOOR(adapter,value) writel(value, (adapter)-mmio_base +
0x20)
-#define WROUTDOOR(adapter,value) writel(value, (adapter)-mmio_base + 0x2C)
+#define RDINDOOR(adapter) readl((volatile void __iomem *) \
+ (adapter)-base + 0x20)
+#define RDOUTDOOR(adapter) readl((volatile void __iomem *) \
+ (adapter)-base + 0x2C)
+#define WRINDOOR(adapter,value)writel(value, (volatile void
__iomem *)\
+ (adapter)-base + 0x20)
+#define WROUTDOOR(adapter,value) writel(value, (volatile void __iomem *)\
+ (adapter)-base + 0x2C)
/*
* Global variables
@@ -3571,7 +3575,7 @@ megadev_ioctl(struct inode *inode, struc
/*
* The user passthru structure
*/
- upthru = (mega_passthru __user *)MBOX(uioc)-xferaddr;
+ upthru = (mega_passthru __user *)(unsigned
long)MBOX(uioc)-xferaddr;
/*
* Copy in the user passthru here.
@@ -3623,7 +3627,7 @@ megadev_ioctl(struct inode *inode, struc
/*
* Get the user data
*/
- if( copy_from_user(data, (char __user
*)uxferaddr,
+ if( copy_from_user(data, (char __user
*)(unsigned long) uxferaddr,
pthru-dataxferlen) ) {
rval = (-EFAULT);
goto freemem_and_return;
@@ -3649,7 +3653,7 @@ megadev_ioctl(struct inode *inode, struc
* Is data going up-stream
*/
if( pthru-dataxferlen (uioc.flags UIOC_RD) ) {
- if( copy_to_user((char __user *)uxferaddr, data,
+ if( copy_to_user((char __user *)(unsigned long)
uxferaddr, data,
pthru-dataxferlen) ) {
rval = (-EFAULT);
}
@@ -3702,7 +3706,7 @@ freemem_and_return:
/*
* Get the user data
*/
- if( copy_from_user(data, (char __user
*)uxferaddr,
+ if( copy_from_user(data, (char __user
*)(unsigned long) uxferaddr,
uioc.xferlen) ) {
pci_free_consistent(pdev,
@@ -3742,7 +3746,7 @@ freemem_and_return:
* Is data going up-stream
*/
if( uioc.xferlen (uioc.flags UIOC_RD) ) {
- if( copy_to_user((char __user *)uxferaddr, data,
+ if( copy_to_user((char __user *)(unsigned long)
uxferaddr, data,
uioc.xferlen) ) {
rval = (-EFAULT);
_
-
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 14/28] scsi: fix CONFIG_SCSI_WAIT_SCAN=m
From: Hugh Dickins [EMAIL PROTECTED] CONFIG_MODULES=y CONFIG_SCSI=y CONFIG_SCSI_SCAN_ASYNC=y CONFIG_SCSI_WAIT_SCAN=m 2.6.21-rc5-mm2 VFS panics unable to find my root on /dev/sda2, but boots okay if I change drivers/scsi/Kconfig to default y instead of default m for SCSI_WAIT_SCAN. Make sure there's a late_initcall to scsi_complete_async_scans when it's built in, so a monolithic SCSI_SCAN_ASYNC kernel can rely on the scans being completed before trying to mount root, even if they're slow. [EMAIL PROTECTED]: build fixes] Signed-off-by: Hugh Dickins [EMAIL PROTECTED] Cc: James Bottomley [EMAIL PROTECTED] --- James sayeth This isn't the right fix ... this has to be invoked last in the call sequence ... I can't see another way of doing this except yet another file added as a final component to the link. Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- drivers/scsi/scsi_scan.c |9 + 1 file changed, 9 insertions(+) diff -puN drivers/scsi/scsi_scan.c~scsi-fix-config_scsi_wait_scan=m drivers/scsi/scsi_scan.c --- a/drivers/scsi/scsi_scan.c~scsi-fix-config_scsi_wait_scan=m +++ a/drivers/scsi/scsi_scan.c @@ -184,6 +184,15 @@ int scsi_complete_async_scans(void) /* Only exported for the benefit of scsi_wait_scan */ EXPORT_SYMBOL_GPL(scsi_complete_async_scans); +#ifndef MODULE +/* + * For async scanning we need to wait for all the scans to complete before + * trying to mount the root fs. Otherwise non-modular drivers may not be ready + * yet. + */ +late_initcall(scsi_complete_async_scans); +#endif + /** * scsi_unlock_floptical - unlock device via a special MODE SENSE command * @sdev: scsi device to send command to _ - 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 06/28] drivers/scsi/wd33c93.c: cleanups
From: Adrian Bunk [EMAIL PROTECTED]
- #include asm/irq.h for getting the prototypes of {dis,en}able_irq()
- make the needlessly global wd33c93_setup() static
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/scsi/wd33c93.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff -puN drivers/scsi/wd33c93.c~drivers-scsi-wd33c93c-cleanups
drivers/scsi/wd33c93.c
--- a/drivers/scsi/wd33c93.c~drivers-scsi-wd33c93c-cleanups
+++ a/drivers/scsi/wd33c93.c
@@ -89,6 +89,8 @@
#include scsi/scsi_device.h
#include scsi/scsi_host.h
+#include asm/irq.h
+
#include wd33c93.h
#define optimum_sx_per(hostdata) (hostdata)-sx_table[1].period_ns
@@ -1762,7 +1764,7 @@ static char setup_buffer[SETUP_BUFFER_SI
static char setup_used[MAX_SETUP_ARGS];
static int done_setup = 0;
-int
+static int
wd33c93_setup(char *str)
{
int i;
_
-
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 10/28] Fix |/|| confusion in fusion driver
From: Dirk Mueller [EMAIL PROTECTED] This patch corrects a |/|| confusion in mptscsih_copy_sense_data. Using || means that the data that ends up being written is (almost always) 1, instead of being bit-wise or'ed. Cc: Eric Moore [EMAIL PROTECTED] Cc: James Bottomley [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- drivers/message/fusion/mptscsih.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff -puN drivers/message/fusion/mptscsih.c~fix--confusion-in-fusion-driver drivers/message/fusion/mptscsih.c --- a/drivers/message/fusion/mptscsih.c~fix--confusion-in-fusion-driver +++ a/drivers/message/fusion/mptscsih.c @@ -2463,9 +2463,9 @@ mptscsih_copy_sense_data(struct scsi_cmn ioc-events[idx].event = MPI_EVENT_SCSI_DEVICE_STATUS_CHANGE; ioc-events[idx].eventContext = ioc-eventContext; - ioc-events[idx].data[0] = (pReq-LUN[1] 24) || - (MPI_EVENT_SCSI_DEV_STAT_RC_SMART_DATA 16) || - (sc-device-channel 8) || sc-device-id; + ioc-events[idx].data[0] = (pReq-LUN[1] 24) | + (MPI_EVENT_SCSI_DEV_STAT_RC_SMART_DATA 16) | + (sc-device-channel 8) | sc-device-id; ioc-events[idx].data[1] = (sense_data[13] 8) || sense_data[12]; _ - 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 08/28] make seagate_st0x_detect() static
From: Adrian Bunk [EMAIL PROTECTED]
seagate_st0x_detect() can become static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/scsi/seagate.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN drivers/scsi/seagate.c~make-seagate_st0x_detect-static
drivers/scsi/seagate.c
--- a/drivers/scsi/seagate.c~make-seagate_st0x_detect-static
+++ a/drivers/scsi/seagate.c
@@ -420,7 +420,7 @@ static inline void borken_wait (void)
#define ULOOP( i ) for (clock = i*8;;)
#define TIMEOUT (!(clock--))
-int __init seagate_st0x_detect (struct scsi_host_template * tpnt)
+static int __init seagate_st0x_detect (struct scsi_host_template * tpnt)
{
struct Scsi_Host *instance;
int i, 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
[patch 25/28] Fix old SCSI adapter crashes with CD-ROM (take 2)
From: Alan Cox [EMAIL PROTECTED]
The CD-ROM layer doesn't bounce requests for old ISA controllers (and nor
should it). However they get injected into the SCSI layer via sr_ioctl
which also doesn't bounce them and SCSI then passes the buffer along to a
device with unchecked_isa_dma set which either panics or truncates the
buffer to 24bits.
According to Jens the right long term fix is for the CD layer to route the
requests differently but in the mean time this has been tested by a victim
and verified to sort the problem out. For the other 99.9% of users it's a
no-op and doesn't bounce data.
(akpm: placeholder fix. Apparently the metaphorical Mike is working on a real
fix).
Signed-off-by: Alan Cox [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/scsi/sr_ioctl.c | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff -puN
drivers/scsi/sr_ioctl.c~fix-old-scsi-adapter-crashes-with-cd-rom-take-2
drivers/scsi/sr_ioctl.c
--- a/drivers/scsi/sr_ioctl.c~fix-old-scsi-adapter-crashes-with-cd-rom-take-2
+++ a/drivers/scsi/sr_ioctl.c
@@ -187,6 +187,7 @@ int sr_do_ioctl(Scsi_CD *cd, struct pack
struct scsi_sense_hdr sshdr;
int result, err = 0, retries = 0;
struct request_sense *sense = cgc-sense;
+ void *zebedee = cgc-buffer;
SDev = cd-device;
@@ -198,6 +199,21 @@ int sr_do_ioctl(Scsi_CD *cd, struct pack
}
}
+ if (cgc-buflen cd-device-host-unchecked_isa_dma) {
+ switch(cgc-data_direction) {
+ case DMA_NONE:
+ break;
+ case DMA_FROM_DEVICE:
+ case DMA_TO_DEVICE:
+ zebedee = kmalloc(cgc-buflen,
GFP_KERNEL|GFP_DMA);
+ if (zebedee ==NULL) {
+ err = -ENOMEM;
+ goto out;
+ }
+ }
+ if (cgc-data_direction == DMA_TO_DEVICE)
+ memcpy(zebedee, cgc-buffer, cgc-buflen);
+ }
retry:
if (!scsi_block_when_processing_errors(SDev)) {
err = -ENODEV;
@@ -206,11 +222,16 @@ int sr_do_ioctl(Scsi_CD *cd, struct pack
memset(sense, 0, sizeof(*sense));
result = scsi_execute(SDev, cgc-cmd, cgc-data_direction,
- cgc-buffer, cgc-buflen, (char *)sense,
+ zebedee, cgc-buflen, (char *)sense,
cgc-timeout, IOCTL_RETRIES, 0);
scsi_normalize_sense((char *)sense, sizeof(*sense), sshdr);
+ if (zebedee != cgc-buffer) {
+ if (cgc-data_direction == DMA_FROM_DEVICE)
+ memcpy(cgc-buffer, zebedee, cgc-buflen);
+ }
+
/* Minimal error checking. Ignore cases we know about, and report the
rest. */
if (driver_byte(result) != 0) {
switch (sshdr.sense_key) {
@@ -266,6 +287,8 @@ int sr_do_ioctl(Scsi_CD *cd, struct pack
/* Wake up a process waiting for device */
out:
+ if (zebedee != cgc-buffer)
+ kfree(zebedee); /* Time for bed */
if (!cgc-sense)
kfree(sense);
cgc-stat = err;
_
-
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 20/28] drivers/scsi/ips.c: remove kernel 2.4 code
From: Adrian Bunk [EMAIL PROTECTED]
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/scsi/ips.c | 145 +--
drivers/scsi/ips.h | 44 -
2 files changed, 20 insertions(+), 169 deletions(-)
diff -puN drivers/scsi/ips.c~drivers-scsi-ipsc-remove-kernel-24-code
drivers/scsi/ips.c
--- a/drivers/scsi/ips.c~drivers-scsi-ipsc-remove-kernel-24-code
+++ a/drivers/scsi/ips.c
@@ -211,19 +211,6 @@ module_param(ips, charp, 0);
#warning This driver has only been tested on the x86/ia64/x86_64 platforms
#endif
-#if LINUX_VERSION_CODE = KERNEL_VERSION(2,5,0)
-#include linux/blk.h
-#include sd.h
-#define IPS_LOCK_SAVE(lock,flags) spin_lock_irqsave(io_request_lock,flags)
-#define IPS_UNLOCK_RESTORE(lock,flags)
spin_unlock_irqrestore(io_request_lock,flags)
-#ifndef __devexit_p
-#define __devexit_p(x) x
-#endif
-#else
-#define IPS_LOCK_SAVE(lock,flags) do{spin_lock(lock);(void)flags;}while(0)
-#define IPS_UNLOCK_RESTORE(lock,flags)
do{spin_unlock(lock);(void)flags;}while(0)
-#endif
-
#define IPS_DMA_DIR(scb) ((!scb-scsi_cmd || ips_is_passthru(scb-scsi_cmd) ||
\
DMA_NONE == scb-scsi_cmd-sc_data_direction) ? \
PCI_DMA_BIDIRECTIONAL : \
@@ -381,24 +368,13 @@ static struct scsi_host_template ips_dri
.eh_abort_handler = ips_eh_abort,
.eh_host_reset_handler = ips_eh_reset,
.proc_name = ips,
-#if LINUX_VERSION_CODE KERNEL_VERSION(2,5,0)
.proc_info = ips_proc_info,
.slave_configure= ips_slave_configure,
-#else
- .proc_info = ips_proc24_info,
- .select_queue_depths= ips_select_queue_depth,
-#endif
.bios_param = ips_biosparam,
.this_id= -1,
.sg_tablesize = IPS_MAX_SG,
.cmd_per_lun= 3,
.use_clustering = ENABLE_CLUSTERING,
-#if LINUX_VERSION_CODE KERNEL_VERSION(2,5,0)
- .use_new_eh_code= 1,
-#endif
-#if LINUX_VERSION_CODE = KERNEL_VERSION(2,4,20)LINUX_VERSION_CODE
KERNEL_VERSION(2,5,0)
-.highmem_io = 1,
-#endif
};
@@ -731,7 +707,7 @@ ips_release(struct Scsi_Host *sh)
/* free IRQ */
free_irq(ha-irq, ha);
- IPS_REMOVE_HOST(sh);
+ scsi_remove_host(sh);
scsi_host_put(sh);
ips_released_controllers++;
@@ -813,7 +789,6 @@ int ips_eh_abort(struct scsi_cmnd *SC)
ips_ha_t *ha;
ips_copp_wait_item_t *item;
int ret;
- unsigned long cpu_flags;
struct Scsi_Host *host;
METHOD_TRACE(ips_eh_abort, 1);
@@ -830,7 +805,7 @@ int ips_eh_abort(struct scsi_cmnd *SC)
if (!ha-active)
return (FAILED);
- IPS_LOCK_SAVE(host-host_lock, cpu_flags);
+ spin_lock(host-host_lock);
/* See if the command is on the copp queue */
item = ha-copp_waitlist.head;
@@ -851,7 +826,7 @@ int ips_eh_abort(struct scsi_cmnd *SC)
ret = (FAILED);
}
- IPS_UNLOCK_RESTORE(host-host_lock, cpu_flags);
+ spin_unlock(host-host_lock);
return ret;
}
@@ -1176,18 +1151,10 @@ static int ips_queue(struct scsi_cmnd *S
/* Set bios geometry for the controller */
/* */
//
-static int
-#if LINUX_VERSION_CODE KERNEL_VERSION(2,5,0)
-ips_biosparam(Disk * disk, kdev_t dev, int geom[])
-{
- ips_ha_t *ha = (ips_ha_t *) disk-device-host-hostdata;
- unsigned long capacity = disk-capacity;
-#else
-ips_biosparam(struct scsi_device *sdev, struct block_device *bdev,
- sector_t capacity, int geom[])
+static int ips_biosparam(struct scsi_device *sdev, struct block_device *bdev,
+sector_t capacity, int geom[])
{
ips_ha_t *ha = (ips_ha_t *) sdev-host-hostdata;
-#endif
int heads;
int sectors;
int cylinders;
@@ -1225,70 +1192,6 @@ ips_biosparam(struct scsi_device *sdev,
return (0);
}
-#if LINUX_VERSION_CODE KERNEL_VERSION(2,5,0)
-
-/* ips_proc24_info is a wrapper around ips_proc_info *
- * for compatibility with the 2.4 scsi parameters*/
-static int
-ips_proc24_info(char *buffer, char **start, off_t offset, int length,
- int hostno, int func)
-{
- int i;
-
- for (i = 0; i ips_next_controller; i++) {
- if (ips_sh[i] ips_sh[i]-host_no == hostno) {
- return ips_proc_info(ips_sh[i], buffer, start,
-offset, length, func);
- }
- }
- return -EINVAL;
-}
-
-//
-/*
[patch 22/28] drivers/message/i2o/device.c: remove redundant GFP_ATOMIC from kmalloc
From: Satyam Sharma [EMAIL PROTECTED] drivers/message/i2o/device.c:i2o_parm_field_get() unnecessarily passes GFP_ATOMIC (along with GFP_KERNEL) to kmalloc() from a context that is not atomic. Remove the pointless GFP_ATOMIC. Signed-off-by: Satyam Sharma [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- drivers/message/i2o/device.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN drivers/message/i2o/device.c~drivers-message-i2o-devicec-remove-redundant-gfp_atomic-from-kmalloc drivers/message/i2o/device.c --- a/drivers/message/i2o/device.c~drivers-message-i2o-devicec-remove-redundant-gfp_atomic-from-kmalloc +++ a/drivers/message/i2o/device.c @@ -485,7 +485,7 @@ int i2o_parm_field_get(struct i2o_device u8 *resblk; /* 8 bytes for header */ int rc; - resblk = kmalloc(buflen + 8, GFP_KERNEL | GFP_ATOMIC); + resblk = kmalloc(buflen + 8, GFP_KERNEL); if (!resblk) return -ENOMEM; _ - 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 24/28] fix for bugzilla 8426: massive slowdown on SCSI CD/DVD drive connected to mptspi driver
From: Doug Chapman [EMAIL PROTECTED] Patch for: http://bugzilla.kernel.org/show_bug.cgi?id=8426 A recent code cleanup that moved code from mptscsih to mptspi inadvertently change the order some code was called. This caused a massive slowdown (of 150x to 300x) on the CD/DVD drive on the high-end HP Integrity servers. Signed-off-by: Doug Chapman [EMAIL PROTECTED] Cc: Moore, Eric Dean [EMAIL PROTECTED] Cc: James Bottomley [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- drivers/message/fusion/mptspi.c |8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff -puN drivers/message/fusion/mptspi.c~fix-for-bugzilla-8426-massive-slowdown-on-scsi-cd-dvd-drive-connected-to-mptspi-driver drivers/message/fusion/mptspi.c --- a/drivers/message/fusion/mptspi.c~fix-for-bugzilla-8426-massive-slowdown-on-scsi-cd-dvd-drive-connected-to-mptspi-driver +++ a/drivers/message/fusion/mptspi.c @@ -727,13 +727,15 @@ static int mptspi_slave_configure(struct struct _MPT_SCSI_HOST *hd = (struct _MPT_SCSI_HOST *)sdev-host-hostdata; VirtTarget *vtarget = scsi_target(sdev)-hostdata; - int ret = mptscsih_slave_configure(sdev); + int ret; + + mptspi_initTarget(hd, vtarget, sdev); + + ret = mptscsih_slave_configure(sdev); if (ret) return ret; - mptspi_initTarget(hd, vtarget, sdev); - ddvprintk((MYIOC_s_INFO_FMT id=%d min_period=0x%02x max_offset=0x%02x max_width=%d\n, hd-ioc-name, sdev-id, spi_min_period(scsi_target(sdev)), _ - 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 16/28] PCI Error Recovery: Symbios SCSI First Failure
From: Linas Vepstas [EMAIL PROTECTED]
Implement the so-called first failure data capture (FFDC) for the symbios
PCI error recovery. After a PCI error event is reported, the driver
requests that MMIO be enabled. Once enabled, it then reads and dumps
assorted status registers, and concludes by requesting the usual reset
sequence.
(includes a whitespace fix for bad indentation).
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
Cc: Matthew Wilcox [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/scsi/sym53c8xx_2/sym_glue.c | 15 +++
drivers/scsi/sym53c8xx_2/sym_glue.h |1 +
drivers/scsi/sym53c8xx_2/sym_hipd.c | 18 ++
3 files changed, 30 insertions(+), 4 deletions(-)
diff -puN
drivers/scsi/sym53c8xx_2/sym_glue.c~pci-error-recovery-symbios-scsi-first-failure
drivers/scsi/sym53c8xx_2/sym_glue.c
---
a/drivers/scsi/sym53c8xx_2/sym_glue.c~pci-error-recovery-symbios-scsi-first-failure
+++ a/drivers/scsi/sym53c8xx_2/sym_glue.c
@@ -1987,6 +1987,20 @@ static pci_ers_result_t sym2_io_error_de
disable_irq(pdev-irq);
pci_disable_device(pdev);
+ /* Request that MMIO be enabled, so register dump can be taken. */
+ return PCI_ERS_RESULT_CAN_RECOVER;
+}
+
+/**
+ * sym2_io_slot_dump -- Enable MMIO and dump debug registers
+ * @pdev: pointer to PCI device
+ */
+static pci_ers_result_t sym2_io_slot_dump(struct pci_dev *pdev)
+{
+ struct sym_hcb *np = pci_get_drvdata(pdev);
+
+ sym_dump_registers(np);
+
/* Request a slot reset. */
return PCI_ERS_RESULT_NEED_RESET;
}
@@ -2241,6 +2255,7 @@ MODULE_DEVICE_TABLE(pci, sym2_id_table);
static struct pci_error_handlers sym2_err_handler = {
.error_detected = sym2_io_error_detected,
+ .mmio_enabled = sym2_io_slot_dump,
.slot_reset = sym2_io_slot_reset,
.resume = sym2_io_resume,
};
diff -puN
drivers/scsi/sym53c8xx_2/sym_glue.h~pci-error-recovery-symbios-scsi-first-failure
drivers/scsi/sym53c8xx_2/sym_glue.h
---
a/drivers/scsi/sym53c8xx_2/sym_glue.h~pci-error-recovery-symbios-scsi-first-failure
+++ a/drivers/scsi/sym53c8xx_2/sym_glue.h
@@ -270,5 +270,6 @@ void sym_xpt_async_bus_reset(struct sym_
void sym_xpt_async_sent_bdr(struct sym_hcb *np, int target);
int sym_setup_data_and_start (struct sym_hcb *np, struct scsi_cmnd *csio,
struct sym_ccb *cp);
void sym_log_bus_error(struct sym_hcb *np);
+void sym_dump_registers(struct sym_hcb *np);
#endif /* SYM_GLUE_H */
diff -puN
drivers/scsi/sym53c8xx_2/sym_hipd.c~pci-error-recovery-symbios-scsi-first-failure
drivers/scsi/sym53c8xx_2/sym_hipd.c
---
a/drivers/scsi/sym53c8xx_2/sym_hipd.c~pci-error-recovery-symbios-scsi-first-failure
+++ a/drivers/scsi/sym53c8xx_2/sym_hipd.c
@@ -1180,10 +1180,10 @@ static void sym_log_hard_error(struct sy
scr_to_cpu((int) *(u32 *)(script_base + script_ofs)));
}
-printf (%s: regdump:, sym_name(np));
-for (i=0; i24;i++)
-printf ( %02x, (unsigned)INB_OFF(np, i));
-printf (.\n);
+ printf(%s: regdump:, sym_name(np));
+ for (i = 0; i 24; i++)
+ printf( %02x, (unsigned)INB_OFF(np, i));
+ printf(.\n);
/*
* PCI BUS error.
@@ -1192,6 +1192,16 @@ static void sym_log_hard_error(struct sy
sym_log_bus_error(np);
}
+void sym_dump_registers(struct sym_hcb *np)
+{
+ u_short sist;
+ u_char dstat;
+
+ sist = INW(np, nc_sist);
+ dstat = INB(np, nc_dstat);
+ sym_log_hard_error(np, sist, dstat);
+}
+
static struct sym_chip sym_dev_table[] = {
{PCI_DEVICE_ID_NCR_53C810, 0x0f, 810, 4, 8, 4, 64,
FE_ERL}
_
-
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] tgt: fix a rdma indirect transfer error bug
This sets sg_dma_len to a proper value.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
drivers/scsi/libsrp.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/libsrp.c b/drivers/scsi/libsrp.c
index 5631c19..732446e 100644
--- a/drivers/scsi/libsrp.c
+++ b/drivers/scsi/libsrp.c
@@ -254,6 +254,7 @@ static int srp_indirect_data(struct scsi
sg_init_one(dummy, md, id-table_desc.len);
sg_dma_address(dummy) = token;
+ sg_dma_len(dummy) = id-table_desc.len;
err = rdma_io(sc, dummy, 1, id-table_desc, 1, DMA_TO_DEVICE,
id-table_desc.len);
if (err) {
--
1.4.3.2
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 14/28] scsi: fix CONFIG_SCSI_WAIT_SCAN=m
On Thu, 10 May 2007, [EMAIL PROTECTED] wrote: From: Hugh Dickins [EMAIL PROTECTED] CONFIG_MODULES=y CONFIG_SCSI=y CONFIG_SCSI_SCAN_ASYNC=y CONFIG_SCSI_WAIT_SCAN=m 2.6.21-rc5-mm2 VFS panics unable to find my root on /dev/sda2, but boots okay if I change drivers/scsi/Kconfig to default y instead of default m for SCSI_WAIT_SCAN. Make sure there's a late_initcall to scsi_complete_async_scans when it's built in, so a monolithic SCSI_SCAN_ASYNC kernel can rely on the scans being completed before trying to mount root, even if they're slow. Thanks for sending this through to James again, Andrew. I'd been gearing up to report it to the regression police: it's certainly still a problem in 2.6.21-git. [EMAIL PROTECTED]: build fixes] Signed-off-by: Hugh Dickins [EMAIL PROTECTED] Cc: James Bottomley [EMAIL PROTECTED] --- James sayeth This isn't the right fix ... this has to be invoked last in the call sequence ... I can't see another way of doing this except yet another file added as a final component to the link. I didn't reply to James' mail at the time, hoping the right fix was about to follow. I don't see what's wrong with the late_initcall myself. Hugh Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- drivers/scsi/scsi_scan.c |9 + 1 file changed, 9 insertions(+) diff -puN drivers/scsi/scsi_scan.c~scsi-fix-config_scsi_wait_scan=m drivers/scsi/scsi_scan.c --- a/drivers/scsi/scsi_scan.c~scsi-fix-config_scsi_wait_scan=m +++ a/drivers/scsi/scsi_scan.c @@ -184,6 +184,15 @@ int scsi_complete_async_scans(void) /* Only exported for the benefit of scsi_wait_scan */ EXPORT_SYMBOL_GPL(scsi_complete_async_scans); +#ifndef MODULE +/* + * For async scanning we need to wait for all the scans to complete before + * trying to mount the root fs. Otherwise non-modular drivers may not be ready + * yet. + */ +late_initcall(scsi_complete_async_scans); +#endif + /** * scsi_unlock_floptical - unlock device via a special MODE SENSE command * @sdev:scsi device to send command to _ - 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 18/28] scsi/lpfc/lpfc_init.c: remove unused variable
ACK -- james s [EMAIL PROTECTED] wrote: From: Adrian Bunk [EMAIL PROTECTED] Signed-off-by: Adrian Bunk [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- drivers/scsi/lpfc/lpfc_init.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN drivers/scsi/lpfc/lpfc_init.c~scsi-lpfc-lpfc_initc-remove-unused-variable drivers/scsi/lpfc/lpfc_init.c --- a/drivers/scsi/lpfc/lpfc_init.c~scsi-lpfc-lpfc_initc-remove-unused-variable +++ a/drivers/scsi/lpfc/lpfc_init.c @@ -1512,7 +1512,7 @@ lpfc_pci_probe_one(struct pci_dev *pdev, struct lpfc_sli *psli; struct lpfc_iocbq *iocbq_entry = NULL, *iocbq_next = NULL; unsigned long bar0map_len, bar2map_len; - int error = -ENODEV, retval; + int error = -ENODEV; int i; uint16_t iotag; _ - 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: [patch 11/28] Use unchecked_isa_dma in sd_revalidate_disk()
On Thu, 2007-05-10 at 23:00 -0700, [EMAIL PROTECTED] wrote: From: Bernhard Walle [EMAIL PROTECTED] In sd_revalidate_disk(), the SCSI Disk driver needs a few bytes DMA memory, allocated by kmalloc() and __GFP_DMA. This patch uses __GFP_DMA only if the corresponding host structure has unchecked_isa_dma set. OK, now we have the Mike Christie fix that actually bounces our submission paths correctly, we can really eliminate all the GFP_DMA buffer allocations in the ULDs ... so this isn't really the right fix. 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 09/28] SCSI: Fix obvious typo spin_lock_irqrestore() in gdth.c
On Thu, 2007-05-10 at 23:00 -0700, [EMAIL PROTECTED] wrote: From: Robert P. J. Day [EMAIL PROTECTED] Fix misspelled spin_lock_irqrestore to read spin_unlock_irqrestore instead. Presumably, GDTH_RTC doesn't get used a lot. I can't actually find a way to get the driver compiled with GDTH_RTC. Achim, Is it dead code and therefore can it be removed? 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 25/28] Fix old SCSI adapter crashes with CD-ROM (take 2)
On Thu, 2007-05-10 at 23:01 -0700, [EMAIL PROTECTED] wrote: From: Alan Cox [EMAIL PROTECTED] The CD-ROM layer doesn't bounce requests for old ISA controllers (and nor should it). However they get injected into the SCSI layer via sr_ioctl which also doesn't bounce them and SCSI then passes the buffer along to a device with unchecked_isa_dma set which either panics or truncates the buffer to 24bits. According to Jens the right long term fix is for the CD layer to route the requests differently but in the mean time this has been tested by a victim and verified to sort the problem out. For the other 99.9% of users it's a no-op and doesn't bounce data. (akpm: placeholder fix. Apparently the metaphorical Mike is working on a real fix). No, we fixed this in a different way ... the fix should already be in git 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]: Fix old SCSI adapter crashes with CD-ROM
On Tue, 2007-05-08 at 17:03 +0100, Alan Cox wrote: The CD-ROM layer doesn't bounce requests for old ISA controllers (and nor should it). However they get injected into the SCSI layer via sr_ioctl which also doesn't bounce them and SCSI then passes the buffer along to a device with unchecked_isa_dma set which either panics or truncates the buffer to 24bits. According to Jens the right long term fix is for the CD layer to route the requests differently but in the mean time this has been tested by a victim and verified to sort the problem out. For the other 99.9% of users it's a no-op and doesn't bounce data. OK, the alternative fix for this is in the vanilla tree. Could you make sure it works ... if it does, I think it's a candidate for 2.6.21 stable as well. 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 v2] add bidi support for block pc requests
On Thu, 2007-05-10 at 11:10 -0400, Douglas Gilbert wrote: +#define scsi_resid(cmd) ((cmd)-resid) I have defined resid in the past as a signed (32 bit) integer following the CAM spec. The cases are: - resid=0 : initiator's DMA engine got (or sent?) the number of bytes it expected - resid0 : dxfer_len-resid bytes received, less than expected - resid0 : more bytes received (or could have been) than indicated by dxfer_len Some definitions of resid make it unsigned which rules out the less common resid0 case. Can this case happen? Does it happen in practice? Naturally no more than dxfer_len should be placed in the scatter gather list. Attempted overrun is usually, and correctly in my opinion, treated as a fatal error in most drivers, so for them the resid 0 case can never happen. SPI and SAS do not convey dxfer_len (or data direction) to a target in their transport frames. This means that the relevant field in the cdb (e.g. transfer length) dictates how much data a target sends back to an initiator in the case of a read like operation. So that opens up the possibility that dxfer_len and the cdb disagree. Well, actually the drivers do (or those few that pay attention). dxfer_len is used to program the SG lists into the device DMA engine, so drivers can retrieve the actuals from the DMA engine at the end of the transfer and set resid accordingly. FCP does convey dxfer_len and data_direction to a target. So a FCP target can detect a mismatch between this and the cdb and send resid information (either under or over) in its response frame back to the initiator. Alternatively it can treat the over case as an error (fcp3r04.pdf section 9.4.2). iSCSI and SRP? The resid0 case may become more common if a driver or application does not properly take account of protection information being sent together with the requested data. So should we keep resid signed? I don't really see a compelling reason to alter the driver behaviour (at least for those where overrun is fatal). However, since resid is signed in the current structure, it makes sense to propagate that. 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
Proposals to change the way all drivers work with SCSI commands
Right at the moment, we're planning to clean up the way SCSI drivers process commands. The proposals are essentially: 1. Get rid of the now unnecessary map_single path (every command is either zero transfer or scatter/gather) 2. use accessors to manipulate the SG lists (mainly so that we can alter the implementation without affecting the drivers) It strikes me that in all of this, we could also consider doing the DMA mapping inside the mid layer (instead of in every driver). This is essentially what libata is already doing ... leading to confusion in SCSI drivers that use libata for SATA. So what do people think about 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: Proposals to change the way all drivers work with SCSI commands
From: James Bottomley [EMAIL PROTECTED] Subject: Proposals to change the way all drivers work with SCSI commands Date: Fri, 11 May 2007 13:33:41 -0500 Right at the moment, we're planning to clean up the way SCSI drivers process commands. The proposals are essentially: 1. Get rid of the now unnecessary map_single path (every command is either zero transfer or scatter/gather) 2. use accessors to manipulate the SG lists (mainly so that we can alter the implementation without affecting the drivers) It strikes me that in all of this, we could also consider doing the DMA mapping inside the mid layer (instead of in every driver). This is essentially what libata is already doing ... leading to confusion in SCSI drivers that use libata for SATA. Several drivers don't take account of the mapping failure and handling the failure for some is tricky. So it would be nice if the mid layer takes care about the mapping. - 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: Proposals to change the way all drivers work with SCSI commands
James Bottomley wrote: Right at the moment, we're planning to clean up the way SCSI drivers process commands. The proposals are essentially: 1. Get rid of the now unnecessary map_single path (every command is either zero transfer or scatter/gather) 2. use accessors to manipulate the SG lists (mainly so that we can alter the implementation without affecting the drivers) It strikes me that in all of this, we could also consider doing the DMA mapping inside the mid layer (instead of in every driver). This is essentially what libata is already doing ... leading to confusion in SCSI drivers that use libata for SATA. My eyes are crossed :) How does doing DMA mapping in the mid layer lead to confusion in SCSI drivers that use libata for SATA? Are you talking about aic94xx and ipr only, or other drivers? Jeff - 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: Proposals to change the way all drivers work with SCSI commands
On Fri, 2007-05-11 at 15:15 -0400, Jeff Garzik wrote: James Bottomley wrote: Right at the moment, we're planning to clean up the way SCSI drivers process commands. The proposals are essentially: 1. Get rid of the now unnecessary map_single path (every command is either zero transfer or scatter/gather) 2. use accessors to manipulate the SG lists (mainly so that we can alter the implementation without affecting the drivers) It strikes me that in all of this, we could also consider doing the DMA mapping inside the mid layer (instead of in every driver). This is essentially what libata is already doing ... leading to confusion in SCSI drivers that use libata for SATA. My eyes are crossed :) How does doing DMA mapping in the mid layer lead to confusion in SCSI drivers that use libata for SATA? Are you talking about aic94xx and ipr only, or other drivers? Those are the only two that use libata for SATA, yes. aic94xx is horrible in this regard ... it has to try to distinguish STP commands that come from libsas (and thus aren't mapped) from ones that come from libata which are ... and it still doesn't get it entirely right. 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: Proposals to change the way all drivers work with SCSI commands
From: James Bottomley [EMAIL PROTECTED] Date: Fri, 11 May 2007 13:33:41 -0500 Right at the moment, we're planning to clean up the way SCSI drivers process commands. The proposals are essentially: 1. Get rid of the now unnecessary map_single path (every command is either zero transfer or scatter/gather) 2. use accessors to manipulate the SG lists (mainly so that we can alter the implementation without affecting the drivers) It strikes me that in all of this, we could also consider doing the DMA mapping inside the mid layer (instead of in every driver). This is essentially what libata is already doing ... leading to confusion in SCSI drivers that use libata for SATA. So what do people think about this? This would require platforms to handle all of their bus types behind the generic dma_*() and that's isn't true everywhere yet. For example, SBUS still requires explicitly using sbus_map_sg() etc. I plan to fix that of course, but we're not there now. - 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: Proposals to change the way all drivers work with SCSI commands
James Bottomley wrote: On Fri, 2007-05-11 at 15:15 -0400, Jeff Garzik wrote: James Bottomley wrote: Right at the moment, we're planning to clean up the way SCSI drivers process commands. The proposals are essentially: 1. Get rid of the now unnecessary map_single path (every command is either zero transfer or scatter/gather) 2. use accessors to manipulate the SG lists (mainly so that we can alter the implementation without affecting the drivers) It strikes me that in all of this, we could also consider doing the DMA mapping inside the mid layer (instead of in every driver). This is essentially what libata is already doing ... leading to confusion in SCSI drivers that use libata for SATA. My eyes are crossed :) How does doing DMA mapping in the mid layer lead to confusion in SCSI drivers that use libata for SATA? Are you talking about aic94xx and ipr only, or other drivers? Those are the only two that use libata for SATA, yes. aic94xx is horrible in this regard ... it has to try to distinguish STP commands that come from libsas (and thus aren't mapped) from ones that come from libata which are ... and it still doesn't get it entirely right. I would lean towards fixing libata to -not- DMA-map for those drivers. Splitting up DMA mapping is ugly. Jeff - 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: Proposals to change the way all drivers work with SCSI commands
On Fri, 2007-05-11 at 13:00 -0700, David Miller wrote: From: James Bottomley [EMAIL PROTECTED] Date: Fri, 11 May 2007 13:33:41 -0500 Right at the moment, we're planning to clean up the way SCSI drivers process commands. The proposals are essentially: 1. Get rid of the now unnecessary map_single path (every command is either zero transfer or scatter/gather) 2. use accessors to manipulate the SG lists (mainly so that we can alter the implementation without affecting the drivers) It strikes me that in all of this, we could also consider doing the DMA mapping inside the mid layer (instead of in every driver). This is essentially what libata is already doing ... leading to confusion in SCSI drivers that use libata for SATA. So what do people think about this? This would require platforms to handle all of their bus types behind the generic dma_*() and that's isn't true everywhere yet. For example, SBUS still requires explicitly using sbus_map_sg() etc. I plan to fix that of course, but we're not there now. I could probably cook up a patch for you, if you like? ... I've already done it for several other architectures. 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: Proposals to change the way all drivers work with SCSI commands
James Bottomley wrote: Right at the moment, we're planning to clean up the way SCSI drivers process commands. The proposals are essentially: 1. Get rid of the now unnecessary map_single path (every command is either zero transfer or scatter/gather) 2. use accessors to manipulate the SG lists (mainly so that we can alter the implementation without affecting the drivers) Should be fine with the old and the new SBP-2 driver. It strikes me that in all of this, we could also consider doing the DMA mapping inside the mid layer (instead of in every driver). This is essentially what libata is already doing ... leading to confusion in SCSI drivers that use libata for SATA. So what do people think about this? The old SBP-2 driver needs the virtual addresses of S/G elements if compiled with a certain config option. This option is meant for use with FireWire controllers which do not implement OHCI-1394, or to run the IEEE 1394 stack in a more secure mode. However, sbp2 seems to be broken in multiple ways with this option at the moment, and I don't plan to fix it anytime soon. So in short, moving the DMA mapping into mid layer should also be fine with the old and the new SBP-2 driver. -- Stefan Richter -=-=-=== -=-= -=-== http://arcgraph.de/sr/ - 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: Proposals to change the way all drivers work with SCSI commands
Kristian Høgsberg wrote: On 5/11/07, Stefan Richter [EMAIL PROTECTED] wrote: James Bottomley wrote: It strikes me that in all of this, we could also consider doing the DMA mapping inside the mid layer (instead of in every driver). ... The old SBP-2 driver needs the virtual addresses of S/G elements if compiled with a certain config option. This option is meant for use with FireWire controllers which do not implement OHCI-1394, or to run the IEEE 1394 stack in a more secure mode. ... Well, if we want to make a more secure mode for fw-sbp2.c where it, like the old driver, manually copies the payload data from the general async receive buffer to the destination, we'll still need the virtual address. Yes, that's right. /If/ we are going to implement such a mode, then (a) the virtual addresses have to be passed down to -queuecommand, and (b) DMA mapping would be unnecessary and wasteful. (For the list: By secure we mean that we wouldn't allow the FireWire controller to act as a bus bridge, and would be able to do boundary checks on local bus addresses which, in the SBP-2 protocol, are generally coming from the _target_. Without such a mode, the lower 4G of the initiator's memory are at the mercy of the target's firmware.) How does the usb storage driver handle this? Kristian -- Stefan Richter -=-=-=== -=-= -=-== http://arcgraph.de/sr/ - 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
