From: Andrew Morton <akpm@osdl.org>
To: Fajun Chen <fajunchen@gmail.com>
Cc: linux-scsi@vger.kernel.org, linux-ide@vger.kernel.org,
dougg@torque.net, jgarzik@pobox.com, htejun@gmail.com,
alan@lxorguk.ukuu.org.uk, rmk@arm.linux.org.uk
Subject: Re: Any known issues to cause data miscompares on sg read/write on 2.6.15.4 and 2.6.18-rc2?
Date: Sun, 20 Aug 2006 10:42:55 -0700 [thread overview]
Message-ID: <20060820104255.25c88623.akpm@osdl.org> (raw)
In-Reply-To: <8202f4270608200230s34aa9505s2426f3f3b90fa7ec@mail.gmail.com>
On Sun, 20 Aug 2006 03:30:56 -0600
"Fajun Chen" <fajunchen@gmail.com> wrote:
> Hi Folks,
>
> I use ATA pass through via sg ioctl interface for data read/write. Two
> kernels were tested:
> Linux 2.6.15.4 with Jeff Garzik's libata patch (pata support)
> Linux 2.6.18-rc2 with Jeff Garzik's git libata patch (new EH, hotplug,
> pata support)
> Hardware: ARM IOP80321 with PCI-X
> Host adapters: sata Sil3124 and pata Sil680
> Test algorithm: random write-read-compare (same range)
>
> I've tried sg mmap, direct and indirect IO on both 2.6.18-rc2 and
> 2.6.15.4 release, none of the combinations survived data compare
> overnight test. I also tried to change cache policy to write through
> on 2.6.15.4, no luck either. Several different symptoms were
> observed among the failures:
> 1. A few bytes in a data pattern were not written correctly to the
> disc (low data miscompare rate)
> 2. Pretty much none of the data were written correctly to the disc
> (high data miscompare rate)
> 3. Data were written to the disc correctly but miscompares when read
> it back. What's weird is that when the read buffer was printed out
> right after data miscompare , it contains the correct data!
> Sg write failures (symptom #1 and #2) are more typical than read
> failure (symptom #3). This problem has been observed on many
> different test machines with both pata and sata drives.
>
> I don't know of a good way to trace and isolate the problem yet. Since
> data miscompare issue can be caused by issues from different
> subsystems, I cc'ed some subsystem maintainers here. Any information
> or suggestions are greatly appreciated.
>
Have you tested the same hardware to the same extent without using the SG
interface? Say, using read() and write()? That'll help us determine
whether the problem is related to the sg stuff, or to something else, like
a hardware failure.
next prev parent reply other threads:[~2006-08-20 17:43 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-20 9:30 Any known issues to cause data miscompares on sg read/write on 2.6.15.4 and 2.6.18-rc2? Fajun Chen
2006-08-20 17:42 ` Andrew Morton [this message]
2006-08-20 23:19 ` Fajun Chen
2006-08-21 1:22 ` Douglas Gilbert
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=20060820104255.25c88623.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=dougg@torque.net \
--cc=fajunchen@gmail.com \
--cc=htejun@gmail.com \
--cc=jgarzik@pobox.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=rmk@arm.linux.org.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).