[patch 1/1] init/main.c: prevent increase of console_loglevel by 'quiet' kernel parameter
From: Sergey Popov
Prevent increase of console_loglevel by 'quiet'
'quiet' kernel option that follows the 'loglevel=N' should
not blindly overwrite console_loglevel, instead it should
respect and keep lower 'loglevel'.
Signed-off-by: Sergey Popov
---
init/main.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
Some drivers tend to print error messages (ex: 'drm/i810 does not support SMP')
to the console
that we at our company don't want to show to people. We use 'quiet' kernel
option to hide kernel decompressing progress and other messages not related to
printk. But to hide error messages from drivers we use 'loglevel=3' parameter
as well. But when it's _before_ the quiet, then quiet overrides loglevel=3 and
set it to be 4.
I think that's a bug, and here's simple solution for it. The only way to live
without this patch is to pass 'loglevel=3' after the 'quiet'. This issue is
known to the community, but everyone is using workaround (ex:
https://wiki.archlinux.org/index.php/Silent_boot).
I had enough inspiration to dive into the linux code and fix it.
--
with best regards,
Sergey Popov
phone: +380687507707
skype: uazure
vk.com/uazure
fb.com/uazurediff --git a/init/main.c b/init/main.c
index 61b99376..91fc78b 100644
--- a/init/main.c
+++ b/init/main.c
@@ -211,7 +211,12 @@ static int __init debug_kernel(char *str)
static int __init quiet_kernel(char *str)
{
- console_loglevel = CONSOLE_LOGLEVEL_QUIET;
+ /*
+ * 'quiet' option should not raise console_loglevel, it's only
+ * allowed to lower it
+ */
+ if (console_loglevel > CONSOLE_LOGLEVEL_QUIET)
+ console_loglevel = CONSOLE_LOGLEVEL_QUIET;
return 0;
}
[patch 1/1] init/main.c: prevent increase of console_loglevel by 'quiet' kernel parameter (inline now, sorry for previous attachment)
From: Sergey Popov < popov_ser...@ukr.net >
Prevent increase of console_loglevel by 'quiet'
'quiet' kernel option that follows the 'loglevel=N' should
not blindly overwrite console_loglevel, instead it should
respect and keep lower 'loglevel'.
Signed-off-by: Sergey Popov < popov_ser...@ukr.net >
---
init/main.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
Some drivers tend to print error messages (ex: 'drm/i810 does not support SMP')
to the console
that we at our company don't want to show to people. We use 'quiet' kernel
option to hide kernel decompressing progress and other messages not related to
printk. But to hide error messages from drivers we use 'loglevel=3' parameter
as well. But when it's _before_ the quiet, then quiet overrides loglevel=3 and
set it to be 4.
I think that's a bug, and here's simple solution for it. The only way to live
without this patch is to pass 'loglevel=3' after the 'quiet'. This issue is
known to the community, but everyone is using workaround (ex:
https://wiki.archlinux.org/index.php/Silent_boot ).
diff --git a/init/main.c b/init/main.c
index 61b99376..91fc78b 100644
--- a/init/main.c
+++ b/init/main.c
@@ -211,7 +211,12 @@ static int __init debug_kernel(char *str)
static int __init quiet_kernel(char *str)
{
- console_loglevel = CONSOLE_LOGLEVEL_QUIET;
+ /*
+* 'quiet' option should not raise console_loglevel, it's only
+* allowed to lower it
+*/
+ if (console_loglevel > CONSOLE_LOGLEVEL_QUIET)
+ console_loglevel = CONSOLE_LOGLEVEL_QUIET;
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 1/1] init/main.c: prevent increase of console_loglevel by 'quiet' kernel parameter
From: Sergey Popov popov_ser...@ukr.net
Prevent increase of console_loglevel by 'quiet'
'quiet' kernel option that follows the 'loglevel=N' should
not blindly overwrite console_loglevel, instead it should
respect and keep lower 'loglevel'.
Signed-off-by: Sergey Popov popov_ser...@ukr.net
---
init/main.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
Some drivers tend to print error messages (ex: 'drm/i810 does not support SMP')
to the console
that we at our company don't want to show to people. We use 'quiet' kernel
option to hide kernel decompressing progress and other messages not related to
printk. But to hide error messages from drivers we use 'loglevel=3' parameter
as well. But when it's _before_ the quiet, then quiet overrides loglevel=3 and
set it to be 4.
I think that's a bug, and here's simple solution for it. The only way to live
without this patch is to pass 'loglevel=3' after the 'quiet'. This issue is
known to the community, but everyone is using workaround (ex:
https://wiki.archlinux.org/index.php/Silent_boot).
I had enough inspiration to dive into the linux code and fix it.
--
with best regards,
Sergey Popov
phone: +380687507707
skype: uazure
vk.com/uazure
fb.com/uazurediff --git a/init/main.c b/init/main.c
index 61b99376..91fc78b 100644
--- a/init/main.c
+++ b/init/main.c
@@ -211,7 +211,12 @@ static int __init debug_kernel(char *str)
static int __init quiet_kernel(char *str)
{
- console_loglevel = CONSOLE_LOGLEVEL_QUIET;
+ /*
+ * 'quiet' option should not raise console_loglevel, it's only
+ * allowed to lower it
+ */
+ if (console_loglevel CONSOLE_LOGLEVEL_QUIET)
+ console_loglevel = CONSOLE_LOGLEVEL_QUIET;
return 0;
}
[patch 1/1] init/main.c: prevent increase of console_loglevel by 'quiet' kernel parameter (inline now, sorry for previous attachment)
From: Sergey Popov popov_ser...@ukr.net
Prevent increase of console_loglevel by 'quiet'
'quiet' kernel option that follows the 'loglevel=N' should
not blindly overwrite console_loglevel, instead it should
respect and keep lower 'loglevel'.
Signed-off-by: Sergey Popov popov_ser...@ukr.net
---
init/main.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
Some drivers tend to print error messages (ex: 'drm/i810 does not support SMP')
to the console
that we at our company don't want to show to people. We use 'quiet' kernel
option to hide kernel decompressing progress and other messages not related to
printk. But to hide error messages from drivers we use 'loglevel=3' parameter
as well. But when it's _before_ the quiet, then quiet overrides loglevel=3 and
set it to be 4.
I think that's a bug, and here's simple solution for it. The only way to live
without this patch is to pass 'loglevel=3' after the 'quiet'. This issue is
known to the community, but everyone is using workaround (ex:
https://wiki.archlinux.org/index.php/Silent_boot ).
diff --git a/init/main.c b/init/main.c
index 61b99376..91fc78b 100644
--- a/init/main.c
+++ b/init/main.c
@@ -211,7 +211,12 @@ static int __init debug_kernel(char *str)
static int __init quiet_kernel(char *str)
{
- console_loglevel = CONSOLE_LOGLEVEL_QUIET;
+ /*
+* 'quiet' option should not raise console_loglevel, it's only
+* allowed to lower it
+*/
+ if (console_loglevel CONSOLE_LOGLEVEL_QUIET)
+ console_loglevel = CONSOLE_LOGLEVEL_QUIET;
return 0;
}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: General slowness with using 64Gb HIGHMEM option on 32-bit kernel
Ok, I found a palliative. Now I'm working with "mem=6770M" option, that gives me 6072MB RAM (of 6144 total). Interesting, that if you choose too much, like "mem=6800M", system behaviour is exactly the same as without any options. Can it be that kernel incorrectly sets amount of memory to use so such a situation occurs? - 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/
General slowness with using 64Gb HIGHMEM option on 32-bit kernel
Short description: after recompiling 32-bit kernel with 64Gb highmem support and rebooting into it, OS started working very much slower then before. Specifications: Intel Core 2 Duo [EMAIL PROTECTED],4Ghz on Intel i965Q-based motherboard. 6Gb of DDR2 RAM, 2x1Gb+2x2Gb, dual-channel. Vector Linux 5.8 (Slackware Linux 11-based), 2.6.20.3 kernel. Long description: after recompiling 32-bit 2.6.20.3 kernel with 64Gb highmem option and rebooting into it, booting process froze on udevd. After booting up from CD and disabling rc.udev, system started, but it's work after rc.M script sarted was 5-10 times slower then usual. top showed, that processes are taking much more CPU% time then usual. I tried downloading the newest stable kernel - 2.6.22.9 - hoping, that it would solve the problem. I downloaded it, booted from CD, and compiled it with 64Gb highmem support. I felt some speed improvement, but if on 2.6.20.3 machine performed like P166, now it is working like P2-350. I've found a similar problem, described on lkml - http://lkml.org/lkml/2007/5/30/5 . But, unfortunately, it is x86_64 related and contains no clues for me. Moving to 64-bit distro is rather unpleasant - as there is an option in 32-bit kernel, it should work ;) . What tests should I run to help investigate this problem? - 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/
General slowness with using 64Gb HIGHMEM option on 32-bit kernel
Short description: after recompiling 32-bit kernel with 64Gb highmem support and rebooting into it, OS started working very much slower then before. Specifications: Intel Core 2 Duo [EMAIL PROTECTED],4Ghz on Intel i965Q-based motherboard. 6Gb of DDR2 RAM, 2x1Gb+2x2Gb, dual-channel. Vector Linux 5.8 (Slackware Linux 11-based), 2.6.20.3 kernel. Long description: after recompiling 32-bit 2.6.20.3 kernel with 64Gb highmem option and rebooting into it, booting process froze on udevd. After booting up from CD and disabling rc.udev, system started, but it's work after rc.M script sarted was 5-10 times slower then usual. top showed, that processes are taking much more CPU% time then usual. I tried downloading the newest stable kernel - 2.6.22.9 - hoping, that it would solve the problem. I downloaded it, booted from CD, and compiled it with 64Gb highmem support. I felt some speed improvement, but if on 2.6.20.3 machine performed like P166, now it is working like P2-350. I've found a similar problem, described on lkml - http://lkml.org/lkml/2007/5/30/5 . But, unfortunately, it is x86_64 related and contains no clues for me. Moving to 64-bit distro is rather unpleasant - as there is an option in 32-bit kernel, it should work ;) . What tests should I run to help investigate this problem? - 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: General slowness with using 64Gb HIGHMEM option on 32-bit kernel
Ok, I found a palliative. Now I'm working with mem=6770M option, that gives me 6072MB RAM (of 6144 total). Interesting, that if you choose too much, like mem=6800M, system behaviour is exactly the same as without any options. Can it be that kernel incorrectly sets amount of memory to use so such a situation occurs? - 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/
