* [PATCH] x86: let 'reservetop' functioning right
@ 2010-03-25 0:54 Liang Li
2010-03-31 2:49 ` Liang Li
0 siblings, 1 reply; 2+ messages in thread
From: Liang Li @ 2010-03-25 0:54 UTC (permalink / raw)
To: mingo; +Cc: linux-kernel
When specify 'reservetop=0xabc000' kernel parameter, kernel will hang
on boot due to a early_ioremap bug that relate to commit 8827247ff.
The root cause of boot failure problem is the value of 'slot_virt[i]'
was initialized in setup_arch->early_ioremap_init. But later in
setup_arch, the function 'parse_early_param' will modify 'FIXADDR_TOP'
when 'reservetop=0xbadc0de' being specified.
The simplest fix might be use __fix_to_virt(idx0) to get updated value
of 'FIXADDR_TOP' in '__early_ioremap' instead of reference old value
from slot_virt[slot] directly.
Signed-off-by: Liang Li <liang.li@windriver.com>
---
arch/x86/mm/ioremap.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index 5eb1ba7..ea82ef0 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -537,9 +537,9 @@ __early_ioremap(resource_size_t phys_addr, unsigned long size, pgprot_t prot)
--nrpages;
}
if (early_ioremap_debug)
- printk(KERN_CONT "%08lx + %08lx\n", offset, slot_virt[slot]);
+ printk(KERN_CONT "%08lx + %08lx\n", offset, __fix_to_virt(idx0));
- prev_map[slot] = (void __iomem *)(offset + slot_virt[slot]);
+ prev_map[slot] = (void __iomem *)(offset + __fix_to_virt(idx0));
return prev_map[slot];
}
--
1.6.6
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [PATCH] x86: let 'reservetop' functioning right
2010-03-25 0:54 [PATCH] x86: let 'reservetop' functioning right Liang Li
@ 2010-03-31 2:49 ` Liang Li
0 siblings, 0 replies; 2+ messages in thread
From: Liang Li @ 2010-03-31 2:49 UTC (permalink / raw)
To: mingo; +Cc: linux-kernel, wangchen, akpm
Hi Ingo,
Seems the problem still there in 2.6.34-rc3. When pass
'reservetop=0x1000' to x86_32 kernel, kernel hangs on
very early boot stage.
Do we have any plan to abandon 'reservetop' or due to
some reason that the patch is non-acceptable?
Thanks,
-Liang Li
On Thu, Mar 25, 2010 at 08:54:05AM +0800, Liang Li wrote:
> When specify 'reservetop=0xabc000' kernel parameter, kernel will hang
> on boot due to a early_ioremap bug that relate to commit 8827247ff.
>
> The root cause of boot failure problem is the value of 'slot_virt[i]'
> was initialized in setup_arch->early_ioremap_init. But later in
> setup_arch, the function 'parse_early_param' will modify 'FIXADDR_TOP'
> when 'reservetop=0xbadc0de' being specified.
>
> The simplest fix might be use __fix_to_virt(idx0) to get updated value
> of 'FIXADDR_TOP' in '__early_ioremap' instead of reference old value
> from slot_virt[slot] directly.
>
> Signed-off-by: Liang Li <liang.li@windriver.com>
> ---
> arch/x86/mm/ioremap.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
> index 5eb1ba7..ea82ef0 100644
> --- a/arch/x86/mm/ioremap.c
> +++ b/arch/x86/mm/ioremap.c
> @@ -537,9 +537,9 @@ __early_ioremap(resource_size_t phys_addr, unsigned long size, pgprot_t prot)
> --nrpages;
> }
> if (early_ioremap_debug)
> - printk(KERN_CONT "%08lx + %08lx\n", offset, slot_virt[slot]);
> + printk(KERN_CONT "%08lx + %08lx\n", offset, __fix_to_virt(idx0));
>
> - prev_map[slot] = (void __iomem *)(offset + slot_virt[slot]);
> + prev_map[slot] = (void __iomem *)(offset + __fix_to_virt(idx0));
> return prev_map[slot];
> }
>
> --
> 1.6.6
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2010-03-31 2:53 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-03-25 0:54 [PATCH] x86: let 'reservetop' functioning right Liang Li
2010-03-31 2:49 ` Liang Li
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox