lkml.org 
[lkml]   [2006]   [Jan]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.6.15-mm4 failure on power5
Quoting Michael Ellerman (michael@ellerman.id.au):
> On Mon, 16 Jan 2006 18:05, Andrew Morton wrote:
> > "Serge E. Hallyn" <serue@us.ibm.com> wrote:
> > > On my power5 partition, 2.6.15-mm4 hangs on boot
> >
> > It might be worth reverting the changes to arch/powerpc/mm/hash_utils_64.c,
> > see if that unbreaks it.
> >
> > - base = lmb.memory.region[i].base + KERNELBASE;
> > + base = (unsigned long)__va(lmb.memory.region[i].base);
>
> You can try it, but if that fixes the problem I'll buy a sombrero and then eat
> it.

Sounds unpleasant, but no need - that didn't fix it.

> > The nice comment in page.h:
> >
> > * KERNELBASE is the virtual address of the start of the kernel, it's often
> > * the same as PAGE_OFFSET, but _might not be_.
> > *
> > * The kdump dump kernel is one example where KERNELBASE != PAGE_OFFSET.
> > *
> > * To get a physical address from a virtual one you subtract PAGE_OFFSET,
> > * _not_ KERNELBASE.
> >
> > Tells us that was not an equivalent transformation.
>
> True, not equivalent in all cases, but correct. For non-kdump kernels (which I
> assume this is) KERNELBASE == PAGE_OFFSET, and for a kdump kernel that code
> wants to use PAGE_OFFSET, not KERNELBASE.
>
> Try enabling early debugging (see arch/powerpc/kernel/setup_64.c) and then
> turning on DEBUG in hash_utils_64.c, setup_64.c etc.

That gives me the following output:

boot: quicktest
Please wait, loading kernel...
Elf64 kernel loaded...
OF stdout device is: /vdevice/vty@30000000
Hypertas detected, assuming LPAR !
command line: ro console=hvc0 root=/dev/sda6 smt-enabled=1
memory layout at init:
memory_limit : 0000000000000000 (16 MB aligned)
alloc_bottom : 0000000002223000
alloc_top : 0000000008000000
alloc_top_hi : 0000000088000000
rmo_top : 0000000008000000
ram_top : 0000000088000000
Looking for displays
instantiating rtas at 0x00000000077d7000 ... done
0000000000000000 : boot cpu 0000000000000000
0000000000000002 : starting cpu hw idx 0000000000000002... done
0000000000000004 : starting cpu hw idx 0000000000000004... done
0000000000000006 : starting cpu hw idx 0000000000000006... done
copying OF device tree ...
Building dt strings...
Building dt structure...
Device tree strings 0x0000000002424000 -> 0x0000000002424f36
Device tree struct 0x0000000002425000 -> 0x000000000242c000
Calling quiesce ...
returning from prom_init
-> early_setup()
Probing machine type for platform 101...
Found, Initializing memory management...
-> htab_initialize()
creating mapping for region: c000000000000000 : 88000000
<- htab_initialize()
<- early_setup()
-> setup_system()
-> initialize_cache_info()
<- initialize_cache_info()
Page orders: linear mapping = 24, others = 12
-> smp_release_cpus()
<- smp_release_cpus()
<- setup_system()

So setup_system() at least finishes, though I don't see the
printk's at the bottom of that function.

thanks,
-serge
-
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/

\
 
 \ /
  Last update: 2006-01-18 15:46    [W:0.161 / U:0.368 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site