linux-kernel - Re: Promise SATA300 TX4: errors, oops in ext3 code

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 01 Oct 2007 14:26:28 +0400
From:	Alexander Sabourenkov <screwdriver@...t.info>
To:	Clemens Koller <clemens.koller@...gramm.de>
CC:	linux-kernel@...r.kernel.org, linux-ide@...r.kernel.org
Subject: Re: Promise SATA300 TX4: errors, oops in ext3 code

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/