From: Pavel Machek <pavel@ucw.cz>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>,
Ingo Molnar <mingo@redhat.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: apic and 8254 wraparound ...
Date: Sun, 26 Dec 2004 19:08:06 +0100 [thread overview]
Message-ID: <20041226180806.GA1334@elf.ucw.cz> (raw)
In-Reply-To: <20041225224843.GA32726@mail.13thfloor.at>
Hi!
> > When you read one 8bit value from an 8254 timer the values latch for
> > read so that when you read the other half of the 16bit value you get the
> > value from the moment of the first read. On
> > neptune that didn't work right so you got halves of two differing
> > samples. That means the error would be worst case a bit under 300 (257
> > for the wrap + a few for timing)
>
> okay, I still wasn't able to find the documentation
> at the intel site, but I could extrapolate the issue
> from your explanation (thanks by the way)
>
> get_8254_timer_count() reads lo byte first, then the
> high byte, so assuming that the latch doesn't work
> as expected on intel 430 NX and LX chipsets, can
> result in the following type of error:
>
> counter >= 2^8 * N, LO is read (for example 0)
> counter is decremented
> counter < 2^8 * N HI is read (N - 1)
>
> so the read value will be exactly 2^8 lower than
> expected (assumed that the counter doesn't do more
> than 256 counts between the two inb_p()s)
>
> second the wrap-around will always happen _after_
> the counter reached zero, so we can further assume
> that the prev_count, has to be lower than 2^8, when
> we observe a wraparound (otherwise we don't care)
>
> let's further assume the counter does not decrement
> more than 2^7 between two consecutive gets, then we
> can change the wraparound check to something like
> this:
>
> curr_count = get_8254_timer_count();
>
> do {
> prev_count = curr_count;
> redo:
> curr_count = get_8254_timer_count();
>
> /* workaround for broken Mercury/Neptune */
> if (prev_count - current_count >= 256)
> goto redo;
>
> /* ignore values far off from zero */
> if (prev_count > 128)
> continue;
>
> } while (prev_count >= curr_count)
>
>
> basically the check for (prev_count > 128) can be
> removed but it feels a little more comfortable ...
>
> would such change be acceptable for mainline?
Not sure... Reading time is quite performance critical; doing it twice
would be bad. It should be acceptable if it was only done on
Mercury/Neptune systems.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
next prev parent reply other threads:[~2004-12-26 18:08 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-24 0:11 apic and 8254 wraparound Herbert Poetzl
2004-12-23 23:37 ` Alan Cox
2004-12-24 20:00 ` Herbert Poetzl
2004-12-24 19:40 ` Alan Cox
2004-12-25 22:48 ` Herbert Poetzl
2004-12-26 18:08 ` Pavel Machek [this message]
2004-12-26 19:42 ` Herbert Poetzl
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=20041226180806.GA1334@elf.ucw.cz \
--to=pavel@ucw.cz \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.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