From: Vojtech Pavlik <vojtech@suse.cz>
To: Daniela Engert <dani@ngrt.de>
Cc: Vojtech Pavlik <vojtech@suse.cz>,
LKML <linux-kernel@vger.kernel.org>,
Martin Dalecki <martin@dalecki.de>,
Shawn Starr <spstarr@sh0n.net>
Subject: Re: [patch] PIIX rewrite patch, pre-final
Date: Thu, 14 Mar 2002 09:18:08 +0100 [thread overview]
Message-ID: <20020314091808.B31998@ucw.cz> (raw)
In-Reply-To: <20020314083038.A31923@ucw.cz> <20020314063843.E0E3210921@mail.medav.de>
In-Reply-To: <20020314063843.E0E3210921@mail.medav.de>; from dani@ngrt.de on Thu, Mar 14, 2002 at 08:44:42AM +0100
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
next prev parent reply other threads:[~2002-03-14 8:18 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-13 23:14 [patch] PIIX rewrite patch, pre-final Vojtech Pavlik
2002-03-14 1:04 ` Shawn Starr
2002-03-14 6:52 ` Vojtech Pavlik
2002-03-14 7:24 ` Daniela Engert
2002-03-14 7:30 ` Vojtech Pavlik
2002-03-14 7:36 ` Andre Hedrick
2002-03-14 7:46 ` Vojtech Pavlik
2002-03-14 7:38 ` Andre Hedrick
2002-03-14 7:44 ` Daniela Engert
2002-03-14 8:18 ` Vojtech Pavlik [this message]
2002-03-14 8:23 ` Vojtech Pavlik
2002-03-14 9:48 ` Daniela Engert
2002-03-14 10:14 ` Vojtech Pavlik
2002-03-14 14:19 ` Alan Cox
2002-03-14 14:39 ` Shawn Starr
2002-03-14 16:47 ` Tom Rini
2002-03-14 16:49 ` Vojtech Pavlik
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=20020314091808.B31998@ucw.cz \
--to=vojtech@suse.cz \
--cc=dani@ngrt.de \
--cc=linux-kernel@vger.kernel.org \
--cc=martin@dalecki.de \
--cc=spstarr@sh0n.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.