[PATCH] Delete trailing full stop

[PATCH] Delete trailing full stop

[Matthew Wilcox]

None of the other domain validation messages have a trailing full stop,
so I don't see why this one should.

Signed-off-by: Matthew Wilcox <matthew@wil.cx>

diff --git a/drivers/scsi/scsi_transport_spi.c b/drivers/scsi/scsi_transport_spi.c
index 718a2bc..ec7bb70 100644
--- a/drivers/scsi/scsi_transport_spi.c
+++ b/drivers/scsi/scsi_transport_spi.c
@@ -1031,7 +1031,7 @@ void spi_display_xfer_agreement(struct s
 			 tp->hold_mcs ? " HMCS" : "",
 			 tmp, tp->offset);
 	} else {
-		dev_info(&starget->dev, "%sasynchronous.\n",
+		dev_info(&starget->dev, "%sasynchronous\n",
 				tp->width ? "wide " : "");
 	}
 }

Re: [PATCH] Delete trailing full stop

[Douglas Gilbert]

Matthew Wilcox wrote:
> None of the other domain validation messages have a trailing full stop,
> so I don't see why this one should.

Speaking of domain validation messages I have noticed
that either the sym53c8xx driver or scsi_transport_spi is
getting noisier in this area.

After "hot plugging" a U160 disk on a unpopulated bus
and then scanning the bus there was lots of redundant
noise on my console and log. The disk had autospin off
so a START STOP UNIT command was needed followed by a wait
for the disk to spin up. This is what I saw in my log after:
  # echo 1 > /sys/class/scsi_host/host0/scan

  Vendor: FUJITSU   Model: MAM3184MP         Rev: 0106
  Type:   Direct-Access                      ANSI SCSI revision: 03
 target0:0:3: tagged command queuing enabled, command queue depth 16.
 target0:0:3: Beginning Domain Validation
 target0:0:3: asynchronous.
 target0:0:3: wide asynchronous.
 target0:0:3: Domain Validation skipping write tests
 target0:0:3: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 62)
 target0:0:3: Ending Domain Validation
 target0:0:3: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 62)
 last message repeated 2 times
sdb: Spinning up disk....<6> target0:0:3: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 62)
 target0:0:3: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 62)
 last message repeated 7 times
.<6> target0:0:3: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 62)
 target0:0:3: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 62)
 last message repeated 7 times
.<6> target0:0:3: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 62)
 target0:0:3: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 62)
 last message repeated 7 times
.<6> target0:0:3: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 62)
 target0:0:3: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 62)
 last message repeated 7 times
.<6> target0:0:3: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 62)
 target0:0:3: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 62)
 last message repeated 7 times
.<6> target0:0:3: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 62)
 target0:0:3: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 62)
 last message repeated 7 times
.<6> target0:0:3: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 62)
 target0:0:3: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 62)
 last message repeated 7 times
.<6> target0:0:3: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 62)
 target0:0:3: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 62)
 last message repeated 7 times
.ready
SCSI device sdb: 35885344 512-byte hdwr sectors (18373 MB)
SCSI device sdb: drive cache: write back
SCSI device sdb: 35885344 512-byte hdwr sectors (18373 MB)
SCSI device sdb: drive cache: write back
 sdb: sdb1 sdb2 sdb3 sdb4 < sdb5 >
sd 0:0:3:0: Attached scsi disk sdb



Surely one "FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 62)"
message is sufficient?


The READ CAPACITY/fetching the caching mode page sequence
seems to be occurring twice. I also see this with scsi_debug
so it isn't a spi or lldd problem.

Doug Gilbert

Re: [PATCH] Delete trailing full stop

[Matthew Wilcox]

On Fri, Nov 18, 2005 at 04:42:10PM +1000, Douglas Gilbert wrote:
> Matthew Wilcox wrote:
> > None of the other domain validation messages have a trailing full stop,
> > so I don't see why this one should.
> 
> Speaking of domain validation messages I have noticed
> that either the sym53c8xx driver or scsi_transport_spi is
> getting noisier in this area.

Definitely the sym2 driver's fault.

>  target0:0:3: Beginning Domain Validation
>  target0:0:3: asynchronous.
>  target0:0:3: wide asynchronous.
>  target0:0:3: Domain Validation skipping write tests
>  target0:0:3: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 62)
>  target0:0:3: Ending Domain Validation
>  target0:0:3: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 62)
>  last message repeated 2 times
> sdb: Spinning up disk....<6> target0:0:3: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 62)
>  target0:0:3: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 62)
>  last message repeated 7 times
(etc)
> 
> Surely one "FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 62)"
> message is sufficient?

Absolutely.  Let's see why it's happening.  That message is displayed by
spi_display_xfer_agreement() which is called from three places in sym2.
However, because DT is set, it must be called from sym_setpprot() [1].
That's only called in a way which would cause this message from
sym_ppr_nego_check(), which is only called from sym_ppr_nego(), which is 
only called when receiving a PPR message.

Now, what I don't know is why the device keeps sending us a PPR message.
Do we keep sending it a PPR message?  Can you turn on negotiation
debugging (echo setdebug nego >/proc/scsi/sym53c8xx/0) and send me the
results?

[1] SDTR and WDTR clear DT.  So it must be in response to a PPR message.

Re: [PATCH] Delete trailing full stop

[Douglas Gilbert]

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

Matthew Wilcox wrote:
> On Fri, Nov 18, 2005 at 04:42:10PM +1000, Douglas Gilbert wrote:
> 
>>Matthew Wilcox wrote:
>>
>>>None of the other domain validation messages have a trailing full stop,
>>>so I don't see why this one should.
>>
>>Speaking of domain validation messages I have noticed
>>that either the sym53c8xx driver or scsi_transport_spi is
>>getting noisier in this area.
> 
> 
> Definitely the sym2 driver's fault.
> 
> 
>> target0:0:3: Beginning Domain Validation
>> target0:0:3: asynchronous.
>> target0:0:3: wide asynchronous.
>> target0:0:3: Domain Validation skipping write tests
>> target0:0:3: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 62)
>> target0:0:3: Ending Domain Validation
>> target0:0:3: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 62)
>> last message repeated 2 times
>>sdb: Spinning up disk....<6> target0:0:3: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 62)
>> target0:0:3: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 62)
>> last message repeated 7 times
> 
> (etc)
> 
>>Surely one "FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 62)"
>>message is sufficient?
> 
> 
> Absolutely.  Let's see why it's happening.  That message is displayed by
> spi_display_xfer_agreement() which is called from three places in sym2.
> However, because DT is set, it must be called from sym_setpprot() [1].
> That's only called in a way which would cause this message from
> sym_ppr_nego_check(), which is only called from sym_ppr_nego(), which is 
> only called when receiving a PPR message.
> 
> Now, what I don't know is why the device keeps sending us a PPR message.
> Do we keep sending it a PPR message?  Can you turn on negotiation
> debugging (echo setdebug nego >/proc/scsi/sym53c8xx/0) and send me the
> results?
> 
> [1] SDTR and WDTR clear DT.  So it must be in response to a PPR message.

I switched disks from a Fujitsu MAM3184 to a Seagate
ST318451 and it seems just as noisy. See attached.

If the disk is spinning when a scan is requested then
the output is succinct; so all that extra output
occurs while the disk is in the process of spinning
up (about a ten second period).

Doug Gilbert


[-- Attachment #2: sym53c8xx_scan2.txt.gz --]
[-- Type: application/x-gzip, Size: 582 bytes --]