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/

> > 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?
If we put every single requested obscure fix for one or two boxes into
the kernel configuration you'd be spending weeks wading through
"Handle weird APM on Dave's homebrew mediagx"
and other questions.
Let me suggest something else. For any kernel built with TSC assumed
(586TSC +) initialize the udelay loop to something guaranteed to be at
least too long for any conceivable processor and use udelay() for the I/O
delay timing.
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/

On Fri, 15 Mar 2002, David Golden wrote:
> Date: Fri, 15 Mar 2002 00:12:42 +0000
> From: David Golden <david.golden@oceanfree.net>
> To: linux-kernel@vger.kernel.org
> Subject: Re: IO delay, port 0x80, and BIOS POST codes
>
> On Thursday 14 March 2002 22:55, Alan Cox wrote:
> >
> > We've got one. Its 0x80. It works everywhere with only marginal non
> > problematic side effects
>
> I've always liked POST cards. They could hypothetically be useful
> for kernel development,too - who hasn't wanted a low-level
> single-asm-instruction status output from a running system at one time or
> another , independent of any other output mechanisms?
>
> OK it's a single byte, but it's still nice... That's two whole hex digits!
> DE... AD... BE... EF... !
Any number of consecutive bits and a target I/O address can be very
useful.
I do it regularly for embedded kernel hacking... harmless I/O, picked up
by your logic analyzer.
Only drawback is it adds pathlength which can impact realtime if you get
excessive.
Johnh
> -
> 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 Thursday 14 March 2002 22:55, Alan Cox wrote:
>
> We've got one. Its 0x80. It works everywhere with only marginal non
> problematic side effects
I've always liked POST cards. They could hypothetically be useful
for kernel development,too - who hasn't wanted a low-level
single-asm-instruction status output from a running system at one time or
another , independent of any other output mechanisms?
OK it's a single byte, but it's still nice... That's two whole hex digits!
DE... AD... BE... EF... !
-
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/

Linus Torvalds <torvalds@transmeta.com> writes:
> 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),
Does the logic outb_p uses continue to work if you have a PCI post
card (possibly on the motherboard). And an ISA device?
Systems without ISA slots but with ISA or LPC devices onboard must
use a PCI post card so I have trouble believing that outb_b and friends
really work as expected....
Eric
-
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, Thunder from the hill wrote:
> 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.
It doesn't even have to be a config option - a line
/* Port used for dummy writes for I/O delays */
/* Change this only if you know what you're doing ! */
#define DUMMY_IO_PORT 0x80
in a header file would perfectly suffice.
Martin
--
Martin Wilck Phone: +49 5251 8 15113
Fujitsu Siemens Computers Fax: +49 5251 8 20409
Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com
D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
-
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/

Martin Wilck <Martin.Wilck@fujitsu-siemens.com> writes:
> On Thu, 14 Mar 2002, Thunder from the hill wrote:
>
> > 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.
>
> It doesn't even have to be a config option - a line
>
> /* Port used for dummy writes for I/O delays */
> /* Change this only if you know what you're doing ! */
> #define DUMMY_IO_PORT 0x80
>
> in a header file would perfectly suffice.
That effectively already exists. You just need to change the __SLOW_DOWN_IO
macro in include/asm-i387/io.h
-Andi
-
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 15 Mar 2002, Andi Kleen wrote:
> > It doesn't even have to be a config option - a line
> >
> > /* Port used for dummy writes for I/O delays */
> > /* Change this only if you know what you're doing ! */
> > #define DUMMY_IO_PORT 0x80
> >
> > in a header file would perfectly suffice.
>
> That effectively already exists. You just need to change the __SLOW_DOWN_IO
> macro in include/asm-i387/io.h
No, that doesn't cover all accesses to port 80. I am still searching.
--
Martin Wilck Phone: +49 5251 8 15113
Fujitsu Siemens Computers Fax: +49 5251 8 20409
Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com
D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
-
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 Fri, Mar 15, 2002 at 01:47:39PM +0100, Martin Wilck wrote:
> On 15 Mar 2002, Andi Kleen wrote:
>
> > > It doesn't even have to be a config option - a line
> > >
> > > /* Port used for dummy writes for I/O delays */
> > > /* Change this only if you know what you're doing ! */
> > > #define DUMMY_IO_PORT 0x80
> > >
> > > in a header file would perfectly suffice.
> >
> > That effectively already exists. You just need to change the __SLOW_DOWN_IO
> > macro in include/asm-i387/io.h
>
> No, that doesn't cover all accesses to port 80. I am still searching.
It should. I would consider all other accesses a bug.
It is possible that some driver used it for private debugging and left it in by
mistake. These should be removed.
-Andi
-
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/

Martin Wilck wrote:
> Thunder from the hill wrote:
> > Maybe add a config option?
> It doesn't even have to be a config option - a line
> in a header file would perfectly suffice.
So guys who don't have an idea of it won't find it. Good idea!
> Martin
Thunder
--
begin-base64 755 -
IyEgL3Vzci9iaW4vcGVybApteSAgICAgJHNheWluZyA9CSMgVGhlIHNjcmlw
dCBvbiB0aGUgbGVmdCBpcyB0aGUgcHJvb2YKIk5lbmEgaXN0IGVpbiIgLgkj
IHRoYXQgaXQgaXNuJ3QgYWxsIHRoZSB3YXkgaXQgc2VlbXMKIiB2ZXJhbHRl
dGVyICIgLgkjIHRvIGJlIChlc3BlY2lhbGx5IG5vdCB3aXRoIG1lKQoiTkRX
LVN0YXIuXG4iICA7CiRzYXlpbmcgPX4Kcy9ORFctU3Rhci9rYW5uXAogdW5z
IHJldHRlbi9nICA7CiRzYXlpbmcgICAgICAgPX4Kcy92ZXJhbHRldGVyL2Rp
XAplIExpZWJlL2c7CiRzYXlpbmcgPX5zL2Vpbi8KbnVyL2c7JHNheWluZyA9
fgpzL2lzdC9zYWd0LC9nICA7CiRzYXlpbmc9fnMvXG4vL2cKO3ByaW50Zigk
c2F5aW5nKQo7cHJpbnRmKCJcbiIpOwo=
====
Extract this and see what will happen if you execute my
signature. Just save it to file and do a
> uudecode $file | perl
-
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/

> If we put every single requested obscure fix for one or two boxes into
> the kernel configuration you'd be spending weeks wading through
>
> "Handle weird APM on Dave's homebrew mediagx"
>
> and other questions.
>
A config option that lets you pick the address for the dummy io would
be a pretty obscure option. But having a CONFIG_POST_SUPPORT buried
somewhere wouldn't be that obscure or confusing. If that config
option is set, then a second question would prompt for an alternate
address to be used for the delay io, and a macro would be defined to
display post codes. If the option is unset, then 0x80 would be the
default for the delay address, and the post code macro would be defined
to do nothing.
Gerald
-
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/

Hi!
> > We've got one. Its 0x80. It works everywhere with only marginal non
> > problematic side effects
>
> I've always liked POST cards. They could hypothetically be useful
> for kernel development,too - who hasn't wanted a low-level
> single-asm-instruction status output from a running system at one time or
> another , independent of any other output mechanisms?
>
> OK it's a single byte, but it's still nice... That's two whole hex digits!
> DE... AD... BE... EF... !
Use 0x378 for that, works equally well.
Pavel
--
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
-
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/