linux-mips
[Top] [All Lists]

Re: Toshiba JMR 3927 working setup?

To: linux-mips@linux-mips.org
Subject: Re: Toshiba JMR 3927 working setup?
From: Gregor Waltz <gregor.waltz@raritan.com>
Date: Thu, 17 Jan 2008 11:50:32 -0500
In-reply-to: <20080117.010459.51867104.anemo@mba.ocn.ne.jp>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <478D121C.4020701@raritan.com> <20080115231421.GB9767@networkno.de> <478E22A4.4070604@raritan.com> <20080117.010459.51867104.anemo@mba.ocn.ne.jp>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Thunderbird 1.5.0.10 (X11/20070403)
Atsushi Nemoto wrote:
Hmm.  The puts() in arch/mips/jmr3927/common/puts.c looks usable even
on kernel entry.  You can verify if it can really be used on
start_kernel(), then start tracking down the problem.

---
Atsushi Nemoto

puts() has helped, but I wish that I had something to dump the stack. Is kgdb easy to set up?

In main.c, init_IRQ() eventually uses kmalloc:
arch_init_irq() -> txx9_irq_init() -> ioremap() -> __get_vm_area_node() -> kmalloc_node()... malloc_sizes is not yet initialized, though, which means that cs_cachep is zero for all entries. My system reboots when it reaches cpu_cache_get() in mm/slab.c where cachep is zero.

It seems to me that kmem_cache_init() ought to be run before any kmallocs. kmem_cache_init() seems to require mem_init(). After I moved mem_init and kmem_cache_init before init_IRQ(), it gets down to pidhash_init() before rebooting, which I am looking into now.


What ought to be done to fix the init_IRQ()/kmalloc problem?

Thanks

<Prev in Thread] Current Thread [Next in Thread>