Skip to contentSkip to conversation

Linux Post codes during runtime, possibly OT

DISCUSSION Ian S. Nelson 12 participants 29 messages Jan 25, 2001 – Jan 30, 2001

lore
Share & tools
lore

Ian S. Nelson

author
#0 lore raw

I'm curious. Why does Linux make that friendly 98/9a/88 looking postcode pattern when it's running? DOS and DOS95 don't do that.

I'm begining to feel like I can tell the system health by observing it, kind of like "seeing the matrix."

Ian

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

#1 lore raw
Followup to:  <[email protected]>
By author:    "Ian S. Nelson" <[email protected]>
In newsgroup: linux.dev.kernel
Quoted 7 lines

I'm curious. Why does Linux make that friendly 98/9a/88 looking postcode pattern when it's running? DOS and DOS95 don't do that.

I'm begining to feel like I can tell the system health by observing it, kind of like "seeing the matrix."

It output garbage to the 80h port in order to enforce I/O delays. It's one of the safe ports to issue outs to.

-hpa

Signature · 7 lines
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
#2 lore raw
Quoted 4 lines · H. Peter Anvin
Followup to:  <[email protected]>
By author:    "Ian S. Nelson" <[email protected]>
In newsgroup: linux.dev.kernel
Quoted 1 line
Quoted 8 lines
Quoted 5 lines

I'm curious. Why does Linux make that friendly 98/9a/88 looking postcode pattern when it's running? DOS and DOS95 don't do that.

I'm begining to feel like I can tell the system health by observing it, kind of like "seeing the matrix."

It output garbage to the 80h port in order to enforce I/O delays. It's one of the safe ports to issue outs to.

Yes, because it is reserved for POST codes. You can get "POST debugging cards" that simply have a BIN -> 7segement encoder and two 7 segment displays on them. They decode 0x80. That's what it's for.

Roger.

Signature · 8 lines
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
#3 lore raw
Quoted 12 lines · Rogier Wolff
Quoted 9 lines · H. Peter Anvin
Followup to:  <[email protected]>
By author:    "Ian S. Nelson" <[email protected]>
In newsgroup: linux.dev.kernel
Quoted 6 lines

I'm curious. Why does Linux make that friendly 98/9a/88 looking postcode pattern when it's running? DOS and DOS95 don't do that.

I'm begining to feel like I can tell the system health by observing it, kind of like "seeing the matrix."

Quoted 7 lines
Quoted 2 lines

It output garbage to the 80h port in order to enforce I/O delays. It's one of the safe ports to issue outs to.

Yes, because it is reserved for POST codes. You can get "POST debugging cards" that simply have a BIN -> 7segement encoder and two 7 segment displays on them. They decode 0x80. That's what it's for.

Again, if you want to change it, find another safe port, test the hell out of it, an *PUBLICIZE IT* so noone will use it in the future.

-hpa

Signature · 7 lines
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
#4 lore raw
Quoted 11 lines · H. Peter Anvin
Quoted 7 lines · Rogier Wolff
Quoted 2 lines · H. Peter Anvin

It output garbage to the 80h port in order to enforce I/O delays. It's one of the safe ports to issue outs to.

Yes, because it is reserved for POST codes. You can get "POST debugging cards" that simply have a BIN -> 7segement encoder and two 7 segment displays on them. They decode 0x80. That's what it's for.

Again, if you want to change it, find another safe port, test the hell out of it, an *PUBLICIZE IT* so noone will use it in the future.

I may have missed too much of the discussion, but I thought that the idea was that some people noted that their POST-code-cards don't really work all that well when Linux is running because Linux keeps on sending garbage to port 0x80.

You seem to state that if you want POST codes, you should find a different port, modify the code, test the hell out of it, and then submit the patch.

That is NOT the right way to go about this: Port 0x80 is RESERVED for POST usage, that's why it's always free. If people want to use it for the original purpose then that is a pretty damn good reason to bump the non-intended users of that port somewhere else.

Now, we've found that small delays are reasonably well generated with an "outb" to 0x80. So, indeed changing that to something else is going to be tricky.

All that I can think of right now is:
- Find a register that can be written without side effects in "standard" hardware like a keyboard controller, or interrupt controller. Especially good are ones that already require us to keep a shadow value. Write the shadow variable to the register. (Tricky: not interrupt safe!)
- Find a scratch register (like the one in the 16450).

- Is port 0x81 possibly "quite often" free?

Roger.

Signature · 8 lines
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
#5 lore raw
Quoted 10 lines · Rogier Wolff

You seem to state that if you want POST codes, you should find a different port, modify the code, test the hell out of it, and then submit the patch.

That is NOT the right way to go about this: Port 0x80 is RESERVED for POST usage, that's why it's always free. If people want to use it for the original purpose then that is a pretty damn good reason to bump the non-intended users of that port somewhere else.

Again, such bumping entails:

- Modify the code
- Test the hell out of it
- Submit the patch

Quoted 12 lines

Now, we've found that small delays are reasonably well generated with an "outb" to 0x80. So, indeed changing that to something else is going to be tricky.

All that I can think of right now is:
- Find a register that can be written without side effects in "standard" hardware like a keyboard controller, or interrupt controller. Especially good are ones that already require us to keep a shadow value. Write the shadow variable to the register. (Tricky: not interrupt safe!)
- Find a scratch register (like the one in the 16450).

Quoted 2 lines

- Is port 0x81 possibly "quite often" free?

Who knows? That's the thing you're going to have to find out if you want to push this. Again, the only way anyone is ever going to find out is by doing *lots* of research (look at things like Ralf Brown's Interrupt List), *then* followed by lots and lots of testing to smoke out boxes that don't work for this.

For what it's worth, I'm talking from experience -- I tried to switch it to port 0xED which I was told was used for this purpose by BIOS manufacturers. It didn't work.

-hpa

Signature · 7 lines
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
#6 lore raw
Quoted 18 lines · H. Peter Anvin
Quoted 10 lines

All that I can think of right now is:
- Find a register that can be written without side effects in "standard" hardware like a keyboard controller, or interrupt controller. Especially good are ones that already require us to keep a shadow value. Write the shadow variable to the register. (Tricky: not interrupt safe!)
- Find a scratch register (like the one in the 16450).

- Is port 0x81 possibly "quite often" free?

Who knows? That's the thing you're going to have to find out if you want to push this. Again, the only way anyone is ever going to find out is by doing *lots* of research (look at things like Ralf Brown's Interrupt List), *then* followed by lots and lots of testing to smoke out boxes that don't work for this.

Quoted 5 lines

Again, such bumping entails:

- Modify the code
- Test the hell out of it
- Submit the patch

Ok. I've thought about it some more, but I don't care enough about this issue to do the painstaking legwork: I don't have one of those POST-code indicators on port 0x80.

I've made the "pause" in outb_p just a few (*) ns slower, because it now loads a variable before outputting the value to port 0x80. As the whole idea about this is "pausing", making it a bit slower shouldn't matter too much. I've tested it: It compiles, it boots.

I'm not too familar with the syntax of the "asm" statement. So I may illegally be modifying the AX register. I don't care enough about this to figure it out right now.

I expect the post_val not to do anything useful at the moment. That is trivial to add, and not my problem. You can put the load in there while the system runs. And/or output one byte of data when the system Ooopses. And/or put values there during the boot process. This will allow you for instance to see wether the system crashes because you compiled it for the wrong processor.

Below is the patch. Feel free to test. Someone please jump in and try to motivate more people to test and submit to Linus once convinced it always works.

Roger.

(*) About 100 when the value is not in the cache.

-------------------------------------------------------------------------

arch/i386/boot/compressed/misc.c +2 -0
diff -ur linux-2.4.0.clean/arch/i386/boot/compressed/misc.c linux-2.4.0.post/arch/i386/boot/compressed/misc.c
@@ -113,6 +113,8 @@
 static int vidport;
 static int lines, cols;
 
+int post_val;
+
 #include "../../../../lib/inflate.c"
 
 static void *malloc(int size)
include/asm-i386/io.h +3 -1
diff -ur linux-2.4.0.clean/include/asm-i386/io.h linux-2.4.0.post/include/asm-i386/io.h
@@ -37,7 +37,7 @@
 #ifdef SLOW_IO_BY_JUMPING
 #define __SLOW_DOWN_IO "\njmp 1f\n1:\tjmp 1f\n1:"
 #else
-#define __SLOW_DOWN_IO "\noutb %%al,$0x80"
+#define __SLOW_DOWN_IO "\nmovb post_val,%%al\noutb %%al,$0x80"
 #endif
 
 #ifdef REALLY_SLOW_IO

@@ -45,6 +45,8 @@
 #else
 #define __FULL_SLOW_DOWN_IO __SLOW_DOWN_IO
 #endif
+
+extern int post_val; 
 
 /*
  * Talk about misusing macros..
init/main.c +2 -0
diff -ur linux-2.4.0.clean/init/main.c linux-2.4.0.post/init/main.c
@@ -130,6 +130,8 @@
 char *execute_command;
 char root_device_name[64];
 
+int post_val;
+
 
 static char * argv_init[MAX_INIT_ARGS+2] = { "init", NULL, };
 static char * envp_init[MAX_INIT_ENVS+2] = { "HOME=/", "TERM=linux", NULL, };
Signature · 8 lines
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
#7 lore raw
Quoted 5 lines · Rogier Wolff

Ok. I've thought about it some more, but I don't care enough about this issue to do the painstaking legwork: I don't have one of those POST-code indicators on port 0x80.

Quoted 9 lines

I've made the "pause" in outb_p just a few (*) ns slower, because it now loads a variable before outputting the value to port 0x80. As the whole idea about this is "pausing", making it a bit slower shouldn't matter too much. I've tested it: It compiles, it boots.

I'm not too familar with the syntax of the "asm" statement. So I may illegally be modifying the AX register. I don't care enough about this to figure it out right now.

It is; you'd have to specify "eax" as a clobber value, and that is undesirable.

And you're still overwriting the POST value written by the BIOS.

-hpa

Signature · 7 lines
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
#8 lore raw
Quoted 11 lines · H. Peter Anvin
Quoted 10 lines · Rogier Wolff

Ok. I've thought about it some more, but I don't care enough about this issue to do the painstaking legwork: I don't have one of those POST-code indicators on port 0x80.

I've made the "pause" in outb_p just a few (*) ns slower, because it now loads a variable before outputting the value to port 0x80. As the whole idea about this is "pausing", making it a bit slower shouldn't matter too much. I've tested it: It compiles, it boots.

Quoted 7 lines
Quoted 4 lines

I'm not too familar with the syntax of the "asm" statement. So I may illegally be modifying the AX register. I don't care enough about this to figure it out right now.

It is; you'd have to specify "eax" as a clobber value, and that is undesirable.

OK. Then someone needs to do the legwork, and add that.

The "_P" version is intended to be inefficient "because the device can't handle us pushing the limit". Thus a little more because of an eax reload is unfortunate, but not the end of the world.

Everybody knows (I hope) that outb_p is not intended as an efficient way to output a byte. So, when possible everybody should be avoiding it already.

Quoted 1 line

And you're still overwriting the POST value written by the BIOS.

Yes, but by the time Linux boots, we should just start putting OUR values there. If the BIOS goes up to 0x8f, then Linux could start at 0x90 and continue there. I don't have one of those thingies, so I don't know what the last value would be that the BIOS leaves there.

Roger.

Signature · 8 lines
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
#9 lore raw
In reply to Rogier Wolff
Quoted 2 lines · H. Peter Anvin

It is; you'd have to specify "eax" as a clobber value, and that is undesirable.

For outb_p, EAX is used, usually for the last time, in the preceding "out" instruction so clobbering it is not a big deal.

For inb_p, you first have to copy EAX to another register before outputting the post_byte. That's a small penalty. Are in[bwl]_p used anywhere time critical? (Richard Johnson's explanation for outb_p implies that inb_p is not required, but perhaps that explanation doesn't tell the whole story).

Quoted 1 line

And you're still overwriting the POST value written by the BIOS.

Can the BIOS-written value be read from port 0x80?

-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

#10 lore raw
In reply to Rogier Wolff

Hi!

Quoted 14 lines
Quoted 4 lines

Ok. I've thought about it some more, but I don't care enough about this issue to do the painstaking legwork: I don't have one of those POST-code indicators on port 0x80.

Quoted 9 lines

I've made the "pause" in outb_p just a few (*) ns slower, because it now loads a variable before outputting the value to port 0x80. As the whole idea about this is "pausing", making it a bit slower shouldn't matter too much. I've tested it: It compiles, it boots.

I'm not too familar with the syntax of the "asm" statement. So I may illegally be modifying the AX register. I don't care enough about this to figure it out right now.

Quoted 4 lines

It is; you'd have to specify "eax" as a clobber value, and that is undesirable.

And you're still overwriting the POST value written by the BIOS.

So save value from bios at initial boot ;-).
Pavel

Signature · 6 lines
I'm [email protected]. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [email protected]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
#11 lore raw
Quoted 16 lines · Pavel Machek

Hi!

Quoted 14 lines
Quoted 13 lines

Ok. I've thought about it some more, but I don't care enough about this issue to do the painstaking legwork: I don't have one of those POST-code indicators on port 0x80.

I've made the "pause" in outb_p just a few (*) ns slower, because it now loads a variable before outputting the value to port 0x80. As the whole idea about this is "pausing", making it a bit slower shouldn't matter too much. I've tested it: It compiles, it boots.

I'm not too familar with the syntax of the "asm" statement. So I may illegally be modifying the AX register. I don't care enough about this to figure it out right now.

Quoted 8 lines
Quoted 4 lines

It is; you'd have to specify "eax" as a clobber value, and that is undesirable.

And you're still overwriting the POST value written by the BIOS.

So save value from bios at initial boot ;-).
Pavel

This is getting all too "strange". Somebody stated that they didn't want the MFG port being overwritten so I posted a patch that would use another port.

Instead of testing their machines with the patch, I get tons of messages like this! I even explained what the purpose of the delay was, just in case somebody really wanted to know. I suggest that those who want their POST codes untouched test the patch, those who don't care, ignore it. Those who are interested in backwards compatibility should try the patch, those who are not interested should ignore it also.

The all too often linux-kernel idea; "It doesn't have to be better, only different..." is getting a bit stale. There are not any extra hardware ports just laying around. The DMA scratch register, which I proposed as an alternate to the MFG port, does not affect DMA operations in any way. It's just one of the few read/write registers available.

Pavel's idea of "saving" the value in the MFG port ignores the fact that there is no specification making it readable. A board manufacturer can save a few gates in his ASIC and leave it write-only. Further, saving eax, reading the port, writing the port, then restoring eax is at least twice the delay required.

If you insist upon using the MFG port (port 0x80), just read it.

	pushl	%eax
	inb	$0x80,al
	popl	%eax

Reads and writes take the same time. The extra overhead is the save/restore of register EAX. FYI, I would not trust gcc with a "clobber" value of EAX. Many versions assume that EAX is usable all the while (like in a called procedure). Just do the push/pop yourself.

If you decide to do this, you also have to take care of the code in floppy.h as well as io.h.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.0 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

#12 lore raw
In reply to Rogier Wolff
Quoted 5 lines · Pavel Machek
Quoted 2 lines
Quoted 1 line

And you're still overwriting the POST value written by the BIOS.

So save value from bios at initial boot ;-).
Pavel

Write-only register.

-hpa

Signature · 7 lines
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
#13 lore raw
In reply to Rogier Wolff

On Sat, 27 Jan 2001, Rogier Wolff wrote:
[snip]

Quoted 9 lines

I may have missed too much of the discussion, but I thought that the idea was that some people noted that their POST-code-cards don't really work all that well when Linux is running because Linux keeps on sending garbage to port 0x80.

You seem to state that if you want POST codes, you should find a different port, modify the code, test the hell out of it, and then submit the patch.

Quoted 8 lines

That is NOT the right way to go about this: Port 0x80 is RESERVED for POST usage, that's why it's always free. If people want to use it for the original purpose then that is a pretty damn good reason to bump the non-intended users of that port somewhere else.

Now, we've found that small delays are reasonably well generated with an "outb" to 0x80. So, indeed changing that to something else is going to be tricky.

So how bad would it be to give these people a place to leave the value that they want to have displayed, and have the delay code write *that* instead of garbage?

Signature · 7 lines
Mark H. Wood, Lead System Programmer   [email protected]
Make a good day.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
#14 lore raw
Quoted 16 lines · Mark H. Wood

On Sat, 27 Jan 2001, Rogier Wolff wrote:
[snip]

Quoted 14 lines

I may have missed too much of the discussion, but I thought that the idea was that some people noted that their POST-code-cards don't really work all that well when Linux is running because Linux keeps on sending garbage to port 0x80.

You seem to state that if you want POST codes, you should find a different port, modify the code, test the hell out of it, and then submit the patch.

That is NOT the right way to go about this: Port 0x80 is RESERVED for POST usage, that's why it's always free. If people want to use it for the original purpose then that is a pretty damn good reason to bump the non-intended users of that port somewhere else.

Quoted 8 lines
Quoted 3 lines

Now, we've found that small delays are reasonably well generated with an "outb" to 0x80. So, indeed changing that to something else is going to be tricky.

So how bad would it be to give these people a place to leave the value that they want to have displayed, and have the delay code write *that* instead of garbage?

You need to save eax on the stack, you need to load al from memory, you need to write al to the port, then you need to restore eax from the stack, i.e.,

	pushl	%eax
	movb	(where_they_put_it),%al
	outb	%al,$0x80
	popl	%eax

This looks trivial. However, what happens if the kernel data segment hasn't been set (yet), etc. To make this 'universal' you have to make sure that "where_they_put_it" is accessible from the current segment. Therefore, you have to do:

	pushl	%ds
	pushl	%eax
	movl	$KERNEL_DS,%eax
	movl	%eax,%ds
	movb	(where_they_put_it),%al
	outb	%al,$0x80
	popl	%eax
	popl	%ds

This gets a bit long for something that is, now, only:

	outb	%al,$0x80

I proposed a simple change, just do:

	outb	%al,$0x19

... instead.

That port is a R/W DMA scratch register. It's an 8-bit R/W latch that is not internally connected to any DMA operations. It was initially designed as a place to store page-register information because the PC/XT/AT DMA controller is a 16-bit part. Since the page register value must be computed for every DMA operation, it is/was never used.

Simple decisions that used to be handled as; "Yeh, lets try it..." now seem to be gobble-de-gooked with proving everything to the world.

Just try it. You'll like it.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.0 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

#15 lore raw
In reply to Mark H. Wood

[...]

Quoted 8 lines
Quoted 4 lines

Now, we've found that small delays are reasonably well generated with an "outb" to 0x80. So, indeed changing that to something else is going to be tricky.

So how bad would it be to give these people a place to leave the value that they want to have displayed, and have the delay code write *that* instead of garbage?

Because Port &h80 is _not_ decoded by the standard PC hardware. There are some ISA and nowadays even PCI cards that convert the value OUTted to that port into two 7-segment-digit-LCDisplays, buffered so you can read it from the card, but normally no chipset actually cares about that port. (I speak of Desktop PCs.)

I repeat: Any OUT to port &h80 is, as long as there are no special extensions, just as well as any OUT to port &h1234 or &h4711 or whateveryouwant as long as nothing uses it.
Since Port &h80 is now "reserved" for that POST code usage, and it is the safest port one can use in order to delay, Linux uses it.
If you don't want this, change it in your kernel or define SLOW_BY_JUMPING.

-mirabilos

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

#16 lore raw
Quoted 16 lines · mirabilos

[...]

Quoted 8 lines
Quoted 4 lines

Now, we've found that small delays are reasonably well generated with an "outb" to 0x80. So, indeed changing that to something else is going to be tricky.

So how bad would it be to give these people a place to leave the value that they want to have displayed, and have the delay code write *that* instead of garbage?

Because Port &h80 is _not_ decoded by the standard PC hardware. There are some ISA and nowadays even PCI cards that convert the value OUTted to that port into two 7-segment-digit-LCDisplays, buffered so you can read it from the card, but normally no chipset actually cares about that port. (I speak of Desktop PCs.)

Quoted 6 lines

I repeat: Any OUT to port &h80 is, as long as there are no special extensions, just as well as any OUT to port &h1234 or &h4711 or whateveryouwant as long as nothing uses it.
Since Port &h80 is now "reserved" for that POST code usage, and it is the safest port one can use in order to delay, Linux uses it.

This is not correct. Port 0x80 is not an "unused" port. It is decoded by standard hardware:

C:\>debug

-i 80
AE
-o 80 20
-i 80
20
-q


In this machine I do not have a 'POST-codes' board. Port 0x80 is an 8-bit read/write latch. It always has been.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.0 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

#17 lore raw

----- Original Message -----
From: "Richard B. Johnson" <[email protected]>
To: "mirabilos" <[email protected]>
Cc: "Linux-Kernel ML" <[email protected]>; "Mark H. Wood" <[email protected]>
Sent: Tuesday, January 30, 2001 6:36 PM
Subject: Re: Linux Post codes during runtime, possibly OT

Quoted 38 lines · mirabilos
Quoted 17 lines

[...]

Quoted 8 lines
Quoted 4 lines

Now, we've found that small delays are reasonably well generated with an "outb" to 0x80. So, indeed changing that to something else is going to be tricky.

So how bad would it be to give these people a place to leave the value that they want to have displayed, and have the delay code write *that* instead of garbage?

Because Port &h80 is _not_ decoded by the standard PC hardware. There are some ISA and nowadays even PCI cards that convert the value OUTted to that port into two 7-segment-digit-LCDisplays, buffered so you can read it from the card, but normally no chipset actually cares about that port. (I speak of Desktop PCs.)

Quoted 6 lines

I repeat: Any OUT to port &h80 is, as long as there are no special extensions, just as well as any OUT to port &h1234 or &h4711 or whateveryouwant as long as nothing uses it.
Since Port &h80 is now "reserved" for that POST code usage, and it is the safest port one can use in order to delay, Linux uses it.

This is not correct. Port 0x80 is not an "unused" port. It is decoded by standard hardware:

C:\>debug

-i 80
AE

(quoted diff) +0 -2
-o 80 20
-i 80

20
-q


Quoted 6 lines

In this machine I do not have a 'POST-codes' board. Port 0x80 is an 8-bit read/write latch. It always has been.

Cheers,
Dick Johnson

OK, I'll check it against every box I've got here. I just was citing what I've learned "ages" ago.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

#18 lore raw
In reply to H. Peter Anvin

Hi!

Quoted 28 lines
Quoted 9 lines
Quoted 6 lines
Quoted 2 lines

It output garbage to the 80h port in order to enforce I/O delays. It's one of the safe ports to issue outs to.

Yes, because it is reserved for POST codes. You can get "POST debugging cards" that simply have a BIN -> 7segement encoder and two 7 segment displays on them. They decode 0x80. That's what it's for.

Again, if you want to change it, find another safe port, test the hell out of it, an *PUBLICIZE IT* so noone will use it in the future.

I may have missed too much of the discussion, but I thought that the idea was that some people noted that their POST-code-cards don't really work all that well when Linux is running because Linux keeps on sending garbage to port 0x80.

You seem to state that if you want POST codes, you should find a different port, modify the code, test the hell out of it, and then submit the patch.

That is NOT the right way to go about this: Port 0x80 is RESERVED for POST usage, that's why it's always free. If people want to use it for the original purpose then that is a pretty damn good reason to bump the non-intended users of that port somewhere else.

Now, we've found that small delays are reasonably well generated with an "outb" to 0x80. So, indeed changing that to something else is going to be tricky.

Quoted 6 lines

All that I can think of right now is:
- Find a register that can be written without side effects in "standard" hardware like a keyboard controller, or interrupt controller. Especially good are ones that already require us to keep a shadow value. Write the shadow variable to the register. (Tricky: not interrupt safe!)

What about just remembering shadow of 0x80 and always writing shadow to 0x80? Interrupt unsafety hopefully does not matter much....
Pavel

Signature · 6 lines
I'm [email protected]. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [email protected]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
#19 lore raw
In reply to Ian S. Nelson

It occurs to me that it might be a good idea to pick a different port for these things. I know a lot of people who want to use port 80h for debugging data, especially in embedded x86 systems.

Matt

Quoted 23 lines · H. Peter Anvin
Followup to:  <[email protected]>
By author:    "Ian S. Nelson" <[email protected]>
In newsgroup: linux.dev.kernel
Quoted 7 lines

I'm curious. Why does Linux make that friendly 98/9a/88 looking postcode pattern when it's running? DOS and DOS95 don't do that.

I'm begining to feel like I can tell the system health by observing it, kind of like "seeing the matrix."

It output garbage to the 80h port in order to enforce I/O delays. It's one of the safe ports to issue outs to.

-hpa

Signature · 7 lines
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Signature · 6 lines
Matthew Dharm                              Home: [email protected] 
Maintainer, Linux USB Mass Storage Driver

I say, what are all those naked people doing?
					-- Big client to Stef
User Friendly, 12/14/1997
#20 lore raw
In reply to Ian S. Nelson
Quoted 5 lines · Matthew Dharm

It occurs to me that it might be a good idea to pick a different port for these things. I know a lot of people who want to use port 80h for debugging data, especially in embedded x86 systems.

Find a safe port, make sure it is tested the hell out of, and we'll consider it.

-hpa

Signature · 7 lines
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
#21 lore raw
Quoted 7 lines · H. Peter Anvin
Quoted 5 lines · Matthew Dharm

It occurs to me that it might be a good idea to pick a different port for these things. I know a lot of people who want to use port 80h for debugging data, especially in embedded x86 systems.

Quoted 5 lines

Find a safe port, make sure it is tested the hell out of, and we'll consider it.

-hpa

You could use the DMA scratch register at 0x19. I'm sure Linux doesn't "save" stuff there when setting up the DMA controller.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.0 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

#22 lore raw
Quoted 10 lines · Richard B. Johnson
Quoted 7 lines · H. Peter Anvin
Quoted 5 lines · Matthew Dharm

It occurs to me that it might be a good idea to pick a different port for these things. I know a lot of people who want to use port 80h for debugging data, especially in embedded x86 systems.

Quoted 9 lines
Quoted 5 lines

Find a safe port, make sure it is tested the hell out of, and we'll consider it.

-hpa

You could use the DMA scratch register at 0x19. I'm sure Linux doesn't "save" stuff there when setting up the DMA controller.

Does that break the BIOS in any way, shape, or form? Again, someone gets to make a patch and then test the hell out of it... and find the random Olivetti which hooks the screen up to the A20M# signal and other weird crap.

-hpa

Signature · 7 lines
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
#23 lore raw
Quoted 21 lines · H. Peter Anvin
Quoted 10 lines · Richard B. Johnson
Quoted 7 lines · H. Peter Anvin
Quoted 5 lines · Matthew Dharm

It occurs to me that it might be a good idea to pick a different port for these things. I know a lot of people who want to use port 80h for debugging data, especially in embedded x86 systems.

Quoted 9 lines
Quoted 5 lines

Find a safe port, make sure it is tested the hell out of, and we'll consider it.

-hpa

You could use the DMA scratch register at 0x19. I'm sure Linux doesn't "save" stuff there when setting up the DMA controller.

Quoted 7 lines

Does that break the BIOS in any way, shape, or form? Again, someone gets to make a patch and then test the hell out of it... and find the random Olivetti which hooks the screen up to the A20M# signal and other weird crap.

-hpa

I will change the port on my machines and run them for a week. I don't have any DEC Rainbows or other such. Yes, I know Linux will not run on a '286.

Since 0x19 is a hardware register in a DMA controller, specifically called a "scratch" register, it is unlikely to hurt anything. Note that the BIOS saves stuff in CMOS. It never expects hardware registers to survive a "warm boot". It even checks in CMOS to see if it should preserve RAM.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.0 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

#24 lore raw
Quoted 11 lines · Richard B. Johnson

I will change the port on my machines and run them for a week. I don't have any DEC Rainbows or other such. Yes, I know Linux will not run on a '286.

Since 0x19 is a hardware register in a DMA controller, specifically called a "scratch" register, it is unlikely to hurt anything. Note that the BIOS saves stuff in CMOS. It never expects hardware registers to survive a "warm boot". It even checks in CMOS to see if it should preserve RAM.

Actually, what you need to do is change it and then try it on something like 300 different systems. Since noone has direct access to that kind of system, you have to get people to help you out trying it.

A better idea might be to find out what port, if any, Windows uses. If Windows does it, it is usually safe.

-hpa

Signature · 7 lines
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
#25 lore raw
In reply to Richard B. Johnson
Quoted 4 lines · H. Peter Anvin

A better idea might be to find out what port, if any, Windows uses. If Windows does it, it is usually safe.

Windows NT 4 Service Pack 6 doesn't use any delay however READ/WRITE_PORT_* are implemented as indirect function calls so they may be slowed down enough.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

#26 lore raw
In reply to Richard B. Johnson
Quoted 6 lines

Actually, what you need to do is change it and then try it on something like 300 different systems. Since noone has direct access to that kind of system, you have to get people to help you out trying it.

A better idea might be to find out what port, if any, Windows uses. If Windows does it, it is usually safe.

In the FWIW category, the collection of DOS packet drivers from Russ Nelson (and the many commercial ones based on them) use a read of the NMI status port to create a similar delay. This code got used on lots of hardware (although probably not much on current hw - mostly 386/486 type vintage stuff I'd guess...)

I'm not advocating we move off 0x80 either - but people wanting to use POST cards have at least a couple of options. And if they have a POST card, it is probably a safe bet that they can manage to apply one of the patches and rebuild the kernel.

Paul.

[Booted old 486-66 with 8390 based card (uses inb_p/outb_p) & works fine]

asm-i386/io.h renamed from asm-i386/io.h~ +9 -0
@@ -23,6 +23,11 @@
  * I feel a bit unsafe about using 0x80 (should be safe, though)
  *
  *		Linus
+ *
+ * Some people get upset since they can't use their POST cards
+ * for diagnostics once linux boots and hammers 0x80 with garbage.
+ * DOS packet drivers do a dummy read of the NMI status port to
+ * obtain a similar delay.			Paul G.
  */
 
  /*

@@ -32,7 +37,11 @@
 #ifdef SLOW_IO_BY_JUMPING
 #define __SLOW_DOWN_IO "\njmp 1f\n1:\tjmp 1f\n1:"
 #else
+#ifdef HAVE_POST_CARD
+#define __SLOW_DOWN_IO "\n\tpushl %%eax\n\tinb $0x61,%%al\n\tpopl %%eax"
+#else
 #define __SLOW_DOWN_IO "\noutb %%al,$0x80"
+#endif
 #endif
 
 #ifdef REALLY_SLOW_IO

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

#27 lore raw
In reply to Ian S. Nelson

Isn't that always the way in the Open Source world? :)

Seriously, tho... does anyone have some list of who is using what ports? At least, in general?

Matt

Quoted 16 lines · H. Peter Anvin
Quoted 5 lines · Matthew Dharm

It occurs to me that it might be a good idea to pick a different port for these things. I know a lot of people who want to use port 80h for debugging data, especially in embedded x86 systems.

Find a safe port, make sure it is tested the hell out of, and we'll consider it.

-hpa

Signature · 3 lines
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
Signature · 7 lines
Matthew Dharm                              Home: [email protected] 
Maintainer, Linux USB Mass Storage Driver

P:  How about "Web Designer"?
DP: I'd like a name that people won't laugh at.
					-- Pitr and Dust Puppy
User Friendly, 12/6/1997
#28 lore raw
In reply to Ian S. Nelson
Quoted 6 lines · Matthew Dharm

Isn't that always the way in the Open Source world? :)

Seriously, tho... does anyone have some list of who is using what ports? At least, in general?

There is one included in Ralf Brown's Interrupt List. No list you're going to find is going to be complete, though.

-hpa

Signature · 7 lines
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/