From: "Henning P. Schmiedehausen" <mailgate@hometree.net>
To: linux-kernel@vger.kernel.org
Subject: Re: Linux 2.4.13-ac4
Date: Mon, 29 Oct 2001 17:14:53 +0000 (UTC) [thread overview]
Message-ID: <9rk2qd$li0$1@forge.intermeta.de> (raw)
In-Reply-To: <20011029084736.A3152@suse.cz> <E15yA5r-0002Ha-00@the-village.bc.nu> <20011029173853.B4041@suse.cz>
Vojtech Pavlik <vojtech@suse.cz> writes:
>On Mon, Oct 29, 2001 at 10:56:35AM +0000, Alan Cox wrote:
>> > bytes read from the 8254 get swapped. I've got some indirect evidence
>> > that this also could happen with the original i8254.
>>
>> Im hoping not. That would imply we interrupted someone half way through
>> reading the counter which means the locking is screwed up.
>Some old DOS assembly sources say that this sometimes happens without
>any interrupts at all - just that the chip is sometimes confused. It'd
Hm. If this is like the 8253 (ugh, way way back in the good old 8085
days I really wired and programmed such a bugger on my CP/M system...),
then the problem is, that the 16 bit counter is read in two 8 bit portions.
And if you do this:
Hi Lo
00000000 11111111 ----> read low byte: 11111111
Counter increments
00000001 00000000 ----> read high byte: 00000001
=> Counter is 00000001 11111111 which is wrong. :-)
Sames goes for decrement, I have forgotten in which direction this
bugger counts.
There was a trick when CPUs had much less MHz:
read low byte -> A
read high byte -> B
read low byte -> C
If A and C are the same, then the counter didn't change while reading:
byte a, b, c;
a = inb(lowbyte);
for(;;) {
b = inb(hibyte);
c = inb(lobyte);
if(c == a)
break;
a = c;
}
result = b<<8+a;
This assumes that you can't get _two_ changes in the high byte while
reading the ports in a row.
>be definitely worth printing the bad and good values when a problem is
>detected, so that we know what's happening.
This will happen all the time, so printing out is neither a good idea
nor is the read problem described above an error. It is just a quirk
in using an 8 bit chip in an 16 bit environment without being able to
"latch" the count.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH hps@intermeta.de
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 info@intermeta.de
D-91054 Buckenhof Fax.: 09131 / 50654-20
next prev parent reply other threads:[~2001-10-29 17:14 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-28 20:40 Linux 2.4.13-ac4 Alan Cox
2001-10-29 7:47 ` Vojtech Pavlik
2001-10-29 10:56 ` Alan Cox
2001-10-29 16:38 ` Vojtech Pavlik
2001-10-29 17:14 ` Henning P. Schmiedehausen [this message]
2001-10-29 17:28 ` Maciej W. Rozycki
2001-10-29 17:48 ` Vojtech Pavlik
2001-10-29 16:07 ` Maciej W. Rozycki
2001-10-29 16:19 ` Alan Cox
2001-10-29 20:03 ` Vojtech Pavlik
2001-10-30 11:23 ` Maciej W. Rozycki
2001-10-30 4:09 ` George Garvey
2001-10-30 4:24 ` Mike Fedyk
[not found] <E15yFhL-0003ED-00@the-village.bc.nu>
2001-10-29 17:11 ` Maciej W. Rozycki
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='9rk2qd$li0$1@forge.intermeta.de' \
--to=mailgate@hometree.net \
--cc=hps@intermeta.de \
--cc=linux-kernel@vger.kernel.org \
/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.