Mailing List Archive

On Thu, 14 Mar 2002, Martin Wilck wrote:
>
> Hello,
>
> the BIOS on our machines (Phoenix) uses IO-port 0x80 for storing
> POST codes, not only during sytem startup, but also for messages
> generated during SMM (system management mode) operation.
> I have been told other BIOSs do the same.
>
> Unfortunately we can't read this information because Linux uses
> port 80 as "dummy" port for delay operations. (outb_p and friends,
> actually there seem to be a more hard-coded references to port
> 0x80 in the code).
>
> It seems this problem was always there, just nobody took notice of it yet
> (at least in our company). Sometimes people wondered about the weird POST
> codes displayed in the LCD panel, but who cares once the machine is up...
>
> Would it be too outrageous to ask that this port number be changed, or
> made configurable?
>
> Martin
This is a 'N' year-old question. Do you know of a port that is
guaranteed to exist on the Intel/PC/AT class machine? If so, submit
a patch. I proposed using 0x19h (DMA scratch register) several
years ago, but it was shot down for some reason. Then I proposed
0x42 (PIT Misc register), that too was declared off-limits. So
I suggested that the outb to 0x80 be changed to an inp, saving
%eax on the stack first. That too was shot down. So, you try
something... and good luck.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Windows-2000/Professional isn't.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

> Unfortunately we can't read this information because Linux uses
> port 80 as "dummy" port for delay operations. (outb_p and friends,
> actually there seem to be a more hard-coded references to port
> 0x80 in the code).
The dummy port needs to exist. By using 0x80 we have probably the only
port we can safely use in this way. We know it fouls old style POST
boards on odd occasions.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Richard B. Johnson wrote:
> On Thu, 14 Mar 2002, Martin Wilck wrote:
>
>
> >Hello,
> >
> >the BIOS on our machines (Phoenix) uses IO-port 0x80 for storing
> >POST codes, not only during sytem startup, but also for messages
> >generated during SMM (system management mode) operation.
> >I have been told other BIOSs do the same.
> >
> >Unfortunately we can't read this information because Linux uses
> >port 80 as "dummy" port for delay operations. (outb_p and friends,
> >actually there seem to be a more hard-coded references to port
> >0x80 in the code).
> >
> >It seems this problem was always there, just nobody took notice of it yet
> >(at least in our company). Sometimes people wondered about the weird POST
> >codes displayed in the LCD panel, but who cares once the machine is up...
> >
> >Would it be too outrageous to ask that this port number be changed, or
> >made configurable?
> >
> >Martin
>
> This is a 'N' year-old question. Do you know of a port that is
> guaranteed to exist on the Intel/PC/AT class machine? If so, submit
> a patch. I proposed using 0x19h (DMA scratch register) several
> years ago, but it was shot down for some reason. Then I proposed
> 0x42 (PIT Misc register), that too was declared off-limits. So
> I suggested that the outb to 0x80 be changed to an inp, saving
> %eax on the stack first. That too was shot down. So, you try
> something... and good luck.
I also remember this been discussed anually. Making it configurable with
a warning might be a solution, but that's nothing we could decide. Maybe
add a config option? It night be a [DANGEROUS] one, so the guys and gals
who might compile are warned of changing this.
I think the problem is that on PC arch anything is quite limited.
Thunder
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

In article <E16lZg3-0001Ug-00@the-village.bc.nu>,
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> Unfortunately we can't read this information because Linux uses
>> port 80 as "dummy" port for delay operations. (outb_p and friends,
>> actually there seem to be a more hard-coded references to port
>> 0x80 in the code).
>
>The dummy port needs to exist. By using 0x80 we have probably the only
>port we can safely use in this way. We know it fouls old style POST
>boards on odd occasions.
In fact, port 0x80 is safe exactly _because_ it is used for BIOS POST
codes, which pretty much guarantees that it will never be used for
anything else. That tends to not be as true of any other ports.
Also, it should be noted that to get the 1us delay, the port should be
behind the ISA bridge in a legacy world (in a modern all-PCI system it
doesn't really matter, because the ports that need more delays are
faster too, so this works out ok). That's why I personally would be
nervous about using some of the well-specified (but irrelevant) ports
that are on the PCI side of a super-IO controller.
I suspect the _real_ solution is to stop using "inb_p/outb_p" and make
the delay explicit, although it may be that some drivers depend on the
fact that not only is the "outb $0x80" a delay, it also tends to act as
a posting barrier.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Followup to: <a6qtb8$6fg$1@penguin.transmeta.com>
By author: torvalds@transmeta.com (Linus Torvalds)
In newsgroup: linux.dev.kernel
>
> I suspect the _real_ solution is to stop using "inb_p/outb_p" and make
> the delay explicit, although it may be that some drivers depend on the
> fact that not only is the "outb $0x80" a delay, it also tends to act as
> a posting barrier.
>
... as well as a push-out to the ISA bus. I suspect dumping the outb
way of doing it and instead wait in the CPU might cause the delay to
happen in the wrong part of the system (consider split-transaction
queued busses like HyperTransport, where a delay in the CPU doesn't
necessarily mean a delay in the southbridge.)
Port 0x80 has served us well, at least as a default. If you really
care about the POST display you can recompile using a different port.
-hpa
--
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <amsp@zytor.com>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Thu, 14 Mar 2002, Linus Torvalds wrote:
> Date: Thu, 14 Mar 2002 19:23:20 +0000 (UTC)
> From: Linus Torvalds <torvalds@transmeta.com>
> To: linux-kernel@vger.kernel.org
> Subject: Re: IO delay, port 0x80, and BIOS POST codes
>
> In article <E16lZg3-0001Ug-00@the-village.bc.nu>,
> Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> >> Unfortunately we can't read this information because Linux uses
> >> port 80 as "dummy" port for delay operations. (outb_p and friends,
> >> actually there seem to be a more hard-coded references to port
> >> 0x80 in the code).
> >
> >The dummy port needs to exist. By using 0x80 we have probably the only
> >port we can safely use in this way. We know it fouls old style POST
> >boards on odd occasions.
>
> In fact, port 0x80 is safe exactly _because_ it is used for BIOS POST
> codes, which pretty much guarantees that it will never be used for
> anything else. That tends to not be as true of any other ports.
>
> Also, it should be noted that to get the 1us delay, the port should be
> behind the ISA bridge in a legacy world (in a modern all-PCI system it
> doesn't really matter, because the ports that need more delays are
> faster too, so this works out ok). That's why I personally would be
> nervous about using some of the well-specified (but irrelevant) ports
> that are on the PCI side of a super-IO controller.
>
> I suspect the _real_ solution is to stop using "inb_p/outb_p" and make
> the delay explicit, although it may be that some drivers depend on the
> fact that not only is the "outb $0x80" a delay, it also tends to act as
> a posting barrier.
>
> Linus
No, the better/correct port is 0xED which removes the conflict.
We've used 0xED w/o problem doing an embedded linux implementation
at kernel 2.4.1, where SMM issues were involved. (It was recommended
to me by an x-Phoenix BIOS developer, because of its safety as well as
conflict resolution,
Johnh
-
-----------------------------------------------------------------
John Heil
South Coast Software
Custom systems software for UNIX and IBM MVS mainframes
1-714-774-6952
johnhscs@sc-software.com
http://www.sc-software.com
-----------------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Thu, 14 Mar 2002, John Heil wrote:
> On Thu, 14 Mar 2002, Linus Torvalds wrote:
>
> > Date: Thu, 14 Mar 2002 19:23:20 +0000 (UTC)
> > From: Linus Torvalds <torvalds@transmeta.com>
> > To: linux-kernel@vger.kernel.org
> > Subject: Re: IO delay, port 0x80, and BIOS POST codes
> >
> > In article <E16lZg3-0001Ug-00@the-village.bc.nu>,
> > Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > >> Unfortunately we can't read this information because Linux uses
> > >> port 80 as "dummy" port for delay operations. (outb_p and friends,
> > >> actually there seem to be a more hard-coded references to port
> > >> 0x80 in the code).
> > >
> > >The dummy port needs to exist. By using 0x80 we have probably the only
> > >port we can safely use in this way. We know it fouls old style POST
> > >boards on odd occasions.
> >
> > In fact, port 0x80 is safe exactly _because_ it is used for BIOS POST
> > codes, which pretty much guarantees that it will never be used for
> > anything else. That tends to not be as true of any other ports.
> >
> > Also, it should be noted that to get the 1us delay, the port should be
> > behind the ISA bridge in a legacy world (in a modern all-PCI system it
> > doesn't really matter, because the ports that need more delays are
> > faster too, so this works out ok). That's why I personally would be
> > nervous about using some of the well-specified (but irrelevant) ports
> > that are on the PCI side of a super-IO controller.
> >
> > I suspect the _real_ solution is to stop using "inb_p/outb_p" and make
> > the delay explicit, although it may be that some drivers depend on the
> > fact that not only is the "outb $0x80" a delay, it also tends to act as
> > a posting barrier.
> >
> > Linus
>
> No, the better/correct port is 0xED which removes the conflict.
>
> We've used 0xED w/o problem doing an embedded linux implementation
> at kernel 2.4.1, where SMM issues were involved. (It was recommended
> to me by an x-Phoenix BIOS developer, because of its safety as well as
> conflict resolution,
>
> Johnh
>
Well I can see why he's an EX-Phoenix BIOS developer. A port at 0xed
does not exist on any standard or known non-standard Intel/PC/AT
compatible.
Remember DOS debug?
C:\>debug
-i ed
FF
-o ed aa
-i ed
FF
-o ed 55
-i ed
FF
-q

This is not a DOS emulation. This is a real-mode boot where any ports
will be visible. If you used it with success, it means that you didn't
need the I/O delay of writing to a real port. Instead you got the
few hundred nanoseconds of delay you get by writing to nowhere.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Windows-2000/Professional isn't.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Followup to: <Pine.LNX.4.33.0203141234170.1286-100000@scsoftware.sc-software.com>
By author: John Heil <kerndev@sc-software.com>
In newsgroup: linux.dev.kernel
>
> No, the better/correct port is 0xED which removes the conflict.
>
> We've used 0xED w/o problem doing an embedded linux implementation
> at kernel 2.4.1, where SMM issues were involved. (It was recommended
> to me by an x-Phoenix BIOS developer, because of its safety as well as
> conflict resolution,
>
Sorry, causes breakage on quite a few machines. I used it briefly in
SYSLINUX. Phoenix doesn't have that issue since they're part of the
platform, so they can make it a requirement for their BIOS.
-hpa
--
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <amsp@zytor.com>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

This piece of code is taken from an old Minix source code tree, the file being
boothead.s . Notice the port 0xED usage and the comment.
! Enable (ah = 0xDF) or disable (ah = 0xDD) the A20 address line.
gate_A20:
call kb_wait
movb al, #0xD1 ! Tell keyboard that a command is coming
outb 0x64
call kb_wait
movb al, ah ! Enable or disable code
outb 0x60
call kb_wait
mov ax, #25 ! 25 microsec delay for slow keyboard chip
0: out 0xED ! Write to an unused port (1us)
dec ax
jne 0b
ret
kb_wait:
inb 0x64
testb al, #0x02 ! Keyboard input buffer full?
jnz kb_wait ! If so, wait
ret
/Pedro
On 14 Mar 2002 at 16:03, Richard B. Johnson wrote:
>
>
> Well I can see why he's an EX-Phoenix BIOS developer. A port at 0xed
> does not exist on any standard or known non-standard Intel/PC/AT
> compatible.
>
> Remember DOS debug?
>
> C:\>debug
>
> -i ed
> FF
> -o ed aa
> -i ed
> FF
> -o ed 55
> -i ed
> FF
> -q
>
>
> This is not a DOS emulation. This is a real-mode boot where any ports
> will be visible. If you used it with success, it means that you didn't
> need the I/O delay of writing to a real port. Instead you got the few
> hundred nanoseconds of delay you get by writing to nowhere.
>
> Cheers,
> Dick Johnson
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Thu, 14 Mar 2002, John Heil wrote:
>
> No, the better/correct port is 0xED which removes the conflict.
Port ED is fine for a BIOS, which (by definition) knows what the
motherboard devices are, and thus knows that ED cannot be used by
anything.
But it _is_ an unused port, and that's exactly the kind of thing that
might be used sometime in the future. Remember the port 22/23 brouhaha
with Cyrix using it for their stuff, and later Intel getting into the fray
too?
So the fact that ED works doesn't mean that _stays_ working.
The fact that 80 is the post code register means that it is fairly likely
to _stay_ that way, without any ugly surprises.
Now, if there is something _else_ than just the fact that it is unused
that makes ED a good choice in the future too, that might be worth looking
into (like NT using it for the same purpose as Linux does port 80),
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Thu, 14 Mar 2002, Pedro M. Rodrigues wrote:
> Date: Thu, 14 Mar 2002 22:19:23 +0100
> From: Pedro M. Rodrigues <pmanuel@myrealbox.com>
> To: John Heil <kerndev@sc-software.com>, root@chaos.analogic.com
> Cc: Linus Torvalds <torvalds@transmeta.com>, linux-kernel@vger.kernel.org,
> Martin Wilck <Martin.Wilck@fujitsu-siemens.com>
> Subject: Re: IO delay, port 0x80, and BIOS POST codes
>
>
> This piece of code is taken from an old Minix source code tree, the file being
> boothead.s . Notice the port 0xED usage and the comment.
>
>
> ! Enable (ah = 0xDF) or disable (ah = 0xDD) the A20 address line.
> gate_A20:
> call kb_wait
> movb al, #0xD1 ! Tell keyboard that a command is coming
> outb 0x64
> call kb_wait
> movb al, ah ! Enable or disable code
> outb 0x60
> call kb_wait
>
>
> mov ax, #25 ! 25 microsec delay for slow keyboard chip
> 0: out 0xED ! Write to an unused port (1us)
> dec ax
> jne 0b
>
> ret
> kb_wait:
> inb 0x64
> testb al, #0x02 ! Keyboard input buffer full?
> jnz kb_wait ! If so, wait
> ret
>
>
>
> /Pedro
>
> On 14 Mar 2002 at 16:03, Richard B. Johnson wrote:
>
> >
> >
> > Well I can see why he's an EX-Phoenix BIOS developer. A port at 0xed
> > does not exist on any standard or known non-standard Intel/PC/AT
> > compatible.
> >
> > Remember DOS debug?
> >
> > C:\>debug
> >
> > -i ed
> > FF
> > -o ed aa
> > -i ed
> > FF
> > -o ed 55
> > -i ed
> > FF
> > -q
> >
> >
> > This is not a DOS emulation. This is a real-mode boot where any ports
> > will be visible. If you used it with success, it means that you didn't
> > need the I/O delay of writing to a real port. Instead you got the few
> > hundred nanoseconds of delay you get by writing to nowhere.
> >
> > Cheers,
> > Dick Johnson
>
>
We did not want the I/O delay based on the port itself.
We specifically wanted an unused port, and avoid the 0x80 conflict.
Perhaps this should be a kernel hacking/debug option, due to the
difference in environments and needs.
Johnh
-
-----------------------------------------------------------------
John Heil
South Coast Software
Custom systems software for UNIX and IBM MVS mainframes
1-714-774-6952
johnhscs@sc-software.com
http://www.sc-software.com
-----------------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Thu, 14 Mar 2002, Richard B. Johnson wrote:
>
> Well I can see why he's an EX-Phoenix BIOS developer. A port at 0xed
> does not exist on any standard or known non-standard Intel/PC/AT
> compatible.
Note that "doesn't exist" is actually a _bonus_. It means that no
controller will answer to it, which causes the IO to time out, which on a
regular ISA bus will also take the same 1us. Which is what we want.
Real ports with real controllers can be faster - they could, for example,
be fast motherboard PCI ports and be positively decoded and be faster than
1us.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Thu, 14 Mar 2002, Pedro M. Rodrigues wrote:
>
> This piece of code is taken from an old Minix source code tree, the file being
> boothead.s . Notice the port 0xED usage and the comment.
>
>
> ! Enable (ah = 0xDF) or disable (ah = 0xDD) the A20 address line.
> gate_A20:
> call kb_wait
> movb al, #0xD1 ! Tell keyboard that a command is coming
> outb 0x64
> call kb_wait
> movb al, ah ! Enable or disable code
> outb 0x60
> call kb_wait
>
>
> mov ax, #25 ! 25 microsec delay for slow keyboard chip
> 0: out 0xED ! Write to an unused port (1us)
> dec ax
> jne 0b
>
> ret
> kb_wait:
> inb 0x64
> testb al, #0x02 ! Keyboard input buffer full?
> jnz kb_wait ! If so, wait
> ret
>
>
>
> /Pedro
>
Well I see the comment. Writing to IO Space where there are no devices
is basically a no-op. The ISA/PC/AT bus is asynchronous, it is not
clocked. If there's is no contention due to bus activity from some
hardware read, it's just some address lines and data bits that are
eventually sinked by the bus capacity. The CPU isn't forced to wait
for anything. Since it's in I/O space, you don't even get the delay
from a cache-line reload. No thanks, it's bogus as a delay mechanism.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Windows-2000/Professional isn't.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Thu, 14 Mar 2002, Linus Torvalds wrote:
>
> On Thu, 14 Mar 2002, Richard B. Johnson wrote:
> >
> > Well I can see why he's an EX-Phoenix BIOS developer. A port at 0xed
> > does not exist on any standard or known non-standard Intel/PC/AT
> > compatible.
>
> Note that "doesn't exist" is actually a _bonus_. It means that no
> controller will answer to it, which causes the IO to time out, which on a
> regular ISA bus will also take the same 1us. Which is what we want.
>
> Real ports with real controllers can be faster - they could, for example,
> be fast motherboard PCI ports and be positively decoded and be faster than
> 1us.
>
> Linus
>
Well no, IO doesn't "time-out". The PC/AT/ISA bus is asychronous, it's
not clocked. If there's no hardware activity as a result of the write
to nowhere, it's just a no-op. The CPU isn't slowed down at all. It's
just some bits that got flung out on the bus with no feed-back at all.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Windows-2000/Professional isn't.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Followup to: <Pine.LNX.3.95.1020314164142.382B-100000@chaos.analogic.com>
By author: "Richard B. Johnson" <root@chaos.analogic.com>
In newsgroup: linux.dev.kernel
>
> Well no, IO doesn't "time-out". The PC/AT/ISA bus is asychronous, it's
> not clocked. If there's no hardware activity as a result of the write
> to nowhere, it's just a no-op. The CPU isn't slowed down at all. It's
> just some bits that got flung out on the bus with no feed-back at all.
>
An OUT on the x86 architecture is synchronous... the CPU will not
proceed until the OUT is present on the bus. This is a requirement of
the SMM architecture, actually.
-hpa
--
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <amsp@zytor.com>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Followup to: <Pine.LNX.4.33.0203141318130.9855-100000@penguin.transmeta.com>
By author: Linus Torvalds <torvalds@transmeta.com>
In newsgroup: linux.dev.kernel
>
> Port ED is fine for a BIOS, which (by definition) knows what the
> motherboard devices are, and thus knows that ED cannot be used by
> anything.
>
> But it _is_ an unused port, and that's exactly the kind of thing that
> might be used sometime in the future. Remember the port 22/23 brouhaha
> with Cyrix using it for their stuff, and later Intel getting into the fray
> too?
>
> So the fact that ED works doesn't mean that _stays_ working.
>
It is, in fact, broken on several systems -- I tried ED in SYSLINUX
for a while, and it broke things for people.
-hpa
--
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <amsp@zytor.com>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On 14 Mar 2002, H. Peter Anvin wrote:
> Date: 14 Mar 2002 13:57:40 -0800
> From: H. Peter Anvin <hpa@zytor.com>
> To: linux-kernel@vger.kernel.org
> Subject: Re: IO delay, port 0x80, and BIOS POST codes
>
> Followup to: <Pine.LNX.4.33.0203141318130.9855-100000@penguin.transmeta.com>
> By author: Linus Torvalds <torvalds@transmeta.com>
> In newsgroup: linux.dev.kernel
> >
> > Port ED is fine for a BIOS, which (by definition) knows what the
> > motherboard devices are, and thus knows that ED cannot be used by
> > anything.
> >
> > But it _is_ an unused port, and that's exactly the kind of thing that
> > might be used sometime in the future. Remember the port 22/23 brouhaha
> > with Cyrix using it for their stuff, and later Intel getting into the fray
> > too?
> >
> > So the fact that ED works doesn't mean that _stays_ working.
> >
>
> It is, in fact, broken on several systems -- I tried ED in SYSLINUX
> for a while, and it broke things for people.
It does work on many, in fact, we used on a Crusoe based platform
as well as the other x86s
Let's make it a configurable kernel debug/hacking option else
we have the added burden of chasing down a common address.
Johnh
>
> -hpa
> --
> <hpa@transmeta.com> at work, <hpa@zytor.com> in private!
> "Unix gives you enough rope to shoot yourself in the foot."
> http://www.zytor.com/~hpa/puzzle.txt <amsp@zytor.com>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
-
-----------------------------------------------------------------
John Heil
South Coast Software
Custom systems software for UNIX and IBM MVS mainframes
1-714-774-6952
johnhscs@sc-software.com
http://www.sc-software.com
-----------------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On 14 Mar 2002, H. Peter Anvin wrote:
> Followup to: <Pine.LNX.3.95.1020314164142.382B-100000@chaos.analogic.com>
> By author: "Richard B. Johnson" <root@chaos.analogic.com>
> In newsgroup: linux.dev.kernel
> >
> > Well no, IO doesn't "time-out". The PC/AT/ISA bus is asychronous, it's
> > not clocked. If there's no hardware activity as a result of the write
> > to nowhere, it's just a no-op. The CPU isn't slowed down at all. It's
> > just some bits that got flung out on the bus with no feed-back at all.
> >
>
> An OUT on the x86 architecture is synchronous... the CPU will not
> proceed until the OUT is present on the bus. This is a requirement of
> the SMM architecture, actually.
>
> -hpa
Yeh? Then "how do it know?". It doesn't. I/O instructions are ordered,
however, that's all. There is no bus-interface state machine that exists
except on the addressed device. The CPU driven interface device just
makes sure that the data is valid before the address and I/O-read or
I/O-write are valid after this. The address is decoded by the device
and is used to enable the device. It either puts its data onto the
bus in the case of a read, or gets data off the bus, in the case of
a write. The interface timing is specified and is handled by hardware.
In the meantime the CPU has not waited because there is nothing to
wait for. On a READ, if the device cannot put its data on the bus
fast enough, it puts its finger io IO-chan-ready. This forces the
CPU (through its bus-interface) to wait.
Writes to nowhere are just that, writes to nowhere.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Windows-2000/Professional isn't.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Richard B. Johnson wrote:
>
> Yeh? Then "how do it know?". It doesn't. I/O instructions are ordered,
> however, that's all. There is no bus-interface state machine that exists
> except on the addressed device. The CPU driven interface device just
> makes sure that the data is valid before the address and I/O-read or
> I/O-write are valid after this. The address is decoded by the device
> and is used to enable the device. It either puts its data onto the
> bus in the case of a read, or gets data off the bus, in the case of
> a write. The interface timing is specified and is handled by hardware.
> In the meantime the CPU has not waited because there is nothing to
> wait for. On a READ, if the device cannot put its data on the bus
> fast enough, it puts its finger io IO-chan-ready. This forces the
> CPU (through its bus-interface) to wait.
>
> Writes to nowhere are just that, writes to nowhere.
>
On the ISA bus, yes. The PCI and front side busses will be held in wait
until the transaction is completed.
The exact requirement is a bit more complicated, something along the
lines of "an SMI triggered in response to an OUT will be taken before
the OUT is retired."
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Thu, 14 Mar 2002, H. Peter Anvin wrote:
> Richard B. Johnson wrote:
>
> >
> > Yeh? Then "how do it know?". It doesn't. I/O instructions are ordered,
> > however, that's all. There is no bus-interface state machine that exists
> > except on the addressed device. The CPU driven interface device just
> > makes sure that the data is valid before the address and I/O-read or
> > I/O-write are valid after this. The address is decoded by the device
> > and is used to enable the device. It either puts its data onto the
> > bus in the case of a read, or gets data off the bus, in the case of
> > a write. The interface timing is specified and is handled by hardware.
> > In the meantime the CPU has not waited because there is nothing to
> > wait for. On a READ, if the device cannot put its data on the bus
> > fast enough, it puts its finger io IO-chan-ready. This forces the
> > CPU (through its bus-interface) to wait.
> >
> > Writes to nowhere are just that, writes to nowhere.
> >
>
>
> On the ISA bus, yes. The PCI and front side busses will be held in wait
> until the transaction is completed.
>
> The exact requirement is a bit more complicated, something along the
> lines of "an SMI triggered in response to an OUT will be taken before
> the OUT is retired."
>
Correct! The PCI is very much different, I'm glad, and hopefully nobody
will be using that for deliberate waits.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Windows-2000/Professional isn't.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Thu, 14 Mar 2002, Alan Cox wrote:
> Date: Thu, 14 Mar 2002 22:55:45 +0000 (GMT)
> From: Alan Cox <alan@lxorguk.ukuu.org.uk>
> To: John Heil <kerndev@sc-software.com>
> Cc: H. Peter Anvin <hpa@zytor.com>, linux-kernel@vger.kernel.org
> Subject: Re: IO delay, port 0x80, and BIOS POST codes
>
> > > It is, in fact, broken on several systems -- I tried ED in SYSLINUX
> > > for a while, and it broke things for people.
> >
> > It does work on many, in fact, we used on a Crusoe based platform
> > as well as the other x86s
> >
> > Let's make it a configurable kernel debug/hacking option else
> > we have the added burden of chasing down a common address.
>
> We've got one. Its 0x80. It works everywhere with only marginal non
> problematic side effects
>
Ok, cool but does that mean you agree or disagree with a configurable
override for those of us in the minority?
Johnh
-
-----------------------------------------------------------------
John Heil
South Coast Software
Custom systems software for UNIX and IBM MVS mainframes
1-714-774-6952
johnhscs@sc-software.com
http://www.sc-software.com
-----------------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

> > It is, in fact, broken on several systems -- I tried ED in SYSLINUX
> > for a while, and it broke things for people.
>
> It does work on many, in fact, we used on a Crusoe based platform
> as well as the other x86s
>
> Let's make it a configurable kernel debug/hacking option else
> we have the added burden of chasing down a common address.
We've got one. Its 0x80. It works everywhere with only marginal non
problematic side effects
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

> Yeh? Then "how do it know?". It doesn't. I/O instructions are ordered,
> however, that's all. There is no bus-interface state machine that exists
How about because
o The intel docs say out is synchronizing
o HPA works for an x86 clone manufacturer
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

> Correct! The PCI is very much different, I'm glad, and hopefully nobody
> will be using that for deliberate waits.
On the x86 platform the PCI bridges make PCI out instructions synchronous.
Lots of driver code relies on this and people handling ports to non x86
where the odd bridge doesn't do this have had some real fun.
PCI mmio writes are however (even on the good old x86 platform) async
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/