All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Sabourenkov <screwdriver@lxnt.info>
To: Clemens Koller <clemens.koller@anagramm.de>
Cc: linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org
Subject: Re: Promise SATA300 TX4: errors, oops in ext3 code
Date: Mon, 01 Oct 2007 14:26:28 +0400	[thread overview]
Message-ID: <4700CB54.7000206@lxnt.info> (raw)
In-Reply-To: <4700B966.1030508@anagramm.de>

Clemens Koller wrote:
> Alexander Sabourenkov schrieb:
>  > Hardware:  Athlon64, Asus A8V, Promise SATA300 TX4, 2xSeagate 7200.10
>  > 320G, jumper-limited to SATA150.
>  > Kernel : 2.6.22.9 amd64
>  >
>  > Problem:
>  > Heavy load causes errors and triggers oops.
> 
> Have you checked your memory already (memtest86)?

Last run was about a year ago.

This box gets regularly updated (rebuild of all installed software),
so I'm reasonably certain that memory is ok - gcc being almost as 
sensitive as memtest.

Will recheck anyway.

> 
> We have several applications with Promise controllers on strange
> hardware and we never had integrity problems with i.e. not so standard
> SATA connections over custom vaccum-tight connectors.

Judging from linux and freebsd mailing lists, the TX4 is now quite 
well-known for
intermittent problems, which are hard to reproduce on different hardware.

I have two machines with those controllers, one FreeBSD-6.2 on MSI 
K8Neo2 motherboard (ATI chipset),
  and this one. FreeBSD box does not exhibit this problem under the 
little load it gets, but
6-STABLE and 7-CURRENT branches do have similar symptoms since around 19 
April 2007,
with rare occurences (but not unheard of) before.

Thus I am unable to keep machines up to date, and before having to dump 
$140 worth of hardware,
I'd like to try to help fix this problem or at least be certain that 
those controllers are indeed unusable.


>  > Problems were blamed:
>  >   - SATA300 being too 'hot'  (jumpered the drives)
> 
> Is this a common known problem with your harddrives or controller?
> (ask google) Otherwise, it sounds like a problem with broken hardware.

This is a common problem with at least VIA onboard controllers and 
Seagate disks,
and I think with SATA150 controllers and speed negotiation in general.

This step was suggested in some mailing list as a general precaution, but
actually made no difference to error rate.

I did not unjumper drivers back to SATA300 so that I can easily connect 
the drives
to the onboard controller.

-- 

./lxnt



  reply	other threads:[~2007-10-01 10:24 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-01  7:04 Promise SATA300 TX4: errors, oops in ext3 code Alexander Sabourenkov
2007-10-01  9:09 ` Clemens Koller
2007-10-01 10:26   ` Alexander Sabourenkov [this message]
2007-10-02  4:35   ` Alexander Sabourenkov
2007-10-02  9:08     ` Clemens Koller
2007-10-02  9:49       ` Alexander Sabourenkov
2007-10-02  9:25 ` Clemens Koller

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=4700CB54.7000206@lxnt.info \
    --to=screwdriver@lxnt.info \
    --cc=clemens.koller@anagramm.de \
    --cc=linux-ide@vger.kernel.org \
    --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 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.