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.
> From past experiences we need 2 weeks of availability of code in
> the AC/pre kernels before the wave of meaningful bugreports ends.
Then I think ripping out the problem idents is safest
On Mon, 29 Jul 2002 01:37:54 +0200, Lionel Bouton wrote:
>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).
>
>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.
Lionel,
as you already figured out, looking at the northbridge IDs is simply
not sufficient to find out which capabilities and register layout the
IDE controller in the southbridge (no matter if integrated or external)
has.
Some comments:
1) the 745 has an integrated southbridge and an ATA/100 capable IDE
controller
2) the 646 (and most likely the 645 and others as well) may be paired
with a 961 (ATA/100) or 961B (ATA133) MutIOL southbridge with different
register programming values.
Thus simply ripping out some northbridge IDs wouldn't prevent
corruption problems.
Ciao,
Dani
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Daniela Engert, systems engineer at MEDAV GmbH
Gr?fenberger Str. 34, 91080 Uttenreuth, Germany
Phone ++49-9131-583-348, Fax ++49-9131-583-11
On lun, jui 29, 2002 at 09:11:34 +0200, Daniela Engert wrote:
> On Mon, 29 Jul 2002 01:37:54 +0200, Lionel Bouton wrote:
>
>
> Lionel,
>
> as you already figured out, looking at the northbridge IDs is simply
> not sufficient to find out which capabilities and register layout the
> IDE controller in the southbridge (no matter if integrated or external)
> has.
>
> Some comments:
>
> 1) the 745 has an integrated southbridge and an ATA/100 capable IDE
> controller
>
I believed so too, but Lei-Chun patch changed it to ATA133.
Lei-Chun, could you tell us what we can expect from 745 chips ?
> 2) the 646 (and most likely the 645 and others as well) may be paired
> with a 961 (ATA/100) or 961B (ATA133) MutIOL southbridge with different
> register programming values.
>
> Thus simply ripping out some northbridge IDs wouldn't prevent
> corruption problems.
>
I don't see why (unless you refer to the 962/963 problem I did mention).
If we remove the IDs, the chips will be detected as SiS5513 (ATA_16). If
I'm correct, in this mode (only allowing PIO modes and SW/MW DMA modes)
all chips are OK.
I didn't dig in all specs to check each config register change, but all I
saw was OK and I *never* received any data corruption report for a chip that
was configured as original SiS5513 (though I have many reports of bad
performance due to PIO modes being used in such cases).
LB.
On Mon, 29 Jul 2002 10:56:26 +0200, Lionel Bouton wrote:
>On lun, jui 29, 2002 at 09:11:34 +0200, Daniela Engert wrote:
>> On Mon, 29 Jul 2002 01:37:54 +0200, Lionel Bouton wrote:
>>
>>
>> Lionel,
>>
>> as you already figured out, looking at the northbridge IDs is simply
>> not sufficient to find out which capabilities and register layout the
>> IDE controller in the southbridge (no matter if integrated or external)
>> has.
>>
>> Some comments:
>>
>> 1) the 745 has an integrated southbridge and an ATA/100 capable IDE
>> controller
>>
>
>I believed so too, but Lei-Chun patch changed it to ATA133.
>Lei-Chun, could you tell us what we can expect from 745 chips ?
I have a user report indicating that:
PCI BIOS V2.10 detected, 2 PCI buses present.
Found embedded SiS 5513 on 0/2/5
00: 39 10 13 55 07 00 00 00 D0 80 01 01 00 80 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 40 00 00 00 00 00 00 00 00 00 00 19 10 41 0A
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 31 81 31 82 31 00 31 00 08 01 E6 33 00 02 00 02
50: 01 00 01 06 00 00 00 00 00 00 00 00 00 00 00 00
BusMaster Registers:
00: 08 00 60 00 58 28 F6 00 00 00 04 00 FC 5F 00 00
VendorID 1039, DeviceID 5513, Subsystem VendorID 1019, DeviceID 0A41
IOBase 4000h (Len 10h)
Host bridge (1039/0745 rev 01) on 0/0/0
South bridge (1039/0008 rev 00) on 0/2/0
The primary master is a UDMA 5 disk, and primary slave a UDMA 4 one.
>> 2) the 646 (and most likely the 645 and others as well) may be paired
>> with a 961 (ATA/100) or 961B (ATA133) MutIOL southbridge with different
>> register programming values.
>>
>> Thus simply ripping out some northbridge IDs wouldn't prevent
>> corruption problems.
>>
>
>I don't see why (unless you refer to the 962/963 problem I did mention).
>If we remove the IDs, the chips will be detected as SiS5513 (ATA_16). If
>I'm correct, in this mode (only allowing PIO modes and SW/MW DMA modes)
>all chips are OK.
>I didn't dig in all specs to check each config register change, but all I
>saw was OK and I *never* received any data corruption report for a chip that
>was configured as original SiS5513 (though I have many reports of bad
>performance due to PIO modes being used in such cases).
Ok, I think you are right, disabling UDMA mode should be a safe bet.
Ciao,
Dani
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Daniela Engert, systems engineer at MEDAV GmbH
Gr?fenberger Str. 34, 91080 Uttenreuth, Germany
Phone ++49-9131-583-348, Fax ++49-9131-583-11
SiS 745/746/750/... like 645/646/650/..., is an independent north bridge
which may be paired with SiS 961a/961b/962(963).
And as you known, the northbridge ID alone was not able to distinguish
the UDMA support in those chipset family. So I changed all of them
to ATA133 in my patch. When ATA133 family found in
pci_init_sis5513(), I would look for further information to determine
which family it belongs to (ATA100/ATA133a/ATA133).
L.C.
> On lun, jui 29, 2002 at 09:11:34 +0200, Daniela Engert wrote:
> > On Mon, 29 Jul 2002 01:37:54 +0200, Lionel Bouton wrote:
> >
> >
> > Lionel,
> >
> > as you already figured out, looking at the northbridge IDs is simply
> > not sufficient to find out which capabilities and register layout the
> > IDE controller in the southbridge (no matter if integrated or external)
> > has.
> >
> > Some comments:
> >
> > 1) the 745 has an integrated southbridge and an ATA/100 capable IDE
> > controller
> >
>
> I believed so too, but Lei-Chun patch changed it to ATA133.
> Lei-Chun, could you tell us what we can expect from 745 chips ?
>
> > 2) the 646 (and most likely the 645 and others as well) may be paired
> > with a 961 (ATA/100) or 961B (ATA133) MutIOL southbridge with different
> > register programming values.
> >
> > Thus simply ripping out some northbridge IDs wouldn't prevent
> > corruption problems.
> >
>
> I don't see why (unless you refer to the 962/963 problem I did mention).
> If we remove the IDs, the chips will be detected as SiS5513 (ATA_16). If
> I'm correct, in this mode (only allowing PIO modes and SW/MW DMA modes)
> all chips are OK.
> I didn't dig in all specs to check each config register change, but all I
> saw was OK and I *never* received any data corruption report for a chip
that
> was configured as original SiS5513 (though I have many reports of bad
> performance due to PIO modes being used in such cases).
>
> LB.
On Mon, 29 Jul 2002, Lionel Bouton wrote:
> 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.
Lets do that. Please send me a patch ASAP so I can release 2.4.19.
diff -urN linux-2.4.19-rc3/drivers/ide/sis5513.c linux-2.4.19-rc3-sis/drivers/ide/sis5513.c
--- linux-2.4.19-rc3/drivers/ide/sis5513.c Tue Jul 30 18:10:31 2002
+++ linux-2.4.19-rc3-sis/drivers/ide/sis5513.c Tue Jul 30 18:27:29 2002
@@ -169,13 +169,13 @@
unsigned char chipset_family;
unsigned char flags;
} SiSHostChipInfo[] = {
- { "SiS750", PCI_DEVICE_ID_SI_750, ATA_100, SIS5513_LATENCY },
- { "SiS745", PCI_DEVICE_ID_SI_745, ATA_100, SIS5513_LATENCY },
+// { "SiS750", PCI_DEVICE_ID_SI_750, ATA_100, SIS5513_LATENCY },
+// { "SiS745", PCI_DEVICE_ID_SI_745, ATA_100, SIS5513_LATENCY },
{ "SiS740", PCI_DEVICE_ID_SI_740, ATA_100, SIS5513_LATENCY },
{ "SiS735", PCI_DEVICE_ID_SI_735, ATA_100, SIS5513_LATENCY },
{ "SiS730", PCI_DEVICE_ID_SI_730, ATA_100a, SIS5513_LATENCY },
- { "SiS650", PCI_DEVICE_ID_SI_650, ATA_100, SIS5513_LATENCY },
- { "SiS645", PCI_DEVICE_ID_SI_645, ATA_100, SIS5513_LATENCY },
+// { "SiS650", PCI_DEVICE_ID_SI_650, ATA_100, SIS5513_LATENCY },
+// { "SiS645", PCI_DEVICE_ID_SI_645, ATA_100, SIS5513_LATENCY },
{ "SiS635", PCI_DEVICE_ID_SI_635, ATA_100, SIS5513_LATENCY },
{ "SiS640", PCI_DEVICE_ID_SI_640, ATA_66, SIS5513_LATENCY },
{ "SiS630", PCI_DEVICE_ID_SI_630, ATA_66, SIS5513_LATENCY },