[PATCH 1/2] ch: fix device minor number management bug
Oops, sorry, I sent the patches to linux-kernel...
=
From: FUJITA Tomonori [EMAIL PROTECTED]
Subject: [PATCH 1/2] ch: fix device minor number management bug
ch_probe uses the total number of ch devices as minor.
ch_probe:
ch-minor = ch_devcount;
...
ch_devcount++;
Then ch_remove decreases ch_devcount:
ch_remove:
ch_devcount--;
If you have two ch devices, sch0 and sch1, and remove sch0,
ch_devcount is 1. Then if you add another ch device, ch_probe tries to
create sch1. So you get a warning and fail to create sch1:
Jan 24 16:01:05 nice kernel: sysfs: duplicate filename 'sch1' can not be created
Jan 24 16:01:05 nice kernel: WARNING: at fs/sysfs/dir.c:424 sysfs_add_one()
Jan 24 16:01:05 nice kernel: Pid: 2571, comm: iscsid Not tainted
2.6.24-rc7-ga3d2c2e8-dirty #1
Jan 24 16:01:05 nice kernel:
Jan 24 16:01:05 nice kernel: Call Trace:
Jan 24 16:01:05 nice kernel: [802a22b8] sysfs_add_one+0x54/0xbd
Jan 24 16:01:05 nice kernel: [802a283c] create_dir+0x4f/0x87
Jan 24 16:01:05 nice kernel: [802a28a9] sysfs_create_dir+0x35/0x4a
Jan 24 16:01:05 nice kernel: [803069a1] kobject_get+0x12/0x17
Jan 24 16:01:05 nice kernel: [80306ece] kobject_add+0xf3/0x1a6
Jan 24 16:01:05 nice kernel: [8034252b] class_device_add+0xaa/0x39d
Jan 24 16:01:05 nice kernel: [803428fb] class_device_create+0xcb/0xfa
Jan 24 16:01:05 nice kernel: [80229e09] printk+0x4e/0x56
Jan 24 16:01:05 nice kernel: [802a2054] sysfs_ilookup_test+0x0/0xf
Jan 24 16:01:05 nice kernel: [88022580] :ch:ch_probe+0xbe/0x61a
(snip)
This patch converts ch to use a standard minor number management way,
idr like sg and bsg.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
drivers/scsi/ch.c | 71 +---
1 files changed, 40 insertions(+), 31 deletions(-)
diff --git a/drivers/scsi/ch.c b/drivers/scsi/ch.c
index 765f2fc..2b07014 100644
--- a/drivers/scsi/ch.c
+++ b/drivers/scsi/ch.c
@@ -21,6 +21,7 @@
#include linux/compat.h
#include linux/chio.h/* here are all the ioctls */
#include linux/mutex.h
+#include linux/idr.h
#include scsi/scsi.h
#include scsi/scsi_cmnd.h
@@ -33,6 +34,7 @@
#define CH_DT_MAX 16
#define CH_TYPES8
+#define CH_MAX_DEVS 128
MODULE_DESCRIPTION(device driver for scsi media changer devices);
MODULE_AUTHOR(Gerd Knorr [EMAIL PROTECTED]);
@@ -113,9 +115,8 @@ typedef struct {
struct mutexlock;
} scsi_changer;
-static LIST_HEAD(ch_devlist);
-static DEFINE_SPINLOCK(ch_devlist_lock);
-static int ch_devcount;
+static DEFINE_IDR(ch_index_idr);
+static DEFINE_SPINLOCK(ch_index_lock);
static struct scsi_driver ch_template =
{
@@ -598,20 +599,17 @@ ch_release(struct inode *inode, struct file *file)
static int
ch_open(struct inode *inode, struct file *file)
{
- scsi_changer *tmp, *ch;
+ scsi_changer *ch;
int minor = iminor(inode);
- spin_lock(ch_devlist_lock);
- ch = NULL;
- list_for_each_entry(tmp,ch_devlist,list) {
- if (tmp-minor == minor)
- ch = tmp;
- }
+ spin_lock(ch_index_lock);
+ ch = idr_find(ch_index_idr, minor);
+
if (NULL == ch || scsi_device_get(ch-device)) {
- spin_unlock(ch_devlist_lock);
+ spin_unlock(ch_index_lock);
return -ENXIO;
}
- spin_unlock(ch_devlist_lock);
+ spin_unlock(ch_index_lock);
file-private_data = ch;
return 0;
@@ -914,6 +912,7 @@ static int ch_probe(struct device *dev)
{
struct scsi_device *sd = to_scsi_device(dev);
struct class_device *class_dev;
+ int minor, ret = -ENOMEM;
scsi_changer *ch;
if (sd-type != TYPE_MEDIUM_CHANGER)
@@ -923,7 +922,22 @@ static int ch_probe(struct device *dev)
if (NULL == ch)
return -ENOMEM;
- ch-minor = ch_devcount;
+ if (!idr_pre_get(ch_index_idr, GFP_KERNEL))
+ goto free_ch;
+
+ spin_lock(ch_index_lock);
+ ret = idr_get_new(ch_index_idr, ch, minor);
+ spin_unlock(ch_index_lock);
+
+ if (ret)
+ goto free_ch;
+
+ if (minor CH_MAX_DEVS) {
+ ret = -ENODEV;
+ goto remove_idr;
+ }
+
+ ch-minor = minor;
sprintf(ch-name,ch%d,ch-minor);
class_dev = class_device_create(ch_sysfs_class, NULL,
@@ -932,8 +946,8 @@ static int ch_probe(struct device *dev)
if (IS_ERR(class_dev)) {
printk(KERN_WARNING ch%d: class_device_create failed\n,
ch-minor);
- kfree(ch);
- return PTR_ERR(class_dev);
+ ret = PTR_ERR(class_dev);
+ goto remove_idr;
}
mutex_init(ch-lock);
@@ -942,35 +956,29 @@ static int ch_probe(struct device *dev)
if (init)
ch_init_elem(ch);
+
[PATCH 2/2] ch: remove forward declarations
This moves ch_template and changer_fops structs to the end of file and
removes forward declarations.
This also removes some trailing whitespace.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
drivers/scsi/ch.c | 120 -
1 files changed, 54 insertions(+), 66 deletions(-)
diff --git a/drivers/scsi/ch.c b/drivers/scsi/ch.c
index 2b07014..7aad154 100644
--- a/drivers/scsi/ch.c
+++ b/drivers/scsi/ch.c
@@ -90,16 +90,6 @@ static const char * vendor_labels[CH_TYPES-4] = {
#define MAX_RETRIES 1
-static int ch_probe(struct device *);
-static int ch_remove(struct device *);
-static int ch_open(struct inode * inode, struct file * filp);
-static int ch_release(struct inode * inode, struct file * filp);
-static long ch_ioctl(struct file *filp, unsigned int cmd, unsigned long arg);
-#ifdef CONFIG_COMPAT
-static long ch_ioctl_compat(struct file * filp,
- unsigned int cmd, unsigned long arg);
-#endif
-
static struct class * ch_sysfs_class;
typedef struct {
@@ -118,27 +108,6 @@ typedef struct {
static DEFINE_IDR(ch_index_idr);
static DEFINE_SPINLOCK(ch_index_lock);
-static struct scsi_driver ch_template =
-{
- .owner = THIS_MODULE,
- .gendrv = {
- .name = ch,
- .probe = ch_probe,
- .remove = ch_remove,
- },
-};
-
-static const struct file_operations changer_fops =
-{
- .owner = THIS_MODULE,
- .open = ch_open,
- .release= ch_release,
- .unlocked_ioctl = ch_ioctl,
-#ifdef CONFIG_COMPAT
- .compat_ioctl = ch_ioctl_compat,
-#endif
-};
-
static const struct {
unsigned char sense;
unsigned char asc;
@@ -207,7 +176,7 @@ ch_do_scsi(scsi_changer *ch, unsigned char *cmd,
{
int errno, retries = 0, timeout, result;
struct scsi_sense_hdr sshdr;
-
+
timeout = (cmd[0] == INITIALIZE_ELEMENT_STATUS)
? timeout_init : timeout_move;
@@ -245,7 +214,7 @@ static int
ch_elem_to_typecode(scsi_changer *ch, u_int elem)
{
int i;
-
+
for (i = 0; i CH_TYPES; i++) {
if (elem = ch-firsts[i]
elem ch-firsts[i] +
@@ -261,15 +230,15 @@ ch_read_element_status(scsi_changer *ch, u_int elem, char
*data)
u_char cmd[12];
u_char *buffer;
int result;
-
+
buffer = kmalloc(512, GFP_KERNEL | GFP_DMA);
if(!buffer)
return -ENOMEM;
-
+
retry:
memset(cmd,0,sizeof(cmd));
cmd[0] = READ_ELEMENT_STATUS;
- cmd[1] = (ch-device-lun 5) |
+ cmd[1] = (ch-device-lun 5) |
(ch-voltags ? 0x10 : 0) |
ch_elem_to_typecode(ch,elem);
cmd[2] = (elem 8) 0xff;
@@ -296,7 +265,7 @@ ch_read_element_status(scsi_changer *ch, u_int elem, char
*data)
return result;
}
-static int
+static int
ch_init_elem(scsi_changer *ch)
{
int err;
@@ -322,7 +291,7 @@ ch_readconfig(scsi_changer *ch)
buffer = kzalloc(512, GFP_KERNEL | GFP_DMA);
if (!buffer)
return -ENOMEM;
-
+
memset(cmd,0,sizeof(cmd));
cmd[0] = MODE_SENSE;
cmd[1] = ch-device-lun 5;
@@ -365,7 +334,7 @@ ch_readconfig(scsi_changer *ch)
} else {
vprintk(reading element address assigment page failed!\n);
}
-
+
/* vendor specific element types */
for (i = 0; i 4; i++) {
if (0 == vendor_counts[i])
@@ -443,7 +412,7 @@ static int
ch_position(scsi_changer *ch, u_int trans, u_int elem, int rotate)
{
u_char cmd[10];
-
+
dprintk(position: 0x%x\n,elem);
if (0 == trans)
trans = ch-firsts[CHET_MT];
@@ -462,7 +431,7 @@ static int
ch_move(scsi_changer *ch, u_int trans, u_int src, u_int dest, int rotate)
{
u_char cmd[12];
-
+
dprintk(move: 0x%x = 0x%x\n,src,dest);
if (0 == trans)
trans = ch-firsts[CHET_MT];
@@ -484,7 +453,7 @@ ch_exchange(scsi_changer *ch, u_int trans, u_int src,
u_int dest1, u_int dest2, int rotate1, int rotate2)
{
u_char cmd[12];
-
+
dprintk(exchange: 0x%x = 0x%x = 0x%x\n,
src,dest1,dest2);
if (0 == trans)
@@ -501,7 +470,7 @@ ch_exchange(scsi_changer *ch, u_int trans, u_int src,
cmd[8] = (dest2 8) 0xff;
cmd[9] = dest20xff;
cmd[10] = (rotate1 ? 1 : 0) | (rotate2 ? 2 : 0);
-
+
return ch_do_scsi(ch, cmd, NULL,0, DMA_NONE);
}
@@ -539,14 +508,14 @@ ch_set_voltag(scsi_changer *ch, u_int elem,
elem, tag);
memset(cmd,0,sizeof(cmd));
cmd[0] = SEND_VOLUME_TAG;
- cmd[1] = (ch-device-lun 5) |
+ cmd[1] = (ch-device-lun 5) |
ch_elem_to_typecode(ch,elem);
cmd[2] = (elem 8) 0xff;
cmd[3] = elem
Re: [BUG] The kernel thread for md RAID1 could cause a md RAID1 array deadlock
Hi, Thank you for the patch. I have applied the patch to 2.6.23.14 and it works well. - In case of 2.6.23.14, the problem is reproduced. - In case of 2.6.23.14 with this patch, raid1 works well so far. The fault injection script continues to run, and it doesn't deadlock. I will keep it running for a while. Also, md raid10 seems to have the same problem. I will test raid10 applying this patch as well. Neil Brown wrote: On Tuesday January 15, [EMAIL PROTECTED] wrote: This message describes the details about md-RAID1 issue found by testing the md RAID1 using the SCSI fault injection framework. Abstract: Both the error handler for md RAID1 and write access request to the md RAID1 use raid1d kernel thread. The nr_pending flag could cause a race condition in raid1d, results in a raid1d deadlock. Thanks for finding and reporting this. I believe the following patch should fix the deadlock. If you are able to repeat your test and confirm this I would appreciate it. Thanks, NeilBrown Fix deadlock in md/raid1 when handling a read error. When handling a read error, we freeze the array to stop any other IO while attempting to over-write with correct data. This is done in the raid1d thread and must wait for all submitted IO to complete (except for requests that failed and are sitting in the retry queue - these are counted in -nr_queue and will stay there during a freeze). However write requests need attention from raid1d as bitmap updates might be required. This can cause a deadlock as raid1 is waiting for requests to finish that themselves need attention from raid1d. So we create a new function 'flush_pending_writes' to give that attention, and call it in freeze_array to be sure that we aren't waiting on raid1d. Thanks to K.Tanaka [EMAIL PROTECTED] for finding and reporting this problem. Cc: K.Tanaka [EMAIL PROTECTED] Signed-off-by: Neil Brown [EMAIL PROTECTED] -- - Kenichi TANAKA| Open Source Software Platform Development Division | Computers Software Operations Unit, NEC Corporation | [EMAIL PROTECTED] - 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: [Stgt-devel] Performance of SCST versus STGT
On Jan 24, 2008 8:06 AM, Robin Humble [EMAIL PROTECTED] wrote: On Tue, Jan 22, 2008 at 01:32:08PM +0100, Bart Van Assche wrote: . . . STGT read SCST read.STGT read SCST read. . . performance performance . performance performance . . . (0.5K, MB/s) (0.5K, MB/s) . (1 MB MB/s) (1 MB, MB/s) . . . Ethernet (1 Gb/s network) . 77 78 . 77 89 . . IPoIB(8 Gb/s network) . 163185 .201 239 . . iSER (8 Gb/s network) . 250N/A .360 N/A . . SRP (8 Gb/s network) . N/A421 .N/A 683 . how are write speeds with SCST SRP? for some kernels and tests tgt writes at 2x the read speed. also I see much higher speeds that what you report in my DDR 4x IB tgt testing... which could be taken as inferring that tgt is scaling quite nicely on the faster fabric? ib_write_bw of 1473 MB/s ib_read_bw of 1378 MB/s iSER to 7G ramfs, x86_64, centos4.6, 2.6.22 kernels, git tgtd, initiator end booted with mem=512M, target with 8G ram direct i/o dd write/read 800/751 MB/s dd if=/dev/zero of=/dev/sdc bs=1M count=5000 oflag=direct dd of=/dev/null if=/dev/sdc bs=1M count=5000 iflag=direct buffered i/o dd write/read 1109/350 MB/s dd if=/dev/zero of=/dev/sdc bs=1M count=5000 dd of=/dev/null if=/dev/sdc bs=1M count=5000 Hello Robin, The tests I performed were read performance tests with dd and with buffered I/O. For this test you obtained 350 MB/s with STGT on a DDR 4x InfiniBand network, while I obtained 360 MB/s on a SDR 4x InfiniBand network. I don't think that we can call this scaling up ... Regarding write performance: the write tests were performed with a real target (three disks in RAID-0, write bandwidth about 100 MB/s). I did not yet publish these numbers because it is not yet clear to me how much disk writing speed / InfiniBand transfer speed / target write buffering each contribute in the results. The results I obtained in the write tests (dd, buffered I/O) show the same trend as for the read tests: for large data transfers over a Gigabit Ethernet network the results for STGT and SCST are similar. For small transfer sizes (512 bytes) or fast network technology (SRP / iSER) the write performance of SCST is significantly better than that of STGT. Bart. Bart. - 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: Performance of SCST versus STGT
Bart Van Assche wrote: On Jan 24, 2008 8:06 AM, Robin Humble [EMAIL PROTECTED] wrote: On Tue, Jan 22, 2008 at 01:32:08PM +0100, Bart Van Assche wrote: . . . STGT read SCST read.STGT read SCST read. . . performance performance . performance performance . . . (0.5K, MB/s) (0.5K, MB/s) . (1 MB MB/s) (1 MB, MB/s) . . . Ethernet (1 Gb/s network) . 77 78 . 77 89 . . IPoIB(8 Gb/s network) . 163185 .201 239 . . iSER (8 Gb/s network) . 250N/A .360 N/A . . SRP (8 Gb/s network) . N/A421 .N/A 683 . how are write speeds with SCST SRP? for some kernels and tests tgt writes at 2x the read speed. Robin, There is a fundamental difference between regular dd-like reads and writes: reads are sync, i.e. latency sensitive, but writes are async, i.e. latency insensitive. You should use O_DIRECT dd writes for the fair comparison. Vlad - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Stgt-devel] Performance of SCST versus STGT
On Thu, Jan 24, 2008 at 11:36:45AM +0100, Bart Van Assche wrote: On Jan 24, 2008 8:06 AM, Robin Humble [EMAIL PROTECTED] wrote: On Tue, Jan 22, 2008 at 01:32:08PM +0100, Bart Van Assche wrote: . . . STGT read SCST read.STGT read SCST read. . . performance performance . performance performance . . . (0.5K, MB/s) (0.5K, MB/s) . (1 MB MB/s) (1 MB, MB/s) . . . Ethernet (1 Gb/s network) . 77 78 . 77 89 . . IPoIB(8 Gb/s network) . 163185 .201 239 . . iSER (8 Gb/s network) . 250N/A .360 N/A . . SRP (8 Gb/s network) . N/A421 .N/A 683 . how are write speeds with SCST SRP? for some kernels and tests tgt writes at 2x the read speed. also I see much higher speeds that what you report in my DDR 4x IB tgt testing... which could be taken as inferring that tgt is scaling quite nicely on the faster fabric? ib_write_bw of 1473 MB/s ib_read_bw of 1378 MB/s iSER to 7G ramfs, x86_64, centos4.6, 2.6.22 kernels, git tgtd, initiator end booted with mem=512M, target with 8G ram direct i/o dd write/read 800/751 MB/s dd if=/dev/zero of=/dev/sdc bs=1M count=5000 oflag=direct dd of=/dev/null if=/dev/sdc bs=1M count=5000 iflag=direct buffered i/o dd write/read 1109/350 MB/s dd if=/dev/zero of=/dev/sdc bs=1M count=5000 dd of=/dev/null if=/dev/sdc bs=1M count=5000 buffered i/o lmdd write/read 682/438 MB/s lmdd if=internal of=/dev/sdc bs=1M count=5000 lmdd of=internal if=/dev/sdc bs=1M count=5000 The tests I performed were read performance tests with dd and with buffered I/O. For this test you obtained 350 MB/s with STGT on a DDR ... and 1.1GB/s writes :) presumably because buffer aggregation works well. 4x InfiniBand network, while I obtained 360 MB/s on a SDR 4x InfiniBand network. I don't think that we can call this scaling up ... the direct i/o read speed being twice the buffered i/o speed would seem to imply that Linux's page cache is being slow and confused with this particular set of kernel + OS + OFED versions. I doubt that this result actually says that much about tgt really. Regarding write performance: the write tests were performed with a real target (three disks in RAID-0, write bandwidth about 100 MB/s). I I'd be interested to see ramdisk writes. cheers, robin - 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: Performance of SCST versus STGT
On Thu, Jan 24, 2008 at 02:10:06PM +0300, Vladislav Bolkhovitin wrote: On Jan 24, 2008 8:06 AM, Robin Humble [EMAIL PROTECTED] wrote: how are write speeds with SCST SRP? for some kernels and tests tgt writes at 2x the read speed. There is a fundamental difference between regular dd-like reads and writes: reads are sync, i.e. latency sensitive, but writes are async, i.e. latency insensitive. You should use O_DIRECT dd writes for the fair comparison. I agree, although the vast majority of applications don't use O_DIRECT. anwyay, the direct i/o results were in the email: direct i/o dd write/read 800/751 MB/s dd if=/dev/zero of=/dev/sdc bs=1M count=5000 oflag=direct dd of=/dev/null if=/dev/sdc bs=1M count=5000 iflag=direct I couldn't find a direct i/o option for lmdd. cheers, robin - 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: [Stgt-devel] Performance of SCST versus STGT
Robin Humble wrote: On Thu, Jan 24, 2008 at 11:36:45AM +0100, Bart Van Assche wrote: On Jan 24, 2008 8:06 AM, Robin Humble [EMAIL PROTECTED] wrote: On Tue, Jan 22, 2008 at 01:32:08PM +0100, Bart Van Assche wrote: . . . STGT read SCST read.STGT read SCST read. . . performance performance . performance performance . . . (0.5K, MB/s) (0.5K, MB/s) . (1 MB MB/s) (1 MB, MB/s) . . . Ethernet (1 Gb/s network) . 77 78 . 77 89 . . IPoIB(8 Gb/s network) . 163185 .201 239 . . iSER (8 Gb/s network) . 250N/A .360 N/A . . SRP (8 Gb/s network) . N/A421 .N/A 683 . how are write speeds with SCST SRP? for some kernels and tests tgt writes at 2x the read speed. also I see much higher speeds that what you report in my DDR 4x IB tgt testing... which could be taken as inferring that tgt is scaling quite nicely on the faster fabric? ib_write_bw of 1473 MB/s ib_read_bw of 1378 MB/s iSER to 7G ramfs, x86_64, centos4.6, 2.6.22 kernels, git tgtd, initiator end booted with mem=512M, target with 8G ram direct i/o dd write/read 800/751 MB/s dd if=/dev/zero of=/dev/sdc bs=1M count=5000 oflag=direct dd of=/dev/null if=/dev/sdc bs=1M count=5000 iflag=direct buffered i/o dd write/read 1109/350 MB/s dd if=/dev/zero of=/dev/sdc bs=1M count=5000 dd of=/dev/null if=/dev/sdc bs=1M count=5000 buffered i/o lmdd write/read 682/438 MB/s lmdd if=internal of=/dev/sdc bs=1M count=5000 lmdd of=internal if=/dev/sdc bs=1M count=5000 The tests I performed were read performance tests with dd and with buffered I/O. For this test you obtained 350 MB/s with STGT on a DDR ... and 1.1GB/s writes :) presumably because buffer aggregation works well. 4x InfiniBand network, while I obtained 360 MB/s on a SDR 4x InfiniBand network. I don't think that we can call this scaling up ... the direct i/o read speed being twice the buffered i/o speed would seem to imply that Linux's page cache is being slow and confused with this particular set of kernel + OS + OFED versions. I doubt that this result actually says that much about tgt really. Buffered dd read is, actually, one of the best benchmarks if you want to compare STGT vs SCST, because it's single threaded with one outstanding command most of the time, i.e. it's a latency bound workload. Plus, most of the applications reading files do exactly what dd does. Both SCST and STGT suffer equally from possible problems on the initiator, but SCST bears it much better, because it has much less processing latency (e.g., because there are no extra user-kernel spaces switches and other related overhead). Regarding write performance: the write tests were performed with a real target (three disks in RAID-0, write bandwidth about 100 MB/s). I I'd be interested to see ramdisk writes. cheers, robin ___ Stgt-devel mailing list [EMAIL PROTECTED] https://lists.berlios.de/mailman/listinfo/stgt-devel - 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: Performance of SCST versus STGT
Robin Humble wrote: On Thu, Jan 24, 2008 at 02:10:06PM +0300, Vladislav Bolkhovitin wrote: On Jan 24, 2008 8:06 AM, Robin Humble [EMAIL PROTECTED] wrote: how are write speeds with SCST SRP? for some kernels and tests tgt writes at 2x the read speed. There is a fundamental difference between regular dd-like reads and writes: reads are sync, i.e. latency sensitive, but writes are async, i.e. latency insensitive. You should use O_DIRECT dd writes for the fair comparison. I agree, although the vast majority of applications don't use O_DIRECT. Sorry, it isn't about O_DIRECT usage. It's about latency bound or not workload. anwyay, the direct i/o results were in the email: direct i/o dd write/read 800/751 MB/s dd if=/dev/zero of=/dev/sdc bs=1M count=5000 oflag=direct dd of=/dev/null if=/dev/sdc bs=1M count=5000 iflag=direct I couldn't find a direct i/o option for lmdd. cheers, robin - 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: aic94xx: failing on high load
On Mon, Jan 14, 2008 at 04:04:21PM -0600, James Bottomley wrote: On Mon, 2008-01-14 at 22:03 +0100, Vojtech Pavlik wrote: On Mon, Jan 14, 2008 at 02:03:45PM -0600, James Bottomley wrote: On Mon, 2008-01-14 at 11:45 -0800, Darrick J. Wong wrote: On Mon, Jan 14, 2008 at 03:49:16PM +0100, Jan Sembera wrote: Hi, we have array of 16 SAS disks connected to Adaptec controllers ... this elsewhere and I was recommended to send it to linux-scsi. Hmm... I think Peter Bogdanovic was hitting this error recently (cc'd). There are a lot of PRIMITIVE_RECVD messages in the log, which make me wonder if the expander is being flaky or something? The commands that start timing out under heavy load followed by the repeated broadcasts might be indicative of that, since the sequencer firmware and the kernel driver are up to date. Unfortunately, I don't have any LSI expanders... I do, and actually, I've seen behaviour like this, except on a SATAPI DVD not a disk. What seems to happen is that the expander hangs up on the device and I can't recover it except by power cycling the expander (other devices on the expander continue to work normally). It'd be rather hard to power cycle the 16-drive backplane with dual LSISASx28 expanders in this server without bringing the rest of the system down. If the backplane was as flaky as you suggest, I doubt anyone could use these machines in production, even under other OSs ... I'm merely telling you what I see in my LSI expanders. However, one of the characteristics is that I can't get any response even to a hard reset on the port (that's echo 1 /sys/class/sas_phy/phy/hard_reset) if it is the same problem. This one doesn't help either. However, we borrowed another controller, only this time from LSI and therefore using another driver and this controller has worked without issues and complains for two days (our previous error occured after about 1 or 2 hours of heavy workload). So it really seems this is some kind of adaptec vs. expander incompatibility (in firmware?) or driver bug. The problem is (if it is the same problem) there isn't any defined error recovery from this ... the standards don't contain an expander reset, and the expander isn't responding to the phy reset (either hard or soft). So I'm not sure what can be done at this point. In our last test run, we've received some more errors, but this time the system recovered and actually finished the test load: It could just be a simple failure in the error handler then. libsas implements its own, so I bet there are a few corner cases ... I'm not sure about that unfortunately, I tried to do some digging into the aic94xx driver, but it's way out of my league. We'll have those Adaptec controllers available for some period of time (weeks maybe?) for ebugging, but when we go production with this machine, we'll have to replace them with LSI controllers and we won't be able to contribute to finding the solution of this problems any longer. We've tried new adaptec firmware shipped with SLES and we got ourselves new error string that appears just above error messages that you have seen before and that were attached to the original message: kernel: aic94xx: escb_tasklet_complete: REQ_TASK_ABORT, reason=0x6 kernel: aic94xx: escb_tasklet_complete: Can't find task (tc=71) to abort! Do you think they have any significance? Best regards -- Jan Sembera Linux Administrator - SUSE LINUX, s. r. o.e-mail: [EMAIL PROTECTED] Lihovarská 1060/12 tel: +420 284 028 981 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ - 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] aacraid: fib context lock for management ioctls
Alan noticed the lack of locking surrounding the driver's dealings with the fib
context managed by the trio of ioctls that are used by the RAID management
applications to retrieve Adapter Initiated FIBs. I merely expanded the fib lock
to include the fib context. There have been no field reports of any issues
generally because the applications are relatively static and do not come and go
often enough to stress this area. I bloated this patch a little with some space
junk.
This attached patch is against current scsi-misc-2.6.
ObligatoryDisclaimer: Please accept my condolences regarding Outlook's handling
of patch attachments. The following inline patch is 'diff -rub' to pull out the
space junk to enable convenient inspection, please use the attached file to
patch.
Signed-off-by: Mark Salyzyn [EMAIL PROTECTED]
drivers/scsi/aacraid/commctrl.c | 29 +
1 file changed, 17 insertions(+), 12 deletions(-)
diff -rub a/commctrl.c b/commctrl.c
--- a/drivers/scsi/aacraid/commctrl.c2008-01-24 09:44:33.080806785 -0500
+++ b/drivers/scsi/aacraid/commctrl.c2008-01-24 09:50:41.071552674 -0500
@@ -243,6 +243,7 @@
* Search the list of AdapterFibContext addresses on the adapter
* to be sure this is a valid address
*/
+ spin_lock_irqsave(dev-fib_lock, flags);
entry = dev-fib_list.next;
fibctx = NULL;
@@ -258,17 +259,18 @@
fibctx = NULL;
}
if (!fibctx) {
+ spin_unlock_irqrestore(dev-fib_lock, flags);
dprintk ((KERN_INFO Fib Context not found\n));
return -EINVAL;
}
if((fibctx-type != FSAFS_NTC_GET_ADAPTER_FIB_CONTEXT) ||
(fibctx-size != sizeof(struct aac_fib_context))) {
+ spin_unlock_irqrestore(dev-fib_lock, flags);
dprintk ((KERN_INFO Fib Context corrupt?\n));
return -EINVAL;
}
status = 0;
- spin_lock_irqsave(dev-fib_lock, flags);
/*
* If there are no fibs to send back, then either wait or return
* -EAGAIN
@@ -326,7 +328,9 @@
int aac_close_fib_context(struct aac_dev * dev, struct aac_fib_context *
fibctx)
{
struct fib *fib;
+ unsigned long flags;
+ spin_lock_irqsave(dev-fib_lock, flags);
/*
* First free any FIBs that have not been consumed.
*/
@@ -349,6 +353,7 @@
* Remove the Context from the AdapterFibContext List
*/
list_del(fibctx-next);
+ spin_unlock_irqrestore(dev-fib_lock, flags);
/*
* Invalidate context
*/
Sincerely - Mark Salyzyn
aacraid_fibctx_lock.patch
Description: aacraid_fibctx_lock.patch
Re: [Stgt-devel] Performance of SCST versus STGT
On Jan 24, 2008 8:06 AM, Robin Humble [EMAIL PROTECTED] wrote: On Tue, Jan 22, 2008 at 01:32:08PM +0100, Bart Van Assche wrote: . . . STGT read SCST read.STGT read SCST read. . . performance performance . performance performance . . . (0.5K, MB/s) (0.5K, MB/s) . (1 MB MB/s) (1 MB, MB/s) . . . Ethernet (1 Gb/s network) . 77 78 . 77 89 . . IPoIB(8 Gb/s network) . 163185 .201 239 . . iSER (8 Gb/s network) . 250N/A .360 N/A . . SRP (8 Gb/s network) . N/A421 .N/A 683 . Results with /dev/ram0 configured as backing store on the target (buffered I/O): Read Write Read Write performance performance performance performance (0.5K, MB/s) (0.5K, MB/s) (1 MB, MB/s) (1 MB, MB/s) STGT + iSER 250 48 349 781 SCST + SRP411 66 659 746 Results with /dev/ram0 configured as backing store on the target (direct I/O): Read Write Read Write performance performance performance performance (0.5K, MB/s) (0.5K, MB/s) (1 MB, MB/s) (1 MB, MB/s) STGT + iSER 7.9 9.8 589 647 SCST + SRP 12.3 9.7 811 794 Bart. - 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
qla_sup.c: compilation warning
With gcc 4.1.2 on fedora7 x86_64, cross compiling an i386 kernel i get the following compilation warning: CC [M] drivers/scsi/qla2xxx/qla_sup.o /usr0/export/dev/bharrosh/git/pub/scsi-misc/drivers/scsi/qla2xxx/qla_sup.c: In function ‘qla2x00_beacon_blink’: /usr0/export/dev/bharrosh/git/pub/scsi-misc/drivers/scsi/qla2xxx/qla_sup.c:906: warning: cast to pointer from integer of different size /usr0/export/dev/bharrosh/git/pub/scsi-misc/drivers/scsi/qla2xxx/qla_sup.c: In function ‘qla2x00_beacon_on’: /usr0/export/dev/bharrosh/git/pub/scsi-misc/drivers/scsi/qla2xxx/qla_sup.c:966: warning: cast to pointer from integer of different size /usr0/export/dev/bharrosh/git/pub/scsi-misc/drivers/scsi/qla2xxx/qla_sup.c: In function ‘qla2x00_read_flash_byte’: /usr0/export/dev/bharrosh/git/pub/scsi-misc/drivers/scsi/qla2xxx/qla_sup.c:1247: warning: cast to pointer from integer of different size /usr0/export/dev/bharrosh/git/pub/scsi-misc/drivers/scsi/qla2xxx/qla_sup.c: In function ‘qla2x00_write_flash_byte’: /usr0/export/dev/bharrosh/git/pub/scsi-misc/drivers/scsi/qla2xxx/qla_sup.c:1307: warning: cast to pointer from integer of different size Perhaps the compiler is right this time ? configured with: make ARCH=i386 allmodconfig Boaz - 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: usb-storage-set-last-sector-bug-flag.patch
Greg KH wrote: I just am worried that we are now suddenly keeping access from the last sector for devices that currently did work just fine. This new workaround doesn't prevent access to the last sector. It only breaks up a multi-sector access which would also reach the last sector into several (two? I'm too lazy to look back in the mail thread) accesses, in order to access the last sector in a dedicated single-sector access. So that's very differently to the fix-capacity workaround. The fix-capacity workaround manipulates the READ CAPACITY parameter data. Therefore the fix-capacity workaround is unsafe for non-buggy devices. The last-sector-(access-)bug workaround _only_ modifies the command stream which is sent to the device. A dangerous command is replaced by equivalent safe commands. These commands are luckily safe for _all_ devices, buggy and non-buggy ones. The only cost of this workaround is (1.) the code, (2.) the runtime/ bandwidth/ latency overhead for accesses which reach the last sector. Somebody correct me if I got something wrong. -- 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
Unexpected IRQ trap when reloading mptspi with MSI
I get unexpected IRQ trap at vector dd when reloading mptspi with MSI
enabled. This seems to happen only on dual-channel HBAs; single-channel
HBAs are unaffected. It looks like the second channel is generating a
bogus MSI interrupt while the first channel is being brought up.
modprobe mpt_base mpt_msi_enable=1
Jan 24 11:09:16 kernel: Fusion MPT base driver 3.04.06
Jan 24 11:09:16 kernel: Copyright (c) 1999-2007 LSI Corporation
modprobe mptspi
Jan 24 11:09:36 kernel: Fusion MPT SPI Host driver 3.04.06
Jan 24 11:09:36 kernel: ACPI: PCI Interrupt :03:04.0[A] - GSI 22 (level,
low) - IRQ 19
Jan 24 11:09:36 kernel: mptbase: ioc0: Initiating bringup
Jan 24 11:09:37 kernel: ioc0: LSI53C1030T A0: Capabilities={Initiator,Target}
Jan 24 11:09:37 kernel: mptbase: ioc0: PCI-MSI enabled
Jan 24 11:09:37 kernel: scsi0 : ioc0: LSI53C1030T A0, FwRev=01032700h, Ports=1,
MaxQ=255, IRQ=222
Jan 24 11:09:42 kernel: ACPI: PCI Interrupt :03:04.1[B] - GSI 23 (level,
low) - IRQ 20
Jan 24 11:09:42 kernel: mptbase: ioc1: Initiating bringup
Jan 24 11:09:42 kernel: ioc1: LSI53C1030T A0: Capabilities={Initiator,Target}
Jan 24 11:09:42 kernel: mptbase: ioc1: PCI-MSI enabled
Jan 24 11:09:43 kernel: scsi1 : ioc1: LSI53C1030T A0, FwRev=01032700h, Ports=1,
MaxQ=255, IRQ=221
rmmod mptspi
modprobe mptspi
Jan 24 11:11:05 kernel: Fusion MPT SPI Host driver 3.04.06
Jan 24 11:11:05 kernel: mptbase: ioc2: Initiating bringup
Jan 24 11:11:05 kernel: ioc2: LSI53C1030T A0: Capabilities={Initiator,Target}
Jan 24 11:11:05 kernel: mptbase: ioc2: PCI-MSI enabled
Jan 24 11:11:06 kernel: irq 221, desc: c03a9c00, depth: 0, count: 45,
unhandled: 0
Jan 24 11:11:06 kernel: -handle_irq(): c01400b0, handle_bad_irq+0x0/0x290
Jan 24 11:11:06 kernel: -chip(): c03873c0, 0xc03873c0
Jan 24 11:11:06 kernel: -action():
Jan 24 11:11:06 kernel: IRQ_DISABLED set
Jan 24 11:11:06 kernel: unexpected IRQ trap at vector dd
Jan 24 11:11:06 kernel: scsi2 : ioc2: LSI53C1030T A0, FwRev=01032700h, Ports=1,
MaxQ=255, IRQ=222
Jan 24 11:11:10 kernel: mptbase: ioc3: Initiating bringup
Jan 24 11:11:11 kernel: ioc3: LSI53C1030T A0: Capabilities={Initiator,Target}
Jan 24 11:11:11 kernel: mptbase: ioc3: PCI-MSI enabled
Jan 24 11:11:11 kernel: scsi3 : ioc3: LSI53C1030T A0, FwRev=01032700h, Ports=1,
MaxQ=255, IRQ=221
uname -a
Linux monster 2.6.24-rc8-git7 #1 SMP Thu Jan 24 11:26:53 EST 2008 i686 unknown
cat /proc/mpt/ioc0/info
ioc0:
ProductID = 0x020b (LSI53C1030T A0)
FWVersion = 0x01032700 (fw_size=42804)
MsgVersion = 0x0102
FirstWhoInit = 0x00
EventState = 0x01
CurrentHostMfaHighAddr = 0x
CurrentSenseBufferHighAddr = 0x
MaxChainDepth = 0x30 frames
MinBlockSize = 0x20 bytes
RequestFrames @ 0xf6402800 (Dma @ 0x36402800)
{CurReqSz=96} x {CurReqDepth=255} = 24480 bytes ^= 0x7000
{MaxReqSz=96} {MaxReqDepth=255}
Frames @ 0xf640 (Dma @ 0x3640)
{CurRepSz=80} x {CurRepDepth=128} = 10240 bytes ^= 0x2880
{MaxRepSz=0} {MaxRepDepth=511}
MaxDevices = 16
MaxBuses = 1
PortNumber = 1 (of 1)
cat /proc/mpt/ioc1/info
ioc1:
ProductID = 0x020b (LSI53C1030T A0)
FWVersion = 0x01032700 (fw_size=42804)
MsgVersion = 0x0102
FirstWhoInit = 0x00
EventState = 0x01
CurrentHostMfaHighAddr = 0x
CurrentSenseBufferHighAddr = 0x
MaxChainDepth = 0x30 frames
MinBlockSize = 0x20 bytes
RequestFrames @ 0xf6442800 (Dma @ 0x36442800)
{CurReqSz=96} x {CurReqDepth=255} = 24480 bytes ^= 0x7000
{MaxReqSz=96} {MaxReqDepth=255}
Frames @ 0xf644 (Dma @ 0x3644)
{CurRepSz=80} x {CurRepDepth=128} = 10240 bytes ^= 0x2880
{MaxRepSz=0} {MaxRepDepth=511}
MaxDevices = 16
MaxBuses = 1
PortNumber = 1 (of 1)
cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
0:129 0 0 1 IO-APIC-edge timer
1:125 0 0 1 IO-APIC-edge i8042
3: 14 0 0 1 IO-APIC-edge serial
8: 0 0 0 0 IO-APIC-edge rtc
9: 0 0 0 0 IO-APIC-fasteoi acpi
10: 0 0 0 23 IO-APIC-fasteoi
ehci_hcd:usb1, ohci_hcd:usb2, ohci_hcd:usb3
12: 1 0 0 2 IO-APIC-edge i8042
14:432 0 0 8 IO-APIC-edge ide0
18:231 0 0 1 IO-APIC-fasteoi eth2
221: 0 0 1 44 PCI-MSI-edge ioc1
222: 0 0 0 46 PCI-MSI-edge ioc0
223: 0 0 0 2 PCI-MSI-edge eth0
NMI: 0 0 0 0 Non-maskable interrupts
LOC: 2160823677 1009 Local timer interrupts
RES:716417179370 Rescheduling interrupts
CAL: 35 88 86 58
Re: PATCH: usb-storage-set-last-sector-bug-flag.patch
The last-sector-(access-)bug workaround _only_ modifies the command stream which is sent to the device. A dangerous command is replaced by equivalent safe commands. BTW, one thing about this patch set needs to be criticized: last_sector_bug is a really bad name choice for the new flag. No wonder that it is confused with the (well named) fix_capacity flag. How about read_last_sector_separately or something in the way? -- 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: PATCH: usb-storage-set-last-sector-bug-flag.patch
On Thu, Jan 24, 2008 at 06:07:00PM +0100, Stefan Richter wrote: Greg KH wrote: I just am worried that we are now suddenly keeping access from the last sector for devices that currently did work just fine. This new workaround doesn't prevent access to the last sector. It only breaks up a multi-sector access which would also reach the last sector into several (two? I'm too lazy to look back in the mail thread) accesses, in order to access the last sector in a dedicated single-sector access. So that's very differently to the fix-capacity workaround. The fix-capacity workaround manipulates the READ CAPACITY parameter data. Therefore the fix-capacity workaround is unsafe for non-buggy devices. The last-sector-(access-)bug workaround _only_ modifies the command stream which is sent to the device. A dangerous command is replaced by equivalent safe commands. These commands are luckily safe for _all_ devices, buggy and non-buggy ones. The only cost of this workaround is (1.) the code, (2.) the runtime/ bandwidth/ latency overhead for accesses which reach the last sector. Ok, thanks for explaining it better. I have no objection to this change anymore. thanks, greg k-h - 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: qla_sup.c: compilation warning
On Thu, 24 Jan 2008, Boaz Harrosh wrote:
With gcc 4.1.2 on fedora7 x86_64, cross compiling an i386 kernel i get
the following compilation warning:
CC [M] drivers/scsi/qla2xxx/qla_sup.o
/usr0/export/dev/bharrosh/git/pub/scsi-misc/drivers/scsi/qla2xxx/qla_sup.c:
In function ‘qla2x00_beacon_blink’:
/usr0/export/dev/bharrosh/git/pub/scsi-misc/drivers/scsi/qla2xxx/qla_sup.c:906:
warning: cast to pointer from integer of different size
/usr0/export/dev/bharrosh/git/pub/scsi-misc/drivers/scsi/qla2xxx/qla_sup.c:
In function ‘qla2x00_beacon_on’:
/usr0/export/dev/bharrosh/git/pub/scsi-misc/drivers/scsi/qla2xxx/qla_sup.c:966:
warning: cast to pointer from integer of different size
/usr0/export/dev/bharrosh/git/pub/scsi-misc/drivers/scsi/qla2xxx/qla_sup.c:
In function ‘qla2x00_read_flash_byte’:
/usr0/export/dev/bharrosh/git/pub/scsi-misc/drivers/scsi/qla2xxx/qla_sup.c:1247:
warning: cast to pointer from integer of different size
/usr0/export/dev/bharrosh/git/pub/scsi-misc/drivers/scsi/qla2xxx/qla_sup.c:
In function ‘qla2x00_write_flash_byte’:
/usr0/export/dev/bharrosh/git/pub/scsi-misc/drivers/scsi/qla2xxx/qla_sup.c:1307:
warning: cast to pointer from integer of different size
Perhaps the compiler is right this time ?
configured with: make ARCH=i386 allmodconfig
Hmm, it looks like the conversion to resource_size_t usage
(3776541d8a46347a4924353a192c6ce4a3d04e2e) requires some additional
fixups to cleanup the structure-pointer castings used during IO mapped
accesses to the chip.
There's only a small number of locations, where the driver uses IO
mapped accesses to the hardware, the patch below should take care of
it without introducing to many structural changes to code flow.
Signed-off-by: Andrew Vasquez [EMAIL PROTECTED]
---
diff --git a/drivers/scsi/qla2xxx/qla_sup.c b/drivers/scsi/qla2xxx/qla_sup.c
index b68fb73..26822c8 100644
--- a/drivers/scsi/qla2xxx/qla_sup.c
+++ b/drivers/scsi/qla2xxx/qla_sup.c
@@ -893,6 +893,8 @@ qla2x00_flip_colors(scsi_qla_host_t *ha, uint16_t *pflags)
}
}
+#define PIO_REG(h, r) ((h)-pio_address + offsetof(struct device_reg_2xxx, r))
+
void
qla2x00_beacon_blink(struct scsi_qla_host *ha)
{
@@ -902,15 +904,12 @@ qla2x00_beacon_blink(struct scsi_qla_host *ha)
unsigned long flags;
struct device_reg_2xxx __iomem *reg = ha-iobase-isp;
- if (ha-pio_address)
- reg = (struct device_reg_2xxx __iomem *)ha-pio_address;
-
spin_lock_irqsave(ha-hardware_lock, flags);
/* Save the Original GPIOE. */
if (ha-pio_address) {
- gpio_enable = RD_REG_WORD_PIO(reg-gpioe);
- gpio_data = RD_REG_WORD_PIO(reg-gpiod);
+ gpio_enable = RD_REG_WORD_PIO(PIO_REG(ha, gpioe));
+ gpio_data = RD_REG_WORD_PIO(PIO_REG(ha, gpiod));
} else {
gpio_enable = RD_REG_WORD(reg-gpioe);
gpio_data = RD_REG_WORD(reg-gpiod);
@@ -920,7 +919,7 @@ qla2x00_beacon_blink(struct scsi_qla_host *ha)
gpio_enable |= GPIO_LED_MASK;
if (ha-pio_address) {
- WRT_REG_WORD_PIO(reg-gpioe, gpio_enable);
+ WRT_REG_WORD_PIO(PIO_REG(ha, gpioe), gpio_enable);
} else {
WRT_REG_WORD(reg-gpioe, gpio_enable);
RD_REG_WORD(reg-gpioe);
@@ -936,7 +935,7 @@ qla2x00_beacon_blink(struct scsi_qla_host *ha)
/* Set the modified gpio_data values */
if (ha-pio_address) {
- WRT_REG_WORD_PIO(reg-gpiod, gpio_data);
+ WRT_REG_WORD_PIO(PIO_REG(ha, gpiod), gpio_data);
} else {
WRT_REG_WORD(reg-gpiod, gpio_data);
RD_REG_WORD(reg-gpiod);
@@ -962,14 +961,11 @@ qla2x00_beacon_on(struct scsi_qla_host *ha)
return QLA_FUNCTION_FAILED;
}
- if (ha-pio_address)
- reg = (struct device_reg_2xxx __iomem *)ha-pio_address;
-
/* Turn off LEDs. */
spin_lock_irqsave(ha-hardware_lock, flags);
if (ha-pio_address) {
- gpio_enable = RD_REG_WORD_PIO(reg-gpioe);
- gpio_data = RD_REG_WORD_PIO(reg-gpiod);
+ gpio_enable = RD_REG_WORD_PIO(PIO_REG(ha, gpioe));
+ gpio_data = RD_REG_WORD_PIO(PIO_REG(ha, gpiod));
} else {
gpio_enable = RD_REG_WORD(reg-gpioe);
gpio_data = RD_REG_WORD(reg-gpiod);
@@ -978,7 +974,7 @@ qla2x00_beacon_on(struct scsi_qla_host *ha)
/* Set the modified gpio_enable values. */
if (ha-pio_address) {
- WRT_REG_WORD_PIO(reg-gpioe, gpio_enable);
+ WRT_REG_WORD_PIO(PIO_REG(ha, gpioe), gpio_enable);
} else {
WRT_REG_WORD(reg-gpioe, gpio_enable);
RD_REG_WORD(reg-gpioe);
@@ -987,7 +983,7 @@ qla2x00_beacon_on(struct scsi_qla_host *ha)
/* Clear out previously set LED colour. */
gpio_data = ~GPIO_LED_MASK;
if (ha-pio_address) {
-
Re: Unexpected IRQ trap when reloading mptspi with MSI
Tony Battersby wrote:
I get unexpected IRQ trap at vector dd when reloading mptspi with MSI
enabled. This seems to happen only on dual-channel HBAs; single-channel
HBAs are unaffected. It looks like the second channel is generating a
bogus MSI interrupt while the first channel is being brought up.
Update:
With the IO resource allocation using pci_request_selected_regions API
patch (http://marc.info/?l=linux-scsim=120004270121533w=4) applied, I
get the following output instead:
Jan 24 13:38:03 kernel: Fusion MPT base driver 3.04.06
Jan 24 13:38:03 kernel: Copyright (c) 1999-2007 LSI Corporation
Jan 24 13:38:07 kernel: Fusion MPT SPI Host driver 3.04.06
Jan 24 13:38:07 kernel: ACPI: PCI Interrupt :03:04.0[A] - GSI 22
(level, low) - IRQ 19
Jan 24 13:38:07 kernel: mptbase: ioc0: Initiating bringup
Jan 24 13:38:08 kernel: ioc0: LSI53C1030T A0:
Capabilities={Initiator,Target}
Jan 24 13:38:08 kernel: mptbase: ioc0: PCI-MSI enabled
Jan 24 13:38:08 kernel: scsi0 : ioc0: LSI53C1030T A0, FwRev=01032700h,
Ports=1, MaxQ=255, IRQ=222
Jan 24 13:38:13 kernel: ACPI: PCI Interrupt :03:04.1[B] - GSI 23
(level, low) - IRQ 20
Jan 24 13:38:13 kernel: mptbase: ioc1: Initiating bringup
Jan 24 13:38:13 kernel: ioc1: LSI53C1030T A0:
Capabilities={Initiator,Target}
Jan 24 13:38:13 kernel: mptbase: ioc1: PCI-MSI enabled
Jan 24 13:38:14 kernel: scsi1 : ioc1: LSI53C1030T A0, FwRev=01032700h,
Ports=1, MaxQ=255, IRQ=221
Jan 24 13:38:39 kernel: ACPI: PCI interrupt for device :03:04.1 disabled
Jan 24 13:38:39 kernel: ACPI: PCI interrupt for device :03:04.0 disabled
Jan 24 13:38:43 kernel: Fusion MPT SPI Host driver 3.04.06
Jan 24 13:38:43 kernel: ACPI: PCI Interrupt :03:04.0[A] - GSI 22
(level, low) - IRQ 19
Jan 24 13:38:43 kernel: mptbase: ioc2: Initiating bringup
Jan 24 13:38:43 kernel: ioc2: LSI53C1030T A0:
Capabilities={Initiator,Target}
Jan 24 13:38:43 kernel: mptbase: ioc2: PCI-MSI enabled
Jan 24 13:39:03 kernel: mptbase: ioc2: Initiating recovery
Jan 24 13:39:03 kernel: mptbase: ioc2: WARNING - IOC is in FAULT state!!!
Jan 24 13:39:03 kernel: mptbase: ioc2: WARNING - FAULT code = 8112h
Jan 24 13:39:03 kernel: mptbase: ioc2: ERROR - Doorbell ACK timeout
(count=4999), IntStatus=8001!
Jan 24 13:39:03 kernel: mptbase: ioc2: Recovered from IOC FAULT
Jan 24 13:39:03 kernel: Clocksource tsc unstable (delta = 9373613660 ns)
Jan 24 13:39:03 kernel: scsi2 : ioc2: LSI53C1030T A0, FwRev=01032700h,
Ports=1, MaxQ=255, IRQ=222
Jan 24 13:39:07 kernel: ACPI: PCI Interrupt :03:04.1[B] - GSI 23
(level, low) - IRQ 20
Jan 24 13:39:07 kernel: mptbase: ioc3: Initiating bringup
Jan 24 13:39:08 kernel: ioc3: LSI53C1030T A0:
Capabilities={Initiator,Target}
Jan 24 13:39:08 kernel: mptbase: ioc3: PCI-MSI enabled
Jan 24 13:39:08 kernel: scsi3 : ioc3: LSI53C1030T A0, FwRev=01032700h,
Ports=1, MaxQ=255, IRQ=221
This is much more annoying, since reloading the driver takes an extra 20
seconds for the IOC recovery. I believe the difference may be caused by
the addition of pci_disable_device() to mpt_adapter_dispose().
Tony
-
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: Performance of SCST versus STGT
Bart Van Assche wrote: On Jan 24, 2008 8:06 AM, Robin Humble [EMAIL PROTECTED] wrote: On Tue, Jan 22, 2008 at 01:32:08PM +0100, Bart Van Assche wrote: . . . STGT read SCST read.STGT read SCST read. . . performance performance . performance performance . . . (0.5K, MB/s) (0.5K, MB/s) . (1 MB MB/s) (1 MB, MB/s) . . . Ethernet (1 Gb/s network) . 77 78 . 77 89 . . IPoIB(8 Gb/s network) . 163185 .201 239 . . iSER (8 Gb/s network) . 250N/A .360 N/A . . SRP (8 Gb/s network) . N/A421 .N/A 683 . Results with /dev/ram0 configured as backing store on the target (buffered I/O): Read Write Read Write performance performance performance performance (0.5K, MB/s) (0.5K, MB/s) (1 MB, MB/s) (1 MB, MB/s) STGT + iSER 250 48 349 781 SCST + SRP411 66 659 746 Ib_rdma_bw now reports 933 MB/s on the same system, correct? Those ~250MB/s difference is what you will gain with zero-copy IO implemented and what STGT with the current architecture has no chance to achieve. Results with /dev/ram0 configured as backing store on the target (direct I/O): Read Write Read Write performance performance performance performance (0.5K, MB/s) (0.5K, MB/s) (1 MB, MB/s) (1 MB, MB/s) STGT + iSER 7.9 9.8 589 647 SCST + SRP 12.3 9.7 811 794 Bart. - 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
Scsi error : device overrun on Adaptec AIC-7902B
Hi, I am experiencing odd error messages on a server and can't sort out if it is a software or hardware problem. Server is running linux 2.6.22 kernel from Ubuntu server distro (2.6.22-14-server) on a bi-AMD64 Opteron machine. The SCSI board is an Adaptec AIC-7902B (see (1) below for lspci output). First SCSI chain has 4 Ultra320 harddrives, and second one (scsi5) has 4 Ultra320 harddrives and a 160 tape reader. Regularely, we have a bunch of errors in /var/log/messages, saying 'Transmission error' ... 'scsi5: device overrun (status a) on 0:3:0' (every 10 minutes or so, when the machine is active, plus a detailed card dump) (see (2)) Smartctl (v 5.37) on /dev/sdj (scsi5 0:3:0) seems ok, except for a quite high correction algorithm invocation count (see (3)). But yesterday, we had a worse problem, where half our disks went offline. (see the log below in (4)). So, any tip on what might be going wrong ?? Thanks in advance, Franck PS : 2 hours ago, the machine did freeze completely. Hard reboot, no log... scarring ! (1) output of 'lspci -v' : 0a:07.0 SCSI storage controller: Adaptec AIC-7902B U320 (rev 10) Subsystem: Adaptec Unknown device 005e Flags: bus master, 66MHz, slow devsel, latency 72, IRQ 28 I/O ports at 3400 [disabled] [size=256] Memory at df30 (64-bit, non-prefetchable) [size=8K] I/O ports at 3000 [disabled] [size=256] [virtual] Expansion ROM at c210 [disabled] [size=512K] Capabilities: [dc] Power Management version 2 Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1 Enable- Capabilities: [94] PCI-X non-bridge device 0a:07.1 SCSI storage controller: Adaptec AIC-7902B U320 (rev 10) Subsystem: Adaptec Unknown device 005e Flags: bus master, 66MHz, slow devsel, latency 72, IRQ 29 I/O ports at 3c00 [disabled] [size=256] Memory at df302000 (64-bit, non-prefetchable) [size=8K] I/O ports at 3800 [disabled] [size=256] [virtual] Expansion ROM at c218 [disabled] [size=512K] Capabilities: [dc] Power Management version 2 Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1 Enable- Capabilities: [94] PCI-X non-bridge device (2) Recurrent error : Jan 24 12:20:37 pariou kernel: [64896.014316] scsi5: Transmission error detected Jan 24 12:20:37 pariou kernel: [64896.014347] scsi5: Dumping Card State at program address 0x257 Mode 0x0 Jan 24 12:20:37 pariou kernel: [64896.014651] scsi5: FIFO0 Active, LONGJMP == 0x252, SCB 0x7b Jan 24 12:20:37 pariou kernel: [64896.014722] scsi5: FIFO1 Free, LONGJMP == 0x81f7, SCB 0x62 Jan 24 12:20:37 pariou kernel: [64896.014808] scsi5: LQISTATE = 0x2b, LQOSTATE = 0x0, OPTIONMODE = 0x52 Jan 24 12:20:37 pariou kernel: [64896.014812] scsi5: OS_SPACE_CNT = 0x20 MAXCMDCNT = 0x1 Jan 24 12:20:37 pariou kernel: [64896.014815] scsi5: SAVED_SCSIID = 0x0 SAVED_LUN = 0x0 Jan 24 12:20:37 pariou kernel: [64896.014834] scsi5: REG0 == 0x7d60, SINDEX = 0x158, DINDEX = 0x10a Jan 24 12:20:37 pariou kernel: [64896.014842] scsi5: SCBPTR == 0x7b, SCB_NEXT == 0xff00, SCB_NEXT2 == 0x79 Jan 24 12:20:37 pariou kernel: [64896.015374] scsi5: Returning to Idle Loop Jan 24 12:20:37 pariou kernel: [64896.015438] scsi5: device overrun (status a) on 0:3:0 (3) smartctl output on scsi5 0:3:0 : Device: HITACHI HUS151436VL3600 Version: S3C0 Serial number: J3WE8KLA Device type: disk Transport protocol: Parallel SCSI (SPI-4) Local Time is: Thu Jan 24 13:25:08 2008 CET Device supports SMART and is Enabled Temperature Warning Enabled SMART Health Status: OK Current Drive Temperature: 40 C Drive Trip Temperature:85 C Manufactured in week 08 of year 2006 Recommended maximum start stop count: 5 times Current start stop count: 105 times Elements in grown defect list: 0 Vendor (Seagate) cache information Blocks sent to initiator = 300818938986496 Error counter log: Errors Corrected by Total Correction GigabytesTotal ECC rereads/errors algorithm processeduncorrected fast | delayed rewrites corrected invocations [10^9 bytes] errors read: 11032593424 0110325956340.501 0 write: 328450 0 32845 0316.122 0 Non-medium error count:0 No self-tests have been logged Long (extended) Self Test duration: 607 seconds [10.1 minutes] (4) /var/log/message when scsi5 went offline (one card dump for each of the four disks) : [452353.991582] sd 5:0:1:0: [sdg] Attempting to queue an ABORT message:CDB: 0x0 0x0 0x0 0x0 0x0 0x0 [452353.992109] scsi5: At time of recovery, card was not paused [452353.992116] Dump Card State Begins [452353.992118] scsi5: Dumping Card State at program address 0x6 Mode 0x33 [452353.992121] Card was paused [452353.992123] INTSTAT[0x0] SELOID[0x2] SELID[0x10] [452353.992132] HS_MAILBOX[0x0]
[PATCH 11/77] aic7(3*x): fix firmware build
From: Vegard Nossum [EMAIL PROTECTED] This patch adds the proper $(obj) and $(src) prefixes to dependency rules in aic7xxx makefile. Without this patch, there is a remote possibility that parallel make with a different output directory can fail. Also changed the deprecated EXTRA_CFLAGS construct to ccflags-y syntax. Fixed up patch to survive make drivers/scsi/ -j with BUILD_FIRMWARE enable. /Sam Signed-off-by: Vegard Nossum [EMAIL PROTECTED] Signed-off-by: Sam Ravnborg [EMAIL PROTECTED] Acked-by: Hannes Reinecke [EMAIL PROTECTED] Cc: linux-scsi@vger.kernel.org --- drivers/scsi/aic7xxx/Makefile | 45 1 files changed, 18 insertions(+), 27 deletions(-) diff --git a/drivers/scsi/aic7xxx/Makefile b/drivers/scsi/aic7xxx/Makefile index 9a6ce19..e4f70c5 100644 --- a/drivers/scsi/aic7xxx/Makefile +++ b/drivers/scsi/aic7xxx/Makefile @@ -33,11 +33,10 @@ aic79xx-y += aic79xx_osm.o\ aic79xx_proc.o \ aic79xx_osm_pci.o -EXTRA_CFLAGS += -Idrivers/scsi +ccflags-y += -Idrivers/scsi ifdef WARNINGS_BECOME_ERRORS -EXTRA_CFLAGS += -Werror +ccflags-y += -Werror endif -#EXTRA_CFLAGS += -g # Files generated that shall be removed upon make clean clean-files := aic7xxx_seq.h aic7xxx_reg.h aic7xxx_reg_print.c @@ -46,53 +45,45 @@ clean-files += aic79xx_seq.h aic79xx_reg.h aic79xx_reg_print.c # Dependencies for generated files need to be listed explicitly $(obj)/aic7xxx_core.o: $(obj)/aic7xxx_seq.h +$(obj)/aic7xxx_core.o: $(obj)/aic7xxx_reg.h $(obj)/aic79xx_core.o: $(obj)/aic79xx_seq.h -$(obj)/aic79xx_reg_print.c: $(src)/aic79xx_reg_print.c_shipped -$(obj)/aic7xxx_reg_print.c: $(src)/aic7xxx_reg_print.c_shipped +$(obj)/aic79xx_core.o: $(obj)/aic79xx_reg.h -$(addprefix $(obj)/,$(aic7xxx-y)): $(obj)/aic7xxx_reg.h -$(addprefix $(obj)/,$(aic79xx-y)): $(obj)/aic79xx_reg.h +$(addprefix $(obj)/,$(aic7xxx-y)): $(obj)/aic7xxx_seq.h +$(addprefix $(obj)/,$(aic79xx-y)): $(obj)/aic79xx_seq.h -aic7xxx-gen-$(CONFIG_AIC7XXX_BUILD_FIRMWARE) := $(obj)/aic7xxx_seq.h \ - $(obj)/aic7xxx_reg.h +aic7xxx-gen-$(CONFIG_AIC7XXX_BUILD_FIRMWARE) := $(obj)/aic7xxx_reg.h aic7xxx-gen-$(CONFIG_AIC7XXX_REG_PRETTY_PRINT) += $(obj)/aic7xxx_reg_print.c aicasm-7xxx-opts-$(CONFIG_AIC7XXX_REG_PRETTY_PRINT) := \ -p $(obj)/aic7xxx_reg_print.c -i aic7xxx_osm.h ifeq ($(CONFIG_AIC7XXX_BUILD_FIRMWARE),y) -# Create a dependency chain in generated files -# to avoid concurrent invocations of the single -# rule that builds them all. -aic7xxx_seq.h: aic7xxx_reg.h -ifeq ($(CONFIG_AIC7XXX_REG_PRETTY_PRINT),y) -aic7xxx_reg.h: aic7xxx_reg_print.c -endif -$(aic7xxx-gen-y): $(src)/aic7xxx.seq $(src)/aic7xxx.reg $(obj)/aicasm/aicasm +$(obj)/aic7xxx_seq.h: $(src)/aic7xxx.seq $(src)/aic7xxx.reg $(obj)/aicasm/aicasm $(obj)/aicasm/aicasm -I$(src) -r $(obj)/aic7xxx_reg.h \ $(aicasm-7xxx-opts-y) -o $(obj)/aic7xxx_seq.h \ $(src)/aic7xxx.seq + +$(aic7xxx-gen-y): $(obj)/aic7xxx_seq.h +else +$(obj)/aic7xxx_reg_print.c: $(src)/aic7xxx_reg_print.c_shipped endif -aic79xx-gen-$(CONFIG_AIC79XX_BUILD_FIRMWARE) := $(obj)/aic79xx_seq.h \ - $(obj)/aic79xx_reg.h +aic79xx-gen-$(CONFIG_AIC79XX_BUILD_FIRMWARE) := $(obj)/aic79xx_reg.h aic79xx-gen-$(CONFIG_AIC79XX_REG_PRETTY_PRINT) += $(obj)/aic79xx_reg_print.c aicasm-79xx-opts-$(CONFIG_AIC79XX_REG_PRETTY_PRINT) := \ -p $(obj)/aic79xx_reg_print.c -i aic79xx_osm.h ifeq ($(CONFIG_AIC79XX_BUILD_FIRMWARE),y) -# Create a dependency chain in generated files -# to avoid concurrent invocations of the single -# rule that builds them all. -aic79xx_seq.h: aic79xx_reg.h -ifeq ($(CONFIG_AIC79XX_REG_PRETTY_PRINT),y) -aic79xx_reg.h: aic79xx_reg_print.c -endif -$(aic79xx-gen-y): $(src)/aic79xx.seq $(src)/aic79xx.reg $(obj)/aicasm/aicasm +$(obj)/aic79xx_seq.h: $(src)/aic79xx.seq $(src)/aic79xx.reg $(obj)/aicasm/aicasm $(obj)/aicasm/aicasm -I$(src) -r $(obj)/aic79xx_reg.h \ $(aicasm-79xx-opts-y) -o $(obj)/aic79xx_seq.h \ $(src)/aic79xx.seq + +$(aic79xx-gen-y): $(obj)/aic79xx_seq.h +else +$(obj)/aic79xx_reg_print.c: $(src)/aic79xx_reg_print.c_shipped endif $(obj)/aicasm/aicasm: $(src)/aicasm/*.[chyl] -- 1.5.4.rc3.14.g44397 - 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
Code error in mptsas.c ?
In mptsas.c there are two functions mptsas_find_phyinfo_by_target and
mptsas_find_phyinfo_by_sas
_address. Below is the 'by_target' function. It appears the intent
is to break out of the search when the matching phy_info is found.
However, the 'break' statement will only move to the next 'list' entry
and continue the search. The 'by_sas_address' function appears to
have the same flaw. I believe the addition of if (phy_info) break;
outside the 'for' loop would correct the functionality.
Can you confirm this?
static struct mptsas_phyinfo *
mptsas_find_phyinfo_by_target(MPT_ADAPTER *ioc, u32 id)
{
struct mptsas_portinfo *port_info;
struct mptsas_phyinfo *phy_info = NULL;
int i;
mutex_lock(ioc-sas_topology_mutex);
list_for_each_entry(port_info, ioc-sas_topology, list) {
for (i = 0; i port_info-num_phys; i++) {
if (port_info-phy_info[i].attached.id != id)
continue;
if (!mptsas_is_end_device(
port_info-phy_info[i].attached))
continue;
phy_info = port_info-phy_info[i];
break;
}
}
mutex_unlock(ioc-sas_topology_mutex);
return phy_info;
}
-Mark G
-
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: Performance of SCST versus STGT
On Jan 24, 2008 8:54 PM, Vladislav Bolkhovitin [EMAIL PROTECTED] wrote: Ib_rdma_bw now reports 933 MB/s on the same system, correct? Those ~250MB/s difference is what you will gain with zero-copy IO implemented and what STGT with the current architecture has no chance to achieve. Yes, that's correct: * ib_rdma_bw, ib_write_bw and ib_read_bw report 933 MB/s between the two test systems. * ib_read_bw reports 905 MB/s. * ib_rdma_lat reports 3.1 microseconds. * ib_read_lat reports 7.5 microseconds. Bart. - 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
