All of lore.kernel.org
 help / color / mirror / Atom feed
From: Francois Payette <francoisp@netmosphere.net>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: linux-ide@vger.kernel.org
Subject: Re: SATA150TX4 atat1:command timeout
Date: Wed, 16 Feb 2005 10:04:13 -0500	[thread overview]
Message-ID: <421360ED.2040505@netmosphere.net> (raw)
In-Reply-To: <4211279C.5070205@pobox.com>

With plain vanilla 2.6.11-rc4 the same bug appears after about 250GB 
(avg of 2 trials). With the TBG clock setting line omitted it still 
happens, but after about 1 1 TB (avg of 2 trials, takes about 6hrs per 
trial). Interestingly enough, this change does not slow down the setup, 
it even seems a little faster.

I was mistaken earlier: the 4 drives are not exactly the same, there is 
2 6B200M0 one 6B200S0 and one 6Y200M0. This should be irrelevant as I 
have swapped disks and wires and the problem happens anyway. One 
interesting thing: in init 1 the timeout seems to appear faster, after 
about 200GB in the case with the omission. I would be inclined to think 
this is some sort of a deadlock or race condition: the kernel does not 
dump or panic, it just hangs on pdc_eng_timeout. When we dumped the 
stack  in that function, all we had was pdc_eng_timeout, as there seems 
to a be a separate thread per disk that gets waken up for error handling.

Any ideas on how we can catch this one?
TIA,
Francois

  reply	other threads:[~2005-02-16 15:03 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-14 21:41 SATA150TX4 atat1:command timeout Francois Payette
2005-02-14 22:35 ` Jeff Garzik
2005-02-16 15:04   ` Francois Payette [this message]
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=421360ED.2040505@netmosphere.net \
    --to=francoisp@netmosphere.net \
    --cc=jgarzik@pobox.com \
    --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 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.