Hi!
This is a rewrite of the PIIX IDE timing driver. It should give slightly
better performance (+4% was measured), and also replaces the slc90c66
Efar Victory66 driver, because the Victory66 is mostly a PIIX clone.
It has been tested on PIIX4 only. Please anyone with a PIIX or ICH chip,
and if anyone has the Victory66 one even moreso, test this if you can.
The patch is against 2.5.6 + the patches I sent earlier, for a complete
patch against clean 2.5.6 see
http://twilight.ucw.cz/ide-via-amd-piix-timing-8-pre-final.diff
Killed code good code. :)
--
Vojtech Pavlik
SuSE Labs
This will benifit PIIX3 chipsets? :)
On Thu, 14 Mar 2002, Vojtech Pavlik wrote:
> Hi!
>
> This is a rewrite of the PIIX IDE timing driver. It should give slightly
> better performance (+4% was measured), and also replaces the slc90c66
> Efar Victory66 driver, because the Victory66 is mostly a PIIX clone.
>
> It has been tested on PIIX4 only. Please anyone with a PIIX or ICH chip,
> and if anyone has the Victory66 one even moreso, test this if you can.
>
> The patch is against 2.5.6 + the patches I sent earlier, for a complete
> patch against clean 2.5.6 see
>
> http://twilight.ucw.cz/ide-via-amd-piix-timing-8-pre-final.diff
>
> Killed code good code. :)
>
> --
> Vojtech Pavlik
> SuSE Labs
>
On Wed, Mar 13, 2002 at 08:04:38PM -0500, Shawn Starr wrote:
> This will benifit PIIX3 chipsets? :)
It should.
>
> On Thu, 14 Mar 2002, Vojtech Pavlik wrote:
>
> > Hi!
> >
> > This is a rewrite of the PIIX IDE timing driver. It should give slightly
> > better performance (+4% was measured), and also replaces the slc90c66
> > Efar Victory66 driver, because the Victory66 is mostly a PIIX clone.
> >
> > It has been tested on PIIX4 only. Please anyone with a PIIX or ICH chip,
> > and if anyone has the Victory66 one even moreso, test this if you can.
> >
> > The patch is against 2.5.6 + the patches I sent earlier, for a complete
> > patch against clean 2.5.6 see
> >
> > http://twilight.ucw.cz/ide-via-amd-piix-timing-8-pre-final.diff
> >
> > Killed code good code. :)
> >
> > --
> > Vojtech Pavlik
> > SuSE Labs
> >
--
Vojtech Pavlik
SuSE Labs
On Thu, 14 Mar 2002 07:52:58 +0100, Vojtech Pavlik wrote:
>> This will benifit PIIX3 chipsets? :)
>It should.
Are you aware of the batches of broken PIIX3 chips ?
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 Thu, Mar 14, 2002 at 08:24:02AM +0100, Daniela Engert wrote:
> On Thu, 14 Mar 2002 07:52:58 +0100, Vojtech Pavlik wrote:
>
> >> This will benifit PIIX3 chipsets? :)
> >It should.
>
> Are you aware of the batches of broken PIIX3 chips ?
I don't know of any IDE-related errata for the PIIX3 chip. At least
Intel didn't publish any and there doesn't seem to be any workarounds in
the original piix.c code, only a statement stating that the PIIX3 UDMA
is broken, however, as far as I know, PIIX3 isn't UDMA capable at all.
(Hmm, perhaps some BIOSes enable UDMA on PIIX3, that'd explain it ...
though I believe that's quite improbable).
In what way are those batches broken?
--
Vojtech Pavlik
SuSE Labs
On Thu, 14 Mar 2002, Vojtech Pavlik wrote:
> On Thu, Mar 14, 2002 at 08:24:02AM +0100, Daniela Engert wrote:
> > On Thu, 14 Mar 2002 07:52:58 +0100, Vojtech Pavlik wrote:
> >
> > >> This will benifit PIIX3 chipsets? :)
> > >It should.
> >
> > Are you aware of the batches of broken PIIX3 chips ?
>
> I don't know of any IDE-related errata for the PIIX3 chip. At least
> Intel didn't publish any and there doesn't seem to be any workarounds in
> the original piix.c code, only a statement stating that the PIIX3 UDMA
> is broken, however, as far as I know, PIIX3 isn't UDMA capable at all.
27296302.pdf 82371SB (PIIX3) Timing Specification
29765804.pdf INTEL 82371FB (PIIX) and 82371SB (PIIX3) SPECIFICATION UPDATE
Regards,
Andre
On Thu, 14 Mar 2002, Vojtech Pavlik wrote:
> On Thu, Mar 14, 2002 at 08:24:02AM +0100, Daniela Engert wrote:
> > On Thu, 14 Mar 2002 07:52:58 +0100, Vojtech Pavlik wrote:
> >
> > >> This will benifit PIIX3 chipsets? :)
> > >It should.
> >
> > Are you aware of the batches of broken PIIX3 chips ?
>
> I don't know of any IDE-related errata for the PIIX3 chip. At least
> Intel didn't publish any and there doesn't seem to be any workarounds in
> the original piix.c code, only a statement stating that the PIIX3 UDMA
> is broken, however, as far as I know, PIIX3 isn't UDMA capable at all.
Forgot one more ...
29055002.pdf 82371FB (PIIX) AND 82371SB (PIIX3)
Happy hunting.
Cheers,
Andre
On Thu, 14 Mar 2002 08:30:38 +0100, Vojtech Pavlik wrote:
>> Are you aware of the batches of broken PIIX3 chips ?
>
>I don't know of any IDE-related errata for the PIIX3 chip. At least
>Intel didn't publish any and there doesn't seem to be any workarounds in
>the original piix.c code, only a statement stating that the PIIX3 UDMA
>is broken, however, as far as I know, PIIX3 isn't UDMA capable at all.
>
>(Hmm, perhaps some BIOSes enable UDMA on PIIX3, that'd explain it ...
>though I believe that's quite improbable).
>
>In what way are those batches broken?
Have a look at the table below which summarizes my findings from personal experiences,
user reports and manufacturer info, accumulated in my 3 years of writing IDE drivers
(well, actually only one - it's an universal driver).
The PIIX3 bug is real, I have several user reports about it!
Ciao,
Dani
Vendor
| Device
| | Revision ATA ATAPI ATA66 ATA133
| | | south/host bridge id PIO DMA PIO DMA ATA33 | ATA100| Docs
| | | | south/host bridge rev. 32bit | 32bit | | | | | avail
| | | | | | | | | | | | | |
v v v v v v v v v v v v v v
0x8086 Intel
0x1230 PIIX x x x x - - - - x
< 02 x - x - - - - - x
0x84C4 Orion
< 04 x - x - - - - - x
0x7010 PIIX3 x x x x - - - - x
0x7111 PIIX4 x x x x x - - - x
0x7199 PIIX4 MX x x x x x - - - x
0x84CA PIIX4 NX x x x x x - - - x
0x2411 ICH x x x x x x - - x
0x7601 ICH x x x x x x - - x
0x2421 ICH0 x x x x x - - - x
0x244B ICH2 x x x x x x x - x
0x244A ICH2 mobile x x x x x x x - x
0x248B ICH3 x x x x x x x - x
0x248A ICH3 mobile x x x x x x x - x
known bugs:
- PIIX3: some chips 'forget' to assert the IRQ sometimes. These chips are not
detectable in advance.
--------------------------------------------------------------------------------
0x1106 VIA
0x1571 571 x x x x - - - - -
0x0571 571
0x0586
< 0x20 586 x x x x - - - - -
>=0x20 586A/B x x x x x - - - x
0x0596
< 0x10 596/A x x x x x - - - x
< 0x10 596B x x x x x x - - x
0x0686
< 0x10 686 x x x x x - - - -
< 0x40 686A x x x x x x - - x
>=0x40 686B x x x x x x x - -
0x8231 VT8231 x x x x x x x - -
0x3074 VT8233 x x x x x x x - -
0x3109 VT8233c x x x x x x x - -
0x3147 VT8233a x x x x x x x x -
known bugs:
- all: no host side cable type detection.
- all: the busmaster 'active' bit doesn't match the actual busmaster state.
- 596B: don't touch the busmaster registers too early after interrupt
don't touch taskfile registers before stopping the busmaster!
- 686 rev 40/41 and VT8231 rev 10/11 have the PCI corruption bug!
--------------------------------------------------------------------------------
0x10B9 ALi
0x5229 M5229
< 0x20 x x x - - - - - (x)
< 0xC1 1533, 1543E, 1543F x x x - x - - - (x)
< 0xC2 1543C x x x xR x - - - (x)
0xC3/
0x12 1543C-E x x x xR (x) - - - (x)
< 0xC4 1535, 1553, 1543C-Bx x x x x x x - - x
1535D
==0xC4 1535D+ x x x x x x x - x
> 0xC4 1535D+ x x x x x x x x -
known bugs:
- 1535 and better: varying methods of host side cable type detection.
- up to 1543C: busmaster engine 'active' status bit is nonfunctional
in UltraDMA modes.
- up to 1543C: can't do ATAPI DMA writes.
- 1543C-E: UltraDMA CRC checker fails with WDC disks.
- 1543C-Bx: must stop busmaster reads with 0x00 instead of 0x08.
--------------------------------------------------------------------------------
0x1039 SiS
0x5513 5513
< 0xD0 x x x x - - - - x
>=0xD0 x x x x x - - - x
>= 0x0530 x x x x x x - - (x)
> 0x0630 x x x x x x x - (x)
6/746 6/751 x x x x x x x x -
- older SiS: don't touch the busmaster registers too early after interrupt
--------------------------------------------------------------------------------
0x1095 CMD
0x0640 CMD 640 - - - - - - - - x
00 refuse!
0x0643 CMD 643
< 03 x x x x - - - - x
>=03 x x x x x - - - x
0x0646 CMD 646
< 03 x x x x - - - - x
>=03 x x x x x - - - x
0x0648 CMD 648 x x x x x x - - x
0x0649 CMD 649 x x x x x x x - (x)
known bugs:
- 640: the enable bit of the secondary channel is erratic. You need to check
both settings '0' and '1' for a populated channel.
- 640: revision 0 doesn't work reliably.
- up to 646: both channels share internal resources. Serialization is
required.
--------------------------------------------------------------------------------
0x105A Promise
0x4D33 Ultra/FastTrack33 x x - - x - - - -
0x4D38 Ultra/FastTrack66 x x - (x) x x - - x
0x4D30 Ultra/FastTrack100 x x - (x) x x x - x
0x0D30 Ultra/FastTrack100 x x - (x) x x x - x
0x4D68 Ultra/FastTrack100 TX2 x x x x x x x - (x)
0x6268 Ultra/FastTrack100 TX2 x x x x x x x - (x)
0x4D69 Ultra/FastTrack133 x x x x x x x x x
0x1275 Ultra/FastTrack133 x x x x x x x x -
known bugs:
- up to Ultra100: don't issue superfluous PIO transfer mode setups.
- up to Ultra100: if any device is initialized to UltraDMA, you need to
reset the channel if you want to select MultiWord DMA instead.
- Ultra66/100: ATAPI DMA should work according to Windows drivers, but I
can see channel lockups only.
--------------------------------------------------------------------------------
0x1078 Cyrix
0x0102 CX5530 x x x x x - - - x
known bugs:
- all: busmaster transfers need to be 16 byte aligned instead of word
aligned.
--------------------------------------------------------------------------------
0x1103 HighPoint
0x0004 HPT 36x/37x
<=01 HPT 366 x x x x x x - - x
02 HPT 368 x x x x x x - - -
03 HPT 370 x x x x x x x - x
04 HPT 370A x x x x x x x - (x)
05 HPT 372 x x x x x x x x x
0x0008 HPT 36x/37x dual
07 HPT 374 x x x x x x x x x
known bugs:
- HPT366: random failures with several disks.
- HPT366: random PCI bus lockups in case of too long bursts.
- HPT366: IBM DTLA series drives must be set to Ultra DMA mode 5 (!!) to work
reliably at Ultra DMA mode 4 speed.
--------------------------------------------------------------------------------
0x1022 AMD
0x7401 AMD 751 x x x x x - - - -
0x7409 AMD 756 x x x x x x - - x
0x7411 AMD 766 MP x x x x x x x - x
0x7441 AMD 768 MPX x x x x x x x - x
0x7469 AMD 8111 x x x x x x x - -
known bugs:
- 756: no host side cable type detection.
- 756: SingleWord DMA doesn't work on early chip revisions.
- 766: read/write prefetches must be disabled to defeat infinite
PCI bus retries.
--------------------------------------------------------------------------------
0x1191 AEC/Artop
0x0005 AEC 6210 x x ? ? x - - - -
0x0006 AEC 6260 x x ? ? x x - - -
0x0007 AEC 6260 x x ? ? x x - - -
0x0009 AEC 6280/6880 x x ? ? x x x x -
known bugs:
- 6210 (possibly 6260): task file registers are inaccessible until busmaster
engine is stopped.
- possibly all: both channels share internal resources. Serialization is
required.
--------------------------------------------------------------------------------
0x1055 SMSC
0x9130 SLC90E66 ? x ? ? x x - - x
--------------------------------------------------------------------------------
0x1166 ServerWorks
0x0211 OSB4 x x ? ? x - - - x
0x0212 CSB5
< 0x92 x x ? ? x x - - -
>= 0x92 x x ? ? x x x - -
known bugs:
- OSB4: at least some chip revisions can't do Ultra DMA mode 1 and above
- CSB5: no host side cable type detection.
--------------------------------------------------------------------------------
0x1045 Opti
0xC621 n/a x - ? - - - - - x
0xC558 Viper x x ? ? - - - - x
0xD568 x x ? ? - - - - x
< 0xC700 Viper x x ? ? - - - - x
>=0xC700 FireStar/Vendetta? x x x x x - - - x
0xD721 Vendetta? x x x x x - - - x
0xD768 Vendetta x x x x x - - - x
known bugs:
- C621: both channels share internal resources. Serialization is required.
- FireStar: Ultra DMA works reliably only at mode 0.
Update: not even that! Better do MWDMA2 at most.
--------------------------------------------------------------------------------
0x10DE Nvidia
0x01BC nForce x x x x x x x - -
known bugs:
- nForce: no host side cable type detection.
--------------------------------------------------------------------------------
0x100B National Semiconductor
0x0502 SCx200 x x x x x - - - -
known bugs:
- all: busmaster transfers need to be 16 byte aligned instead of word
aligned.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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 Wed, Mar 13, 2002 at 11:36:30PM -0800, Andre Hedrick wrote:
> On Thu, 14 Mar 2002, Vojtech Pavlik wrote:
>
> > On Thu, Mar 14, 2002 at 08:24:02AM +0100, Daniela Engert wrote:
> > > On Thu, 14 Mar 2002 07:52:58 +0100, Vojtech Pavlik wrote:
> > >
> > > >> This will benifit PIIX3 chipsets? :)
> > > >It should.
> > >
> > > Are you aware of the batches of broken PIIX3 chips ?
> >
> > I don't know of any IDE-related errata for the PIIX3 chip. At least
> > Intel didn't publish any and there doesn't seem to be any workarounds in
> > the original piix.c code, only a statement stating that the PIIX3 UDMA
> > is broken, however, as far as I know, PIIX3 isn't UDMA capable at all.
>
> 27296302.pdf 82371SB (PIIX3) Timing Specification
> 29765804.pdf INTEL 82371FB (PIIX) and 82371SB (PIIX3) SPECIFICATION UPDATE
Gee, thanks, like if I haven't read those twice over already. No mention
of UDMA (or SDMA in Intel speech), or any IDE errata anyway.
--
Vojtech Pavlik
SuSE Labs
On Thu, Mar 14, 2002 at 08:44:42AM +0100, Daniela Engert wrote:
> The PIIX3 bug is real, I have several user reports about it!
Thanks A LOT for the tables, added are some comments from me ...
> Vendor
> | Device
> | | Revision ATA ATAPI ATA66 ATA133
> | | | south/host bridge id PIO DMA PIO DMA ATA33 | ATA100| Docs
> | | | | south/host bridge rev. 32bit | 32bit | | | | | avail
> | | | | | | | | | | | | | |
> v v v v v v v v v v v v v v
>
> 0x8086 Intel
> 0x1230 PIIX x x x x - - - - x
> < 02 x - x - - - - - x
I suppose this means on PIIXes with rev 00 and 01 of the IDE controller
DMA transfers don't work reliably, right?
> 0x84C4 Orion
> < 04 x - x - - - - - x
And this means that if there is an 84c4 PCI bridge in the system with
rev less than 04 (04 is OK), then DMA transfers are broken again.
> 0x7010 PIIX3 x x x x - - - - x
> 0x7111 PIIX4 x x x x x - - - x
> 0x7199 PIIX4 MX x x x x x - - - x
> 0x84CA PIIX4 NX x x x x x - - - x
This one confuses me, because the 0x84ca chip doesn't seem to have any
IDE capability. Is this id by any chance taken from the linux kernel?
> 0x2411 ICH x x x x x x - - x
> 0x7601 ICH x x x x x x - - x
This one is actually a PIIX5, not ICH.
> 0x2421 ICH0 x x x x x - - - x
> 0x244B ICH2 x x x x x x x - x
> 0x244A ICH2 mobile x x x x x x x - x
> 0x248B ICH3 x x x x x x x - x
> 0x248A ICH3 mobile x x x x x x x - x
>
> known bugs:
> - PIIX3: some chips 'forget' to assert the IRQ sometimes. These chips are not
> detectable in advance.
Is there any workaround for that? Or there isn't to do anything about
the bug and we just have to live with it ...
> 0x1106 VIA
> 0x1571 571 x x x x - - - - -
Irq unmasking during PIO transfers is known to cause problems on
these. Also, some have wrong ISA bridge vendor ID of 1107.
> 0x0571 571
> 0x0586
> < 0x20 586 x x x x - - - - -
I have docs on this one.
> >=0x20 586A/B x x x x x - - - x
00..1f 586
20..2f 586a
30..3f 586b
40..46 586b 3040 silicon
Has a bug where the preq# til ddack# bit must be cleared or can cause
spontaneous reboots.
47..4f 586b 3041 silicon
> 0x0596
> < 0x10 596/A x x x x x - - - x
> < 0x10 596B x x x x x x - - x
That probably should be >= 10
> 0x0686
> < 0x10 686 x x x x x - - - -
> < 0x40 686A x x x x x x - - x
> >=0x40 686B x x x x x x x - -
I have docs here as well.
> 0x8231 VT8231 x x x x x x x - -
> 0x3074 VT8233 x x x x x x x - -
And for this, too.
> 0x3109 VT8233c x x x x x x x - -
> 0x3147 VT8233a x x x x x x x x -
>
> known bugs:
> - all: no host side cable type detection.
Not true, for the UDMA100 and UDMA133 capable ones, there are defined
bits in the UDMA_TIMING register. Not all BIOSes use those, though.
> - all: the busmaster 'active' bit doesn't match the actual busmaster state.
> - 596B: don't touch the busmaster registers too early after interrupt
> don't touch taskfile registers before stopping the busmaster!
> - 686 rev 40/41 and VT8231 rev 10/11 have the PCI corruption bug!
Hmm, what's this one?
> --------------------------------------------------------------------------------
> 0x1022 AMD
> 0x7401 AMD 751 x x x x x - - - -
> 0x7409 AMD 756 x x x x x x - - x
> 0x7411 AMD 766 MP x x x x x x x - x
> 0x7441 AMD 768 MPX x x x x x x x - x
> 0x7469 AMD 8111 x x x x x x x - -
>
> known bugs:
> - 756: no host side cable type detection.
> - 756: SingleWord DMA doesn't work on early chip revisions.
> - 766: read/write prefetches must be disabled to defeat infinite
> PCI bus retries.
Correct.
> --------------------------------------------------------------------------------
> 0x1055 SMSC
> 0x9130 SLC90E66 ? x ? ? x x - - x
This one is a PIIX clone, identical to PIIX4, except for slightly
different UDMA66 programming.
> --------------------------------------------------------------------------------
> 0x10DE Nvidia
> 0x01BC nForce x x x x x x x - -
>
> known bugs:
> - nForce: no host side cable type detection.
Do you have any info on this one? I'd really like to have a Linux driver
for it ...
--
Vojtech Pavlik
SuSE Labs
On Thu, Mar 14, 2002 at 09:18:08AM +0100, Vojtech Pavlik wrote:
> On Thu, Mar 14, 2002 at 08:44:42AM +0100, Daniela Engert wrote:
>
> > The PIIX3 bug is real, I have several user reports about it!
>
> Thanks A LOT for the tables, added are some comments from me ...
>
> > Vendor
> > | Device
> > | | Revision ATA ATAPI ATA66 ATA133
> > | | | south/host bridge id PIO DMA PIO DMA ATA33 | ATA100| Docs
> > | | | | south/host bridge rev. 32bit | 32bit | | | | | avail
> > | | | | | | | | | | | | | |
> > v v v v v v v v v v v v v v
> >
> > 0x8086 Intel
> > 0x1230 PIIX x x x x - - - - x
> > < 02 x - x - - - - - x
>
> I suppose this means on PIIXes with rev 00 and 01 of the IDE controller
> DMA transfers don't work reliably, right?
>
> > 0x84C4 Orion
> > < 04 x - x - - - - - x
>
> And this means that if there is an 84c4 PCI bridge in the system with
> rev less than 04 (04 is OK), then DMA transfers are broken again.
And there is one more Intel chip:
0x1234, the infamous MPIIX. Can do PIO only, 32 bit is OK, has a single
channel switchable to primary or secondary, IDETIM is located in
registers 6C-6D on the ISA bridge. Docs available.
--
Vojtech Pavlik
SuSE Labs
On Thu, 14 Mar 2002 09:18:08 +0100, Vojtech Pavlik wrote:
>> Vendor
>> | Device
>> | | Revision ATA ATAPI ATA66 ATA133
>> | | | south/host bridge id PIO DMA PIO DMA ATA33 | ATA100| Docs
>> | | | | south/host bridge rev. 32bit | 32bit | | | | | avail
>> | | | | | | | | | | | | | |
>> v v v v v v v v v v v v v v
>>
>> 0x8086 Intel
>> 0x1230 PIIX x x x x - - - - x
>> < 02 x - x - - - - - x
>
>I suppose this means on PIIXes with rev 00 and 01 of the IDE controller
>DMA transfers don't work reliably, right?
True.
>> 0x84C4 Orion
>> < 04 x - x - - - - - x
>
>And this means that if there is an 84c4 PCI bridge in the system with
>rev less than 04 (04 is OK), then DMA transfers are broken again.
True.
>> 0x84CA PIIX4 NX x x x x x - - - x
>
>This one confuses me, because the 0x84ca chip doesn't seem to have any
>IDE capability. Is this id by any chance taken from the linux kernel?
I can't remember. The driver has its roots more than 10 years ago, and
there are so many open and closed driver sources around.
>> 0x7601 ICH x x x x x x - - x
>
>This one is actually a PIIX5, not ICH.
May be, but who cares about names ;-)
>> known bugs:
>> - PIIX3: some chips 'forget' to assert the IRQ sometimes. These chips are not
>> detectable in advance.
>
>Is there any workaround for that? Or there isn't to do anything about
>the bug and we just have to live with it ...
There is no known workaround. My driver has the option to tune the
command timeouts such that missing interrupts have no noticable impact.
The choice is up to the user.
>> 0x1106 VIA
>> 0x1571 571 x x x x - - - - -
>
>Irq unmasking during PIO transfers is known to cause problems on
>these. Also, some have wrong ISA bridge vendor ID of 1107.
True, but this is stone-age technology. I don't really care about
non-UltraDMA capable chips at all.
>> 0x0571 571
>> 0x0586
>> < 0x20 586 x x x x - - - - -
>
>I have docs on this one.
>
>> >=0x20 586A/B x x x x x - - - x
>
>00..1f 586
>20..2f 586a
>30..3f 586b
>40..46 586b 3040 silicon
>Has a bug where the preq# til ddack# bit must be cleared or can cause
>spontaneous reboots.
>47..4f 586b 3041 silicon
True. I leave this particular setup to the BIOS which is supposed to
take care of such idiosyncrasies...
>> 0x0596
>> < 0x10 596/A x x x x x - - - x
>> < 0x10 596B x x x x x x - - x
>
>That probably should be >= 10
Oops - fixed :-)
>> 0x0686
>> < 0x10 686 x x x x x - - - -
>> < 0x40 686A x x x x x x - - x
>> >=0x40 686B x x x x x x x - -
>
>I have docs here as well.
>
>> 0x8231 VT8231 x x x x x x x - -
>> 0x3074 VT8233 x x x x x x x - -
>
>And for this, too.
>
>> 0x3109 VT8233c x x x x x x x - -
>> 0x3147 VT8233a x x x x x x x x -
>>
>> known bugs:
>> - all: no host side cable type detection.
>
>Not true, for the UDMA100 and UDMA133 capable ones, there are defined
>bits in the UDMA_TIMING register. Not all BIOSes use those, though.
Interesting. None of the user reports ever indicated that.
>> --------------------------------------------------------------------------------
>> 0x10DE Nvidia
>> 0x01BC nForce x x x x x x x - -
>>
>> known bugs:
>> - nForce: no host side cable type detection.
>
>Do you have any info on this one? I'd really like to have a Linux driver
>for it ...
I have no docs, but my father's machine has this chip built in :-) My
driver is running it just fine. In fact, this is a clone of the ATA/100
capable AMD IDE chip cell with all config register addresses shifted up
by 0x10.
I'm looking forward to the new ATI chipset, let's bet where their IDE
cell is licenced from :-)
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 Thu, Mar 14, 2002 at 10:48:10AM +0100, Daniela Engert wrote:
> >00..1f 586
> >20..2f 586a
> >30..3f 586b
> >40..46 586b 3040 silicon
> >Has a bug where the preq# til ddack# bit must be cleared or can cause
> >spontaneous reboots.
> >47..4f 586b 3041 silicon
>
> True. I leave this particular setup to the BIOS which is supposed to
> take care of such idiosyncrasies...
Unfortunately not all BIOSes do. I have at least two reported buggy
BIOSES which set the bit even on the 3040 silicon.
> >> 0x3109 VT8233c x x x x x x x - -
> >> 0x3147 VT8233a x x x x x x x x -
> >>
> >> known bugs:
> >> - all: no host side cable type detection.
> >
> >Not true, for the UDMA100 and UDMA133 capable ones, there are defined
> >bits in the UDMA_TIMING register. Not all BIOSes use those, though.
>
> Interesting. None of the user reports ever indicated that.
It's possible the BIOSes don't set the bits. My driver also checks if
the BIOS enabled UDMA >= 44MB/s on these chips, assuming 80 cable as
well.
Anyway, the docs state the bits should reflect the cable presence.
> >> --------------------------------------------------------------------------------
> >> 0x10DE Nvidia
> >> 0x01BC nForce x x x x x x x - -
> >>
> >> known bugs:
> >> - nForce: no host side cable type detection.
> >
> >Do you have any info on this one? I'd really like to have a Linux driver
> >for it ...
>
> I have no docs, but my father's machine has this chip built in :-) My
> driver is running it just fine. In fact, this is a clone of the ATA/100
> capable AMD IDE chip cell with all config register addresses shifted up
> by 0x10.
Thanks for this info. :) I think I'll add the support to my AMD driver.
Could you by any chance send me a PCI config space dump of the IDE
controller there?
> I'm looking forward to the new ATI chipset, let's bet where their IDE
> cell is licenced from :-)
I don't think it'll be Intel. I bet on VIA ...
--
Vojtech Pavlik
SuSE Labs
Let me try and contribute a bit more back to this wonderful document..
> 0x1078 Cyrix
> 0x0102 CX5530 x x x x x - - - x
>
> known bugs:
> - all: busmaster transfers need to be 16 byte aligned instead of wor=
> d
> aligned.
Add: A DMA block of 65536 bytes comes out as 0 bytes in the chipset.
> 0x1166 ServerWorks
> 0x0211 OSB4 x x ? ? x - - - x
> 0x0212 CSB5
> < 0x92 x x ? ? x x - - -
> >=3D 0x92 x x ? ? x x x - -
>
> known bugs:
> - OSB4: at least some chip revisions can't do Ultra DMA mode 1 and a=
> bove
Interesting - any idea which you've found a problem. One errata we see in
the Linux case with specific drive/board combinations is a
transfer completing but the DMA busy bit never being cleared. The next
DMA transaction is shifted by 4 bytes starting with the last dword of
the previous I/O (as if the DMA engine got something stuck in a FIFO)
> - CSB5: no host side cable type detection.
(Except with extra glue - eg on Dell boxes)
Alan
00:00.0 Host bridge: Intel Corporation 430HX - 82439HX TXC [Triton II]
(rev 03)
00:07.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton
II] (rev 01)
00:07.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE
[Natoma/Triton II]
I suppose mine is ;-)
On Thu, 2002-03-14 at 02:24, Daniela Engert wrote:
> On Thu, 14 Mar 2002 07:52:58 +0100, Vojtech Pavlik wrote:
>
> >> This will benifit PIIX3 chipsets? :)
> >It should.
>
> Are you aware of the batches of broken PIIX3 chips ?
>
> 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
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Thu, Mar 14, 2002 at 12:14:49AM +0100, Vojtech Pavlik wrote:
[snip]
> diff -urN linux-2.5.6-timing/drivers/ide/Config.in linux-2.5.6-piix/drivers/ide/Config.in
> --- linux-2.5.6-timing/drivers/ide/Config.in Mon Mar 11 08:46:22 2002
> +++ linux-2.5.6-piix/drivers/ide/Config.in Wed Mar 13 23:37:20 2002
> @@ -67,10 +67,7 @@
> dep_bool ' HPT34X chipset support' CONFIG_BLK_DEV_HPT34X $CONFIG_BLK_DEV_IDEDMA_PCI
> dep_mbool ' HPT34X AUTODMA support (WIP)' CONFIG_HPT34X_AUTODMA $CONFIG_BLK_DEV_HPT34X $CONFIG_IDEDMA_PCI_WIP
> dep_bool ' HPT366 chipset support' CONFIG_BLK_DEV_HPT366 $CONFIG_BLK_DEV_IDEDMA_PCI
> - if [ "$CONFIG_X86" = "y" -o "$CONFIG_IA64" = "y" ]; then
> - dep_mbool ' Intel PIIXn chipsets support' CONFIG_BLK_DEV_PIIX $CONFIG_BLK_DEV_IDEDMA_PCI
> - dep_mbool ' PIIXn Tuning support' CONFIG_PIIX_TUNING $CONFIG_BLK_DEV_PIIX $CONFIG_IDEDMA_PCI_AUTO
> - fi
> + dep_bool ' Intel PIIX, ICH and Efar Victory66 chipsets support' CONFIG_BLK_DEV_PIIX $CONFIG_BLK_DEV_IDEDMA_PCI
> if [ "$CONFIG_MIPS_ITE8172" = "y" -o "$CONFIG_MIPS_IVR" = "y" ]; then
> dep_mbool ' IT8172 IDE support' CONFIG_BLK_DEV_IT8172 $CONFIG_BLK_DEV_IDEDMA_PCI
> dep_mbool ' IT8172 IDE Tuning support' CONFIG_IT8172_TUNING $CONFIG_BLK_DEV_IT8172 $CONFIG_IDEDMA_PCI_AUTO
> @@ -83,7 +80,6 @@
> dep_bool ' Special FastTrak Feature' CONFIG_PDC202XX_FORCE $CONFIG_BLK_DEV_PDC202XX
> dep_bool ' ServerWorks OSB4/CSB5 chipsets support' CONFIG_BLK_DEV_SVWKS $CONFIG_BLK_DEV_IDEDMA_PCI $CONFIG_X86
> dep_bool ' SiS5513 chipset support' CONFIG_BLK_DEV_SIS5513 $CONFIG_BLK_DEV_IDEDMA_PCI $CONFIG_X86
> - dep_bool ' SLC90E66 chipset support' CONFIG_BLK_DEV_SLC90E66 $CONFIG_BLK_DEV_IDEDMA_PCI $CONFIG_X86
> dep_bool ' Tekram TRM290 chipset support (EXPERIMENTAL)' CONFIG_BLK_DEV_TRM290 $CONFIG_BLK_DEV_IDEDMA_PCI
> dep_bool ' VIA82CXXX chipset support' CONFIG_BLK_DEV_VIA82CXXX $CONFIG_BLK_DEV_IDEDMA_PCI
> fi
This reminds (and I'm about to submit a patch to fix it..) but the above
is wrong, and should look like:
if [ "$CONFIG_X86" = "y" -o "$CONFIG_IA64" = "y" ]; then
dep_bool ' Intel PIIX, ICH and Efar Victory66 chipsets support' CONFIG_BLK_DEV_PIIX $CONFIG_BLK_DEV_IDEDMA_PCI
fi
Unless the Efar Victory66 is showing up in other arches now...
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
On Thu, Mar 14, 2002 at 09:47:25AM -0700, Tom Rini wrote:
> On Thu, Mar 14, 2002 at 12:14:49AM +0100, Vojtech Pavlik wrote:
>
> [snip]
> > diff -urN linux-2.5.6-timing/drivers/ide/Config.in linux-2.5.6-piix/drivers/ide/Config.in
> > --- linux-2.5.6-timing/drivers/ide/Config.in Mon Mar 11 08:46:22 2002
> > +++ linux-2.5.6-piix/drivers/ide/Config.in Wed Mar 13 23:37:20 2002
> > @@ -67,10 +67,7 @@
> > dep_bool ' HPT34X chipset support' CONFIG_BLK_DEV_HPT34X $CONFIG_BLK_DEV_IDEDMA_PCI
> > dep_mbool ' HPT34X AUTODMA support (WIP)' CONFIG_HPT34X_AUTODMA $CONFIG_BLK_DEV_HPT34X $CONFIG_IDEDMA_PCI_WIP
> > dep_bool ' HPT366 chipset support' CONFIG_BLK_DEV_HPT366 $CONFIG_BLK_DEV_IDEDMA_PCI
> > - if [ "$CONFIG_X86" = "y" -o "$CONFIG_IA64" = "y" ]; then
> > - dep_mbool ' Intel PIIXn chipsets support' CONFIG_BLK_DEV_PIIX $CONFIG_BLK_DEV_IDEDMA_PCI
> > - dep_mbool ' PIIXn Tuning support' CONFIG_PIIX_TUNING $CONFIG_BLK_DEV_PIIX $CONFIG_IDEDMA_PCI_AUTO
> > - fi
> > + dep_bool ' Intel PIIX, ICH and Efar Victory66 chipsets support' CONFIG_BLK_DEV_PIIX $CONFIG_BLK_DEV_IDEDMA_PCI
> > if [ "$CONFIG_MIPS_ITE8172" = "y" -o "$CONFIG_MIPS_IVR" = "y" ]; then
> > dep_mbool ' IT8172 IDE support' CONFIG_BLK_DEV_IT8172 $CONFIG_BLK_DEV_IDEDMA_PCI
> > dep_mbool ' IT8172 IDE Tuning support' CONFIG_IT8172_TUNING $CONFIG_BLK_DEV_IT8172 $CONFIG_IDEDMA_PCI_AUTO
> > @@ -83,7 +80,6 @@
> > dep_bool ' Special FastTrak Feature' CONFIG_PDC202XX_FORCE $CONFIG_BLK_DEV_PDC202XX
> > dep_bool ' ServerWorks OSB4/CSB5 chipsets support' CONFIG_BLK_DEV_SVWKS $CONFIG_BLK_DEV_IDEDMA_PCI $CONFIG_X86
> > dep_bool ' SiS5513 chipset support' CONFIG_BLK_DEV_SIS5513 $CONFIG_BLK_DEV_IDEDMA_PCI $CONFIG_X86
> > - dep_bool ' SLC90E66 chipset support' CONFIG_BLK_DEV_SLC90E66 $CONFIG_BLK_DEV_IDEDMA_PCI $CONFIG_X86
> > dep_bool ' Tekram TRM290 chipset support (EXPERIMENTAL)' CONFIG_BLK_DEV_TRM290 $CONFIG_BLK_DEV_IDEDMA_PCI
> > dep_bool ' VIA82CXXX chipset support' CONFIG_BLK_DEV_VIA82CXXX $CONFIG_BLK_DEV_IDEDMA_PCI
> > fi
>
> This reminds (and I'm about to submit a patch to fix it..) but the above
> is wrong, and should look like:
> if [ "$CONFIG_X86" = "y" -o "$CONFIG_IA64" = "y" ]; then
> dep_bool ' Intel PIIX, ICH and Efar Victory66 chipsets support' CONFIG_BLK_DEV_PIIX $CONFIG_BLK_DEV_IDEDMA_PCI
> fi
>
> Unless the Efar Victory66 is showing up in other arches now...
No, but Intel PIIX certainly is used at least on Alphas, and I've seen
it used together with an ARM.
--
Vojtech Pavlik
SuSE Labs