* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> updated patch attached. (from the MakeItBuild'n'Stuff dept)
the one below is against current upstream. (previous ones were against
x86.git)
Ingo
--->
Subject: x86: fix in/out_p delays
From: Ingo Molnar <[EMAIL PROTECTED]>
On 14-12-07 14:15, Ingo Molnar wrote:
wow, cool fix! (I remember that there were other systems as well that
are affected by port 0x80 muckery - i thought we had removed port 0x80
accesses long ago.)
how about the simpler fix below, as a first-level approach? We can then
remove the _p in/out
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> wow, cool fix! (I remember that there were other systems as well that
> are affected by port 0x80 muckery - i thought we had removed port 0x80
> accesses long ago.)
>
> how about the simpler fix below, as a first-level approach? We can
> then remove
* David P. Reed <[EMAIL PROTECTED]> wrote:
> Replace use of outb to "unused" diagnostic port 0x80 for time delay
> with udelay based time delay on x86_64 architecture machines. Fix for
> bugs 9511 and 6307 in bugzilla, plus bugs reported in
> bugzilla.redhat.com.
>
> Derived from suggestion
Andi Kleen wrote:
"
With the additional call this should be completely out of line now to save
code size. Similar for the in variant.
Sure. Want me to make a new patch with the _p croutines out-of-line?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
"David P. Reed" <[EMAIL PROTECTED]> writes:
>
> i386 family fixes (completely parallel) were not included, considering
> that such machines might involve more risk of problems on legacy machines.
They're needed because lots of people fomr some reason still boot 32bit kernels
on 64bit machines.
>
On 14-12-07 03:59, David P. Reed wrote:
Replace use of outb to "unused" diagnostic port 0x80 for time delay
with udelay based time delay on x86_64 architecture machines. Fix for
bugs 9511 and 6307 in bugzilla, plus bugs reported in
bugzilla.redhat.com.
Derived from suggestion (that didn't
On 14-12-07 03:59, David P. Reed wrote:
Replace use of outb to unused diagnostic port 0x80 for time delay
with udelay based time delay on x86_64 architecture machines. Fix for
bugs 9511 and 6307 in bugzilla, plus bugs reported in
bugzilla.redhat.com.
Derived from suggestion (that didn't
David P. Reed [EMAIL PROTECTED] writes:
i386 family fixes (completely parallel) were not included, considering
that such machines might involve more risk of problems on legacy machines.
They're needed because lots of people fomr some reason still boot 32bit kernels
on 64bit machines.
+#define
Andi Kleen wrote:
With the additional call this should be completely out of line now to save
code size. Similar for the in variant.
Sure. Want me to make a new patch with the _p croutines out-of-line?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
* Ingo Molnar [EMAIL PROTECTED] wrote:
wow, cool fix! (I remember that there were other systems as well that
are affected by port 0x80 muckery - i thought we had removed port 0x80
accesses long ago.)
how about the simpler fix below, as a first-level approach? We can
then remove the _p
* Ingo Molnar [EMAIL PROTECTED] wrote:
updated patch attached. (from the MakeItBuild'n'Stuff dept)
the one below is against current upstream. (previous ones were against
x86.git)
Ingo
---
Subject: x86: fix in/out_p delays
From: Ingo Molnar [EMAIL PROTECTED]
Debugged
* Rene Herman [EMAIL PROTECTED] wrote:
--- a/init/main.c
+++ b/init/main.c
@@ -229,10 +229,9 @@ static int __init obsolete_checksetup(char *line)
}
/*
- * This should be approx 2 Bo*oMips to start (note initial shift), and will
- * still work even if initially too large, it will just
On 14-12-07 14:15, Ingo Molnar wrote:
wow, cool fix! (I remember that there were other systems as well that
are affected by port 0x80 muckery - i thought we had removed port 0x80
accesses long ago.)
how about the simpler fix below, as a first-level approach? We can then
remove the _p in/out
On 14-12-07 15:46, Ingo Molnar wrote:
* Rene Herman [EMAIL PROTECTED] wrote:
/*
- * This should be approx 2 Bo*oMips to start (note initial shift), and will
- * still work even if initially too large, it will just take slightly longer
+ * Initial value roughly corresponds to a 1 GHz CPU
*/
* Rene Herman [EMAIL PROTECTED] wrote:
On 14-12-07 14:15, Ingo Molnar wrote:
wow, cool fix! (I remember that there were other systems as well that are
affected by port 0x80 muckery - i thought we had removed port 0x80
accesses long ago.)
how about the simpler fix below, as a first-level
On 14-12-07 15:23, Ingo Molnar wrote:
* Rene Herman [EMAIL PROTECTED] wrote:
--- a/init/main.c
+++ b/init/main.c
@@ -229,10 +229,9 @@ static int __init obsolete_checksetup(char *line)
}
/*
- * This should be approx 2 Bo*oMips to start (note initial shift), and will
- * still work even if
updated patch attached. (from the MakeItBuild'n'Stuff dept)
the one below is against current upstream. (previous ones were against
x86.git)
the last version is the one below. Pending further discussion and
testing. And David, i nominate your fix as the coolest Linux kernel fix
of 2007
* Rene Herman [EMAIL PROTECTED] wrote:
/*
- * This should be approx 2 Bo*oMips to start (note initial shift), and will
- * still work even if initially too large, it will just take slightly
longer
+ * Initial value roughly corresponds to a 1 GHz CPU
*/
-unsigned long loops_per_jiffy =
David P. Reed wrote:
Replace use of outb to unused diagnostic port 0x80 for time delay
with udelay based time delay on x86_64 architecture machines. Fix for
bugs 9511 and 6307 in bugzilla, plus bugs reported in
bugzilla.redhat.com.
Derived from suggestion (that didn't compile) by Pavel Machek,
* David P. Reed [EMAIL PROTECTED] wrote:
Replace use of outb to unused diagnostic port 0x80 for time delay
with udelay based time delay on x86_64 architecture machines. Fix for
bugs 9511 and 6307 in bugzilla, plus bugs reported in
bugzilla.redhat.com.
Derived from suggestion (that
* Rene Herman [EMAIL PROTECTED] wrote:
And as to testing -- good luck finding a machine that cares at all ;-)
actually, there's a whole lot more testing angle to a change like this
than ancient boxes.
Ingo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
On 14-12-07 15:03, Ingo Molnar wrote:
yep, i have updated the delay to 2 usecs. The latest patch is below, as
queued up in x86.git. (not yet queued up for .24 - it's pending testing
and more feedback, etc.)
Yes, I'd like feedback on the initial value thing:
On 14-12-07 19:02, H. Peter Anvin wrote:
I believe this will suffer from the issue that was raised: this will use
udelay() long before loop calibration (and no, we can't just be
conservative since there is no conservative value we can use.)
Worse, I suspect that at least the PIT, which may
Alan Cox wrote:
i dont think this should matter: old systems that truly _need_ the ISA
delay will be slow enough to not trip up. (nor are they really affected
by these early delays - the delays were more for crappy ISA devices that
get initialized later down, when the delay loop is already
Ingo Molnar wrote:
wow, cool fix! (I remember that there were other systems as well that
are affected by port 0x80 muckery - i thought we had removed port 0x80
accesses long ago.)
how about the simpler fix below, as a first-level approach? We can then
remove the _p in/out sequences after
i dont think this should matter: old systems that truly _need_ the ISA
delay will be slow enough to not trip up. (nor are they really affected
by these early delays - the delays were more for crappy ISA devices that
get initialized later down, when the delay loop is already calibrated)
On Fri 2007-12-14 10:02:57, H. Peter Anvin wrote:
Ingo Molnar wrote:
wow, cool fix! (I remember that there were other systems as well that are
affected by port 0x80 muckery - i thought we had removed port 0x80
accesses long ago.)
how about the simpler fix below, as a first-level approach?
On Fri 2007-12-14 18:36:26, Alan Cox wrote:
i dont think this should matter: old systems that truly _need_ the ISA
delay will be slow enough to not trip up. (nor are they really affected
by these early delays - the delays were more for crappy ISA devices that
get initialized later
Pavel Machek wrote:
On Fri 2007-12-14 10:02:57, H. Peter Anvin wrote:
Ingo Molnar wrote:
wow, cool fix! (I remember that there were other systems as well that are
affected by port 0x80 muckery - i thought we had removed port 0x80
accesses long ago.)
how about the simpler fix below, as a
On Fri, 14 Dec 2007 14:13:46 -0800
H. Peter Anvin [EMAIL PROTECTED] wrote:
Pavel Machek wrote:
On Fri 2007-12-14 10:02:57, H. Peter Anvin wrote:
Ingo Molnar wrote:
wow, cool fix! (I remember that there were other systems as well that are
affected by port 0x80 muckery - i thought we had
Avi Kivity wrote:
kvm will forward a virtual machine's writes to port 0x80 to the real
port. The reason is that the write is much faster than exiting and
emulating it; the difference is measurable when compiling kernels.
Now if the cause is simply writing to port 0x80, then we must stop
David P. Reed wrote:
I believe (though no one seems to have confirming documentation from the
chipset or motherboard vendor) that port 80 is actually functional for
some unknown function on these machines. (They do respond to in
instructions faster than a bus cycle abort does - more
Just a thought for a way to fix the very early timing needed to set up
udelay to work in a way that works on all machines. Perhaps we haven't
exploited the BIOS enough: The PC BIOS since the PC AT (286) has
always had a standard countdown timer way to delay for n microseconds,
which as far
David P. Reed wrote:
Just a thought for a way to fix the very early timing needed to set up
udelay to work in a way that works on all machines. Perhaps we haven't
exploited the BIOS enough: The PC BIOS since the PC AT (286) has
always had a standard countdown timer way to delay for n
* H. Peter Anvin [EMAIL PROTECTED] wrote:
I believe this will suffer from the issue that was raised: this will
use udelay() long before loop calibration (and no, we can't just be
conservative since there is no conservative value we can use.)
Worse, I suspect that at least the PIT, which
On Dec 13, 2007 6:59 PM, David P. Reed <[EMAIL PROTECTED]> wrote:
> Replace use of outb to "unused" diagnostic port 0x80 for time delay
> with udelay based time delay on x86_64 architecture machines. Fix for
> bugs 9511 and 6307 in bugzilla, plus bugs reported in
> bugzilla.redhat.com.
>
>
Replace use of outb to "unused" diagnostic port 0x80 for time delay
with udelay based time delay on x86_64 architecture machines. Fix for
bugs 9511 and 6307 in bugzilla, plus bugs reported in
bugzilla.redhat.com.
Derived from suggestion (that didn't compile) by Pavel Machek, and
tested, also
Replace use of outb to unused diagnostic port 0x80 for time delay
with udelay based time delay on x86_64 architecture machines. Fix for
bugs 9511 and 6307 in bugzilla, plus bugs reported in
bugzilla.redhat.com.
Derived from suggestion (that didn't compile) by Pavel Machek, and
tested, also
On Dec 13, 2007 6:59 PM, David P. Reed [EMAIL PROTECTED] wrote:
Replace use of outb to unused diagnostic port 0x80 for time delay
with udelay based time delay on x86_64 architecture machines. Fix for
bugs 9511 and 6307 in bugzilla, plus bugs reported in
bugzilla.redhat.com.
Derived from
101 - 140 of 140 matches
Mail list logo
