Messages in this thread |  | | | Date | Thu, 14 Mar 2002 09:18:08 +0100 | | From | Vojtech Pavlik <> | | Subject | Re: [patch] PIIX rewrite patch, pre-final |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |