Re: Status of 'cris' architecture support in Linux kernel

[Jesper Nilsson]

On Wed, Sep 17, 2014 at 09:07:53PM +0200, Guenter Roeck wrote:
> Just to give you an update. I "kind of" got an image to run with qemu
> after applying the following patches.
> 
> 8119d33 cris: Add basic qemu_defconfig
> 40d078b cris: time.c: Add missing include file to fix compile error
> a4f2390 cris: Add dummy free_initrd_mem
> 88585aa cris: Add serial driver for Cris v32
> a38d868 cris: Add support for early console
> 
> Let me know if you would like a copy of those patches. Out of those, 40d078b,
> a4f2390, and a38d868 should be pretty much acceptable for upstream integration.
> 88585aa would need a lot of work (and probably a rewrite).

Yes please, that would be helpful.

> Compiler version is 4.7.4; 4.9.1 builds even after applying a number of upstream
> patches, but the resulting image hangs. The weekly gcc snapshot fails to build.
> 
> The configuration is (I believe) derived from the configuration used for the
> image available from the qemu web site. The same is true for the crisv32
> serial driver and early console support. time.c needed an additional include
> file (<linux/mm.h>). free_initrd_mem is needed to be able to build an image
> with initrd support; it currently does nothing.
> 
> With this, I am able to get into a shell using a built-in initrd.
> 
> / # uname -a
> Linux (none) 3.16.2-00005-g8119d33 #40 Wed Sep 17 11:49:31 PDT 2014 crisv32 GNU/Linux
> 
> However, I see the following traceback.
> 
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 186 at kernel/softirq.c:146 0xc000fd72()
> Modules linked in:
> CPU: 0 PID: 186 Comm: init Not tainted 3.16.2-00005-g8119d33 #40
> 
> Stack from c1cf9eb0:
>        00000000 c02569d0 00000009 c0279f80 c1fda770 c1fa3680 c02574d6 c000cbb8
>        00000092 c000fd72 00000200 c02d0d94 00000000 00000000 c000fd72 00000092
>        c000cbea 00000000 c000fd72 c1f862d2 c1cdbc20 c01ff768 c1f862d2 c1f862d6
> Call Trace: [<c02569d0>] [<c02574d6>] [<c000cbb8>] [<c000fd72>] [<c000fd72>] [<c000cbea>] [<c000fd72>]
>        [<c01ff768>] [<c01ff908>] [<c016f83c>] [<c016fb10>] [<c006cfc0>] [<c025855a>] [<c006d0f4>] [<c001f212>]
>        [<c0004b80>] [<c00054f0>]
> ---[ end trace 5bb306335a1f3b62 ]---
> 
> Manual symbol decode (this is from a 3.10 traceback, so the addresses
> are a bit different):
> 
> c0234d8a	printk
> c0012b0e	local_bh_enable
> c0236004	dump_stack
> c000ca4a	warn_slowpath_common
> c000ca78	warn_slowpath_null
> c0012b0e	local_bh_enable
> c01e3c16	unix_release_sock
> c01e3dae	unix_release
> c015fb9a	sock_release
> c015fe68	sock_close
> c0067fae	__fput
> c0237a20	_cond_resched
> c0068168	____fput
> c0022062	task_work_run
> c0004954	do_notify_resume
> c0005324	_work_notifysig


I'm not sure if this has happened here, but please note that
some of the symbols in the stack backtrace might be false,
since the CRIS does not have true stack unwinding,
the backtrace code only checks the stack for any
pointers in the kernel address space and reports them too.

> --> Further debugging shows that interrupts are disabled when this happens.
> 
> This traceback is seen from 3.10 onwards. 3.4 did not show the traceback; I did
> not test any releases in between.

Ok thanks, will try to reproduce here.

> Guenter

/^JN - Jesper Nilsson
-- 
               Jesper Nilsson -- jesper.nilsson@xxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/