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

[Guenter Roeck <linux@roeck-us.net>]

On 09/18/2014 01:52 AM, Jesper Nilsson wrote:
> 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.
>

I just sent the series. My suspicion is that you might have some
relevant changes in architecture code which never made it upstream.

Guenter