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
>
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, t
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.
> > 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.
Nex
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 initial
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.
C
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 with
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 rea
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-> et
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 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
* 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.
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
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 o
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 sus
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 Fe
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 Ubunt
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 o
* 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
> successf
* 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 unknow
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
br
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 report
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 s
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 linux-kern
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, no
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 mac
> 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 time
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
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 a
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 kn
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.)
Worse
* 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 PI
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 mic
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 f
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 evide
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
doin
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 first-
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 app
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 initiali
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 cali
> > 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 calib
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 ma
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 th
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
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 20
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 wi
* 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" i
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:
http://lkml.org/lkml/2007/12/14/72
* 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
* 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]>
Deb
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 b
"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 comp
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
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 bas
70 matches
Mail list logo