* [PATCH 1/2] MIPS: pfn_valid() is broken on low memory HIGHMEM systems
@ 2010-05-30 7:32 ` Kevin Cernekee
0 siblings, 0 replies; 6+ messages in thread
From: Kevin Cernekee @ 2010-05-30 7:32 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips, linux-kernel
pfn_valid() compares the PFN to max_mapnr:
__pfn >= min_low_pfn && __pfn < max_mapnr;
On HIGHMEM kernels, highend_pfn is used to set the value of max_mapnr.
Unfortunately, highend_pfn is left at zero if the system does not
actually have enough RAM to reach into the HIGHMEM range. This causes
pfn_valid() to always return false, and when debug checks are enabled
the kernel will fail catastrophically:
Memory: 22432k/32768k available (2249k kernel code, 10336k reserved, 653k data, 1352k init, 0k highmem)
NR_IRQS:128
kfree_debugcheck: out of range ptr 81c02900h.
Kernel bug detected[#1]:
Cpu 0
$ 0 : 00000000 10008400 00000034 00000000
$ 4 : 8003e160 802a0000 8003e160 00000000
$ 8 : 00000000 0000003e 00000747 00000747
...
On such a configuration, max_low_pfn should be used to set max_mapnr.
This was seen on 2.6.34.
Signed-off-by: Kevin Cernekee <cernekee@gmail.com>
---
arch/mips/mm/init.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/mips/mm/init.c b/arch/mips/mm/init.c
index 2efcbd2..18183a4 100644
--- a/arch/mips/mm/init.c
+++ b/arch/mips/mm/init.c
@@ -370,7 +370,7 @@ void __init mem_init(void)
#ifdef CONFIG_DISCONTIGMEM
#error "CONFIG_HIGHMEM and CONFIG_DISCONTIGMEM dont work together yet"
#endif
- max_mapnr = highend_pfn;
+ max_mapnr = highend_pfn ? : max_low_pfn;
#else
max_mapnr = max_low_pfn;
#endif
--
1.7.0.4
^ permalink raw reply related [flat|nested] 6+ messages in thread* [PATCH 1/2] MIPS: pfn_valid() is broken on low memory HIGHMEM systems
@ 2010-05-30 7:32 ` Kevin Cernekee
0 siblings, 0 replies; 6+ messages in thread
From: Kevin Cernekee @ 2010-05-30 7:32 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips, linux-kernel
pfn_valid() compares the PFN to max_mapnr:
__pfn >= min_low_pfn && __pfn < max_mapnr;
On HIGHMEM kernels, highend_pfn is used to set the value of max_mapnr.
Unfortunately, highend_pfn is left at zero if the system does not
actually have enough RAM to reach into the HIGHMEM range. This causes
pfn_valid() to always return false, and when debug checks are enabled
the kernel will fail catastrophically:
Memory: 22432k/32768k available (2249k kernel code, 10336k reserved, 653k data, 1352k init, 0k highmem)
NR_IRQS:128
kfree_debugcheck: out of range ptr 81c02900h.
Kernel bug detected[#1]:
Cpu 0
$ 0 : 00000000 10008400 00000034 00000000
$ 4 : 8003e160 802a0000 8003e160 00000000
$ 8 : 00000000 0000003e 00000747 00000747
...
On such a configuration, max_low_pfn should be used to set max_mapnr.
This was seen on 2.6.34.
Signed-off-by: Kevin Cernekee <cernekee@gmail.com>
---
arch/mips/mm/init.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/mips/mm/init.c b/arch/mips/mm/init.c
index 2efcbd2..18183a4 100644
--- a/arch/mips/mm/init.c
+++ b/arch/mips/mm/init.c
@@ -370,7 +370,7 @@ void __init mem_init(void)
#ifdef CONFIG_DISCONTIGMEM
#error "CONFIG_HIGHMEM and CONFIG_DISCONTIGMEM dont work together yet"
#endif
- max_mapnr = highend_pfn;
+ max_mapnr = highend_pfn ? : max_low_pfn;
#else
max_mapnr = max_low_pfn;
#endif
--
1.7.0.4
^ permalink raw reply related [flat|nested] 6+ messages in thread* [PATCH 2/2] MIPS: Fix deferred console messages during CPU hotplug
@ 2010-05-30 7:35 ` Kevin Cernekee
0 siblings, 0 replies; 6+ messages in thread
From: Kevin Cernekee @ 2010-05-30 7:35 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips, linux-kernel
When a secondary CPU is booting up in start_secondary(), cpu_probe() and
calibrate_delay() are called while cpu_online(smp_processor_id()) == 0.
This means that can_use_console() will return 0 on many systems:
static inline int can_use_console(unsigned int cpu)
{
return cpu_online(cpu) || have_callable_console();
}
If (can_use_console() == 0), printk() will spool its output to log_buf
and it will be visible in "dmesg", but that output will NOT be echoed to
the console until somebody calls release_console_sem() from a CPU that
is online. Effectively this means that the cpu_probe() and
calibrate_delay() messages will sit in limbo, and will only get dumped
to the screen the next time printk() happens to get called.
At boot time, more printk() messages are invariably generated after SMP
initialization as the kernel boot proceeds, so this problem is unlikely
to be noticed. But when using the CPU hotplug feature to reactivate a
dormant processor, the new CPU's boot messages could be stuck in limbo
for quite a while since nothing is necessarily printed to the kernel log
afterward.
The proposed workaround is to acquire and release console_sem from
__cpu_up(), so any queued messages can be flushed out to the console by
a CPU that is definitely known to be online.
This issue was seen on 2.6.34.
Signed-off-by: Kevin Cernekee <cernekee@gmail.com>
---
arch/mips/kernel/smp.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/mips/kernel/smp.c b/arch/mips/kernel/smp.c
index 6cdca19..bf8923f 100644
--- a/arch/mips/kernel/smp.c
+++ b/arch/mips/kernel/smp.c
@@ -33,6 +33,7 @@
#include <linux/cpu.h>
#include <linux/err.h>
#include <linux/ftrace.h>
+#include <linux/console.h>
#include <asm/atomic.h>
#include <asm/cpu.h>
@@ -219,6 +220,10 @@ int __cpuinit __cpu_up(unsigned int cpu)
cpu_set(cpu, cpu_online_map);
+ /* Flush out any buffered log messages from the new CPU */
+ if (try_acquire_console_sem() == 0)
+ release_console_sem();
+
return 0;
}
--
1.7.0.4
^ permalink raw reply related [flat|nested] 6+ messages in thread* [PATCH 2/2] MIPS: Fix deferred console messages during CPU hotplug
@ 2010-05-30 7:35 ` Kevin Cernekee
0 siblings, 0 replies; 6+ messages in thread
From: Kevin Cernekee @ 2010-05-30 7:35 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips, linux-kernel
When a secondary CPU is booting up in start_secondary(), cpu_probe() and
calibrate_delay() are called while cpu_online(smp_processor_id()) == 0.
This means that can_use_console() will return 0 on many systems:
static inline int can_use_console(unsigned int cpu)
{
return cpu_online(cpu) || have_callable_console();
}
If (can_use_console() == 0), printk() will spool its output to log_buf
and it will be visible in "dmesg", but that output will NOT be echoed to
the console until somebody calls release_console_sem() from a CPU that
is online. Effectively this means that the cpu_probe() and
calibrate_delay() messages will sit in limbo, and will only get dumped
to the screen the next time printk() happens to get called.
At boot time, more printk() messages are invariably generated after SMP
initialization as the kernel boot proceeds, so this problem is unlikely
to be noticed. But when using the CPU hotplug feature to reactivate a
dormant processor, the new CPU's boot messages could be stuck in limbo
for quite a while since nothing is necessarily printed to the kernel log
afterward.
The proposed workaround is to acquire and release console_sem from
__cpu_up(), so any queued messages can be flushed out to the console by
a CPU that is definitely known to be online.
This issue was seen on 2.6.34.
Signed-off-by: Kevin Cernekee <cernekee@gmail.com>
---
arch/mips/kernel/smp.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/mips/kernel/smp.c b/arch/mips/kernel/smp.c
index 6cdca19..bf8923f 100644
--- a/arch/mips/kernel/smp.c
+++ b/arch/mips/kernel/smp.c
@@ -33,6 +33,7 @@
#include <linux/cpu.h>
#include <linux/err.h>
#include <linux/ftrace.h>
+#include <linux/console.h>
#include <asm/atomic.h>
#include <asm/cpu.h>
@@ -219,6 +220,10 @@ int __cpuinit __cpu_up(unsigned int cpu)
cpu_set(cpu, cpu_online_map);
+ /* Flush out any buffered log messages from the new CPU */
+ if (try_acquire_console_sem() == 0)
+ release_console_sem();
+
return 0;
}
--
1.7.0.4
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [PATCH 2/2] MIPS: Fix deferred console messages during CPU hotplug
2010-05-30 7:35 ` Kevin Cernekee
(?)
@ 2010-05-31 4:41 ` Paul Mundt
-1 siblings, 0 replies; 6+ messages in thread
From: Paul Mundt @ 2010-05-31 4:41 UTC (permalink / raw)
To: Kevin Cernekee; +Cc: Ralf Baechle, linux-mips, linux-kernel
On Sun, May 30, 2010 at 12:35:58AM -0700, Kevin Cernekee wrote:
> diff --git a/arch/mips/kernel/smp.c b/arch/mips/kernel/smp.c
> index 6cdca19..bf8923f 100644
> --- a/arch/mips/kernel/smp.c
> +++ b/arch/mips/kernel/smp.c
> @@ -219,6 +220,10 @@ int __cpuinit __cpu_up(unsigned int cpu)
>
> cpu_set(cpu, cpu_online_map);
>
> + /* Flush out any buffered log messages from the new CPU */
> + if (try_acquire_console_sem() == 0)
> + release_console_sem();
> +
> return 0;
> }
>
Since this is entirely generic why not just have kernel/printk.c register
a hotcpu notifier and handle this in the CPU_ONLINE case?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 1/2] MIPS: pfn_valid() is broken on low memory HIGHMEM systems
2010-05-30 7:32 ` Kevin Cernekee
(?)
(?)
@ 2011-05-19 11:48 ` Ralf Baechle
-1 siblings, 0 replies; 6+ messages in thread
From: Ralf Baechle @ 2011-05-19 11:48 UTC (permalink / raw)
To: Kevin Cernekee; +Cc: linux-mips, linux-kernel
Queued for 2.6.41 with David Daney's suggested change to avoid GNU C
extensions but I'm probably going to change my mind and will push this
earlier.
Thanks!
Ralf
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-05-19 11:48 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-05-30 7:32 [PATCH 1/2] MIPS: pfn_valid() is broken on low memory HIGHMEM systems Kevin Cernekee
2010-05-30 7:32 ` Kevin Cernekee
2010-05-30 7:35 ` [PATCH 2/2] MIPS: Fix deferred console messages during CPU hotplug Kevin Cernekee
2010-05-30 7:35 ` Kevin Cernekee
2010-05-31 4:41 ` Paul Mundt
2011-05-19 11:48 ` [PATCH 1/2] MIPS: pfn_valid() is broken on low memory HIGHMEM systems Ralf Baechle
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.