From: Pavel Machek <pavel@suse.cz>
To: kernel list <linux-kernel@vger.kernel.org>,
benh@kernel.crashing.org, jgarzik@pobox.com
Subject: sata_svw data corruption, strange problems
Date: Tue, 17 Jun 2008 11:36:02 +0200 [thread overview]
Message-ID: <20080617093602.GA28140@elf.ucw.cz> (raw)
I see strange problems on machine with sata_svw. The machine seems to
corrupt data every few days (ext3 error, dir index corrupted), and has
some other very strange problems (keyboard misbehaves, pulling out
SATA disk cures it, see
https://bugzilla.novell.com/show_bug.cgi?id=400772 ).
Then I got to the comment
writeb(dmactl | ATA_DMA_START, mmio + ATA_DMA_CMD);
/* There is a race condition in certain SATA controllers that
can
be seen when the r/w command is given to the controller
before the
host DMA is started. On a Read command, the controller
would initiate
the command to the drive even before it sees the DMA
start. When there
are very fast drives connected to the controller, or when
the data request
hits in the drive cache, there is the possibility that the
drive returns a part
or all of the requested data to the controller before the
DMA start is issued.
In this case, the controller would become confused as to
what to do with the data.
In the worst case when all the data is returned back to the
controller, the
controller could hang. In other cases it could return
partial data returning
in data corruption. This problem has been seen in PPC
systems and can also appear
on an system with very fast disks, where the SATA
controller is sitting behind a
number of bridges, and hence there is significant latency
between the r/w command
and the start command. */
/* issue r/w command if the access is to ATA*/
if (qc->tf.protocol == ATA_PROT_DMA)
...and that would certainly explain what we are seeing. Are
serverworks controllers broken by design?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
next reply other threads:[~2008-06-17 10:41 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-17 9:36 Pavel Machek [this message]
2008-06-23 0:37 ` sata_svw data corruption, strange problems Tejun Heo
2008-06-23 8:20 ` Pavel Machek
2008-06-23 8:22 ` Tejun Heo
2008-06-23 8:39 ` Andreas Schwab
2008-06-23 8:53 ` Pavel Machek
2008-06-23 8:56 ` Tejun Heo
2008-06-23 9:01 ` Pavel Machek
2008-06-23 9:04 ` Benjamin Herrenschmidt
2008-06-23 9:26 ` Pavel Machek
2008-06-23 9:48 ` Tejun Heo
2008-06-23 9:42 ` Alan Cox
2008-06-23 10:23 ` Benjamin Herrenschmidt
2008-06-23 13:05 ` Tejun Heo
2008-06-27 6:41 ` Jeff Garzik
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=20080617093602.GA28140@elf.ucw.cz \
--to=pavel@suse.cz \
--cc=benh@kernel.crashing.org \
--cc=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.org \
/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