dc395x: can't write to tape

I have a Travan NS-20 tape drive connected to a Tekram DC395UW controller. Both have worked without trouble for years. My kernel is 2.6.7, and I use the dc395x driver (built as a module) from the kernel source.

Since about a month ago, I can't write a tar archive to tape. The operation aborts before completion:

# tar -vv --one-file-system --file=/dev/st0 --create / /boot /home
tar: Removing leading `/' from member names
tar: /dev/st0: Wrote only 0 of 10240 bytes
tar: Error is not recoverable: exiting now

I've cleaned the drive with the approved head cleaner, tried three different tapes, and retensioned each tape before writing. Still no joy. I haven't rebuilt my kernel since the problem started, so it seems likely to be a hardware problem.

/var/log/kern.log says

Jan  5 22:50:18 helium kernel: dc395x: sg_update_list: sg_to_virt failed

Jan  5 22:50:18 helium kernel: st0: Error with sense data: Info fld=0x67, 

Current st0: sense = f0 4

Jan  5 22:50:18 helium kernel: ASC=80 ASCQ=98

Jan  5 22:50:18 helium kernel: Raw sense data:0xf0 0x00 0x04 0x00 0x00 0x00 
0x67 0x0a 0x00 0x00 0x00 0x00 0x80 0x98 0x00 0x00 0x00 0x00
Jan  5 22:50:18 helium kernel: st0: Error with sense data: Current st0: sense 
= 70  4
Jan  5 22:50:18 helium kernel: ASC=80 ASCQ=98
Jan  5 22:50:18 helium kernel: Raw sense data:0x70 0x00 0x04 0x00 0x00 0x00 
0x00 0x0a 0x00 0x00 0x00 0x00 0x80 0x98 0x00 0x00 0x00 0x00
Jan  5 22:50:18 helium kernel: st0: Error on write filemark.
Jan  5 22:50:18 helium kernel: st0: Error with sense data: Info 
fld=0xffffff63, Current st0: sense = f0  4
Jan  5 22:50:18 helium kernel: ASC=80 ASCQ=98
Jan  5 22:50:18 helium kernel: Raw sense data:0xf0 0x00 0x04 0xff 0xff 0xff 

0x63 0x0a 0x00 0x00 0x00 0x00 0x80 0x98 0x00 0x00 0x00 0x00

Question: from this log output, can anyone tell if my problem is more likely in the controller, or in the tape drive? I realize there's not a lot of data there... unfortunately even that doesn't mean anything to me.

To get more information, I uncommented

#define DEBUG_MASK (DBG_0|DBG_1|DBG_SG|DBG_FIFO|DBG_PIO)

in drivers/scsi/dc395x.c, rebuilt and reinserted the module, and tried to tar again. But this resulted in multi-GB log files, so if there's a smaller subset of debug options that would be useful, please let me know and I'll try again.

I'd like very much to keep using this tape drive for several more years. It's noisy and slow, but 10 GB/tape still isn't bad, and to replace the drive and 6 tapes would cost around $400, even today.

OTOH, SCSI cards are cheap and I wouldn't mind junking my old DC395 if it's at fault.

Thanks in advance for any light you can shed.
Andrew.
-
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

Quoted 1 line

Jan  5 22:50:18 helium kernel: dc395x: sg_update_list: sg_to_virt failed

This doesn't look good. However, after a brief look at the code, I cannot say what exactly went wrong there. Jamie?

Quoted 2 lines

Jan  5 22:50:18 helium kernel: st0: Error with sense data: Info fld=0x67,

Current st0: sense = f0 4

Sense key 4 - hardware error.

Quoted 1 line

Jan  5 22:50:18 helium kernel: ASC=80 ASCQ=98

Additional sense code 0x80 - vendor specific.

So, the sense codes indicate a hardware problem on the tape drive, but the first message might mean a software bug. You don't have highmem on that machine (> 1GB RAM), do you?

Quoted 4 lines

Quoted 1 line

Jan  5 22:50:18 helium kernel: dc395x: sg_update_list: sg_to_virt failed

This doesn't look good. However, after a brief look at the code, I cannot say what exactly went wrong there. Jamie?

I didn't mention it before, but I've gotten that particular message for a long time, even when the tape drive used to work. I reported on it several months ago on this list
(http://marc.theaimsgroup.com/?l=linux-scsi&m=108039964822342&w=2) in connection with a balky CD burner, which I've since junked. After some work and upgrading my kernel, I got the CD burner working again, but the flood of sg_to_virt failed messages continued. Jaime finally recommended that I just disable them, which I did until I got rid of the CD burner. Maybe relevant...

Quoted 7 lines

Quoted 2 lines

Jan  5 22:50:18 helium kernel: st0: Error with sense data: Info fld=0x67,

Current st0: sense = f0 4

Sense key 4 - hardware error.

Quoted 1 line

Jan  5 22:50:18 helium kernel: ASC=80 ASCQ=98

Quoted 5 lines

Additional sense code 0x80 - vendor specific.

So, the sense codes indicate a hardware problem on the tape drive, but the first message might mean a software bug. You don't have highmem on that machine (> 1GB RAM), do you?

CONFIG_HIGHMEM4G is enabled in the kernel, and I have 1 GiB of RAM.

Quoted 1 line · Andrew Schulman

Quoted 1 line

Quoted 1 line

Jan  5 22:50:18 helium kernel: dc395x: sg_update_list: sg_to_virt failed

Quoted 8 lines

Quoted 8 lines

Quoted 2 lines

Jan  5 22:50:18 helium kernel: st0: Error with sense data: Info fld=0x67,

Current st0: sense = f0 4

Sense key 4 - hardware error.

Quoted 1 line

Jan  5 22:50:18 helium kernel: ASC=80 ASCQ=98

Additional sense code 0x80 - vendor specific.

Quoted 6 lines

Quoted 5 lines

Quoted 2 lines

Jan  5 22:50:18 helium kernel: dc395x: sg_update_list: sg_to_virt

failed

This doesn't look good. However, after a brief look at the code, I cannot say what exactly went wrong there. Jamie?

Quoted 2 lines

I didn't mention it before, but I've gotten that particular message for a long time, even when the tape drive used to work.

Could you try disabling highmem either try a kernel without highmem support, or boot with mem=900M, or remove a part of your RAM (if you don't have to saw your RAMs for that:-)), maybe, booting with highmem=0, or with nohighio.

Quoted 4 lines

Quoted 4 lines

Quoted 2 lines

Jan  5 22:50:18 helium kernel: st0: Error with sense data: Info

fld=0x67, Current st0: sense = f0 4

Sense key 4 - hardware error.

Still, your tape problem seems to be unrelated. Do you have a chance to test it in another system / with another controller?

Quoted 7 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Jan  5 22:50:18 helium kernel: dc395x: sg_update_list: sg_to_virt

failed

Could you try disabling highmem either try a kernel without highmem support, or boot with mem=900M, or remove a part of your RAM (if you don't have to saw your RAMs for that:-)), maybe, booting with highmem=0, or with nohighio.

Okay, I finally got to this. Rebooted with mem=900M. Unfortunately tar fails as before:

tar: /dev/st0: Wrote only 0 of 10240 bytes
tar: Error is not recoverable: exiting now

I had rebuilt dc395x with

#define DEBUG_MASK (DBG_0|DBG_1|DBG_SG|DBG_FIFO|DBG_PIO)

uncommented in dc395x.c. Here's what I got:

# tail -40 /var/log/kern.log
Jan 11 06:29:18 helium kernel: dc395x: srb_done: (pid#4596449) <02-0>
Jan 11 06:29:18 helium kernel: dc395x: srb_done: srb=f6aa2eec sg=0(0/1) 
buf=e7c64000 addr=e7c64000
Jan 11 06:29:18 helium kernel: dc395x: srb_done: AUTO_REQSENSE1
Jan 11 06:29:18 helium kernel: dc395x: pci_unmap_srb_sense: buffer=12a69452
Jan 11 06:29:18 helium kernel: dc395x: ReqSense: MEDIUM_ERROR cmnd=0x10 <02-0> 
stat=0 scan=1 sense=0x03 ASC=0x0c ASCQ=0x00 (0x00000000 0x00000000)

I have your other suggestions and will get to them as soon as I have time.

Quoted 5 lines

Okay, I finally got to this. Rebooted with mem=900M. Unfortunately tar fails as before:

tar: /dev/st0: Wrote only 0 of 10240 bytes
tar: Error is not recoverable: exiting now

I didn't expect disabling highmem to fix _this_ error. But do you still see the "dc395x: sg_update_list: sg_to_virt failed" message with 900M? Perhaps, the most interesting test would be with my patch...

...well, could you just keep the log for now, maybe we'll have a look at it later, I'd just first try to fix the highmem problem, before trying to figure out what's going on with your tape drive. BTW, when it worked, you already had 1G RAM in the PC, right?

Quoted 1 line

Jan  5 22:50:18 helium kernel: dc395x: sg_update_list: sg_to_virt failed

This doesn't look good. However, after a brief look at the code, I cannot say what exactly went wrong there. Jamie?

On Thu, Jan 06, 2005 at 10:48:38PM +0100, Guennadi Liakhovetski wrote:
[...]

Quoted 4 lines

Quoted 1 line

Jan  5 22:50:18 helium kernel: dc395x: sg_update_list: sg_to_virt failed

This doesn't look good. However, after a brief look at the code, I cannot say what exactly went wrong there. Jamie?

This messages has been happening in the driver for ever for some people (mos tlikely related to specific devices they are using?). I

believe the sg_to_virt thing is trying to convert from the bus address back to the virtual address to be able to recaculate the position for the next transfer after a partial transfer. I've never been able to actually reproduce this specific problem myself.

All the s/g list handling stuff really needs to be re-written. I'm certain that it's not high-mem safe and another rather nasty thing is that it modifies the sg lists after dma mapping them in some situations which isn't really on (and seems to be the cause of the hangs I see when running on sparc64 with some additional patches I have to support big endien machines.)

The driver is full of "hardware bug workarounds". Jamie, are those PIO operations really needed? Do you ever see, that DMA doesn't transfer the last 1-3 bytes of the segment?

I could try to improve the highmem situation / sg-handling. Or do you plan to do it, Jamie?

On Sun, Jan 09, 2005 at 12:42:26PM +0100, Guennadi Liakhovetski wrote:
[...]

Quoted 2 lines

I could try to improve the highmem situation / sg-handling. Or do you plan to do it, Jamie?

It's on my list of things to do, but I doubt I'll have any time to do anything about in the next few months. So if you have the time and desire please go ahead! I'll can test any changes you make (with a CD-R/W, tape-drive and HDD), although it may take me a week or two to get around to it.

Quoted 8 lines

Quoted 2 lines

I could try to improve the highmem situation / sg-handling. Or do you plan to do it, Jamie?

It's on my list of things to do, but I doubt I'll have any time to do anything about in the next few months. So if you have the time and desire please go ahead! I'll can test any changes you make (with a CD-R/W, tape-drive and HDD), although it may take me a week or two to get around to it.

Ok, less than 2 weeks and here comes the first attempt. It removes page_to_virt and maps sg lists dynamically. Please, review, test. Slightly tested here - without highmem.

Quoted 9 lines

Quoted 8 lines

Quoted 2 lines

I could try to improve the highmem situation / sg-handling. Or do you plan to do it, Jamie?

It's on my list of things to do, but I doubt I'll have any time to do anything about in the next few months. So if you have the time and desire please go ahead! I'll can test any changes you make (with a CD-R/W, tape-drive and HDD), although it may take me a week or two to get around to it.

Quoted 3 lines

Ok, less than 2 weeks and here comes the first attempt. It removes page_to_virt and maps sg lists dynamically. Please, review, test. Slightly tested here - without highmem.

Guennadi and Jamie, thanks for your help on this. However, I'm afraid I have to bail out at this point. My tape drive was the only reason I was keeping my old DC395UW controller going, and it has now gone bad. So I've had to yank both the card and tape drive and install a different backup solution. So, I can't test any patches.

Quoted 10 lines · Jamie Lenehan

On Sun, Jan 09, 2005 at 12:42:26PM +0100, Guennadi Liakhovetski wrote:
[...]

Quoted 2 lines

I could try to improve the highmem situation / sg-handling. Or do you plan to do it, Jamie?

It's on my list of things to do, but I doubt I'll have any time to do anything about in the next few months. So if you have the time and desire please go ahead! I'll can test any changes you make (with a CD-R/W, tape-drive and HDD), although it may take me a week or two to get around to it.

Ok, less than 2 weeks and here comes the first attempt. It removes page_to_virt and maps sg lists dynamically. Please, review, test. Slightly tested here - without highmem.

Thanks
Guennadi
---
Guennadi Liakhovetski

Signed-off-by Guennadi Liakhovetski <[email protected]>

diff -u a/drivers/scsi/dc395x.c b/drivers/scsi/dc395x.c

drivers/scsi/dc395x.c +28 -13

@@ -182,7 +182,7 @@
  * cross a page boundy.
  */
 #define SEGMENTX_LEN	(sizeof(struct SGentry)*DC395x_MAX_SG_LISTENTRY)
-
+#define VIRTX_LEN	(sizeof(void *) * DC395x_MAX_SG_LISTENTRY)
 
 struct SGentry {
 	u32 address;		/* bus! address */

@@ -234,6 +234,7 @@
 	u8 sg_count;			/* No of HW sg entries for this request */
 	u8 sg_index;			/* Index of HW sg entry for this request */
 	u32 total_xfer_length;		/* Total number of bytes remaining to be transfered */
+	void **virt_map;
 	unsigned char *virt_addr;	/* Virtual address of current transfer position */
 
 	/*

@@ -1020,14 +1021,14 @@
 			reqlen, cmd->request_buffer, cmd->use_sg,
 			srb->sg_count);
 
-		srb->virt_addr = page_address(sl->page);
 		for (i = 0; i < srb->sg_count; i++) {
-			u32 busaddr = (u32)sg_dma_address(&sl[i]);
-			u32 seglen = (u32)sl[i].length;
-			sgp[i].address = busaddr;
+			u32 seglen = (u32)sg_dma_len(sl + i);
+			sgp[i].address = (u32)sg_dma_address(sl + i);
 			sgp[i].length = seglen;
 			srb->total_xfer_length += seglen;
+			srb->virt_map[i] = kmap(sl[i].page);
 		}
+		srb->virt_addr = srb->virt_map[0];
 		sgp += srb->sg_count - 1;
 
 		/*

@@ -1964,6 +1965,7 @@
 	int segment = cmd->use_sg;
 	u32 xferred = srb->total_xfer_length - left; /* bytes transfered */
 	struct SGentry *psge = srb->segment_x + srb->sg_index;
+	void **virt = srb->virt_map;
 
 	dprintkdbg(DBG_0,
 		"sg_update_list: Transfered %i of %i bytes, %i remain\n",

@@ -2003,16 +2005,16 @@
 
 	/* We have to walk the scatterlist to find it */
 	sg = (struct scatterlist *)cmd->request_buffer;
+	idx = 0;
 	while (segment--) {
 		unsigned long mask =
 		    ~((unsigned long)sg->length - 1) & PAGE_MASK;
 		if ((sg_dma_address(sg) & mask) == (psge->address & mask)) {
-			srb->virt_addr = (page_address(sg->page)
-					   + psge->address -
-					   (psge->address & PAGE_MASK));
+			srb->virt_addr = virt[idx] + (psge->address & ~PAGE_MASK);
 			return;
 		}
 		++sg;
+		++idx;
 	}
 
 	dprintkl(KERN_ERR, "sg_update_list: sg_to_virt failed\n");

@@ -2138,7 +2140,7 @@
 				DC395x_read32(acb, TRM_S1040_DMA_CXCNT));
 		}
 		/*
-		 * calculate all the residue data that not yet tranfered
+		 * calculate all the residue data that not yet transfered
 		 * SCSI transfer counter + left in SCSI FIFO data
 		 *
 		 * .....TRM_S1040_SCSI_COUNTER (24bits)

@@ -3256,6 +3258,7 @@
 	struct scsi_cmnd *cmd = srb->cmd;
 	enum dma_data_direction dir = cmd->sc_data_direction;
 	if (cmd->use_sg && dir != PCI_DMA_NONE) {
+		int i;
 		/* unmap DC395x SG list */
 		dprintkdbg(DBG_SG, "pci_unmap_srb: list=%08x(%05x)\n",
 			srb->sg_bus_addr, SEGMENTX_LEN);

@@ -3265,6 +3268,8 @@
 		dprintkdbg(DBG_SG, "pci_unmap_srb: segs=%i buffer=%p\n",
 			cmd->use_sg, cmd->request_buffer);
 		/* unmap the sg segments */
+		for (i = 0; i < srb->sg_count; i++)
+			kunmap(virt_to_page(srb->virt_map[i]));
 		pci_unmap_sg(acb->dev,
 			     (struct scatterlist *)cmd->request_buffer,
 			     cmd->use_sg, dir);

@@ -3311,7 +3316,7 @@
 
 	if (cmd->use_sg) {
 		struct scatterlist* sg = (struct scatterlist *)cmd->request_buffer;
-		ptr = (struct ScsiInqData *)(page_address(sg->page) + sg->offset);
+		ptr = (struct ScsiInqData *)(srb->virt_map[0] + sg->offset);
 	} else {
 		ptr = (struct ScsiInqData *)(cmd->request_buffer);
 	}

@@ -4246,8 +4251,9 @@
 	const unsigned srbs_per_page = PAGE_SIZE/SEGMENTX_LEN;
 
 	for (i = 0; i < DC395x_MAX_SRB_CNT; i += srbs_per_page)
-		if (acb->srb_array[i].segment_x)
-			kfree(acb->srb_array[i].segment_x);
+		kfree(acb->srb_array[i].segment_x);
+
+	vfree(acb->srb_array[0].virt_map);
 }
 
 

@@ -4263,9 +4269,12 @@
 	int srb_idx = 0;
 	unsigned i = 0;
 	struct SGentry *ptr;
+	void **virt_array;
 
-	for (i = 0; i < DC395x_MAX_SRB_CNT; i++)
+	for (i = 0; i < DC395x_MAX_SRB_CNT; i++) {
 		acb->srb_array[i].segment_x = NULL;
+		acb->srb_array[i].virt_map = NULL;
+	}
 
 	dprintkdbg(DBG_1, "Allocate %i pages for SG tables\n", pages);
 	while (pages--) {

@@ -4286,6 +4295,19 @@
 		    ptr + (i * DC395x_MAX_SG_LISTENTRY);
 	else
 		dprintkl(KERN_DEBUG, "No space for tmsrb SG table reserved?!\n");
+
+	virt_array = vmalloc((DC395x_MAX_SRB_CNT + 1) * DC395x_MAX_SG_LISTENTRY * sizeof(void*));
+
+	if (!virt_array) {
+		adapter_sg_tables_free(acb);
+		return 1;

Two weeks since I posted this patch - ping...

Quoted 169 lines · Jamie Lenehan

Quoted 11 lines · Guennadi Liakhovetski

[...]

Quoted 2 lines

I could try to improve the highmem situation / sg-handling. Or do you plan to do it, Jamie?

It's on my list of things to do, but I doubt I'll have any time to do anything about in the next few months. So if you have the time and desire please go ahead! I'll can test any changes you make (with a CD-R/W, tape-drive and HDD), although it may take me a week or two to get around to it.

Ok, less than 2 weeks and here comes the first attempt. It removes page_to_virt and maps sg lists dynamically. Please, review, test. Slightly tested here - without highmem.

Thanks
Guennadi
---
Guennadi Liakhovetski

Signed-off-by Guennadi Liakhovetski <[email protected]>

diff -u a/drivers/scsi/dc395x.c b/drivers/scsi/dc395x.c

drivers/scsi/dc395x.c +34 -13

@@ -182,7 +182,7 @@
  * cross a page boundy.
  */
 #define SEGMENTX_LEN	(sizeof(struct SGentry)*DC395x_MAX_SG_LISTENTRY)
-
+#define VIRTX_LEN	(sizeof(void *) * DC395x_MAX_SG_LISTENTRY)
 
 struct SGentry {
 	u32 address;		/* bus! address */

@@ -234,6 +234,7 @@
 	u8 sg_count;			/* No of HW sg entries for this request */
 	u8 sg_index;			/* Index of HW sg entry for this request */
 	u32 total_xfer_length;		/* Total number of bytes remaining to be transfered */
+	void **virt_map;
 	unsigned char *virt_addr;	/* Virtual address of current transfer position */
 
 	/*

@@ -1020,14 +1021,14 @@
 			reqlen, cmd->request_buffer, cmd->use_sg,
 			srb->sg_count);
 
-		srb->virt_addr = page_address(sl->page);
 		for (i = 0; i < srb->sg_count; i++) {
-			u32 busaddr = (u32)sg_dma_address(&sl[i]);
-			u32 seglen = (u32)sl[i].length;
-			sgp[i].address = busaddr;
+			u32 seglen = (u32)sg_dma_len(sl + i);
+			sgp[i].address = (u32)sg_dma_address(sl + i);
 			sgp[i].length = seglen;
 			srb->total_xfer_length += seglen;
+			srb->virt_map[i] = kmap(sl[i].page);
 		}
+		srb->virt_addr = srb->virt_map[0];
 		sgp += srb->sg_count - 1;
 
 		/*

@@ -1964,6 +1965,7 @@
 	int segment = cmd->use_sg;
 	u32 xferred = srb->total_xfer_length - left; /* bytes transfered */
 	struct SGentry *psge = srb->segment_x + srb->sg_index;
+	void **virt = srb->virt_map;
 
 	dprintkdbg(DBG_0,
 		"sg_update_list: Transfered %i of %i bytes, %i remain\n",

@@ -2003,16 +2005,16 @@
 
 	/* We have to walk the scatterlist to find it */
 	sg = (struct scatterlist *)cmd->request_buffer;
+	idx = 0;
 	while (segment--) {
 		unsigned long mask =
 		    ~((unsigned long)sg->length - 1) & PAGE_MASK;
 		if ((sg_dma_address(sg) & mask) == (psge->address & mask)) {
-			srb->virt_addr = (page_address(sg->page)
-					   + psge->address -
-					   (psge->address & PAGE_MASK));
+			srb->virt_addr = virt[idx] + (psge->address & ~PAGE_MASK);
 			return;
 		}
 		++sg;
+		++idx;
 	}
 
 	dprintkl(KERN_ERR, "sg_update_list: sg_to_virt failed\n");

@@ -2138,7 +2140,7 @@
 				DC395x_read32(acb, TRM_S1040_DMA_CXCNT));
 		}
 		/*
-		 * calculate all the residue data that not yet tranfered
+		 * calculate all the residue data that not yet transfered
 		 * SCSI transfer counter + left in SCSI FIFO data
 		 *
 		 * .....TRM_S1040_SCSI_COUNTER (24bits)

@@ -3256,6 +3258,7 @@
 	struct scsi_cmnd *cmd = srb->cmd;
 	enum dma_data_direction dir = cmd->sc_data_direction;
 	if (cmd->use_sg && dir != PCI_DMA_NONE) {
+		int i;
 		/* unmap DC395x SG list */
 		dprintkdbg(DBG_SG, "pci_unmap_srb: list=%08x(%05x)\n",
 			srb->sg_bus_addr, SEGMENTX_LEN);

@@ -3265,6 +3268,8 @@
 		dprintkdbg(DBG_SG, "pci_unmap_srb: segs=%i buffer=%p\n",
 			cmd->use_sg, cmd->request_buffer);
 		/* unmap the sg segments */
+		for (i = 0; i < srb->sg_count; i++)
+			kunmap(virt_to_page(srb->virt_map[i]));
 		pci_unmap_sg(acb->dev,
 			     (struct scatterlist *)cmd->request_buffer,
 			     cmd->use_sg, dir);

@@ -3311,7 +3316,7 @@
 
 	if (cmd->use_sg) {
 		struct scatterlist* sg = (struct scatterlist *)cmd->request_buffer;
-		ptr = (struct ScsiInqData *)(page_address(sg->page) + sg->offset);
+		ptr = (struct ScsiInqData *)(srb->virt_map[0] + sg->offset);
 	} else {
 		ptr = (struct ScsiInqData *)(cmd->request_buffer);
 	}

@@ -4246,8 +4251,9 @@
 	const unsigned srbs_per_page = PAGE_SIZE/SEGMENTX_LEN;
 
 	for (i = 0; i < DC395x_MAX_SRB_CNT; i += srbs_per_page)
-		if (acb->srb_array[i].segment_x)
-			kfree(acb->srb_array[i].segment_x);
+		kfree(acb->srb_array[i].segment_x);
+
+	vfree(acb->srb_array[0].virt_map);
 }
 
 

@@ -4263,9 +4269,12 @@
 	int srb_idx = 0;
 	unsigned i = 0;
 	struct SGentry *ptr;
+	void **virt_array;
 
-	for (i = 0; i < DC395x_MAX_SRB_CNT; i++)
+	for (i = 0; i < DC395x_MAX_SRB_CNT; i++) {
 		acb->srb_array[i].segment_x = NULL;
+		acb->srb_array[i].virt_map = NULL;
+	}
 
 	dprintkdbg(DBG_1, "Allocate %i pages for SG tables\n", pages);
 	while (pages--) {

@@ -4286,6 +4295,19 @@
 		    ptr + (i * DC395x_MAX_SG_LISTENTRY);
 	else
 		dprintkl(KERN_DEBUG, "No space for tmsrb SG table reserved?!\n");
+
+	virt_array = vmalloc((DC395x_MAX_SRB_CNT + 1) * DC395x_MAX_SG_LISTENTRY * sizeof(void*));
+
+	if (!virt_array) {
+		adapter_sg_tables_free(acb);
+		return 1;
+	}
+
+	for (i = 0; i < DC395x_MAX_SRB_CNT + 1; i++) {
+		acb->srb_array[i].virt_map = virt_array;
+		virt_array += DC395x_MAX_SG_LISTENTRY;
+	}

drivers/scsi/dc395x.c line 4313

Quoted 5 lines

drivers/scsi/dc395x.c +1 -0

+
 	return 0;
 }
 

---
Guennadi Liakhovetski

Quoted 1 line · Guennadi Liakhovetski

Two weeks since I posted this patch - ping...

...and another two weeks since you, Jamie, replied to me privately. Just wanted to say, it would be good to get this bug fixed for the post-2.6.11 SCSI patch.