dc395x: Report

dc395x: Report

[Robert Annessi]

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 <linux-scsi@vger.kernel.org> 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 
 >TAbort- <TAbort- <MAbort- >SERR- <PERR-
         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

Re: dc395x: Report

[Guennadi Liakhovetski]

On Tue, 1 Aug 2006, Robert Annessi wrote:

> 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
> <linux-scsi@vger.kernel.org> 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.

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

> 
> 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 >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
>         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
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

---
Guennadi Liakhovetski

Re: dc395x: Report

[Robert Annessi]

[-- Attachment #1: Type: text/plain, Size: 9073 bytes --]

On 08/02/06 01:24, Guennadi Liakhovetski wrote:
> On Tue, 1 Aug 2006, Robert Annessi wrote:
>>
>> 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.
> 
> 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


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..


> {"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.


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>


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: dc395x: Report

[Robert Annessi]

[-- Attachment #1: Type: text/plain, Size: 222 bytes --]

On 08/02/06 01:24, Guennadi Liakhovetski wrote:
> a) uncommenting the line
> 
> #define DC395x_NO_TAGQ

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

Regards,
Robert


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: dc395x: Report

[Guennadi Liakhovetski]

On Wed, 2 Aug 2006, Robert Annessi wrote:

> On 08/02/06 01:24, Guennadi Liakhovetski wrote:
> > a) uncommenting the line
> > 
> > #define DC395x_NO_TAGQ
> 
> I forgot to mention:
> Using this workaround works with 2.6.16 and does not trigger bug().

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

Re: dc395x: Report

[Robert Annessi]

[-- Attachment #1: Type: text/plain, Size: 682 bytes --]

On 08/02/06 12:11, Guennadi Liakhovetski wrote:
> 
> 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?

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: dc395x: Report

[Guennadi Liakhovetski]

On Wed, 2 Aug 2006, Robert Annessi wrote:

> 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

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.

> 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)

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

--- a/drivers/scsi/dc395x.c	2006-06-09 00:18:41.000000000 +0200
+++ b/drivers/scsi/dc395x.c	2006-08-02 23:42:37.000000000 +0200
@@ -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 ... */

Re: dc395x: Report

[Robert Annessi]

[-- Attachment #1: Type: text/plain, Size: 2698 bytes --]

On 08/03/06 00:07, Guennadi Liakhovetski wrote:
> On Wed, 2 Aug 2006, Robert Annessi wrote:
> 
>> 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
> 
> 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.


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


> 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 

For me the problem is definetely solved. Thank you!


> 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.

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: dc395x: Report

[Guennadi Liakhovetski]

Sorry, was on a holiday...

On Thu, 3 Aug 2006, Robert Annessi wrote:

> 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

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)"

> > 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 
> 
> For me the problem is definetely solved. Thank you!

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

Thanks
Guennadi
---
Guennadi Liakhovetski

--- drivers/scsi/dc395x.c-20060811	2006-08-12 19:56:50.000000000 +0200
+++ drivers/scsi/dc395x.c	2006-08-12 20:01:42.000000000 +0200
@@ -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) ||

Re: dc395x: Report

[Robert Annessi]

[-- Attachment #1: Type: text/plain, Size: 1556 bytes --]

On 08/12/06 20:06, Guennadi Liakhovetski wrote:
> Great, maybe you still could test the patch below (applied on the top of 
> all my patches until now)?

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: dc395x: Report

[Guennadi Liakhovetski]

On Sun, 13 Aug 2006, Robert Annessi wrote:

> On 08/12/06 20:06, Guennadi Liakhovetski wrote:
> > Great, maybe you still could test the patch below (applied on the top of 
> > all my patches until now)?
> 
> 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

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

Re: dc395x: Report

[Robert Annessi]

[-- Attachment #1.1: Type: text/plain, Size: 2720 bytes --]

On 08/13/06 21:47, Guennadi Liakhovetski wrote:
> 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 

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


> 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");



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

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: linux-2.6.18-rc4-dc395x.patch --]
[-- Type: text/x-patch; name="linux-2.6.18-rc4-dc395x.patch", Size: 2250 bytes --]

diff -urN linux-2.6.18-rc4.orig/drivers/scsi/dc395x.c linux-2.6.18-rc4-dc395x/drivers/scsi/dc395x.c
--- linux-2.6.18-rc4.orig/drivers/scsi/dc395x.c	2006-08-13 23:30:21.000000000 +0200
+++ linux-2.6.18-rc4-dc395x/drivers/scsi/dc395x.c	2006-08-13 23:34:05.000000000 +0200
@@ -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 ... */

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: dc395x: Report

[Guennadi Liakhovetski]

On Mon, 14 Aug 2006, Robert Annessi wrote:

> dc395x: inconsistent counters: FIFOCNT 64, SCSICNT 16777214, left 16777215, wide

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