From: Douglas Gilbert <dougg@torque.net>
To: Matthew Wilcox <matthew@wil.cx>
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH] Delete trailing full stop
Date: Sat, 19 Nov 2005 10:48:57 +1000 [thread overview]
Message-ID: <437E7679.2040700@torque.net> (raw)
In-Reply-To: <20051118132048.GI17171@parisc-linux.org>
[-- 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 --]
prev parent reply other threads:[~2005-11-19 0:47 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-17 18:13 [PATCH] Delete trailing full stop Matthew Wilcox
2005-11-18 6:42 ` Douglas Gilbert
2005-11-18 13:20 ` Matthew Wilcox
2005-11-19 0:48 ` Douglas Gilbert [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=437E7679.2040700@torque.net \
--to=dougg@torque.net \
--cc=linux-scsi@vger.kernel.org \
--cc=matthew@wil.cx \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.