From: Francois Payette <francoisp@netmosphere.net>
To: linux-ide@vger.kernel.org
Subject: SATA150TX4 atat1:command timeout
Date: Mon, 14 Feb 2005 16:41:22 -0500 [thread overview]
Message-ID: <42111B02.4010805@netmosphere.net> (raw)
Hi,
We have reported earlier a strange bug at bugzilla.kernel.org (#4106
<http://bugzilla.kernel.org/show_bug.cgi?id=4106>): in our setup of a
20318 (the SATA150 TX4, not the fastrack one) we are systematically
getting ata1: command timeout after copying between 200 and 600GB of
data through the controller. Our setup is with 4 maxtor 6Y200M0, 2 of
them in raid 0, and the other 2 in a LV group over a raid 0 md array.
When copying from one array to the other one repeatedly, the machines
freezes once out out of every 2 copy. We changed the drive order, but we
still got the msg ata1 command timeout. We swapped the order of the
cables, and still got ata1 command timeout. We got a few kernel panics
with spin locks, but since finding this forum we added the line
writel(mask, mmio_base + PDC_INT_SEQMASK);
to pdc_interrupt, and that one was gone.
We have kernel 2.6.10-753 (fc3) with all relevant patches to the sata
stuff, the last of which is the one Bartlomiej Zolnierkiewicz posted on
06/02/2005.
http://marc.theaimsgroup.com/?l=linux-ide&m=110769875419863&w=2
<http://marc.theaimsgroup.com/?l=linux-ide&m=110769875419863&w=2>
After commenting out the line
/* reduce TBG clock to 133 Mhz. */
/*tmp = readl(mmio + PDC_TBG_MODE); */
tmp &= ~0x30000; /* clear bit 17, 16*/
tmp |= 0x10000; /* set bit 17:16 = 0:1 */
/*writel(tmp, mmio + PDC_TBG_MODE); */
in pdc_host_init (total shot in the dark) the setup seems more stable,
we have now gone through 3 cycles of stress test (600GB of copying) and
have not seen the crash.
Earlier we tried the same stress test with ATA_DEBUG and
ATA_VERBOSE_DEBUG defined, the error did not occur maybe because of it
was slowed down with all the output)?
Later we tried commenting out the line that sets bmr burst
(PDC_FLASH_CTL) and slew rate (PDC_SLEW_CTL) in pdc_host_init, and that
slowed the setup to half it's orignal speed, but in that case the
problem did not show up.
We outputted the command timeout and it's 0x35 (ATA_CMD_WRITE_EXT)
protocol is 4 (ATA_PROT_DMA).
Any ideas?
TIA,
Francois Payette
next reply other threads:[~2005-02-14 21:40 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-14 21:41 Francois Payette [this message]
2005-02-14 22:35 ` SATA150TX4 atat1:command timeout Jeff Garzik
2005-02-16 15:04 ` Francois Payette
2005-02-18 16:40 ` Francois Payette
2005-09-30 10:40 ` Robin Bowes
2005-10-06 9:55 ` Ian Oliver
2005-10-06 10:44 ` Erik Slagter
2005-10-13 20:37 ` Ian Oliver
2005-10-13 21:04 ` Mark Lord
2005-10-14 10:17 ` Ian Oliver
2005-10-14 13:07 ` Mark Lord
2005-10-14 10:00 ` Erik Slagter
2005-10-14 16:00 ` Ian Oliver
2005-10-17 10:08 ` Erik Slagter
2005-10-17 13:01 ` Ian Oliver
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=42111B02.4010805@netmosphere.net \
--to=francoisp@netmosphere.net \
--cc=linux-ide@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;
as well as URLs for NNTP newsgroup(s).