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 ht
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 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 rudeness,
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
toward
> 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 th
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 now.
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
> 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 coul
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
> 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:
> 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 fo
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 perfo
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 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 ac
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'. I
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 b
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 doesn'
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 d
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 fro
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
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 drive
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" disc
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 consider
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).
Hi,
David P. Reed reed.com> writes:
> And actually, if I had looked at the /sys/bus/pnp definitions, rather
> than /proc/ioports, I would have noticed that port 80 was part of a
> PNP0C02 resource set. That means exactly one thing: ACPI says that
> port 80 is NOT free to be used, for delay
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 d
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 http://vge
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 earl
Maciej W. Rozycki wrote:
On Tue, 1 Jan 2008, H. Peter Anvin wrote:
It's specifically a side effect *we don't care about*, except in the
by-now-somewhat-exotic case of 386+387 (where we indeed can't use it once user
code has touched the FPU -- but we can fall back to 0x80 on those, a very
small
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 Tue, 1 Jan 2008, H. Peter Anvin wrote:
> It's specifically a side effect *we don't care about*, except in the
> by-now-somewhat-exotic case of 386+387 (where we indeed can't use it once user
> code has touched the FPU -- but we can fall back to 0x80 on those, a very
> small number of systems.)
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 devi
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 satisfactio
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 bac
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 s
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 bac
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 definite
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 ful
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 betwee
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 with
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 a
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 machi
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.
> 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 tim
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 take
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 respon
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 b
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
>
> As long as there is no port 80 card or a similar device using it. If
> there is a port 80 card, ISA acess needing the delay does break
Such cards are very unusual on ISA machines and it hasn't been a problem
in fifteen years. All the alternatives are vastly higher risk
--
To unsubscribe from th
> 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
> OTOH, the DOS drivers I heared about use delays and would break on
> underclocked ISA busses if the n * ISA_HZ delay was needed. Maybe
> somebody having a configurable ISA bus speed and some problematic
> chips can test it ...
I've been looking at DOS reference drivers - they almost all use I/O
On 08-01-08 13:51, Bodo Eggert wrote:
On Tue, 8 Jan 2008, Rene Herman wrote:
Is this only about the ones then left for things like legacy PIC and PIT?
Does anyone care about just sticking in a udelay(2) (or 1) there as a
replacement and call it a day?
PIT is problematic because the PIT may
On Mon, 7 Jan 2008, Alan Cox wrote:
> > But overclocking is not the problem for udelay, it would err to the safe
> > side. The problem would be a BUS having < 8 MHz, and since the days of
> > 80286, they are hard to find. IMO having an option to set the bus speed
> > for those systems should 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 ins
On Tue, 8 Jan 2008, Rene Herman wrote:
> On 08-01-08 00:24, H. Peter Anvin wrote:
> > Rene Herman wrote:
> > > Is this only about the ones then left for things like legacy PIC and PIT?
> > > Does anyone care about just sticking in a udelay(2) (or 1) there as a
> > > replacement and call it a day?
On Mon, 07 Jan 2008 20:38:09 +0100
Bodo Eggert <[EMAIL PROTECTED]> wrote:
> Christer Weinigel <[EMAIL PROTECTED]> wrote:
>
> > How do you find out the speed of the ISA bus? AFAIK there is no
> > standardized way to do that. On the Geode SC2200 the ISA bus speed
> > is usually the PCI clock divi
> The PIT usage for calibrating the delay loop can be moderated, if need
> by, by using the PC BIOS which by definition uses the PIT correctly it
> its int 15 function 83 call.. Just do it before coming up in a state
> where the PC BIOS int 15h calls no longer work. I gave code to do this
>
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 it's created largely by a collection of Taiwanese and Ch
David P. Reed wrote:
And actually, if I had looked at the /sys/bus/pnp definitions, rather
than /proc/ioports, I would have noticed that port 80 was part of a
PNP0C02 resource set. That means exactly one thing: ACPI says that
port 80 is NOT free to be used, for delays or anything else.
T
On another topic. I have indeed determined what device uses port 80 on
Quanta AMD64 laptops from HP.
I had lunch with Jim Gettys of OLPC a week ago; he's an old friend since
he worked on the original X windows system. After telling him my story
about port 80, he mentioned that the OLPC XO m
H. Peter Anvin wrote:
Rene Herman wrote:
Is this only about the ones then left for things like legacy PIC and
PIT? Does anyone care about just sticking in a udelay(2) (or 1) there
as a replacement and call it a day?
PIT is problematic because the PIT may be necessary for udelay setup.
> But overclocking is not the problem for udelay, it would err to the safe
> side. The problem would be a BUS having < 8 MHz, and since the days of
> 80286, they are hard to find. IMO having an option to set the bus speed
> for those systems should be enough.
If you get it wrong you risk data co
On 08-01-08 00:24, H. Peter Anvin wrote:
Rene Herman wrote:
Is this only about the ones then left for things like legacy PIC and
PIT? Does anyone care about just sticking in a udelay(2) (or 1) there
as a replacement and call it a day?
PIT is problematic because the PIT may be necessary f
Rene Herman wrote:
Is this only about the ones then left for things like legacy PIC and
PIT? Does anyone care about just sticking in a udelay(2) (or 1) there as
a replacement and call it a day?
PIT is problematic because the PIT may be necessary for udelay setup.
-hpa
--
To unsubs
On 07-01-08 23:27, Bodo Eggert wrote:
On Mon, 7 Jan 2008, H. Peter Anvin wrote:
There might have been a few 386/20's clocking the ISA bus at ÷3 (6.67
MHz) rather than ÷2 (10 MHz) or ÷2.5 (8 MHz).
Yes, and the remaining users should set the kernel option. Both of them.
The question is: Ho
On Mon, 7 Jan 2008, H. Peter Anvin wrote:
> Bodo Eggert wrote:
> > But overclocking is not the problem for udelay, it would err to the safe
> > side. The problem would be a BUS having < 8 MHz, and since the days of
> > 80286, they are hard to find. IMO having an option to set the bus speed
> > for
Bodo Eggert wrote:
But overclocking is not the problem for udelay, it would err to the safe
side. The problem would be a BUS having < 8 MHz, and since the days of
80286, they are hard to find. IMO having an option to set the bus speed
for those systems should be enough.
There might have be
On Mon, 7 Jan 2008, H. Peter Anvin wrote:
> Bodo Eggert wrote:
> > Christer Weinigel <[EMAIL PROTECTED]> wrote:
> > > How do you find out the speed of the ISA bus? AFAIK there is no
> > > standardized way to do that. On the Geode SC2200 the ISA bus speed is
> > > usually the PCI clock divided by
Bodo Eggert wrote:
Christer Weinigel <[EMAIL PROTECTED]> wrote:
How do you find out the speed of the ISA bus? AFAIK there is no
standardized way to do that. On the Geode SC2200 the ISA bus speed is
usually the PCI clock divided by 4 giving 33MHz/4=8.3MHz or
30/4=7.5MHz, but with no external I
Christer Weinigel <[EMAIL PROTECTED]> wrote:
> How do you find out the speed of the ISA bus? AFAIK there is no
> standardized way to do that. On the Geode SC2200 the ISA bus speed is
> usually the PCI clock divided by 4 giving 33MHz/4=8.3MHz or
> 30/4=7.5MHz, but with no external ISA devices it'
On 02-01-08 16:35, Rene Herman wrote:
> On 02-01-08 14:47, Alan Cox wrote:
>
>>> ok, you are right. How about we go with one of your suggestions:
>>> rename the API family to isa_*_p() in the affected ISA drivers? That
>>> makes it perfectly clear that this is an ISA related historic quirk
>>> tha
On 02-01-08 14:47, Alan Cox wrote:
ok, you are right. How about we go with one of your suggestions: rename
the API family to isa_*_p() in the affected ISA drivers? That makes it
perfectly clear that this is an ISA related historic quirk that we just
cannot properly emulate in an acceptable fas
> ok, you are right. How about we go with one of your suggestions: rename
> the API family to isa_*_p() in the affected ISA drivers? That makes it
> perfectly clear that this is an ISA related historic quirk that we just
> cannot properly emulate in an acceptable fashion. It will also make the
* David P. Reed <[EMAIL PROTECTED]> wrote:
> FYI - another quirky Quanta motherboard from HP, with DMI readings reported
> to me.
> Using port80.c, I could hard lock a HP Pavilion tx1000 laptop on the
> first go. This was with ubuntu hardy's stock kernel (a 2.6.24-rc)
>
>> dmidecode -s baseboa
FYI - another quirky Quanta motherboard from HP, with DMI readings
reported to me.
Original Message
Date: Wed, 2 Jan 2008 16:23:27 +1030
From: Joel Stanley <[EMAIL PROTECTED]>
To: David P. Reed <[EMAIL PROTECTED]>
Subject:Re: [PATCH] Option to disable AMD C1E (a
* H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> Christer Weinigel wrote:
>>
>> out 80h, al is only two bytes. Any alternative that has been suggested
>> in this discussion will use more space. mov dx, alt_port; out dx, al
>> will be larger, a function call will definitely be a lot larger. People
* Alan Cox <[EMAIL PROTECTED]> wrote:
> > udelay is supposed to be reliable. If someone runs a new kernel and
> > has no TSC (which might happen even on modern hardware or with
> > notsc) _and_ finds that udelay is not calibrated well enough then
> > that's a kernel bug we want to fix.
>
> Yo
On 31-12-07 16:56, Alan Cox wrote:
Okay. Am about to go stuff my face with new years celebrations but will
definitely try to make that old WD8003 hickup.
Have fun. Is it an 8390 or an 83905 ?
A DP8390BN. And I have a DP8390CN on a 3Com Etherlink II. The NE1000 has a
DP83901AV, my new-fangle
Christer Weinigel wrote:
Both 0xed and 0xf0 are mapped to internal functions on the AMD Elan
SC400 processor. It is an AMD 486 based system on a chip and since AMD
just knew that it would never have a math coprocessor, they reused the
0xf0-0xf2 range for the PCMCIA controller. I guess the AMD
On 02-01-08 01:55, Christer Weinigel wrote:
On Wed, 02 Jan 2008 00:11:54 +0100
Rene Herman <[EMAIL PROTECTED]> wrote:
Well, on the PIIX it is and I guess on anything where it's _not_
fully internal an 0xf0 write wouldn't have any effect on IRQ13...
When you earlier mentioned this it seemed 0x
On Wed, 02 Jan 2008 00:11:54 +0100
Rene Herman <[EMAIL PROTECTED]> wrote:
> Well, on the PIIX it is and I guess on anything where it's _not_
> fully internal an 0xf0 write wouldn't have any effect on IRQ13...
>
> When you earlier mentioned this it seemed 0xed switched on DMI would
> be good enoug
On 02-01-08 00:11, Rene Herman wrote:
On 01-01-08 23:39, H. Peter Anvin wrote:
Yes, we do. It's exactly this side effect which makes this safer
than either 0x80 or 0xED -- it's a port that *guaranteed* can't be
reclaimed for other purposes without breaking MS-DOS compatibility.
I see that
On Tue, 1 Jan 2008 23:12:50 +
Alan Cox <[EMAIL PROTECTED]> wrote:
> > Besides the above there are only a handful of _p uses outside of
> > real ISA device drivers, and those should not be relevant for a
> > modern PC unless somebody wants to use an 8390 based PCMCIA card,
> > but we could tell
> Besides the above there are only a handful of _p uses outside of real
> ISA device drivers, and those should not be relevant for a modern PC
> unless somebody wants to use an 8390 based PCMCIA card, but we could
> tell them "don't do that then".
We need to build 8390.c twice anyway - once for PC
On 01-01-08 23:39, H. Peter Anvin wrote:
Yes, we do. It's exactly this side effect which makes this safer
than either 0x80 or 0xED -- it's a port that *guaranteed* can't be
reclaimed for other purposes without breaking MS-DOS compatibility.
I see that with CR0.NE set (*) we indeed don't care
On Tue, 01 Jan 2008 13:21:47 -0800
"H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
> Christer Weinigel wrote:
> >
> > out 80h, al is only two bytes. Any alternative that has been
> > suggested in this discussion will use more space. mov dx,
> > alt_port; out dx, al will be larger, a function call w
Rene Herman wrote:
Yes, we do. It's exactly this side effect which makes this safer than
either 0x80 or 0xED -- it's a port that *guaranteed* can't be
reclaimed for other purposes without breaking MS-DOS compatibility.
I see that with CR0.NE set (*) we indeed don't care about IGNNE#...
How
On 01-01-08 22:44, H. Peter Anvin wrote:
Rene Herman wrote:
On 01-01-08 22:15, H. Peter Anvin wrote:
I have mentioned this before... I think writing zero to port 0xf0
would be an acceptable pause interface (to the extent where we need
an I/O port) except on 386 with 387 present; on those sys
Christer Weinigel wrote:
And once again, the _p in the code that talks to the PIT is very much
non-bogus. And it is a critical path that's called a lot. The i8253
PIT and the i8259 interrupt controller are probably the only ones that
are relevant on a modern machine, and it seems that even som
Rene Herman wrote:
On 01-01-08 22:15, H. Peter Anvin wrote:
I have mentioned this before... I think writing zero to port 0xf0
would be an acceptable pause interface (to the extent where we need an
I/O port) except on 386 with 387 present; on those systems we can fall
back to 0x80.
PII 400 /
On 01-01-08 22:42, Christer Weinigel wrote:
The data sheet for the Intel M8259A says:
End of /RD to Next Command: 300 ns
End of /WR to Next Command: 370 ns
On the other hand, I don't know how all the i8253/i8259 clones or the
numerous variants of Super I/O chips behave. It wouldn't su
On Tue, 1 Jan 2008 22:01:43 +0100
Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > out 80h, al is only two bytes. Any alternative that has been
> > suggested in this discussion will use more space. mov dx,
> > alt_port; out dx, al will be larger, a function call will
> > definitely be a lot larger. P
On 01-01-08 22:15, H. Peter Anvin wrote:
I have mentioned this before... I think writing zero to port 0xf0 would
be an acceptable pause interface (to the extent where we need an I/O
port) except on 386 with 387 present; on those systems we can fall back
to 0x80.
PII 400 / Intel 440 BX (PIIX4
1 - 100 of 246 matches
Mail list logo
