public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Vojtech Pavlik <vojtech@suse.cz>
To: Byron Stanoszek <gandalf@winds.org>
Cc: safemode <safemode@voicenet.com>, linux-kernel@vger.kernel.org
Subject: Re: VT82C686A corruption with 2.4.x
Date: Thu, 1 Feb 2001 19:06:53 +0100	[thread overview]
Message-ID: <20010201190653.H2341@suse.cz> (raw)
In-Reply-To: <3A794945.5F652819@voicenet.com> <Pine.LNX.4.21.0102011137590.27273-100000@winds.org>
In-Reply-To: <Pine.LNX.4.21.0102011137590.27273-100000@winds.org>; from gandalf@winds.org on Thu, Feb 01, 2001 at 11:46:08AM -0500

On Thu, Feb 01, 2001 at 11:46:08AM -0500, Byron Stanoszek wrote:

> Yeah, by bios does the same thing too on the Abit KT7(a).

Ok, I'll remember this. This is most likely the cause of the problems
many people had with the KT7 in the past.

> But you might not
> want to run your PCI clock at 34 instead of 33. Two problems can occur. If you
> don't specify idebus=34 on the kernel prompt, the IDE timings might eventually
> get a DMA reset under 100% disk access. If you do say idebus=34, then you drop
> your maximum throughput from 33 MB/s to 27MB/s.
> 
> I was curious and compiled a list of timings from Vojtech's formula for certain
> idebus=xx MHz ratings (I _think_ the UDMA-66 timings are correct, maybe you can
> check on these, Vojtech..)
> 
> Clock | Setup  Active  Recover  Cycle  UDMA | UDMA-33  UDMA-66  UDMA-100
>    21 |    1       2        1      3    0   |   28.0     56.0      84.0
>    22 |    1       2        1      3    0   |   29.3     58.6      88.0
>    23 |    1       2        1      3    0   |   30.6     61.2      92.0
[snip]
>    31 |    1       3        1      4    0   |   31.0     62.0      93.0
>    32 |    1       3        1      4    0   |   32.0     64.0      96.0
>    33 |    1       3        1      4    0   |   33.0     66.0      99.0
>    34 |    1       3        2      5    0   |   27.2     54.4      81.6
[snip]
>    59 |    2       5        3      8    1   |   29.5     59.0      88.5
>    60 |    2       5        3      8    1   |   30.0     60.0      90.0

Well, the table depends on what type of southbridge chip are you using -
if it's 586b or other UDMA33 chip, 586b/686a or other UDMA66 chip or the
UDMA100 capable 686b.

The U33 chips do UDMA timing in PCICLK (T = 30ns @ 33MHz) increments, U66 in
PCICLK*2 (T = 15ns @ 33 MHz) increments, and for U100 it's assumed that
there is an external 100MHz clock fed to the chip, so that the UDMA timing is
in T = 10ns increments independent of the PCICLK. I'm not 100% sure about
the last, it might be just PCICLK*3 (T = 10ns @ 33 MHz). An experiment needs
to be carried out to verify this.

So, s ahort excerpt of the table will look like:

Chip   | Clock | Setup Active Recover | T  | UDMA-33  UDMA-66  UDMA-100
586b   |    25 |    1      2       1  | 40 | 2T=25.0  xxxxxxx  xxxxxxxx
686a   |    25 |    1      2       1  | 20 | 3T=33.3  2T=50.0  xxxxxxxx
686b   |    25 |    1      2       1  | 10 | 6T=33.3  4T=66.6  2T=100.0

Chip   | Clock | Setup Active Recover | T  | UDMA-33  UDMA-66  UDMA-100
586b   |    33 |    1      2       1  | 30 | 2T=33.3  xxxxxxx  xxxxxxxx
686a   |    33 |    1      2       1  | 15 | 4T=33.3  2T=66.6  xxxxxxxx
686b   |    33 |    1      2       1  | 10 | 6T=33.3  4T=66.6  2T=100.0

... that is, if the 686b indeed has a 100MHz clock source. If not, then
in the case of 25 MHz, T would be 13.3ns. If you can verify this, it'd
be nice.

-- 
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
Please read the FAQ at http://www.tux.org/lkml/

  reply	other threads:[~2001-02-01 18:07 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Pine.LNX.4.10.10101301743180.30535-100000@coffee.psychology.mcmaster.ca>
2001-01-31  1:18 ` VT82C686A corruption with 2.4.x David D.W. Downey
2001-01-31  2:04   ` David D.W. Downey
2001-01-31  7:36     ` Vojtech Pavlik
2001-01-31  7:55       ` David Raufeisen
2001-01-31  9:48         ` safemode
2001-01-31 11:43           ` Vojtech Pavlik
2001-01-31 12:54           ` Mark Hahn
2001-01-31 19:58             ` David Riley
2001-02-01 12:51               ` David D.W. Downey
2001-01-31 20:01             ` safemode
2001-01-31 22:04               ` Tobias Ringstrom
2001-01-31 22:40                 ` safemode
2001-01-31 22:46                   ` Alan Cox
2001-01-31 22:57                     ` safemode
2001-02-01  6:31                       ` Vojtech Pavlik
2001-02-01  0:46                   ` Byron Stanoszek
2001-02-01  1:52                     ` safemode
2001-02-01  6:52                       ` Vojtech Pavlik
2001-02-01 11:32                         ` safemode
2001-02-01 16:46                           ` Byron Stanoszek
2001-02-01 18:06                             ` Vojtech Pavlik [this message]
2001-02-01 18:20                               ` Byron Stanoszek
2001-02-01 20:51                                 ` Vojtech Pavlik
2001-02-01 21:51                                   ` safemode
2001-02-01 21:56                               ` Alan Chandler
2001-02-01  6:39                     ` Vojtech Pavlik
2001-01-31 11:39         ` Vojtech Pavlik
2001-01-31 15:41           ` David D.W. Downey
2001-01-30 13:40 Nicholas Knight
2001-01-30 15:03 ` Tobias Ringstrom
2001-01-30 19:51   ` David D.W. Downey
2001-01-30 20:53     ` David Raufeisen

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=20010201190653.H2341@suse.cz \
    --to=vojtech@suse.cz \
    --cc=gandalf@winds.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=safemode@voicenet.com \
    /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