public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Lionel Bouton <Lionel.Bouton@inet6.fr>
To: Alan Cox <alan@redhat.com>, Lei-Chun Chang <lcchang@sis.com.tw>,
	Andre Hedrick <andre@linuxdiskcert.org>,
	Marcelo Tosatti <marcelo@conectiva.com.br>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: SiS 5513 ATA133 support patch for 2.4.19-rc3-ac3
Date: Mon, 29 Jul 2002 01:37:54 +0200	[thread overview]
Message-ID: <3D448052.4070805@inet6.fr> (raw)

Hi,

Marcelo, I was mistaken when I told you that the patch (adding ATA133
support and bringing sis5513.c from v0.13 to v0.14) only brought
performance enhancements.

The matter is far more complicated.
Background:
- sis5513.c v0.13 looks only for a set of known northbridge PCI IDs 
instead of using a more fine probing,
- SiS started to produce separate northbridge/southbridge chips.

 From earliest bugreports I believed updated southbridges came
with new northbriges too (reports indicated "646" for 645DX and thus the 
driver didn't recognised the chip and fallbacked to original SiS5513 
mode -> no data corruption) and didn't bother.

Today I received a report for v0.13 with a *645* ID for a 645DX. This ID 
is recognised as only ATA100-capable -> data corruption occured (problem 
solved with v0.14).

So I'm now sure we will have data corruption with v0.13 (we overclock 
the IDE UDMA writes for problematic configurations).

A workaround would be to remove support for problematic PCI IDs in v0.13.

*But* I guess we have an unresolvable problem in v0.13 with latest 
southbridges (962/963): the register layout changed completely. Unlike 
previous chipsets, fallback to sis5513 mode could fail. I guess that the 
master of the primary controller would be fine when the registers aren't 
relocated (may be BIOS dependant or even worse, having booted another OS 
dependant). But all other IDE devices could be screwed up and all of 
them can be if the registers have been remapped.
The only workaround for this is a v0.14 with enough time for tests.

Before releasing 2.4.19 I think we should either :
- completely remove the affected northbridges (645, 650, 745, 750) 
support in v0.13, this is a simple patch. Then we wait for 2.4.20 to 
include v0.14.
- put v0.14 in.

 From past experiences we need 2 weeks of availability of code in
the AC/pre kernels before the wave of meaningful bugreports ends.

LB.


             reply	other threads:[~2002-07-28 23:34 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-28 23:37 Lionel Bouton [this message]
2002-07-28 23:43 ` SiS 5513 ATA133 support patch for 2.4.19-rc3-ac3 Alan Cox
2002-07-29  7:11 ` Daniela Engert
2002-07-29  8:56   ` Lionel Bouton
2002-07-29  9:15     ` Daniela Engert
2002-07-29 11:35     ` L.C. Chang
2002-07-29 19:12 ` Marcelo Tosatti
2002-07-30 16:38   ` Lionel Bouton

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=3D448052.4070805@inet6.fr \
    --to=lionel.bouton@inet6.fr \
    --cc=alan@redhat.com \
    --cc=andre@linuxdiskcert.org \
    --cc=lcchang@sis.com.tw \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcelo@conectiva.com.br \
    /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