Cc: Ondrej Zary <linux@...>, H. Peter Anvin <hpa@...>, Rene Herman <rene.herman@...>, Bodo Eggert <7eggert@...>, Ingo Molnar <mingo@...>, Alan Cox <alan@...>, Paul Rolland <rol@...>, Pavel Machek <pavel@...>, Thomas Gleixner <tglx@...>, <linux-kernel@...>, Ingo Molnar <mingo@...>, <rol@...>
There is no other kind of argument. Are you claiming supernatural
authority drives your typing fingers, or is your argument based on what
you think you know? I have piles of code that I wrote, spec sheets (now
that I'm back in my home office), code that others wrote at the time,
and documentation from vendors that come from my personal experiences.
That doesn't mean I'm always right - always happy to learn something
new. Just don't condescend to a 55 year old who has been writing
operating systems, compilers, and designing hardware for almost 40 years
professionally (yes, I got my first job at 16 writing FORTRAN code to
simulate hydrodynamic systems).
If you read what I said carefully, I said that the 8390 was a very
special case. The "chip select" problem it experienced was pretty much
unique among boards of the time. Those of us who looked at its design
and had any experience designing hardware for buses like the unibus or
even the buses on PDP-8's and DG machines thought it had to be a joke.
Of course it saved money per board, so it beat the 3Com boards on price
- and you could program it after a fashion. So it involved "cheaping out".
The normal timing problem was that an out or in operation to a board or
chip required some time to elapse before the chip performed the side
effects internally so that the next operation to it would have an
effect. This is exactly the reason why most chips and boards are
designed to either have a polling of a flag indicate operation
completion. The serial "buffer empty" flag is the simplest possible
explanatory example of such handshaking that came to mind (writing a
character to a serial output device twice often leads to surprises,
unless you wait for the previous character to clock out). See my
comment on RTC below, for a more complex to explain example.
The 8253 was a motherboard chip. I am not sure it had any timing
problems with its electrical signalling. I just don't remember. The
spec sheet doesn't say it's internal state can get scrambled.
The RTC has very well documented timing requirements. But none of the
spec sheets, nor my experience with it, mention electrical issues that
prevented back-to-back port operations. The documented timing
requirements have to do with the state during the time it ticks over
internally once per second. But it is carefully designed to have a flag
that is "on" during 244 microseconds prior to and covering the time it
is unsafe to read the registers. That design is special because it is
designed to operate when the machine is powered off, so it has two
internal clock domains, one of which is used in "low power" mode and is
very slow to minimize power.
--
