On 18-01-08 14:37, David Newall wrote:
The problem is that _p is widely used for non-ISA devices.
Yes, we know, it's being fixed. Piss off.
Rene.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Rene,
Here is why you shouldn't leap so quickly to rudeness. Everything is
being repeated over and over and over again (as you put it) because
people like you shout down people like me without making any apparent
effort to understand the truth of the problem.
Rene Herman wrote:
> We've already
Rene,
Here is why you shouldn't leap so quickly to rudeness. Everything is
being repeated over and over and over again (as you put it) because
people like you shout down people like me without making any apparent
effort to understand the truth of the problem.
Rene Herman wrote:
We've already
On 18-01-08 14:37, David Newall wrote:
The problem is that _p is widely used for non-ISA devices.
Yes, we know, it's being fixed. Piss off.
Rene.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On 17-01-08 22:58, David Newall wrote:
Rene Herman wrote:
Over the course of a 100 messages or so in this thread it's been
determined that the best course of action is to keep the out for ISA
and replace it with udelay() for chipset logic. Now go away.
Rather than this incredible
Rene Herman wrote:
> Over the course of a 100 messages or so in this thread it's been
> determined that the best course of action is to keep the out for ISA
> and replace it with udelay() for chipset logic. Now go away.
Rather than this incredible rudeness, why don't you direct your energy
> In the early days of clone PCs, as you know but perhaps many on this
> list might not, the bus speed could be changed, but this was
> user-selectable. For such a machine, delay values can be pre-calculated
> for each bus speed, and a kernel parameter set accordingly. Or are you
> saying that
On 17-01-08 14:36, David Newall wrote:
In the early days of clone PCs, as you know but perhaps many on this
list might not
I'm so incredibly sick of this fucking thread. We've had enough legacy farts
coming out of the woodwork advertising their own massive experience and
cluelessness by
Alan Cox wrote:
>> This is a timing issue, isn't it? How are we synchronising, other than
>> by delaying for a (bus-dependant) period? The characteristics of each
>> bus are known so a number can be assigned for "one bus cycle", without
>> having to use the bus.
>>
>
> The characteristics
> This is a timing issue, isn't it? How are we synchronising, other than
> by delaying for a (bus-dependant) period? The characteristics of each
> bus are known so a number can be assigned for "one bus cycle", without
> having to use the bus.
The characteristics of the bus are not known. It
This is a timing issue, isn't it? How are we synchronising, other than
by delaying for a (bus-dependant) period? The characteristics of each
bus are known so a number can be assigned for one bus cycle, without
having to use the bus.
The characteristics of the bus are not known. It could be
Alan Cox wrote:
This is a timing issue, isn't it? How are we synchronising, other than
by delaying for a (bus-dependant) period? The characteristics of each
bus are known so a number can be assigned for one bus cycle, without
having to use the bus.
The characteristics of the bus are
On 17-01-08 14:36, David Newall wrote:
In the early days of clone PCs, as you know but perhaps many on this
list might not
I'm so incredibly sick of this fucking thread. We've had enough legacy farts
coming out of the woodwork advertising their own massive experience and
cluelessness by
In the early days of clone PCs, as you know but perhaps many on this
list might not, the bus speed could be changed, but this was
user-selectable. For such a machine, delay values can be pre-calculated
for each bus speed, and a kernel parameter set accordingly. Or are you
saying that the
Rene Herman wrote:
Over the course of a 100 messages or so in this thread it's been
determined that the best course of action is to keep the out for ISA
and replace it with udelay() for chipset logic. Now go away.
Rather than this incredible rudeness, why don't you direct your energy
towards
On 17-01-08 22:58, David Newall wrote:
Rene Herman wrote:
Over the course of a 100 messages or so in this thread it's been
determined that the best course of action is to keep the out for ISA
and replace it with udelay() for chipset logic. Now go away.
Rather than this incredible
Alan Cox wrote:
>> If the hardware required an intermediate junk I/O, that would be a
>> reason to do one, but it doesn't, does it? It requires a delay. It's
>> written thus in all of the application notes.
>>
>
> And the only instruction that is synchronized to the bus in question is
> an
> If the hardware required an intermediate junk I/O, that would be a
> reason to do one, but it doesn't, does it? It requires a delay. It's
> written thus in all of the application notes.
And the only instruction that is synchronized to the bus in question is
an I/O instruction.
> Wrong
Alan Cox wrote:
> On Thu, 17 Jan 2008 01:06:24 +1030
> David Newall <[EMAIL PROTECTED]> wrote:
>
>
>> This use of port 80 (or insert some other random number) is a croc of
>> hackery of the most inexperienced kind.
>>
>
> Wrong. It's a careful designed solution used by all sorts of code
On Thu, 17 Jan 2008 01:06:24 +1030
David Newall <[EMAIL PROTECTED]> wrote:
> This use of port 80 (or insert some other random number) is a croc of
> hackery of the most inexperienced kind.
Wrong. It's a careful designed solution used by all sorts of code for
over 15 years.
The task to be
David P. Reed wrote:
> I think we probably have a great shot at getting Intel, Microsoft, HP,
> et al.. to add a feature for Linux to one of the ACPI table
> specifications that define an "unused port for delay purposes" field
> in the ACPI 4.0 spec, and retrofit it into PC/104 machine BIOSes. At
David P. Reed wrote:
I think we probably have a great shot at getting Intel, Microsoft, HP,
et al.. to add a feature for Linux to one of the ACPI table
specifications that define an unused port for delay purposes field
in the ACPI 4.0 spec, and retrofit it into PC/104 machine BIOSes. At
On Thu, 17 Jan 2008 01:06:24 +1030
David Newall [EMAIL PROTECTED] wrote:
This use of port 80 (or insert some other random number) is a croc of
hackery of the most inexperienced kind.
Wrong. It's a careful designed solution used by all sorts of code for
over 15 years.
The task to be
Alan Cox wrote:
On Thu, 17 Jan 2008 01:06:24 +1030
David Newall [EMAIL PROTECTED] wrote:
This use of port 80 (or insert some other random number) is a croc of
hackery of the most inexperienced kind.
Wrong. It's a careful designed solution used by all sorts of code for
over 15
If the hardware required an intermediate junk I/O, that would be a
reason to do one, but it doesn't, does it? It requires a delay. It's
written thus in all of the application notes.
And the only instruction that is synchronized to the bus in question is
an I/O instruction.
Wrong again.
Alan Cox wrote:
If the hardware required an intermediate junk I/O, that would be a
reason to do one, but it doesn't, does it? It requires a delay. It's
written thus in all of the application notes.
And the only instruction that is synchronized to the bus in question is
an I/O
David Woodhouse wrote:
On Fri, 2008-01-11 at 09:35 -0500, David P. Reed wrote:
Using any "unused port" for a delay means that the machine check
feature is wasted and utterly unusable.
Not entirely unusable. You can recover silently from the machine check
if it was one of the known
On Fri, 2008-01-11 at 09:35 -0500, David P. Reed wrote:
> Using any "unused port" for a delay means that the machine check
> feature is wasted and utterly unusable.
Not entirely unusable. You can recover silently from the machine check
if it was one of the known accesses to the 'unused port'.
On Fri, 2008-01-11 at 09:35 -0500, David P. Reed wrote:
Using any unused port for a delay means that the machine check
feature is wasted and utterly unusable.
Not entirely unusable. You can recover silently from the machine check
if it was one of the known accesses to the 'unused port'. It
David Woodhouse wrote:
On Fri, 2008-01-11 at 09:35 -0500, David P. Reed wrote:
Using any unused port for a delay means that the machine check
feature is wasted and utterly unusable.
Not entirely unusable. You can recover silently from the machine check
if it was one of the known
David P. Reed wrote:
Alan Cox wrote:
bus abort on the LPC bus". More problematic is that I would think
some people might want to turn on the AMD feature that generates
machine checks if a bus timeout happens. The whole point of machine
checks is
An ISA/LPC bus timeout is fulfilled
Alan Cox wrote:
bus abort on the LPC bus". More problematic is that I would think some
people might want to turn on the AMD feature that generates machine
checks if a bus timeout happens. The whole point of machine checks is
An ISA/LPC bus timeout is fulfilled by the bridge so
On 11-01-08 15:35, David P. Reed wrote:
Rene Herman wrote:
On 11-01-08 02:36, Zachary Amsden wrote:
FWIW, I fixed the problem locally by recompiling, changing port 80 to
port 84 in io.h; works great, and doesn't conflict with any occupied
ports.
Might not give you a "proper" delay though.
> bus abort on the LPC bus". More problematic is that I would think some
> people might want to turn on the AMD feature that generates machine
> checks if a bus timeout happens. The whole point of machine checks is
An ISA/LPC bus timeout is fulfilled by the bridge so doesn't cause an MCE.
Rene Herman wrote:
On 11-01-08 02:36, Zachary Amsden wrote:
FWIW, I fixed the problem locally by recompiling, changing port 80 to
port 84 in io.h; works great, and doesn't conflict with any occupied
ports.
Might not give you a "proper" delay though. 0xed should be a better
choice...
I
On 11-01-08 15:35, David P. Reed wrote:
Rene Herman wrote:
On 11-01-08 02:36, Zachary Amsden wrote:
FWIW, I fixed the problem locally by recompiling, changing port 80 to
port 84 in io.h; works great, and doesn't conflict with any occupied
ports.
Might not give you a proper delay though.
bus abort on the LPC bus. More problematic is that I would think some
people might want to turn on the AMD feature that generates machine
checks if a bus timeout happens. The whole point of machine checks is
An ISA/LPC bus timeout is fulfilled by the bridge so doesn't cause an MCE.
Rene Herman wrote:
On 11-01-08 02:36, Zachary Amsden wrote:
FWIW, I fixed the problem locally by recompiling, changing port 80 to
port 84 in io.h; works great, and doesn't conflict with any occupied
ports.
Might not give you a proper delay though. 0xed should be a better
choice...
I
Alan Cox wrote:
bus abort on the LPC bus. More problematic is that I would think some
people might want to turn on the AMD feature that generates machine
checks if a bus timeout happens. The whole point of machine checks is
An ISA/LPC bus timeout is fulfilled by the bridge so
David P. Reed wrote:
Alan Cox wrote:
bus abort on the LPC bus. More problematic is that I would think
some people might want to turn on the AMD feature that generates
machine checks if a bus timeout happens. The whole point of machine
checks is
An ISA/LPC bus timeout is fulfilled
On 11-01-08 02:36, Zachary Amsden wrote:
FWIW, I fixed the problem locally by recompiling, changing port 80 to
port 84 in io.h; works great, and doesn't conflict with any occupied
ports.
Might not give you a "proper" delay though. 0xed should be a better choice...
Rene.
--
To unsubscribe
On Wed, 2008-01-09 at 17:22 -0500, David P. Reed wrote:
> Zachary Amsden wrote:
> >
> > According to Phoenix Technologies book "System BIOS for IBM PCs,
> > Compatibles and EISA Computers, 2nd Edition", the I/O port list gives
> >
> > port 0080h R/W Extra page register (temporary storage)
> >
>
Rene Herman wrote:
On 10-01-08 01:37, Robert Hancock wrote:
I agree. In this case the BIOS on these laptops is trying to tell us
"port 80 is used for our purposes, do not touch it". We should be
listening.
Listening is fine but what are you going to do after you have
listened? Right, not
Rene Herman wrote:
On 10-01-08 01:37, Robert Hancock wrote:
I agree. In this case the BIOS on these laptops is trying to tell us
port 80 is used for our purposes, do not touch it. We should be
listening.
Listening is fine but what are you going to do after you have
listened? Right, not
On Wed, 2008-01-09 at 17:22 -0500, David P. Reed wrote:
Zachary Amsden wrote:
According to Phoenix Technologies book System BIOS for IBM PCs,
Compatibles and EISA Computers, 2nd Edition, the I/O port list gives
port 0080h R/W Extra page register (temporary storage)
Despite
On 11-01-08 02:36, Zachary Amsden wrote:
FWIW, I fixed the problem locally by recompiling, changing port 80 to
port 84 in io.h; works great, and doesn't conflict with any occupied
ports.
Might not give you a proper delay though. 0xed should be a better choice...
Rene.
--
To unsubscribe from
On 10-01-08 01:37, Robert Hancock wrote:
David P. Reed wrote:
I have a small suggestion in mind that might be helpful in the future:
the "motherboard resources" discovered as PNP0C02 devices in their _CRS
settings in ACPI during ACPI PnP startup should be reserved (or
checked), and any
David P. Reed wrote:
Christer Weinigel wrote:
Did I miss anyting?
Nothing that seems *crucial* going forward for Linux. The fate of
"legacy machines" is really important to get right.
I have a small suggestion in mind that might be helpful in the future:
the "motherboard resources"
Zachary Amsden wrote:
According to Phoenix Technologies book "System BIOS for IBM PCs,
Compatibles and EISA Computers, 2nd Edition", the I/O port list gives
port 0080h R/W Extra page register (temporary storage)
Despite looking, I've never seen it documented anywhere else, but I
believe it
Christer Weinigel wrote:
On Wed, 09 Jan 2008 10:18:11 -0800
"H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
Zachary Amsden wrote:
I'm speaking specifically in terms of 64-bit platforms here.
Shouldn't we unconditionally drop outb_p doing extra port I/O on
64-bit architectures? Especially
On Tue, 2008-01-08 at 21:19 -0800, H. Peter Anvin wrote:
> Zachary Amsden wrote:
> >
> > BTW, it isn't ever safe to pass port 0x80 through to hardware from a
> > virtual machine; some OSes use port 0x80 as a hardware available scratch
> > register (I believe Darwin/x86 did/does this during boot).
On Wed, 09 Jan 2008 10:18:11 -0800
"H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
> Zachary Amsden wrote:
> >
> > I'm speaking specifically in terms of 64-bit platforms here.
> > Shouldn't we unconditionally drop outb_p doing extra port I/O on
> > 64-bit architectures? Especially considering they
Adrian Bunk wrote:
I don't think the latter statement was true - AFAIR there are Alphas
with ISA slots.
See subject line.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Wed, Jan 09, 2008 at 10:17:24AM -0800, Zachary Amsden wrote:
> On Wed, 2008-01-09 at 16:27 +0100, Rene Herman wrote:
> > On 09-01-08 06:30, Christer Weinigel wrote:
> > I'd not expect very time crtical. The current outb_p use gives a delay
> > somewhere between .5 and 2 microseconds as per
Zachary Amsden wrote:
I'm speaking specifically in terms of 64-bit platforms here. Shouldn't
we unconditionally drop outb_p doing extra port I/O on 64-bit
architectures? Especially considering they don't even have an ISA bus
where the decode timing could even matter?
Why should the bitsize
On Wed, 2008-01-09 at 16:27 +0100, Rene Herman wrote:
> On 09-01-08 06:30, Christer Weinigel wrote:
> I'd not expect very time crtical. The current outb_p use gives a delay
> somewhere between .5 and 2 microseconds as per earlier survey meaning a
> udelay(1) or 2 would be enough -- again, at the
On 09-01-08 06:30, Christer Weinigel wrote:
On Tue, 08 Jan 2008 18:52:42 -0800
Zachary Amsden <[EMAIL PROTECTED]> wrote:
What is the outcome of this thread? Are we going to use timing based
port delays, or can we finally drop these things entirely on 64-bit
architectures?
I a have a doubly
Christer Weinigel wrote:
Did I miss anyting?
Nothing that seems *crucial* going forward for Linux. The fate of
"legacy machines" is really important to get right.
I have a small suggestion in mind that might be helpful in the future:
the "motherboard resources" discovered as PNP0C02
Christer Weinigel wrote:
Did I miss anyting?
Nothing that seems *crucial* going forward for Linux. The fate of
legacy machines is really important to get right.
I have a small suggestion in mind that might be helpful in the future:
the motherboard resources discovered as PNP0C02 devices
On 09-01-08 06:30, Christer Weinigel wrote:
On Tue, 08 Jan 2008 18:52:42 -0800
Zachary Amsden [EMAIL PROTECTED] wrote:
What is the outcome of this thread? Are we going to use timing based
port delays, or can we finally drop these things entirely on 64-bit
architectures?
I a have a doubly
On Wed, 2008-01-09 at 16:27 +0100, Rene Herman wrote:
On 09-01-08 06:30, Christer Weinigel wrote:
I'd not expect very time crtical. The current outb_p use gives a delay
somewhere between .5 and 2 microseconds as per earlier survey meaning a
udelay(1) or 2 would be enough -- again, at the
Zachary Amsden wrote:
I'm speaking specifically in terms of 64-bit platforms here. Shouldn't
we unconditionally drop outb_p doing extra port I/O on 64-bit
architectures? Especially considering they don't even have an ISA bus
where the decode timing could even matter?
Why should the bitsize
On Wed, Jan 09, 2008 at 10:17:24AM -0800, Zachary Amsden wrote:
On Wed, 2008-01-09 at 16:27 +0100, Rene Herman wrote:
On 09-01-08 06:30, Christer Weinigel wrote:
I'd not expect very time crtical. The current outb_p use gives a delay
somewhere between .5 and 2 microseconds as per earlier
On Wed, 09 Jan 2008 10:18:11 -0800
H. Peter Anvin [EMAIL PROTECTED] wrote:
Zachary Amsden wrote:
I'm speaking specifically in terms of 64-bit platforms here.
Shouldn't we unconditionally drop outb_p doing extra port I/O on
64-bit architectures? Especially considering they don't even
On Tue, 2008-01-08 at 21:19 -0800, H. Peter Anvin wrote:
Zachary Amsden wrote:
BTW, it isn't ever safe to pass port 0x80 through to hardware from a
virtual machine; some OSes use port 0x80 as a hardware available scratch
register (I believe Darwin/x86 did/does this during boot).
Zachary Amsden wrote:
According to Phoenix Technologies book System BIOS for IBM PCs,
Compatibles and EISA Computers, 2nd Edition, the I/O port list gives
port 0080h R/W Extra page register (temporary storage)
Despite looking, I've never seen it documented anywhere else, but I
believe it
Christer Weinigel wrote:
On Wed, 09 Jan 2008 10:18:11 -0800
H. Peter Anvin [EMAIL PROTECTED] wrote:
Zachary Amsden wrote:
I'm speaking specifically in terms of 64-bit platforms here.
Shouldn't we unconditionally drop outb_p doing extra port I/O on
64-bit architectures? Especially considering
David P. Reed wrote:
Christer Weinigel wrote:
Did I miss anyting?
Nothing that seems *crucial* going forward for Linux. The fate of
legacy machines is really important to get right.
I have a small suggestion in mind that might be helpful in the future:
the motherboard resources
On 10-01-08 01:37, Robert Hancock wrote:
David P. Reed wrote:
I have a small suggestion in mind that might be helpful in the future:
the motherboard resources discovered as PNP0C02 devices in their _CRS
settings in ACPI during ACPI PnP startup should be reserved (or
checked), and any
On Tue, 08 Jan 2008 18:52:42 -0800
Zachary Amsden <[EMAIL PROTECTED]> wrote:
> On Tue, 2008-01-08 at 14:15 -0500, David P. Reed wrote:
> > Alan Cox wrote:
> > > The natsemi docs here say otherwise. I trust them not you.
> > >
> > As well you should. I am honestly curious (for my own
Zachary Amsden wrote:
BTW, it isn't ever safe to pass port 0x80 through to hardware from a
virtual machine; some OSes use port 0x80 as a hardware available scratch
register (I believe Darwin/x86 did/does this during boot).
That's funny, because there is definitely no guarantee that you get
On Tue, 2008-01-08 at 14:15 -0500, David P. Reed wrote:
> Alan Cox wrote:
> > The natsemi docs here say otherwise. I trust them not you.
> >
> As well you should. I am honestly curious (for my own satisfaction) as
> to what the natsemi docs say the delay code should do (can't imagine
> they
Christer Weinigel wrote:
Argument by personal authority. Thats good.
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
On Tue, 08 Jan 2008 15:28:03 -0500
"David P. Reed" <[EMAIL PROTECTED]> wrote:
> Register compatible. Not the same chips or even the same masks or
> timing requirements.
No, but somehow people keep making similar mistakes. The DEC HiNote
needed outb_p to function correctly? That was
Christer Weinigel wrote:
There is no need to use io writes to supposedly/theoretically "unused
ports" to make drivers work on any bus.
ISA included! You can, for example, wait for an ISA bus serial
adapter to put out its next character by looping reading the port
that has the output buffer
Alan -
I dug up a DP83901A SNIC datasheet in a quick Google search, while that
wasn't the only such chip, it was one of them. I can forward the PDF
(the www.alldatasheet.com site dynamically creates the download URL), if
anyone wants it.
The relevant passage says, in regard to delaying
On Tue, 08 Jan 2008 13:44:54 -0500
"David P. Reed" <[EMAIL PROTECTED]> wrote:
> Ondrej Zary wrote:
> > On Tuesday 08 January 2008 18:24:02 David P. Reed wrote:
> >
> >> Windows these days does delays with timing loops or the
> >> scheduler. It doesn't use a "port". Also, Windows XP only
> >>
> As well you should. I am honestly curious (for my own satisfaction) as
> to what the natsemi docs say the delay code should do (can't imagine
> they say "use io port 80 because it is unused"). I don't have any
They say you must allow 4 bus clocks for the address decode. They don't
deal
Alan Cox wrote:
The natsemi docs here say otherwise. I trust them not you.
As well you should. I am honestly curious (for my own satisfaction) as
to what the natsemi docs say the delay code should do (can't imagine
they say "use io port 80 because it is unused"). I don't have any
copies
On Tuesday 08 January 2008 19:51:41 Bodo Eggert wrote:
> On Tue, 8 Jan 2008, Ondrej Zary wrote:
> > On Tuesday 08 January 2008 18:24:02 David P. Reed wrote:
> > > Windows these days does delays with timing loops or the scheduler. It
> > > doesn't use a "port". Also, Windows XP only supports
On Tue, 8 Jan 2008, Ondrej Zary wrote:
> On Tuesday 08 January 2008 18:24:02 David P. Reed wrote:
> > Windows these days does delays with timing loops or the scheduler. It
> > doesn't use a "port". Also, Windows XP only supports machines that tend
> > not to have timing problems that use
> There is no need to use io writes to supposedly/theoretically "unused
> ports" to make drivers work on any bus.
The natsemi docs here say otherwise. I trust them not you.
> don't remember writing a driver for the 3com devices - probably didn't,
> because 3Com's cards were expensive at the
Ondrej Zary wrote:
On Tuesday 08 January 2008 18:24:02 David P. Reed wrote:
Windows these days does delays with timing loops or the scheduler. It
doesn't use a "port". Also, Windows XP only supports machines that tend
not to have timing problems that use delays. Instead, if a device
On Tuesday 08 January 2008 18:24:02 David P. Reed wrote:
> Windows these days does delays with timing loops or the scheduler. It
> doesn't use a "port". Also, Windows XP only supports machines that tend
> not to have timing problems that use delays. Instead, if a device takes
> a while to
Windows these days does delays with timing loops or the scheduler. It
doesn't use a "port". Also, Windows XP only supports machines that tend
not to have timing problems that use delays. Instead, if a device takes
a while to respond, it has a "busy bit" in some port or memory slot that
can
On Tuesday 08 January 2008 02:38:15 David P. Reed wrote:
> H. Peter Anvin wrote:
> > And shoot the designer of this particular microcontroller firmware.
>
> Well, some days I want to shoot the "designer" of the entire Wintel
> architecture... it's not exactly "designed" by anybody of course, and
> The last time I heard of a 12 MHz bus in a PC system was in the days of
> the PC-AT, when some clone makers sped up their buses (pre PCI!!!) in an
> attempt to allow adapter card *memory* to run at the 12 MHz speed.
It wasn't about clone makers speeding up their busses. The ISA bus
originally
The last time I heard of a 12 MHz bus in a PC system was in the days of
the PC-AT, when some clone makers sped up their buses (pre PCI!!!) in an
attempt to allow adapter card *memory* to run at the 12 MHz speed.
This caused so many industry-wide problems with adapter cards that
couldn't be
The last time I heard of a 12 MHz bus in a PC system was in the days of
the PC-AT, when some clone makers sped up their buses (pre PCI!!!) in an
attempt to allow adapter card *memory* to run at the 12 MHz speed.
This caused so many industry-wide problems with adapter cards that
couldn't be
The last time I heard of a 12 MHz bus in a PC system was in the days of
the PC-AT, when some clone makers sped up their buses (pre PCI!!!) in an
attempt to allow adapter card *memory* to run at the 12 MHz speed.
It wasn't about clone makers speeding up their busses. The ISA bus
originally
On Tuesday 08 January 2008 02:38:15 David P. Reed wrote:
H. Peter Anvin wrote:
And shoot the designer of this particular microcontroller firmware.
Well, some days I want to shoot the designer of the entire Wintel
architecture... it's not exactly designed by anybody of course, and
today
Windows these days does delays with timing loops or the scheduler. It
doesn't use a port. Also, Windows XP only supports machines that tend
not to have timing problems that use delays. Instead, if a device takes
a while to respond, it has a busy bit in some port or memory slot that
can be
On Tuesday 08 January 2008 18:24:02 David P. Reed wrote:
Windows these days does delays with timing loops or the scheduler. It
doesn't use a port. Also, Windows XP only supports machines that tend
not to have timing problems that use delays. Instead, if a device takes
a while to respond, it
There is no need to use io writes to supposedly/theoretically unused
ports to make drivers work on any bus.
The natsemi docs here say otherwise. I trust them not you.
don't remember writing a driver for the 3com devices - probably didn't,
because 3Com's cards were expensive at the time.
On Tue, 8 Jan 2008, Ondrej Zary wrote:
On Tuesday 08 January 2008 18:24:02 David P. Reed wrote:
Windows these days does delays with timing loops or the scheduler. It
doesn't use a port. Also, Windows XP only supports machines that tend
not to have timing problems that use delays.
Ondrej Zary wrote:
On Tuesday 08 January 2008 18:24:02 David P. Reed wrote:
Windows these days does delays with timing loops or the scheduler. It
doesn't use a port. Also, Windows XP only supports machines that tend
not to have timing problems that use delays. Instead, if a device takes
On Tue, 08 Jan 2008 13:44:54 -0500
David P. Reed [EMAIL PROTECTED] wrote:
Ondrej Zary wrote:
On Tuesday 08 January 2008 18:24:02 David P. Reed wrote:
Windows these days does delays with timing loops or the
scheduler. It doesn't use a port. Also, Windows XP only
supports machines
As well you should. I am honestly curious (for my own satisfaction) as
to what the natsemi docs say the delay code should do (can't imagine
they say use io port 80 because it is unused). I don't have any
They say you must allow 4 bus clocks for the address decode. They don't
deal with the
On Tuesday 08 January 2008 19:51:41 Bodo Eggert wrote:
On Tue, 8 Jan 2008, Ondrej Zary wrote:
On Tuesday 08 January 2008 18:24:02 David P. Reed wrote:
Windows these days does delays with timing loops or the scheduler. It
doesn't use a port. Also, Windows XP only supports machines that
Alan Cox wrote:
The natsemi docs here say otherwise. I trust them not you.
As well you should. I am honestly curious (for my own satisfaction) as
to what the natsemi docs say the delay code should do (can't imagine
they say use io port 80 because it is unused). I don't have any
copies
1 - 100 of 121 matches
Mail list logo
