On Sun 2007-12-16 15:34:58, H. Peter Anvin wrote:
> Pavel Machek wrote:
>> Hi!
>>> The process of safely making delicate changes here is beyond my
>>> responsibility as just a user - believe me, I'm not suggesting that a
>>> risky fix be put in .24. I can patch my own kernels, and I can even
On Sun 2007-12-16 15:34:58, H. Peter Anvin wrote:
Pavel Machek wrote:
Hi!
The process of safely making delicate changes here is beyond my
responsibility as just a user - believe me, I'm not suggesting that a
risky fix be put in .24. I can patch my own kernels, and I can even
share an
David P. Reed wrote:
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,
David P. Reed wrote:
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,
On Tue, Dec 18, 2007 at 12:06:08AM +, Alan Cox wrote:
> 300MHz 486 -> Nat Semi Geode.
>
> NextGen as you say are 386 - 586 depending on the BIOS hypercode but I
> believe lack WP even in > 386 mode.
Geode identifies itself as family 5 though. It may prefer 486 code but
it's still family 5.
On Tue, Dec 18, 2007 at 12:06:08AM +, Alan Cox wrote:
300MHz 486 - Nat Semi Geode.
NextGen as you say are 386 - 586 depending on the BIOS hypercode but I
believe lack WP even in 386 mode.
Geode identifies itself as family 5 though. It may prefer 486 code but
it's still family 5. Well
> > By the way, you have a 300 MHz 486? I believe 3 -> 40, 4 -> 133, 5 -> 233
> > would be good? And I'm not really sure about the etc. P6 has a large range
> > again...
>
> Some nexgen 5x86 boxes were pretty fast, still could not do 486... so
> family 3 iirc.
300MHz 486 -> Nat Semi Geode.
On Mon 2007-12-17 22:04:19, Rene Herman wrote:
> On 15-12-07 00:29, Alan Cox wrote:
>
?? Just initialize bogomips to 6GHz equivalent... and we are fine
until 6GHz cpus come out.
>>> How long will that take to boot on a 386?
>> Well the dumb approach to fix that would seem to be to
Jan Engelhardt wrote:
On Dec 15 2007 17:46, Alan Cox wrote:
My understanding is that the linux starts in real mode, and uses the
BIOS for such things as reading the very first image.
Not always. We may enter from 32bit in some cases, and we may also not
have a PC BIOS in the first place.
On Dec 15 2007 17:46, Alan Cox wrote:
>
>> My understanding is that the linux starts in real mode, and uses the
>> BIOS for such things as reading the very first image.
>
>Not always. We may enter from 32bit in some cases, and we may also not
>have a PC BIOS in the first place.
Computers
On Dec 14 2007 14:13, H. Peter Anvin wrote:
>>
>> ?? Just initialize bogomips to 6GHz equivalent... and we are fine
>> until 6GHz cpus come out.
>
> How long will that take to boot on a 386?
>
Load it up in bochs and have look at the wallclock. I think that is a
good estimate when you have no
On 15-12-07 00:29, Alan Cox wrote:
?? Just initialize bogomips to 6GHz equivalent... and we are fine
until 6GHz cpus come out.
How long will that take to boot on a 386?
Well the dumb approach to fix that would seem to be to initialise it to
cpu->family 3 -> 50MHz 4 -> 300Mhz 5->
On 17-12-07 19:14, linux-os (Dick Johnson) wrote:
Attached is a patch that changes the outs to ins on port 0x80.
No, that isn't useful. Only a write is "guaranteed" to make ISA/LPC meaning
the timing for a read varies wildly. See the in/out cycles results posted
earlier. Was also reading
On Fri, 14 Dec 2007, David P. Reed wrote:
> 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
* Robert Hancock <[EMAIL PROTECTED]> wrote:
>> unfortunately this hack's side-effects are mis-used by an unknown
>> number of drivers to mask PCI posting bugs. We want to figure out
>> those bugs (safely and carefully) and we want to remove this hack
>> from modern machines that dont need it.
* Robert Hancock [EMAIL PROTECTED] wrote:
unfortunately this hack's side-effects are mis-used by an unknown
number of drivers to mask PCI posting bugs. We want to figure out
those bugs (safely and carefully) and we want to remove this hack
from modern machines that dont need it. Doing
On Fri, 14 Dec 2007, David P. Reed wrote:
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
On 17-12-07 19:14, linux-os (Dick Johnson) wrote:
Attached is a patch that changes the outs to ins on port 0x80.
No, that isn't useful. Only a write is guaranteed to make ISA/LPC meaning
the timing for a read varies wildly. See the in/out cycles results posted
earlier. Was also reading the
On 15-12-07 00:29, Alan Cox wrote:
?? Just initialize bogomips to 6GHz equivalent... and we are fine
until 6GHz cpus come out.
How long will that take to boot on a 386?
Well the dumb approach to fix that would seem to be to initialise it to
cpu-family 3 - 50MHz 4 - 300Mhz 5-
On Dec 14 2007 14:13, H. Peter Anvin wrote:
?? Just initialize bogomips to 6GHz equivalent... and we are fine
until 6GHz cpus come out.
How long will that take to boot on a 386?
Load it up in bochs and have look at the wallclock. I think that is a
good estimate when you have no real 386
On Dec 15 2007 17:46, Alan Cox wrote:
My understanding is that the linux starts in real mode, and uses the
BIOS for such things as reading the very first image.
Not always. We may enter from 32bit in some cases, and we may also not
have a PC BIOS in the first place.
Computers without a
Jan Engelhardt wrote:
On Dec 15 2007 17:46, Alan Cox wrote:
My understanding is that the linux starts in real mode, and uses the
BIOS for such things as reading the very first image.
Not always. We may enter from 32bit in some cases, and we may also not
have a PC BIOS in the first place.
On Mon 2007-12-17 22:04:19, Rene Herman wrote:
On 15-12-07 00:29, Alan Cox wrote:
?? Just initialize bogomips to 6GHz equivalent... and we are fine
until 6GHz cpus come out.
How long will that take to boot on a 386?
Well the dumb approach to fix that would seem to be to initialise it to
By the way, you have a 300 MHz 486? I believe 3 - 40, 4 - 133, 5 - 233
would be good? And I'm not really sure about the etc. P6 has a large range
again...
Some nexgen 5x86 boxes were pretty fast, still could not do 486... so
family 3 iirc.
300MHz 486 - Nat Semi Geode.
NextGen as you
On 16-12-07 22:43, H. Peter Anvin wrote:
Again, 24 is "right out". 25 is a "maybe", IMO. Rene's fix could be an
exception, since it is a DMI-keyed workaround for a specific machine and
doesn't change behaviour in general.
I've not much opinion on the schedule as I've not the problem but
Ingo Molnar wrote:
* H. Peter Anvin <[EMAIL PROTECTED]> wrote:
Pavel Machek wrote:
this is also something for v2.6.24 merging.
As much as I like this patch, I do not think it is suitable for
.24. Too risky, I'd say.
No kidding! We're talking about removing a hack that has been
successful
David P. Reed wrote:
PS: If I have time, I may try to build Rene's port 80 test for Windows
and run it under WinXP on this machine (I still have a crappy little
partition that boots it). If it freezes the same way, it's almost
certain a design "feature", and if it doesn't freeze, we might
Pavel Machek wrote:
Hi!
The process of safely making delicate changes here is beyond my
responsibility as just a user - believe me, I'm not suggesting that a risky
fix be put in .24. I can patch my own kernels, and I can even share an
unofficial patch with others for now, or suggest that
Hi!
> The process of safely making delicate changes here is beyond my
> responsibility as just a user - believe me, I'm not suggesting that a risky
> fix be put in .24. I can patch my own kernels, and I can even share an
> unofficial patch with others for now, or suggest that Fedora and
The process of safely making delicate changes here is beyond my
responsibility as just a user - believe me, I'm not suggesting that a
risky fix be put in .24. I can patch my own kernels, and I can even
share an unofficial patch with others for now, or suggest that Fedora
and Ubuntu add it to
Ingo Molnar wrote:
* H. Peter Anvin <[EMAIL PROTECTED]> wrote:
Pavel Machek wrote:
this is also something for v2.6.24 merging.
As much as I like this patch, I do not think it is suitable for
.24. Too risky, I'd say.
No kidding! We're talking about removing a hack that has been
successful
* H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> Pavel Machek wrote:
>>>
>>> this is also something for v2.6.24 merging.
>>
>> As much as I like this patch, I do not think it is suitable for
>> .24. Too risky, I'd say.
>>
>
> No kidding! We're talking about removing a hack that has been
>
* H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> Paul Rolland wrote:
>> Just an idea : from what I've read, the problem (port 80 hanging) only occurs
>> on 'modern' machines...
>
> It happens on *one single* "modern" machine...
>
> Let's keep that in perspective.
two or three i think (and an
Ingo Molnar wrote:
* H. Peter Anvin [EMAIL PROTECTED] wrote:
Pavel Machek wrote:
this is also something for v2.6.24 merging.
As much as I like this patch, I do not think it is suitable for
.24. Too risky, I'd say.
No kidding! We're talking about removing a hack that has been
successful on
The process of safely making delicate changes here is beyond my
responsibility as just a user - believe me, I'm not suggesting that a
risky fix be put in .24. I can patch my own kernels, and I can even
share an unofficial patch with others for now, or suggest that Fedora
and Ubuntu add it to
Hi!
The process of safely making delicate changes here is beyond my
responsibility as just a user - believe me, I'm not suggesting that a risky
fix be put in .24. I can patch my own kernels, and I can even share an
unofficial patch with others for now, or suggest that Fedora and Ubuntu
Pavel Machek wrote:
Hi!
The process of safely making delicate changes here is beyond my
responsibility as just a user - believe me, I'm not suggesting that a risky
fix be put in .24. I can patch my own kernels, and I can even share an
unofficial patch with others for now, or suggest that
David P. Reed wrote:
PS: If I have time, I may try to build Rene's port 80 test for Windows
and run it under WinXP on this machine (I still have a crappy little
partition that boots it). If it freezes the same way, it's almost
certain a design feature, and if it doesn't freeze, we might
Ingo Molnar wrote:
* H. Peter Anvin [EMAIL PROTECTED] wrote:
Pavel Machek wrote:
this is also something for v2.6.24 merging.
As much as I like this patch, I do not think it is suitable for
.24. Too risky, I'd say.
No kidding! We're talking about removing a hack that has been
successful on
On 16-12-07 22:43, H. Peter Anvin wrote:
Again, 24 is right out. 25 is a maybe, IMO. Rene's fix could be an
exception, since it is a DMI-keyed workaround for a specific machine and
doesn't change behaviour in general.
I've not much opinion on the schedule as I've not the problem but yes,
* H. Peter Anvin [EMAIL PROTECTED] wrote:
Paul Rolland wrote:
Just an idea : from what I've read, the problem (port 80 hanging) only occurs
on 'modern' machines...
It happens on *one single* modern machine...
Let's keep that in perspective.
two or three i think (and an unknown of others
* H. Peter Anvin [EMAIL PROTECTED] wrote:
Pavel Machek wrote:
this is also something for v2.6.24 merging.
As much as I like this patch, I do not think it is suitable for
.24. Too risky, I'd say.
No kidding! We're talking about removing a hack that has been
successful on thousands of
Pavel Machek wrote:
this is also something for v2.6.24 merging.
As much as I like this patch, I do not think it is suitable for
.24. Too risky, I'd say.
No kidding! We're talking about removing a hack that has been
successful on thousands of pieces of hardware over 15 years because it
On Fri 2007-12-14 14:15:03, Ingo Molnar wrote:
>
> * 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
On Fri 2007-12-14 15:23:55, 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
On Sat 2007-12-15 12:26:26, H. Peter Anvin wrote:
> Paul Rolland wrote:
>> Just an idea : from what I've read, the problem (port 80 hanging) only
>> occurs
>> on 'modern' machines...
>
> It happens on *one single* "modern" machine...
>
> Let's keep that in perspective.
it hurts on other machines
Paul Rolland wrote:
Just an idea : from what I've read, the problem (port 80 hanging) only occurs
on 'modern' machines...
It happens on *one single* "modern" machine...
Let's keep that in perspective.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe
Rene Herman wrote:
Yes, just posted a Patch-For-Comments that switches on the availability
of a TSC (tsc_init sets tsc_disable also for !cpu_has_tsc) which would
mean that only really old stuff would be using the outb still. A TSC is
really all we need to have a sensible udelay().
Uhm,
Rene Herman wrote:
It's really going to have to be a known _un_used register and (the write
direction of) port 0x80 is used exactly for that reason. Port 0xed is a
known "alternate diagnostic port" used by Phoenix BIOSes at least but
Peter Anvin reported trouble with that one -- probably for
> a minor concern, but I did also point out that using an unused port
> causes the bus to be tied up for a microsecond or two, which matters on
> a fast SMP machine.
And I did point out I'd found locking cases that may be relying upon this
> I also note that curent machines like the problem
> My understanding is that the linux starts in real mode, and uses the
> BIOS for such things as reading the very first image.
Not always. We may enter from 32bit in some cases, and we may also not
have a PC BIOS in the first place.
--
To unsubscribe from this list: send the line "unsubscribe
H. Peter Anvin wrote:
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
This change seems rather unlikely for 2.6.24 at this point (high risk),
but could be good for 2.6.25.
One thing it should probably have for the early going,
is a simple way to turn it on/off at boot time,
so that we don't have people "stuck" unable to run
the test kernels should something weird
I understand the risks of such a fundamental change, and it may be only
a minor concern, but I did also point out that using an unused port
causes the bus to be tied up for a microsecond or two, which matters on
a fast SMP machine.
Of course all the other concerns you guys are worrying about
On Sat, 15 Dec 2007 14:27:25 +0100
Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Rene Herman <[EMAIL PROTECTED]> wrote:
>
> > The issue is -- how do you safely replace the outb pre-loops_per_jiffy
> > calibration? I'm currently running with the attached hack (not
> > submitted, only for 32-bit
On 15-12-07 14:27, Ingo Molnar wrote:
* Rene Herman <[EMAIL PROTECTED]> wrote:
The issue is -- how do you safely replace the outb pre-loops_per_jiffy
calibration? I'm currently running with the attached hack (not
submitted, only for 32-bit and discussion) the idea of which might be
the best
* Rene Herman <[EMAIL PROTECTED]> wrote:
> The issue is -- how do you safely replace the outb pre-loops_per_jiffy
> calibration? I'm currently running with the attached hack (not
> submitted, only for 32-bit and discussion) the idea of which might be
> the best we can do?
how about doing a
On 15-12-07 09:08, Paul Rolland wrote:
Hello,
On Fri, 14 Dec 2007 23:29:55 +
Alan Cox <[EMAIL PROTECTED]> wrote:
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:
How long will that take
Hello,
On Fri, 14 Dec 2007 23:29:55 +
Alan Cox <[EMAIL PROTECTED]> wrote:
> 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:
> >
> > How long will that take to boot on a 386?
>
On 15-12-07 08:43, Ingo Molnar wrote:
* 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.)
On 15-12-07 08:43, Ingo Molnar wrote:
* 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
Hello,
On Fri, 14 Dec 2007 23:29:55 +
Alan Cox [EMAIL PROTECTED] wrote:
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:
How long will that take to boot on a 386?
Well the dumb
On 15-12-07 09:08, Paul Rolland wrote:
Hello,
On Fri, 14 Dec 2007 23:29:55 +
Alan Cox [EMAIL PROTECTED] wrote:
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:
How long will that take to
* Rene Herman [EMAIL PROTECTED] wrote:
The issue is -- how do you safely replace the outb pre-loops_per_jiffy
calibration? I'm currently running with the attached hack (not
submitted, only for 32-bit and discussion) the idea of which might be
the best we can do?
how about doing a
On 15-12-07 14:27, Ingo Molnar wrote:
* Rene Herman [EMAIL PROTECTED] wrote:
The issue is -- how do you safely replace the outb pre-loops_per_jiffy
calibration? I'm currently running with the attached hack (not
submitted, only for 32-bit and discussion) the idea of which might be
the best
On Sat, 15 Dec 2007 14:27:25 +0100
Ingo Molnar [EMAIL PROTECTED] wrote:
* Rene Herman [EMAIL PROTECTED] wrote:
The issue is -- how do you safely replace the outb pre-loops_per_jiffy
calibration? I'm currently running with the attached hack (not
submitted, only for 32-bit and
I understand the risks of such a fundamental change, and it may be only
a minor concern, but I did also point out that using an unused port
causes the bus to be tied up for a microsecond or two, which matters on
a fast SMP machine.
Of course all the other concerns you guys are worrying about
This change seems rather unlikely for 2.6.24 at this point (high risk),
but could be good for 2.6.25.
One thing it should probably have for the early going,
is a simple way to turn it on/off at boot time,
so that we don't have people stuck unable to run
the test kernels should something weird
H. Peter Anvin wrote:
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
My understanding is that the linux starts in real mode, and uses the
BIOS for such things as reading the very first image.
Not always. We may enter from 32bit in some cases, and we may also not
have a PC BIOS in the first place.
--
To unsubscribe from this list: send the line unsubscribe
a minor concern, but I did also point out that using an unused port
causes the bus to be tied up for a microsecond or two, which matters on
a fast SMP machine.
And I did point out I'd found locking cases that may be relying upon this
I also note that curent machines like the problem
Rene Herman wrote:
It's really going to have to be a known _un_used register and (the write
direction of) port 0x80 is used exactly for that reason. Port 0xed is a
known alternate diagnostic port used by Phoenix BIOSes at least but
Peter Anvin reported trouble with that one -- probably for
Paul Rolland wrote:
Just an idea : from what I've read, the problem (port 80 hanging) only occurs
on 'modern' machines...
It happens on *one single* modern machine...
Let's keep that in perspective.
-hpa
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
Rene Herman wrote:
Yes, just posted a Patch-For-Comments that switches on the availability
of a TSC (tsc_init sets tsc_disable also for !cpu_has_tsc) which would
mean that only really old stuff would be using the outb still. A TSC is
really all we need to have a sensible udelay().
Uhm,
On Sat 2007-12-15 12:26:26, H. Peter Anvin wrote:
Paul Rolland wrote:
Just an idea : from what I've read, the problem (port 80 hanging) only
occurs
on 'modern' machines...
It happens on *one single* modern machine...
Let's keep that in perspective.
it hurts on other machines (like debug
On Fri 2007-12-14 15:23:55, 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
On Fri 2007-12-14 14:15:03, Ingo Molnar wrote:
* 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
Pavel Machek wrote:
this is also something for v2.6.24 merging.
As much as I like this patch, I do not think it is suitable for
.24. Too risky, I'd say.
No kidding! We're talking about removing a hack that has been
successful on thousands of pieces of hardware over 15 years because it
* 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
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
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
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
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
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 -
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 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
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
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
> > 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
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
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
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
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:
>>> /*
>>> - * 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
> > 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
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
* 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
* 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"
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:
* 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
1 - 100 of 138 matches
Mail list logo
