Mailing List Archive

> > 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/