public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@suse.cz>
To: Rogier Wolff <R.E.Wolff@BitWizard.nl>,
	"H. Peter Anvin" <hpa@transmeta.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>, linux-kernel@vger.kernel.org
Subject: Re: Linux Post codes during runtime, possibly OT
Date: Sun, 28 Jan 2001 23:29:43 +0100	[thread overview]
Message-ID: <20010128232943.D1300@bug.ucw.cz> (raw)
In-Reply-To: <3A7333FF.AA813685@transmeta.com> <200101272101.WAA27234@cave.bitwizard.nl>
In-Reply-To: <200101272101.WAA27234@cave.bitwizard.nl>; from Rogier Wolff on Sat, Jan 27, 2001 at 10:01:02PM +0100

Hi!

> > > > 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!)

What about just remembering shadow of 0x80 and always writing shadow
to 0x80? Interrupt unsafety hopefully does not matter much....
								Pavel
-- 
I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

  parent reply	other threads:[~2001-01-29 14:42 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-01-25 21:46 Linux Post codes during runtime, possibly OT Ian S. Nelson
2001-01-25 22:26 ` H. Peter Anvin
2001-01-25 22:31   ` Matthew Dharm
2001-01-25 22:32     ` H. Peter Anvin
2001-01-25 22:41       ` Matthew Dharm
2001-01-25 22:45         ` H. Peter Anvin
2001-01-25 23:08       ` Richard B. Johnson
2001-01-25 23:10         ` H. Peter Anvin
2001-01-26 13:58           ` Richard B. Johnson
2001-01-26 16:19             ` H. Peter Anvin
2001-01-26 17:54               ` David Welch
2001-01-29  2:35               ` Paul Gortmaker
2001-01-27 10:20   ` Rogier Wolff
2001-01-27 20:47     ` H. Peter Anvin
2001-01-27 21:01       ` Rogier Wolff
2001-01-27 21:24         ` H. Peter Anvin
2001-01-28 10:12           ` Rogier Wolff
2001-01-28 10:18             ` H. Peter Anvin
2001-01-28 11:03               ` Rogier Wolff
2001-01-28 17:22               ` Jamie Lokier
2001-01-28 22:34               ` Pavel Machek
2001-01-29 15:09                 ` Richard B. Johnson
2001-01-29 19:21                 ` H. Peter Anvin
2001-01-28 22:29         ` Pavel Machek [this message]
2001-01-30 17:44         ` Mark H. Wood
2001-01-30 18:10           ` Richard B. Johnson
2001-01-30 18:16           ` mirabilos
2001-01-30 18:36             ` Richard B. Johnson
2001-01-30 18:41               ` mirabilos
  -- strict thread matches above, loose matches on Subject: below --
2001-01-26 15:41 Petr Vandrovec
2001-01-26 15:07 ` Richard B. Johnson
2001-01-26 15:15   ` Mark Hahn
2001-01-26 15:31     ` Jamie Lokier
2001-01-26 16:03       ` Richard B. Johnson
2001-01-26 16:22         ` Jamie Lokier
2001-01-26 15:42 Manfred Spraul
2001-01-26 16:07 ` Richard B. Johnson
2001-01-26 16:33   ` Brian Gerst
2001-01-27 12:28     ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010128232943.D1300@bug.ucw.cz \
    --to=pavel@suse.cz \
    --cc=R.E.Wolff@BitWizard.nl \
    --cc=hpa@transmeta.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox