dc395x: Report

Hi,

I got a Tekram 395UW SCSI controller with one hard disk attached to it. Since the kernel droped me the line "drivers/scsi/dc395x.c: Please, contact <[email protected]> to help improve support for your system.", I give you some feedback.

The default settings of the module were not applicable for me.
When loading the module (or the driver builtin within the kernel) without any additional arguments I got a bunch of these error messages:
"dc395x: QUEUE_FULL for dev <00-0> with 1 cmnds"
(about 10 per second) and I was not able to access the disk.

Some log lines:
<snip>
dc395x: Target 00: Wide16 Sync: 48ns Offset 15 (41.7 MB/s)
Vendor: SEAGATE Model: ST3146807LC Rev: 0007
Type: Direct-Access ANSI SCSI revision:
03
sda : READ CAPACITY failed.
sda : status=12, message=00, host=7, driver=00 sda : sense not available.
sda: test WP failed, assume Write Enabled
sda: asking for cache data failed
sda: assuming drive cache: write through
sda : READ CAPACITY failed.
sda : status=12, message=00, host=7, driver=00 sda : sense not available.
sda: test WP failed, assume Write Enabled
sda: asking for cache data failed
sda: assuming drive cache: write through sda:<6>dc395x: QUEUE_FULL for dev <00-0> with 1 cmnds
dc395x: QUEUE_FULL for dev <00-0> with 1 cmnds
dc395x: QUEUE_FULL for dev <00-0> with 1 cmnds
dc395x: QUEUE_FULL for dev <00-0> with 1 cmnds <snap>

When I turned the (hotswapable) disk off the machine freezed.

Loading the module with safe=1 (or dc395x.safe=1 when builtin) fixed the problem, but the speed of the disk was terrible slow (about 2mb/sec). So I did some try and error to find the arguments with the best performance
and of course no freeze:
dev_mode=0x0f : setting this to a higher value results in the error described above
adapter_mode=0x0f : setting this to a higher value results in the error described above
max_speed=0 : highest speed available - works for me
tags : I did not notice any difference in setting this, so I left the default value
reset_delay : I was not able to set any other value. The driver always uses 1 second (i do not mind - it works for me)

I noticed that there were some dc395 updates in 2.6.17 and 2.6.18-rc.
I currently use 2.6.16 with some patches. Some of them are currently not ported to 2.6.17|2.6.18-rc, so I am not able to upgrade yet. I gave 2.6.17 a short try, but had the same "QUEUE_FULL"-error with the default values (but as I wrote: just a short try - I did not play around with it that much).

The firmware on the controller is the latest available from tekram.com (3.05).

lspci -vv:
<snip>
00:02.0 SCSI storage controller: Tekram Technology Co.,Ltd. TRM-S1040 (rev 01)
Subsystem: Tekram Technology Co.,Ltd. TRM-S1040
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium

Latency: 64, Cache Line Size 04
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at d400 [size=256]
Region 1: Memory at feaef000 (32-bit, non-prefetchable) [size=4K] Expansion ROM at feab0000 [disabled] [size=64K]
Capabilities: [dc] Power Management version 1
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
<snap>

I am not subscribed to the list - please cc me in any replies.

Regards,
Robert

Ok, I think:

1) your _device_ is buggy. If you look in drivers/scsi/scsi_devinfo.c in scsi_static_device_list[] blask list, you'll find 2 more SEAGATE drives with problems with tagged commands. Try adding your drive to the list also with BLIST_NOTQ like

{"SEAGATE", "ST3146807LC", "0007", BLIST_NOTQ}

or you can build dc395x as a module and before loading it add your device to /proc/scsi/device_info. Actually, you can even try it with your 2.6.16 kernel, ...

!!! Oh, no... dc395x doesn't use the generic blacklist table... Anyone to fix it? Until it is fixed you should forget the above and could try disabling it in the driver by either

a) uncommenting the line

#define DC395x_NO_TAGQ

b) removing " | NTC_DO_TAG_QUEUEING" from dev mode from cfg_data

c) some other dirty trick...

2) dc395x was not patched for 2.6.17, only for 2.6.18-rc*, so, would be quite interesting if you could test with that. We haven't had any reports with wide devices with this "help improve support" problem yet.

3) if you do get round to testing your system under 2.6.18-rcX, please first test with vanilla kernel without parameters, then with safe=1, then with your disk added to the blacklist (hacked dc395x.c) without and (if still needed) with safe=1. Please, send all (distinct) negotiation protocols from these tests.

Thanks
Guennadi

---
Guennadi Liakhovetski

It's a decent drive I used with other controllers before - and it worked out of the box. But maybe it's really a buggy drive..

Short answer: it works (more or less).

Long answer:
I tested it with a vanilla 2.6.18-rc3 and workaround a) "uncommenting #define DC395x_NO_TAGQ in dc395x.c".

Notes:
"unknown partition table" is fine. The disk does not have a valid partition table (dm-crypted the whole disk).
I wonder why the dc395x driver version is still the same as in 2.6.16..?

Anyway, the results are below.

Regards,
Robert

Vanilla module with no additional arguments:
<snip>
dc395x: Tekram DC395(U/UW/F), DC315(U) - ASIC TRM-S1040 v2.05, 2004/03/08
PCI: Enabling device 0000:00:02.0 (0100 -> 0103)
PCI: Found IRQ 11 for device 0000:00:02.0
dc395x: Used settings: AdapterID=07, Speed=0(20.0MHz), dev_mode=0x37
dc395x: AdaptMode=0x4e, Tags=0(01), DelayReset=1s
dc395x: (Wide) Connectors: int68 Termination: Auto Low High
dc395x: Performing initial SCSI bus reset
scsi1 : Tekram DC395(U/UW/F), DC315(U) - ASIC TRM-S1040 v2.05, 2004/03/08
dc395x: Target 00: Wide16 Sync: 48ns Offset 15 (41.7 MB/s)
Vendor: SEAGATE Model: ST3146807LC Rev: 0007
Type: Direct-Access ANSI SCSI revision: 03
sda : READ CAPACITY failed.
sda : status=12, message=00, host=7, driver=00
sda : sense not available.
sda: test WP failed, assume Write Enabled
sda: asking for cache data failed
sda: assuming drive cache: write through
sda : READ CAPACITY failed.
sda : status=12, message=00, host=7, driver=00
sda : sense not available.
sda: test WP failed, assume Write Enabled
sda: asking for cache data failed
sda: assuming drive cache: write through
sda:<6>dc395x: QUEUE_FULL for dev <00-0> with 1 cmnds
dc395x: QUEUE_FULL for dev <00-0> with 1 cmnds
dc395x: QUEUE_FULL for dev <00-0> with 1 cmnds
dc395x: QUEUE_FULL for dev <00-0> with 1 cmnds
dc395x: QUEUE_FULL for dev <00-0> with 1 cmnds
dc395x: QUEUE_FULL for dev <00-0> with 1 cmnds
dc395x: QUEUE_FULL for dev <00-0> with 1 cmnds
<snap>

Vanilla module and safe=1:
<snip>
dc395x: Tekram DC395(U/UW/F), DC315(U) - ASIC TRM-S1040 v2.05, 2004/03/08
PCI: setting IRQ 11 as level-triggered
PCI: Found IRQ 11 for device 0000:00:02.0
dc395x: Using safe settings.
dc395x: Used settings: AdapterID=07, Speed=4(06.7MHz), dev_mode=0x09
dc395x: AdaptMode=0x0f, Tags=2(04), DelayReset=3s
dc395x: (Wide) Connectors: int68 Termination: Auto Low High
dc395x: Performing initial SCSI bus reset
scsi0 : Tekram DC395(U/UW/F), DC315(U) - ASIC TRM-S1040 v2.05, 2004/03/08
Vendor: SEAGATE Model: ST3146807LC Rev: 0007
Type: Direct-Access ANSI SCSI revision: 03
SCSI device sda: 286749488 512-byte hdwr sectors (146816 MB)
sda: Write Protect is off
sda: Mode Sense: ab 00 10 08
SCSI device sda: drive cache: write back w/ FUA
SCSI device sda: 286749488 512-byte hdwr sectors (146816 MB)
sda: Write Protect is off
sda: Mode Sense: ab 00 10 08
SCSI device sda: drive cache: write back w/ FUA
sda: unknown partition table
sd 0:0:0:0: Attached scsi disk sda
<snap>

Module with NO_TAGQ workaround and no additional arguments:
<snip>
dc395x: Tekram DC395(U/UW/F), DC315(U) - ASIC TRM-S1040 v2.05, 2004/03/08
PCI: Enabling device 0000:00:02.0 (0100 -> 0103)
PCI: Found IRQ 11 for device 0000:00:02.0
dc395x: Used settings: AdapterID=07, Speed=0(20.0MHz), dev_mode=0x37
dc395x: AdaptMode=0x4e, Tags=0(01), DelayReset=1s
dc395x: (Wide) Connectors: int68 Termination: Auto Low High
dc395x: Performing initial SCSI bus reset
scsi1 : Tekram DC395(U/UW/F), DC315(U) - ASIC TRM-S1040 v2.05, 2004/03/08
dc395x: Target 00: Wide16 Sync: 48ns Offset 15 (41.7 MB/s)
Vendor: SEAGATE Model: ST3146807LC Rev: 0007
Type: Direct-Access ANSI SCSI revision: 03
SCSI device sda: 286749488 512-byte hdwr sectors (146816 MB)

BUG: warning at drivers/scsi/dc395x.c:2329/data_in_phase0()
 [<f884c768>] data_in_phase0+0x190/0x244 [dc395x]
 [<f884c15e>] dc395x_handle_interrupt+0xf7/0x128 [dc395x]
 [<f884c1c0>] dc395x_interrupt+0x31/0x5f [dc395x]
 [<c0137975>] handle_IRQ_event+0x21/0x49
 [<c0137a2e>] __do_IRQ+0x91/0xef
 [<c0104a2f>] do_IRQ+0x43/0x50
 [<c01032aa>] common_interrupt+0x1a/0x20
sda: Write Protect is off
sda: Mode Sense: ab 00 10 08
BUG: warning at drivers/scsi/dc395x.c:2329/data_in_phase0()
 [<f884c768>] data_in_phase0+0x190/0x244 [dc395x]
 [<f884c15e>] dc395x_handle_interrupt+0xf7/0x128 [dc395x]
 [<f884c1c0>] dc395x_interrupt+0x31/0x5f [dc395x]
 [<c0137975>] handle_IRQ_event+0x21/0x49
 [<c0137a2e>] __do_IRQ+0x91/0xef
 [<c0104a2f>] do_IRQ+0x43/0x50
 [<c01032aa>] common_interrupt+0x1a/0x20
SCSI device sda: drive cache: write back w/ FUA
SCSI device sda: 286749488 512-byte hdwr sectors (146816 MB)
BUG: warning at drivers/scsi/dc395x.c:2329/data_in_phase0()
 [<f884c768>] data_in_phase0+0x190/0x244 [dc395x]
 [<f884c15e>] dc395x_handle_interrupt+0xf7/0x128 [dc395x]
 [<f884c1c0>] dc395x_interrupt+0x31/0x5f [dc395x]
 [<c0137975>] handle_IRQ_event+0x21/0x49
 [<c0137a2e>] __do_IRQ+0x91/0xef
 [<c0104a2f>] do_IRQ+0x43/0x50
 [<c01032aa>] common_interrupt+0x1a/0x20
 [<c0100b10>] default_idle+0x0/0x59
 [<c0100b41>] default_idle+0x31/0x59
 [<c0100c25>] cpu_idle+0xa8/0xcf
 [<c03c07b7>] start_kernel+0x1b6/0x1b8
sda: Write Protect is off
sda: Mode Sense: ab 00 10 08
BUG: warning at drivers/scsi/dc395x.c:2329/data_in_phase0()
 [<f884c768>] data_in_phase0+0x190/0x244 [dc395x]
 [<f884c15e>] dc395x_handle_interrupt+0xf7/0x128 [dc395x]
 [<f884c1c0>] dc395x_interrupt+0x31/0x5f [dc395x]
 [<c0137975>] handle_IRQ_event+0x21/0x49
 [<c0137a2e>] __do_IRQ+0x91/0xef
 [<c0104a2f>] do_IRQ+0x43/0x50
 [<c01032aa>] common_interrupt+0x1a/0x20
 [<c0100b10>] default_idle+0x0/0x59
 [<c0100b41>] default_idle+0x31/0x59
 [<c0100c25>] cpu_idle+0xa8/0xcf
 [<c03c07b7>] start_kernel+0x1b6/0x1b8

SCSI device sda: drive cache: write back w/ FUA
sda: unknown partition table
sd 1:0:0:0: Attached scsi disk sda
<snap>

Module with NO_TAGQ workaround and safe=1:
<snip>
dc395x: Tekram DC395(U/UW/F), DC315(U) - ASIC TRM-S1040 v2.05, 2004/03/08
PCI: Enabling device 0000:00:02.0 (0100 -> 0103)
PCI: Found IRQ 11 for device 0000:00:02.0
dc395x: Using safe settings.
dc395x: Used settings: AdapterID=07, Speed=4(06.7MHz), dev_mode=0x09
dc395x: AdaptMode=0x0f, Tags=2(04), DelayReset=3s
dc395x: (Wide) Connectors: int68 Termination: Auto Low High
dc395x: Performing initial SCSI bus reset
scsi2 : Tekram DC395(U/UW/F), DC315(U) - ASIC TRM-S1040 v2.05, 2004/03/08
Vendor: SEAGATE Model: ST3146807LC Rev: 0007
Type: Direct-Access ANSI SCSI revision: 03
SCSI device sda: 286749488 512-byte hdwr sectors (146816 MB)
sda: Write Protect is off
sda: Mode Sense: ab 00 10 08
SCSI device sda: drive cache: write back w/ FUA
SCSI device sda: 286749488 512-byte hdwr sectors (146816 MB)
sda: Write Protect is off
sda: Mode Sense: ab 00 10 08
SCSI device sda: drive cache: write back w/ FUA
sda: unknown partition table
sd 2:0:0:0: Attached scsi disk sda
<snap>

I forgot to mention:
Using this workaround works with 2.6.16 and does not trigger bug().

Regards,
Robert

Yes, this is only present in 2.6.18. And what transfer rates are you getting with this workaround without safe=1? Compared to safe=1 and to other controllers / drivers?

Thanks
Guennadi
---
Guennadi Liakhovetski

Unfortunately I currently don't have another SCSI controller around (only onboard or broken ones).

I tested with 2.6.18-rc3.
"dd if=/dev/sda of=/dev/null bs=1M count=1024" (for read)
"dd if=/dev/zero of=/dev/sda bs=1M count=1024" (for write)
each 5 times (results were almost the same.. maximum difference was 0,1mb/s)

default arguments: ~37,5mb/s (read) ~37,6mb/s(write) safe=1: ~2,8mb/s (read) ~2,3mb/s (write)

Regards,
Robert

Would be interesting to find out what exactly causes these warnings. Could you, please, try the patch at the bottom of this email with 2.6.18-rc3 and see if the message it prints appears in dmesg - together with the NO_TAGQ warkaround and without safe=1.

Well, this looks much better to me. So, I think, we may say for you the problem is solved. Globally, I think, the reason why other drivers have no problems with this drive is because they are using results of the generic inquiry evaluation code, and it chooses better communication parameters than the dc395x. Would be nice to switch dc395x to do that too.

Thanks
Guennadi
---
Guennadi Liakhovetski

@@ -2326,7 +2326,14 @@
 					}
 				}
 
-				WARN_ON((fc != 0x40) == !d_left_counter);
+				if (((fc != 0x40) && !d_left_counter) ||
+				    ((fc == 0x40) && d_left_counter &&
+				     (!(srb->dcb->sync_period & WIDE_SYNC)
+				      || d_left_counter != 1)))
+					printk(KERN_WARNING "dc395x: inconsistent counters: "
+					       "FIFOCNT %u, left %u, %s\n", fc, d_left_counter,
+					       srb->dcb->sync_period & WIDE_SYNC ?
+					       "wide" : "narrow");
 
 				if (fc == 0x40 && (srb->dcb->sync_period & WIDE_SYNC)) {
 					/* Read the last byte ... */

dc395x: Tekram DC395(U/UW/F), DC315(U) - ASIC TRM-S1040 v2.05, 2004/03/08
PCI: setting IRQ 11 as level-triggered
PCI: Found IRQ 11 for device 0000:00:02.0
dc395x: Used settings: AdapterID=07, Speed=0(20.0MHz), dev_mode=0x37
dc395x: AdaptMode=0x4e, Tags=0(01), DelayReset=1s
dc395x: (Wide) Connectors: int68 Termination: Auto Low High
dc395x: Performing initial SCSI bus reset
scsi0 : Tekram DC395(U/UW/F), DC315(U) - ASIC TRM-S1040 v2.05, 2004/03/08
dc395x: Target 00: Wide16 Sync: 48ns Offset 15 (41.7 MB/s)
Vendor: SEAGATE Model: ST3146807LC Rev: 0007
Type: Direct-Access ANSI SCSI revision: 03
SCSI device sda: 286749488 512-byte hdwr sectors (146816 MB)
dc395x: inconsistent counters: FIFOCNT 64, left 16777215, wide
sda: Write Protect is off
sda: Mode Sense: ab 00 10 08
dc395x: inconsistent counters: FIFOCNT 64, left 16777215, wide SCSI device sda: drive cache: write back w/ FUA
SCSI device sda: 286749488 512-byte hdwr sectors (146816 MB)
dc395x: inconsistent counters: FIFOCNT 64, left 16777215, wide
sda: Write Protect is off
sda: Mode Sense: ab 00 10 08
dc395x: inconsistent counters: FIFOCNT 64, left 16777215, wide SCSI device sda: drive cache: write back w/ FUA
sda: unknown partition table
sd 0:0:0:0: Attached scsi disk sda

For me the problem is definetely solved. Thank you!

Unfortunately I don't have the skills for that - as you probably already noticed. (;

Hopefully someone else is willing to adapt the driver.

Regards,
Robert

Sorry, was on a holiday...

Ok, "left 16777215" = 0xffffff, which means we have read 0x01000000 from TRM_S1040_SCSI_COUNTER. There's a comment in the driver:
".....TRM_S1040_SCSI_COUNTER (24bits)"

Great, maybe you still could test the patch below (applied on the top of all my patches until now)?

Thanks
Guennadi
---
Guennadi Liakhovetski

@@ -2123,7 +2123,7 @@
 		 */
 		if (srb->total_xfer_length > DC395x_LASTPIO)
 			d_left_counter +=
-			    DC395x_read32(acb, TRM_S1040_SCSI_COUNTER);
+			    DC395x_read32(acb, TRM_S1040_SCSI_COUNTER) & ((1 << 24) - 1);
 
 		/* Is this a good idea? */
 		/*clear_fifo(acb, "DOP1"); */

@@ -2253,7 +2253,7 @@
 				DC395x_read8(acb, TRM_S1040_DMA_FIFOSTAT));
 		}
 		/* Now: Check remainig data: The SCSI counters should tell us ... */
-		sc = DC395x_read32(acb, TRM_S1040_SCSI_COUNTER);
+		sc = DC395x_read32(acb, TRM_S1040_SCSI_COUNTER) & ((1 << 24) - 1);
 		fc = DC395x_read8(acb, TRM_S1040_SCSI_FIFOCNT);
 		d_left_counter = sc + ((fc & 0x1f)
 		       << ((srb->dcb->sync_period & WIDE_SYNC) ? 1 :

@@ -2307,6 +2307,14 @@
 
 				while (len) {
 					u8 byte;
+
+					fc = DC395x_read8(acb, TRM_S1040_SCSI_FIFOCNT);
+
+					if (fc == 0x40) {
+						left_io = 0;
+						break;
+					}
+
 					byte = DC395x_read8(acb, TRM_S1040_SCSI_FIFO);
 					*virt++ = byte;
 

@@ -2317,13 +2325,6 @@
 					sg_subtract_one(srb);
 
 					len--;
-
-					fc = DC395x_read8(acb, TRM_S1040_SCSI_FIFOCNT);
-
-					if (fc == 0x40) {
-						left_io = 0;
-						break;
-					}
 				}
 
 				if (((fc != 0x40) && !d_left_counter) ||

Sure.

The warning still occurs (I used 2.6.18-rc4):

dc395x: Tekram DC395(U/UW/F), DC315(U) - ASIC TRM-S1040 v2.05, 2004/03/08
PCI: setting IRQ 11 as level-triggered
PCI: Found IRQ 11 for device 0000:00:02.0
dc395x: Used settings: AdapterID=07, Speed=0(20.0MHz), dev_mode=0x37
dc395x: AdaptMode=0x4e, Tags=0(01), DelayReset=1s
dc395x: (Wide) Connectors: int68 Termination: Auto Low High
dc395x: Performing initial SCSI bus reset
scsi0 : Tekram DC395(U/UW/F), DC315(U) - ASIC TRM-S1040 v2.05, 2004/03/08
dc395x: Target 00: Wide16 Sync: 48ns Offset 15 (41.7 MB/s)
Vendor: SEAGATE Model: ST3146807LC Rev: 0007
Type: Direct-Access ANSI SCSI revision: 03
SCSI device sda: 286749488 512-byte hdwr sectors (146816 MB)
dc395x: inconsistent counters: FIFOCNT 64, left 16777215, wide
sda: Write Protect is off
sda: Mode Sense: ab 00 10 08
dc395x: inconsistent counters: FIFOCNT 64, left 16777215, wide SCSI device sda: drive cache: write back w/ FUA
SCSI device sda: 286749488 512-byte hdwr sectors (146816 MB)
dc395x: inconsistent counters: FIFOCNT 64, left 16777215, wide
sda: Write Protect is off
sda: Mode Sense: ab 00 10 08
dc395x: inconsistent counters: FIFOCNT 64, left 16777215, wide SCSI device sda: drive cache: write back w/ FUA
sda: unknown partition table
sd 0:0:0:0: Attached scsi disk sda

Regards,
Robert

Emn, sorry, I have to ask - are you sure this is the correct output (applied the patch, recompiled and reloaded the driver)? The output looks EXACTLY the same as last time, and this is pretty strange. Well, there is still one semi-logical explanation I can come up with:

at first FIFOCNT = 1 and SCSICNT = 0xfffffe, therefore d_left_counter = 0xfffffe + (1 << 1) = 0x1000000. Then after one loop iteration d_left_counter = 0xffffff, and now FIFOCNT = 0x40. So we break out of the loop with the above funny value of d_left_counter. If this is the case, well, I don't know what this value of SCSICNT means and what to do with it (in the absence of a datasheet).

To verify this could you, please, replace the printk at line 2335 with this one:

					printk(KERN_WARNING "dc395x: inconsistent counters: "
					       "FIFOCNT %u, SCSICNT %u, left %u, %s\n", fc, sc, d_left_counter,
					       srb->dcb->sync_period & WIDE_SYNC ?
					       "wide" : "narrow");

Thanks
Guennadi
---
Guennadi Liakhovetski

Yes, I'm sure I applied the patch and used that kernel (freshly built, no modules used).

Here is the relevant output of dmesg with 2.6.18-rc4 (and your patches):

dc395x: Tekram DC395(U/UW/F), DC315(U) - ASIC TRM-S1040 v2.05, 2004/03/08
PCI: setting IRQ 11 as level-triggered
PCI: Found IRQ 11 for device 0000:00:02.0
dc395x: Used settings: AdapterID=07, Speed=0(20.0MHz), dev_mode=0x37
dc395x: AdaptMode=0x4e, Tags=0(01), DelayReset=1s
dc395x: (Wide) Connectors: int68 Termination: Auto Low High
dc395x: Performing initial SCSI bus reset
scsi0 : Tekram DC395(U/UW/F), DC315(U) - ASIC TRM-S1040 v2.05, 2004/03/08
dc395x: Target 00: Wide16 Sync: 48ns Offset 15 (41.7 MB/s)
Vendor: SEAGATE Model: ST3146807LC Rev: 0007
Type: Direct-Access ANSI SCSI revision: 03
SCSI device sda: 286749488 512-byte hdwr sectors (146816 MB)
dc395x: inconsistent counters: FIFOCNT 64, SCSICNT 16777214, left 16777215, wide
sda: Write Protect is off
sda: Mode Sense: ab 00 10 08
dc395x: inconsistent counters: FIFOCNT 64, SCSICNT 16777214, left 16777215, wide
SCSI device sda: drive cache: write back w/ FUA
SCSI device sda: 286749488 512-byte hdwr sectors (146816 MB)
dc395x: inconsistent counters: FIFOCNT 64, SCSICNT 16777214, left 16777215, wide
sda: Write Protect is off
sda: Mode Sense: ab 00 10 08
dc395x: inconsistent counters: FIFOCNT 64, SCSICNT 16777214, left 16777215, wide
SCSI device sda: drive cache: write back w/ FUA
sda: unknown partition table
sd 0:0:0:0: Attached scsi disk sda

Just to make sure I attached the patch I used.

Regards,
Robert

diff -urN linux-2.6.18-rc4.orig/drivers/scsi/dc395x.c linux-2.6.18-rc4-dc395x/drivers/scsi/dc395x.c
@@ -78,7 +78,7 @@
  * Set to disable parts of the driver
  */
 /*#define DC395x_NO_DISCONNECT*/
-/*#define DC395x_NO_TAGQ*/
+#define DC395x_NO_TAGQ
 /*#define DC395x_NO_SYNC*/
 /*#define DC395x_NO_WIDE*/
 

@@ -2123,7 +2123,7 @@
 		 */
 		if (srb->total_xfer_length > DC395x_LASTPIO)
 			d_left_counter +=
-			    DC395x_read32(acb, TRM_S1040_SCSI_COUNTER);
+			    DC395x_read32(acb, TRM_S1040_SCSI_COUNTER) & ((1 << 24) - 1);
 
 		/* Is this a good idea? */
 		/*clear_fifo(acb, "DOP1"); */

@@ -2253,7 +2253,7 @@
 				DC395x_read8(acb, TRM_S1040_DMA_FIFOSTAT));
 		}
 		/* Now: Check remainig data: The SCSI counters should tell us ... */
-		sc = DC395x_read32(acb, TRM_S1040_SCSI_COUNTER);
+		sc = DC395x_read32(acb, TRM_S1040_SCSI_COUNTER) & ((1 << 24) - 1);
 		fc = DC395x_read8(acb, TRM_S1040_SCSI_FIFOCNT);
 		d_left_counter = sc + ((fc & 0x1f)
 		       << ((srb->dcb->sync_period & WIDE_SYNC) ? 1 :

@@ -2307,6 +2307,14 @@
 
 				while (len) {
 					u8 byte;
+
+					fc = DC395x_read8(acb, TRM_S1040_SCSI_FIFOCNT);
+
+					if (fc == 0x40) {
+						left_io = 0;
+						break;
+					}
+
 					byte = DC395x_read8(acb, TRM_S1040_SCSI_FIFO);
 					*virt++ = byte;
 

@@ -2317,16 +2325,16 @@
 					sg_subtract_one(srb);
 
 					len--;
-
-					fc = DC395x_read8(acb, TRM_S1040_SCSI_FIFOCNT);
-
-					if (fc == 0x40) {
-						left_io = 0;
-						break;
-					}
 				}
 
-				WARN_ON((fc != 0x40) == !d_left_counter);
+				if (((fc != 0x40) && !d_left_counter) ||
+				    ((fc == 0x40) && d_left_counter &&
+				     (!(srb->dcb->sync_period & WIDE_SYNC)
+				      || d_left_counter != 1)))
+					printk(KERN_WARNING "dc395x: inconsistent counters: "
+					       "FIFOCNT %u, SCSICNT %u, left %u, %s\n", fc, sc, d_left_counter,
+					       srb->dcb->sync_period & WIDE_SYNC ?
+					       "wide" : "narrow");
 
 				if (fc == 0x40 && (srb->dcb->sync_period & WIDE_SYNC)) {
 					/* Read the last byte ... */

Yes, I see, indeed it is the correct patch and my suspicion from the last message was correct: SCSICNT is indeed 0xfffffe, and I have no idea what this means without docs, sorry. It doesn't look right, but not being able to reproduce the problem myself it would be a waste of your and my time and internet bandwidth trying to debug it.

Thanks
Guennadi
---
Guennadi Liakhovetski