Re: [PATCH 20/24] iscsi_tcp: enable sg chaining
On Thu, Dec 13 2007 at 20:43 +0200, [EMAIL PROTECTED] wrote:
From: Mike Christie [EMAIL PROTECTED]
The previous patches converted iscsi_tcp to support sg chaining.
This patch sets the proper flags and sets sg_table size to
4096. This allows fs io to be capped at max_sectors, but passthrough
IO to be limited by some other part of the kernel.
Signed-off-by: Mike Christie [EMAIL PROTECTED]
---
drivers/scsi/iscsi_tcp.c |5 +++--
drivers/scsi/iscsi_tcp.h |3 ---
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/scsi/iscsi_tcp.c b/drivers/scsi/iscsi_tcp.c
index 65df908..84c4a50 100644
--- a/drivers/scsi/iscsi_tcp.c
+++ b/drivers/scsi/iscsi_tcp.c
@@ -1928,13 +1928,14 @@ static struct scsi_host_template iscsi_sht = {
.queuecommand = iscsi_queuecommand,
.change_queue_depth = iscsi_change_queue_depth,
.can_queue = ISCSI_DEF_XMIT_CMDS_MAX - 1,
- .sg_tablesize = ISCSI_SG_TABLESIZE,
+ .sg_tablesize = 4096,
+ .sg_tablesize = ~0,
I use ~0 in my tree. The 4096 is a mechanical limitation here without
any real reasons. ~0 means that the driver does not have any limitations
and the minimum will be at some higher level.
.max_sectors= 0x,
.cmd_per_lun= ISCSI_DEF_CMD_PER_LUN,
.eh_abort_handler = iscsi_eh_abort,
.eh_device_reset_handler= iscsi_eh_device_reset,
.eh_host_reset_handler = iscsi_eh_host_reset,
.use_clustering = DISABLE_CLUSTERING,
+ .use_sg_chaining= ENABLE_SG_CHAINING,
.slave_configure= iscsi_tcp_slave_configure,
.proc_name = iscsi_tcp,
.this_id= -1,
@@ -1974,7 +1975,7 @@ static struct iscsi_transport iscsi_tcp_transport = {
.host_template = iscsi_sht,
.conndata_size = sizeof(struct iscsi_conn),
.max_conn = 1,
- .max_cmd_len= ISCSI_TCP_MAX_CMD_LEN,
+ .max_cmd_len= 16,
/* session management */
.create_session = iscsi_tcp_session_create,
.destroy_session= iscsi_tcp_session_destroy,
diff --git a/drivers/scsi/iscsi_tcp.h b/drivers/scsi/iscsi_tcp.h
index 893cd2e..ed0b991 100644
--- a/drivers/scsi/iscsi_tcp.h
+++ b/drivers/scsi/iscsi_tcp.h
@@ -24,9 +24,6 @@
#include scsi/libiscsi.h
-#define ISCSI_SG_TABLESIZE SG_ALL
-#define ISCSI_TCP_MAX_CMD_LEN16
-
struct crypto_hash;
struct socket;
struct iscsi_tcp_conn;
Don't fix it just yet. I will send a patch much later,
when I will actually need it. I just wanted to make a note
of it.
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 07/24] arm: scsi convert to accessors and !use_sg cleanup
On Sat, Dec 15 2007 at 2:27 +0200, James Bottomley [EMAIL PROTECTED] wrote:
On Tue, 2007-09-18 at 17:04 +0200, Boaz Harrosh wrote:
On Wed, Sep 12 2007 at 10:42 +0300, Russell King [EMAIL PROTECTED] wrote:
On Wed, Sep 12, 2007 at 02:55:19AM +0300, Boaz Harrosh wrote:
- if (SCpnt-request_bufflen != len)
+ if (scsi_bufflen(SCpnt) != len) {
+ WARN_ON(1);
NAK. The call trace generally doesn't provide any additional information
on the cause of the error.
In my opinion this can not happen any more. If it does, I want to see that
it is not through the regular scsi-ml .queuecommand mechanism.
But if you insist than sure I will remove it.
printk(KERN_WARNING scsi%d.%c: bad request buffer
length %d, should be %ld\n,
SCpnt-device-host-host_no,
- '0' + SCpnt-device-id, SCpnt-request_bufflen,
len);
- SCpnt-request_bufflen = len;
+ '0' + SCpnt-device-id, scsi_bufflen(SCpnt),
len);
+ }
#endif
} else {
- SCpnt-SCp.ptr = (unsigned char *)SCpnt-request_buffer;
- SCpnt-SCp.this_residual = SCpnt-request_bufflen;
- SCpnt-SCp.phase = SCpnt-request_bufflen;
- }
-
- /*
- * If the upper SCSI layers pass a buffer, but zero length,
- * we aren't interested in the buffer pointer.
- */
- if (SCpnt-SCp.this_residual == 0 SCpnt-SCp.ptr) {
-#if 0 //def BELT_AND_BRACES
- printk(KERN_WARNING scsi%d.%c: zero length buffer passed for
- command , SCpnt-host-host_no, '0' + SCpnt-target);
- __scsi_print_command(SCpnt-cmnd);
-#endif
SCpnt-SCp.ptr = NULL;
+ SCpnt-SCp.this_residual = 0;
+ SCpnt-SCp.phase = 0;
}
}
Also NAK. This was added due to bad behaviour of the SCSI layer and
was found to be necessary.
No! This check is no longer Relevant. The master if() is on bufflen() now,
and only than do we ever set SCp.ptr. The else will always set both to Zero.
(Which is what you want)
In any way this check is done in scsi-ml, and since 2.6.18 only scsi-ml
can allocate and issue commands. All other sources of commands where removed.
All upper layers issue requests now.
Russell, could you respond to this, please? Boaz's points seem valid to
me and this conversion must be done soon otherwise these drivers will
break.
James
Reinspecting this code in view of the overall arm-scsi, I conclude that arm
is CURRENTLY BROKEN in 2.6.24-rcx tree. With or without this patch.
Resubmitted in this mail is the sg-safe version of this patch. Maybe
with the bug fixes it will finally be acknowledged by the arm people.
The reason it is currently broken is because of copy_SCp_to_sg() which I did
not previously
touched. It is broken both on the account of the wrong assumption about the
sg-list
coming from scsi at SCp.buffer, and because inspecting the code, the sg-list
pointed
to by destination sg is later passed to a DMA mapper and it is not initialized
properly.
These and more are fixed in the new patch.
After the new patch, arm drivers are not yet safe for chaining. But the
arm-scsi-mid-layer is. Meaning, good behaving arm drivers will no longer
suffer from bugs at the mid-level.
Russell or any other arm person. Please first see if this compiles at all, as I
do
not have a cross compiler set up, and please check that this code works.
(Should apply on top of Linus latest)
--
From f02d6f44c9043258f8aa63c7dfe56c9a67db3fcf Mon Sep 17 00:00:00 2001
From: Boaz Harrosh [EMAIL PROTECTED]
Date: Sun, 9 Sep 2007 21:31:21 +0300
Subject: [PATCH] [SCSI] arm: sg bugfixes and convert to accessors
- convert to accessors and !use_sg cleanup
- fix for sg_chaining bugs
Signed-off-by: Boaz Harrosh [EMAIL PROTECTED]
Cc: Russell King [EMAIL PROTECTED]
---
drivers/scsi/arm/acornscsi.c | 14 +++---
drivers/scsi/arm/scsi.h | 86 -
2 files changed, 57 insertions(+), 43 deletions(-)
diff --git a/drivers/scsi/arm/acornscsi.c b/drivers/scsi/arm/acornscsi.c
index eceacf6..3bedf24 100644
--- a/drivers/scsi/arm/acornscsi.c
+++ b/drivers/scsi/arm/acornscsi.c
@@ -1790,7 +1790,7 @@ int acornscsi_starttransfer(AS_Host *host)
return 0;
}
-residual = host-SCpnt-request_bufflen - host-scsi.SCp.scsi_xferred;
+residual = scsi_bufflen(host-SCpnt) - host-scsi.SCp.scsi_xferred;
sbic_arm_write(host-scsi.io_port, SBIC_SYNCHTRANSFER,
host-device[host-SCpnt-device-id].sync_xfer);
sbic_arm_writenext(host-scsi.io_port, residual 16);
@@ -2270,7 +2270,7 @@ intr_ret_t acornscsi_sbicintr(AS_Host *host, int in_irq)
case 0x4b: /* - PHASE_STATUSIN
*/
case 0x8b: /* - PHASE_STATUSIN
*/
/* DATA IN - STATUS */
- host-scsi.SCp.scsi_xferred = host-SCpnt-request_bufflen -
[PATCH] ieee1394: sbp2: raise default transfer size limit
This patch speeds up sbp2 a little bit --- but more importantly, it
brings the behavior of sbp2 and fw-sbp2 closer to each other. Like
fw-sbp2, sbp2 now does not limit the size of single transfers to 255
sectors anymore, unless told so by a blacklist flag or by module load
parameters.
Only very old bridge chips have been known to need the 255 sectors
limit, and we have got one such chip in our hardwired blacklist. There
certainly is a danger that more bridges need that limit; but I prefer to
have this issue present in both fw-sbp2 and sbp2 rather than just one of
them.
An OXUF922 with 400GB 7200RPM disk on an S400 controller is sped up by
this patch from 22.9 to 23.5 MB/s according to hdparm. The same effect
could be achieved before by setting a higher max_sectors module
parameter. On buses which use 1394b beta mode, sbp2 and fw-sbp2 will
now achieve virtually the same bandwidth. Fw-sbp2 only remains faster
on 1394a buses due to fw-core's gap count optimization.
Signed-off-by: Stefan Richter [EMAIL PROTECTED]
---
drivers/ieee1394/sbp2.c | 26 +++---
drivers/ieee1394/sbp2.h |1 -
2 files changed, 15 insertions(+), 12 deletions(-)
Index: linux/drivers/ieee1394/sbp2.c
===
--- linux.orig/drivers/ieee1394/sbp2.c
+++ linux/drivers/ieee1394/sbp2.c
@@ -51,6 +51,7 @@
* Grep for inline FIXME comments below.
*/
+#include linux/blkdev.h
#include linux/compiler.h
#include linux/delay.h
#include linux/device.h
@@ -127,17 +128,21 @@ MODULE_PARM_DESC(serialize_io, Serializ
(default = Y, faster but buggy = N));
/*
- * Bump up max_sectors if you'd like to support very large sized
- * transfers. Please note that some older sbp2 bridge chips are broken for
- * transfers greater or equal to 128KB. Default is a value of 255
- * sectors, or just under 128KB (at 512 byte sector size). I can note that
- * the Oxsemi sbp2 chipsets have no problems supporting very large
- * transfer sizes.
+ * Adjust max_sectors if you'd like to influence how many sectors each SCSI
+ * command can transfer at most. Please note that some older SBP-2 bridge
+ * chips are broken for transfers greater or equal to 128KB, therefore
+ * max_sectors used to be a safe 255 sectors for many years. We now have a
+ * default of 0 here which means that we let the SCSI stack choose a limit.
+ *
+ * The SBP2_WORKAROUND_128K_MAX_TRANS flag, if set either in the workarounds
+ * module parameter or in the sbp2_workarounds_table[], will override the
+ * value of max_sectors. We should use sbp2_workarounds_table[] to cover any
+ * bridge chip which becomes known to need the 255 sectors limit.
*/
-static int sbp2_max_sectors = SBP2_MAX_SECTORS;
+static int sbp2_max_sectors;
module_param_named(max_sectors, sbp2_max_sectors, int, 0444);
MODULE_PARM_DESC(max_sectors, Change max sectors per I/O supported
-(default = __stringify(SBP2_MAX_SECTORS) ));
+(default = 0 = use SCSI stack's default));
/*
* Exclusive login to sbp2 device? In most cases, the sbp2 driver should
@@ -1980,6 +1985,8 @@ static int sbp2scsi_slave_configure(stru
sdev-skip_ms_page_8 = 1;
if (lu-workarounds SBP2_WORKAROUND_FIX_CAPACITY)
sdev-fix_capacity = 1;
+ if (lu-workarounds SBP2_WORKAROUND_128K_MAX_TRANS)
+ blk_queue_max_sectors(sdev-request_queue, 128 * 1024 / 512);
return 0;
}
@@ -2086,9 +2093,6 @@ static int sbp2_module_init(void)
sbp2_shost_template.cmd_per_lun = 1;
}
- if (sbp2_default_workarounds SBP2_WORKAROUND_128K_MAX_TRANS
- (sbp2_max_sectors * 512) (128 * 1024))
- sbp2_max_sectors = 128 * 1024 / 512;
sbp2_shost_template.max_sectors = sbp2_max_sectors;
hpsb_register_highlevel(sbp2_highlevel);
Index: linux/drivers/ieee1394/sbp2.h
===
--- linux.orig/drivers/ieee1394/sbp2.h
+++ linux/drivers/ieee1394/sbp2.h
@@ -222,7 +222,6 @@ struct sbp2_status_block {
*/
#define SBP2_MAX_SG_ELEMENT_LENGTH 0xf000
-#define SBP2_MAX_SECTORS 255
/* There is no real limitation of the queue depth (i.e. length of the linked
* list of command ORBs) at the target. The chosen depth is merely an
* implementation detail of the sbp2 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: QUEUE_FLAG_CLUSTER: not working in 2.6.24 ?
Just using cp to read the file is enough to cause problems but I included
a very basic program below that produces the BUG_ON checks. Is this a known
issue or am I using the interface incorrectly?
I'd say you're using it correctly but you've found a hitherto unknown bug.
On i386 highmem machines with CONFIG_HIGHPTE (at least) pte_offset_map()
takes kmap_atomic(), so pagemap_pte_range() can't do copy_to_user() as it
presently does.
Drat.
Still, that shouldn't really disrupt the testing which you're doing. You
could disable CONFIG_HIGHPTE to shut it up.
Yes, that did the trick. Using pagemap, it was trivial to show that the
2.6.24-rc5-mm1 kernel was placing pages in reverse physical order like
the following output shows
b: 32763 v: 753091 p:65559 . 65558 contig: 1
b: 32764 v: 753092 p:65558 . 65557 contig: 1
b: 32765 v: 753093 p:65557 . 65556 contig: 1
b: 32766 v: 753094 p:65556 . 6 contig: 1
b: 32767 v: 753095 p:6 . 6 contig: 1
p: is the PFN of the page v: is the page offset within an anonymous
mapping and b: is the number of non-contiguous blocks in the anonymous
mapping. With the patch applied, it looks more like;
b: 1232 v: 752964 p:58944 87328 contig: 15
b: 1233 v: 752980 p:87328 91200 contig: 15
b: 1234 v: 752996 p:91200 40272 contig: 15
b: 1235 v: 753012 p:40272 85664 contig: 15
b: 1236 v: 753028 p:85664 87312 contig: 15
so mappings are using contiguous pages again. This was the final test
program I used in case it's of any interest.
Thanks
/*
* showcontiguous.c
*
* Use the /proc/pid/pagemap interface to give an indication of how contiguous
* physical memory is in an anonymous virtual memory mapping
*/
#include stdio.h
#include sys/mman.h
#include stdlib.h
#include unistd.h
#include linux/types.h
#include sys/types.h
#include sys/stat.h
#include fcntl.h
#define MAPSIZE (128*1048576)
#define PM_ENTRY_BYTES sizeof(__u64)
int main(int argc, char **argv)
{
int pagemap_fd;
unsigned long *anonmapping;
__u64 pagemap_entry = 0ULL;
unsigned long vpfn, ppfn, ppfn_last;
int block_number = 0;
int contig_count = 1;
size_t mmap_offset;
int pagesize = getpagesize();
if (sizeof(pagemap_entry) PM_ENTRY_BYTES) {
printf(ERROR: Failed assumption on size of pagemap_entry\n);
exit(EXIT_FAILURE);
}
/* Open the pagemap interface */
pagemap_fd = open(/proc/self/pagemap, O_RDONLY);
if (pagemap_fd == -1) {
perror(fopen);
exit(EXIT_FAILURE);
}
/* Create an anonymous mapping */
anonmapping = mmap(NULL, MAPSIZE,
PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_POPULATE,
-1, 0);
if (anonmapping == MAP_FAILED) {
perror(mmap);
exit(1);
}
/* Work out the VPN the mapping is at and seek to it in pagemap */
vpfn = ((unsigned long)anonmapping) / pagesize;
mmap_offset = lseek(pagemap_fd, vpfn * PM_ENTRY_BYTES, SEEK_SET);
if (mmap_offset == -1) {
perror(fseek);
exit(EXIT_FAILURE);
}
ppfn_last = 0;
/* Read the PFN of each page in the mapping */
for (mmap_offset = 0; mmap_offset MAPSIZE; mmap_offset += pagesize) {
vpfn = ((unsigned long)anonmapping + mmap_offset) / pagesize;
if (read(pagemap_fd, pagemap_entry, PM_ENTRY_BYTES) == 0) {
perror(fread);
exit(EXIT_FAILURE);
}
ppfn = (unsigned long)pagemap_entry;
if (ppfn == ppfn_last + 1) {
printf(.);
contig_count++;
} else {
printf( %lu contig: %d\nb: %6d v: %8lu p: %8lu .,
ppfn, contig_count,
block_number, vpfn, ppfn);
contig_count = 1;
block_number++;
}
ppfn_last = ppfn;
}
printf( %lu config: %d\n, ppfn, contig_count);
close(pagemap_fd);
munmap(anonmapping, MAPSIZE);
exit(EXIT_SUCCESS);
}
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
-
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 page_alloc for larger I/O segments (improved)
On (14/12/07 13:07), Mark Lord didst pronounce: SNIP That (also) works for me here, regularly generating 64KB I/O segments with SLAB. Brilliant. Thanks a lot Mark. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab - 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: 2.6.24-rc5: tape drive not responding
Hi, This looks to be a regression between 2.6.23 and 2.6.24-rc5, I'll try to bi-sect this and report more on it. Basically, when I bootup, I get a ton of errors in the dmesg log along the lines of: [ 215.007701] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 215.008145] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 215.008678] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 215.009122] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 215.009598] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 215.010042] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 215.010516] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 215.010959] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 215.011403] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 215.011850] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae . . . [ 232.954629] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 233.035902] scsi 3:0:3:0: DEVICE RESET operation started [ 233.099514] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae . . . These repeat for about 15 seconds or so. They're really annoying and I'd love to see some sort of rate limiting put in here. The messages and end with: . . . [ 238.084175] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 238.165887] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 238.247157] scsi 3:0:3:0: DEVICE RESET operation timed-out. [ 238.313892] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 238.395192] scsi 3:0:3:0: BUS RESET operation started [ 238.455690] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 238.539216] sym1: SCSI BUS reset detected. [ 238.592552] sym1: SCSI BUS has been reset. [ 238.641576] scsi 3:0:3:0: BUS RESET operation complete. [ 248.700373] target3:0:3: wide asynchronous [ 248.752026] target3:0:3: Wide Transfers Fail [ 248.805220] target3:0:3: FAST-10 SCSI 10.0 MB/s ST (100 ns, offset 15) [ 248.886729] target3:0:3: Domain Validation skipping write tests [ 248.958666] target3:0:3: Ending Domain Validation [ 252.264086] scsi 3:0:0:0: Attached scsi generic sg2 type 8 [ 252.331257] st 3:0:2:0: Attached scsi tape st0 [ 252.384549] st 3:0:2:0: st0: try direct i/o: yes (alignment 512 B) [ 252.458875] st 3:0:2:0: Attached scsi generic sg3 type 1 [ 252.523963] st 3:0:3:0: Attached scsi tape st1 [ 252.577184] st 3:0:3:0: st1: try direct i/o: yes (alignment 512 B) [ 252.651484] st 3:0:3:0: Attached scsi generic sg4 type 1 I've also got an ATL P1000 SCSI tape library hooked up to this same controller and port, and I can manipulate it properly using the 'mtx' program pointed to the /dev/changer alias, which points to the correct /dev/sg# device. Here's my /proc/scsi/scsi output, as you can see, I've got a bunch of devices on this system: # cat /proc/scsi/scsi Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: COMPAQ Model: HC01841729 Rev: 3208 Type: Direct-AccessANSI SCSI revision: 02 Host: scsi0 Channel: 00 Id: 01 Lun: 00 Vendor: COMPAQ Model: BD018222CA Rev: B016 Type: Direct-AccessANSI SCSI revision: 02 Host: scsi3 Channel: 00 Id: 00 Lun: 00 Vendor: ATL Model: P10006220051 Rev: 1.20 Type: Medium Changer ANSI SCSI revision: 02 Host: scsi3 Channel: 00 Id: 02 Lun: 00 Vendor: QUANTUM Model: DLT7000 Rev: 2565 Type: Sequential-AccessANSI SCSI revision: 02 Host: scsi3 Channel: 00 Id: 03 Lun: 00 Vendor: QUANTUM Model: DLT7000 Rev: 2565 Type: Sequential-AccessANSI SCSI revision: 02 Host: scsi4 Channel: 00 Id: 00 Lun: 00 Vendor: SAMSUNG Model: CDRW/DVD SM-352B Rev: T806 Type: CD-ROM ANSI SCSI revision: 05 Host: scsi6 Channel: 00 Id: 00 Lun: 00 Vendor: ATA Model: ST3320620AS Rev: 3.AA Type: Direct-AccessANSI SCSI revision: 05 Host: scsi7 Channel: 00 Id: 00 Lun: 00 Vendor: ATA Model: WDC WD3200AAKS-0 Rev: 12.0 Type: Direct-AccessANSI SCSI revision: 05 Host: scsi10 Channel: 00 Id: 00 Lun: 00 Vendor: ATA Model: WDC WD1200JB-00C Rev: 17.0 Type: Direct-AccessANSI SCSI revision: 05 Host: scsi11 Channel: 00 Id: 00 Lun: 00 Vendor: ATA Model: WDC WD1200JB-00E Rev: 15.0 Type: Direct-AccessANSI SCSI revision: 05 Host: scsi12 Channel: 00 Id: 00 Lun: 00 Vendor: Generic Model: STORAGE DEVICE Rev: 0001 Type: Direct-AccessANSI SCSI revision: 00 Host: scsi12 Channel: 00 Id: 00 Lun: 01 Vendor: Generic Model: STORAGE DEVICE Rev: 0001 Type: Direct-AccessANSI SCSI revision: 00 Host: scsi12 Channel: 00 Id: 00 Lun: 02 Vendor: Generic Model:
Re: 2.6.24-rc5: tape drive not responding
On Sun, 16 Dec 2007 20:05:51 -0500 John Stoffel [EMAIL PROTECTED] wrote: [ 215.007701] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 215.008145] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 215.008678] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 215.009122] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 215.009598] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 215.010042] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 215.010516] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 215.010959] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 215.011403] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 215.011850] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae . . . [ 232.954629] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 233.035902] scsi 3:0:3:0: DEVICE RESET operation started [ 233.099514] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae . . . These repeat for about 15 seconds or so. They're really annoying and I'd love to see some sort of rate limiting put in here. The messages and end with: . . . [ 238.084175] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 238.165887] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 238.247157] scsi 3:0:3:0: DEVICE RESET operation timed-out. [ 238.313892] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 238.395192] scsi 3:0:3:0: BUS RESET operation started [ 238.455690] sym1: SCSI parity error detected: SCR1=1 DBC=1128 SBCL=ae [ 238.539216] sym1: SCSI BUS reset detected. [ 238.592552] sym1: SCSI BUS has been reset. [ 238.641576] scsi 3:0:3:0: BUS RESET operation complete. [ 248.700373] target3:0:3: wide asynchronous [ 248.752026] target3:0:3: Wide Transfers Fail [ 248.805220] target3:0:3: FAST-10 SCSI 10.0 MB/s ST (100 ns, offset 15) [ 248.886729] target3:0:3: Domain Validation skipping write tests [ 248.958666] target3:0:3: Ending Domain Validation [ 252.264086] scsi 3:0:0:0: Attached scsi generic sg2 type 8 [ 252.331257] st 3:0:2:0: Attached scsi tape st0 [ 252.384549] st 3:0:2:0: st0: try direct i/o: yes (alignment 512 B) [ 252.458875] st 3:0:2:0: Attached scsi generic sg3 type 1 [ 252.523963] st 3:0:3:0: Attached scsi tape st1 [ 252.577184] st 3:0:3:0: st1: try direct i/o: yes (alignment 512 B) [ 252.651484] st 3:0:3:0: Attached scsi generic sg4 type 1 I've also got an ATL P1000 SCSI tape library hooked up to this same controller and port, and I can manipulate it properly using the 'mtx' program pointed to the /dev/changer alias, which points to the correct /dev/sg# device. Here's my /proc/scsi/scsi output, as you can see, I've got a bunch of devices on this system: # cat /proc/scsi/scsi Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: COMPAQ Model: HC01841729 Rev: 3208 Type: Direct-AccessANSI SCSI revision: 02 Host: scsi0 Channel: 00 Id: 01 Lun: 00 Vendor: COMPAQ Model: BD018222CA Rev: B016 Type: Direct-AccessANSI SCSI revision: 02 Host: scsi3 Channel: 00 Id: 00 Lun: 00 Vendor: ATL Model: P10006220051 Rev: 1.20 Type: Medium Changer ANSI SCSI revision: 02 Host: scsi3 Channel: 00 Id: 02 Lun: 00 Vendor: QUANTUM Model: DLT7000 Rev: 2565 Type: Sequential-AccessANSI SCSI revision: 02 Host: scsi3 Channel: 00 Id: 03 Lun: 00 Vendor: QUANTUM Model: DLT7000 Rev: 2565 Type: Sequential-AccessANSI SCSI revision: 02 Host: scsi4 Channel: 00 Id: 00 Lun: 00 Vendor: SAMSUNG Model: CDRW/DVD SM-352B Rev: T806 Type: CD-ROM ANSI SCSI revision: 05 Host: scsi6 Channel: 00 Id: 00 Lun: 00 Vendor: ATA Model: ST3320620AS Rev: 3.AA Type: Direct-AccessANSI SCSI revision: 05 Host: scsi7 Channel: 00 Id: 00 Lun: 00 Vendor: ATA Model: WDC WD3200AAKS-0 Rev: 12.0 Type: Direct-AccessANSI SCSI revision: 05 Host: scsi10 Channel: 00 Id: 00 Lun: 00 Vendor: ATA Model: WDC WD1200JB-00C Rev: 17.0 Type: Direct-AccessANSI SCSI revision: 05 Host: scsi11 Channel: 00 Id: 00 Lun: 00 Vendor: ATA Model: WDC WD1200JB-00E Rev: 15.0 Type: Direct-AccessANSI SCSI revision: 05 Host: scsi12 Channel: 00 Id: 00 Lun: 00 Vendor: Generic Model: STORAGE DEVICE Rev: 0001 Type: Direct-AccessANSI SCSI revision: 00 Host: scsi12 Channel: 00 Id: 00 Lun: 01 Vendor: Generic Model: STORAGE DEVICE Rev: 0001 Type: Direct-AccessANSI SCSI revision: 00 Host: scsi12 Channel: 00 Id: 00 Lun: 02 Vendor: Generic Model: STORAGE DEVICE Rev: 0001
