Bernd Schubert wrote:
On Sat, Jan 03, 2009 at 01:39:36PM +0000, Alan Cox wrote:
On Fri, 2 Jan 2009 22:30:07 +0100
Bernd Schubert <b...@q-leap.de> wrote:

Hello Bengt,

sil3114 is known to cause data corruption with some disks.
News to me. There are a few people with lots of SI and other devices

No no, you just forgot about it, since you even reviewed the patches ;)

http://lkml.org/lkml/2007/10/11/137

And Jeff explained why they were not merged:

http://lkml.org/lkml/2007/10/11/166

All the patch does is try to reduce the speed impact of the workaround. But as was pointed out, they don't reliably solve the problem the workaround is trying to fix, and besides, the workaround is already not applied to SiI3114 at all, as it is apparently not applicable on that controller (only 3112).


jammed into the same mainboard who had problems but that doesn't appear
to be an SI problem as far as I can tell.

There are some incompatibilities between certain silicon image chips and
Nvidia chipsets needing BIOS workarounds according to the errata docs.

Do you have details of these Alan?


Well, I already posted the the links to the discussion we had in the past.
The corruption issue is easily reproducible on Tyan S2882 with AMD-8111,
SiI 3114 and ST3250820AS disks. This is on a compute cluster, and we run into the problem, when a few ST3200822AS failed and got replaced by newer 250GB disks. The 200GB ST3200822AS work perfectly fine, while the 250GB ST3250820AS disks cause data corrution. Presently the cluster is empty, so if you want do help me, your help to properly solve the issue would be highly appreciated (*).


Cheers,
Bernd

PS: The patches I posted work fine on these systems, but they are not upstream and I really would prefer to find a way in vanilla linux to prevent this
data corruption.

Some people have tried turning on the slow_down option or adding their drive to the mod15 blacklist and found that problems went away, but that in no way implies that their setup actually needs this workaround, only that it slows down the IO enough that the problem no longer shows up. It's a big hammer that can cover up all kinds of other issues and has confused a lot of people into thinking the mod15write problem is bigger than it actually is.


PPS: Its a bit funny with this cluster, since it is located at my university group and I did and do many calculations on it myself. But presently I work for the company we bought it from and which is responsible to maintain it... ;)


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to