2.4 kernel hangs on 486 machine at boot
Hello, Problem: Linux kernel 2.4 consistently hangs at boot on 486 machine Shortly after lilo starts the kernel it hangs at the following message: Checking if this processor honours the WP bit even in supervisor mode... I experience this problem on a VLB AMD 486 DX/2-66 system. This machine ran all kernels up to 2.2.18 without any problem (it still does). This 2.4 kernel runs fine on a Pentium, Pentium II and even on a _386DX_ (!!!), but not on my 486 machine (which I am using as a router, and I thought: let's try the netfilter/iptables feature :) on it). I tried both the precompiled 2.4 kernels from the Redhat linux releases and betas, and a couple of self-compiled stock kernels (2.4.0 and 2.4.2) from ftp://ftp.kernel.org/ Anyway I find it obvious that the kernel hangs only on 486's (and probably not all of them), so it must be a bug (can I call this an oops? ;-)) I'm not familiar enough with the kernel and protected mode x86 asm to correct this problem myself, but if anyone would know what may be causing this (probably in arch/i386/mm/init.c) I can rebuild, install and test any supplied patches (don't send entire precompiled kernels to me, please). BTW Keep in mind that I'm not on any kernel related mailing list, but I like to be informed. Thanks & kind regards, -- Vik - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4 kernel hangs on 486 machine at boot
- Original Message - From: "Alan Cox" <[EMAIL PROTECTED]> To: "Vik Heyndrickx" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, April 04, 2001 7:54 PM Subject: Re: 2.4 kernel hangs on 486 machine at boot > > Problem: Linux kernel 2.4 consistently hangs at boot on 486 machine > > > > Shortly after lilo starts the kernel it hangs at the following message: > > Checking if this processor honours the WP bit even in supervisor mode... > > > > Does this happen on 2.4.3-ac kernel trees ? I thought i had it zapped It doesn't even happen with with 2.4.3. Now I feel silly. -- Vik - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] sched: loadavg 0.00, 0.01, 0.05 on idle, 1.00, 0.99, 0.95 on full load
Hi Peter,
Systems show a minimal load average of 0.00, 0.01, 0.05 even when they
have no load at all.
Uptime and /proc/loadavg on all systems with kernels released during the
last five years up until kernel version 4.6-rc5, show a 5- and 15-minute
minimum loadavg of 0.01 and 0.05 respectively. This should be 0.00 on
idle systems, but the way the kernel calculates this value prevents it
from getting lower than the mentioned values.
Likewise but not as obviously noticeable, a fully loaded system with no
processes waiting, shows a maximum 1/5/15 loadavg of 1.00, 0.99, 0.95
(multiplied by number of cores).
Once the (old) load becomes 93 or higher, it mathematically can never
get lower than 93, even when the active (load) remains 0 forever.
This results in the strange 0.00, 0.01, 0.05 uptime values on idle
systems. Note: 93/2048 = 0.0454..., which rounds up to 0.05.
It is not correct to add a 0.5 rounding (=1024/2048) here, since the
result from this function is fed back into the next iteration again,
so the result of that +0.5 rounding value then gets multiplied by
(2048-2037), and then rounded again, so there is a virtual "ghost"
load created, next to the old and active load terms.
By changing the way the internally kept value is rounded, that internal
value equivalent now can reach 0.00 on idle, and 1.00 on full load. Upon
increasing load, the internally kept load value is rounded up, when the
load is decreasing, the load value is rounded down.
The modified code was tested on nohz=off and nohz kernels. It was tested
on vanilla kernel 4.6-rc5 and on centos 7.1 kernel 3.10.0-327. It was
tested on single, dual, and octal cores system. It was tested on virtual
hosts and bare hardware. No unwanted effects have been observed, and the
problems that the patch intended to fix were indeed gone.
Fixes: 0f004f5a696a ("sched: Cure more NO_HZ load average woes")
Cc: Doug Smythies
Tested-by: Damien Wyart
Signed-off-by: Vik Heyndrickx
--- kernel/sched/loadavg.c.orig 2016-04-25 01:17:05.0 +0200
+++ kernel/sched/loadavg.c 2016-04-28 16:47:47.754266136 +0200
@@ -99,10 +99,12 @@ long calc_load_fold_active(struct rq *th
static unsigned long
calc_load(unsigned long load, unsigned long exp, unsigned long active)
{
- load *= exp;
- load += active * (FIXED_1 - exp);
- load += 1UL << (FSHIFT - 1);
- return load >> FSHIFT;
+ long unsigned newload;
+
+ newload = load * exp + active * (FIXED_1 - exp);
+ if (active >= load)
+ newload += FIXED_1-1;
+ return newload / FIXED_1;
}
#ifdef CONFIG_NO_HZ_COMMON
[PATCH] sched: loadavg 0.00, 0.01, 0.05 on idle
Systems show a minimal load average of 0.00, 0.01, 0.05 even when they
have no load at all.
Uptime and /proc/loadavg on all systems with kernels released during the
last five years up until kernel version 4.4, show a 5- and 15-minute
minimum loadavg of 0.01 and 0.05 respectively. This should be 0.00 on
idle systems, but the way the kernel calculates this value prevents it
from getting lower than the mentioned values. Likewise but not as
obviously noticeable, a fully loaded system with no processes waiting,
shows a maximum 1/5/15 loadavg of 1.00, 0.99, 0.95 (multiplied by number
of cores).
By removing the single code line that performed a rounding on the
internally kept load value, effectively returning this function
calc_load to its state it had before, the visualization problem is
completely fixed.
The modified code was tested on nohz=off and nohz kernels. It was tested
on vanilla kernel 4.4 and on centos 7.1 kernel 3.10.0-327. It was tested
on single, dual, and octal cores system. It was tested on virtual hosts
and bare hardware. No unwanted effects have been observed, and the
problems that the patch intended to fix were indeed gone.
The following patch is for kernel version 4.x . In kernel 3.x, the
affected code was in core.c instead of loadavg.c
Signed-off-by: Vik Heyndrickx
--- linux-4.4-org/kernel/sched/loadavg.c 2016-01-21 09:11:15 +0100
+++ linux-4.4/kernel/sched/loadavg.c 2016-01-21 09:11:31 +0100
@@ -101,7 +101,6 @@ calc_load(unsigned long load, unsigned l
{
load *= exp;
load += active * (FIXED_1 - exp);
- load += 1UL << (FSHIFT - 1);
return load >> FSHIFT;
}
Re: [PATCH] sched: loadavg 0.00, 0.01, 0.05 on idle
On 21/01/2016 19:38, Doug Smythies wrote: new = (old * 2037 + load * (2048 - 2037)) / 2048 new = (1862 * 2037 + 2048 * (2048 - 2037)) / 2048 new = 1862 So, the 100% load will always be shown as 91% (double the old limit). Math seems sound, but the fact is that the load on all my test machines now drops to 0.00/0.00/0.00 on idle, and increases to e.g. on my octa- core 8.00/8.00/8.00 on full load. I used mprime -t to cause a full load on all cores. load can never drop below 0, but can and will exceed 2048 unless nothing else is running, which is then likely the reason why 8.00 is actually reached for the 5 and 15 minute value despite the math here above. I would not worry too much about the accuracy, because, with or without the rounding, it takes more than three quarters of an hour to reach 100% 15-minute loadavg from idle, or the other way around 0% from full load. I have been running this proposed code with 100% load on CPU 7 for a couple of hours now, and the 15 minute load average is stuck at 0.91. In theory possible, but any instantaneous load above 100% will raise that 0.91 further. I think I can easily change the calc_load algorithm further to have the best of both worlds, but it will still take 45 minutes to reach a 15-minute avgload. After 40 minutes, and just to be sure, I checked again, and my buildhost now has the following load: 8.00, 8.02, 7.94. -- Vik
[tip:sched/core] sched/loadavg: Fix loadavg artifacts on fully idle and on fully loaded systems
Commit-ID: 20878232c52329f92423d27a60e48b6a6389e0dd
Gitweb: http://git.kernel.org/tip/20878232c52329f92423d27a60e48b6a6389e0dd
Author: Vik Heyndrickx
AuthorDate: Thu, 28 Apr 2016 20:46:28 +0200
Committer: Ingo Molnar
CommitDate: Thu, 12 May 2016 09:55:34 +0200
sched/loadavg: Fix loadavg artifacts on fully idle and on fully loaded systems
Systems show a minimal load average of 0.00, 0.01, 0.05 even when they
have no load at all.
Uptime and /proc/loadavg on all systems with kernels released during the
last five years up until kernel version 4.6-rc5, show a 5- and 15-minute
minimum loadavg of 0.01 and 0.05 respectively. This should be 0.00 on
idle systems, but the way the kernel calculates this value prevents it
from getting lower than the mentioned values.
Likewise but not as obviously noticeable, a fully loaded system with no
processes waiting, shows a maximum 1/5/15 loadavg of 1.00, 0.99, 0.95
(multiplied by number of cores).
Once the (old) load becomes 93 or higher, it mathematically can never
get lower than 93, even when the active (load) remains 0 forever.
This results in the strange 0.00, 0.01, 0.05 uptime values on idle
systems. Note: 93/2048 = 0.0454..., which rounds up to 0.05.
It is not correct to add a 0.5 rounding (=1024/2048) here, since the
result from this function is fed back into the next iteration again,
so the result of that +0.5 rounding value then gets multiplied by
(2048-2037), and then rounded again, so there is a virtual "ghost"
load created, next to the old and active load terms.
By changing the way the internally kept value is rounded, that internal
value equivalent now can reach 0.00 on idle, and 1.00 on full load. Upon
increasing load, the internally kept load value is rounded up, when the
load is decreasing, the load value is rounded down.
The modified code was tested on nohz=off and nohz kernels. It was tested
on vanilla kernel 4.6-rc5 and on centos 7.1 kernel 3.10.0-327. It was
tested on single, dual, and octal cores system. It was tested on virtual
hosts and bare hardware. No unwanted effects have been observed, and the
problems that the patch intended to fix were indeed gone.
Tested-by: Damien Wyart
Signed-off-by: Vik Heyndrickx
Signed-off-by: Peter Zijlstra (Intel)
Cc:
Cc: Doug Smythies
Cc: Linus Torvalds
Cc: Mike Galbraith
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Fixes: 0f004f5a696a ("sched: Cure more NO_HZ load average woes")
Link: http://lkml.kernel.org/r/e8d32bff-d544-7748-72b5-3c86cc71f...@veribox.net
Signed-off-by: Ingo Molnar
---
kernel/sched/loadavg.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/kernel/sched/loadavg.c b/kernel/sched/loadavg.c
index ef71590..b0b93fd 100644
--- a/kernel/sched/loadavg.c
+++ b/kernel/sched/loadavg.c
@@ -99,10 +99,13 @@ long calc_load_fold_active(struct rq *this_rq)
static unsigned long
calc_load(unsigned long load, unsigned long exp, unsigned long active)
{
- load *= exp;
- load += active * (FIXED_1 - exp);
- load += 1UL << (FSHIFT - 1);
- return load >> FSHIFT;
+ unsigned long newload;
+
+ newload = load * exp + active * (FIXED_1 - exp);
+ if (active >= load)
+ newload += FIXED_1-1;
+
+ return newload / FIXED_1;
}
#ifdef CONFIG_NO_HZ_COMMON
[tip:sched/urgent] sched: Fix non-zero idle loadavg
Commit-ID: 1f9649ef6aa1bac53fb478d9e641b22d67f8423c
Gitweb: http://git.kernel.org/tip/1f9649ef6aa1bac53fb478d9e641b22d67f8423c
Author: Vik Heyndrickx
AuthorDate: Thu, 21 Jan 2016 10:23:25 +0100
Committer: Ingo Molnar
CommitDate: Thu, 21 Jan 2016 18:55:23 +0100
sched: Fix non-zero idle loadavg
Systems show a minimal load average of 0.00, 0.01, 0.05 even when they
have no load at all.
Uptime and /proc/loadavg on all systems with kernels released during the
last five years up until kernel version 4.4, show a 5- and 15-minute
minimum loadavg of 0.01 and 0.05 respectively. This should be 0.00 on
idle systems, but the way the kernel calculates this value prevents it
from getting lower than the mentioned values.
Likewise but not as obviously noticeable, a fully loaded system with
no processes waiting, shows a maximum 1/5/15 loadavg of 1.00, 0.99,
0.95 (multiplied by number of cores).
By removing the single code line that performed a rounding on the
internally kept load value, effectively returning this function
calc_load to its state it had before, the visualization problem is
completely fixed.
Once the (old) load becomes 93 or higher, it mathematically can never
get lower than 93, even when the active (load) remains 0 forever.
This results in the strange 0.00, 0.01, 0.05 uptime values on idle
systems. Note: 93/2048 = 0.0454..., which rounds up to 0.05.
It is not correct to add a 0.5 rounding (=1024/2048) here, since the
result from this function is fed back into the next iteration again,
so the result of that +0.5 rounding value then gets multiplied by
(2048-2037), and then rounded again, so there is a virtual "ghost"
load created, next to the old and active load terms.
The modified code was tested on nohz=off and nohz kernels. It was tested
on vanilla kernel 4.4 and on centos 7.1 kernel 3.10.0-327. It was tested
on single, dual, and octal cores system. It was tested on virtual hosts
and bare hardware. No unwanted effects have been observed, and the
problems that the patch intended to fix were indeed gone.
Signed-off-by: Vik Heyndrickx
[ Changelog edits ]
Signed-off-by: Peter Zijlstra (Intel)
Cc: Doug Smythies
Cc: Linus Torvalds
Cc: Mike Galbraith
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: sta...@vger.kernel.org
Fixes: 0f004f5a696a ("sched: Cure more NO_HZ load average woes")
Link: http://lkml.kernel.org/r/56a0a38d.4040...@veribox.net
Signed-off-by: Ingo Molnar
---
kernel/sched/loadavg.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/kernel/sched/loadavg.c b/kernel/sched/loadavg.c
index ef71590..eb83b93 100644
--- a/kernel/sched/loadavg.c
+++ b/kernel/sched/loadavg.c
@@ -101,7 +101,6 @@ calc_load(unsigned long load, unsigned long exp, unsigned
long active)
{
load *= exp;
load += active * (FIXED_1 - exp);
- load += 1UL << (FSHIFT - 1);
return load >> FSHIFT;
}
