linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Christophe LEROY <christophe.leroy@c-s.fr>
To: Guenter Roeck <linux@roeck-us.net>,
	Michael Ellerman <mpe@ellerman.id.au>
Cc: linux-kernel@vger.kernel.org,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	linuxppc-dev@lists.ozlabs.org, Paul Mackerras <paulus@samba.org>
Subject: Re: Traceback due to 'powerpc/mm: Fix kernel RAM protection...' when running ppc image in qemu
Date: Thu, 21 Sep 2017 20:44:32 +0200	[thread overview]
Message-ID: <41b8af14-ada8-448f-5da7-92640ea8c3e7@c-s.fr> (raw)
In-Reply-To: <daaad0c4-75af-4b02-20d0-b0b8e327f94a@roeck-us.net>



Le 20/09/2017 à 05:45, Guenter Roeck a écrit :
> On 09/19/2017 08:05 PM, Michael Ellerman wrote:
>> Guenter Roeck <linux@roeck-us.net> writes:
>>
>>> Hi,
>>>
>>> I see a the following traceback when running an SMP image based on
>>> 85xx/mpc85xx_cds_defconfig in qemu.
>>>
>>> ------------[ cut here ]------------
>>> WARNING: CPU: 0 PID: 1 at kernel/smp.c:416 
>>> smp_call_function_many+0xcc/0x2fc
>>> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.14.0-rc1-00009-g0666f56 #1
>>> task: cf830000 task.stack: cf82e000
>>> NIP:  c00a93c8 LR: c00a9634 CTR: 00000001
>>> REGS: cf82fde0 TRAP: 0700   Not tainted  (4.14.0-rc1-00009-g0666f56)
>>> MSR:  00021000 <CE,ME>  CR: 24000082  XER: 00000000
>>>
>>> GPR00: c00a9634 cf82fe90 cf830000 c050ad3c c0015a54 00000000 00000001 
>>> 00000001
>>> GPR08: 00000001 00000000 00000000 cf82e000 24000084 00000000 c0003150 
>>> 00000000
>>> GPR16: 00000000 00000000 00000000 00000000 00000000 00000001 00000000 
>>> c0510000
>>> GPR24: 00000000 c0015a54 00000000 c050ad3c c051823c c050ad3c 00000025 
>>> 00000000
>>> NIP [c00a93c8] smp_call_function_many+0xcc/0x2fc
>>> LR [c00a9634] smp_call_function+0x3c/0x50
>>> Call Trace:
>>> [cf82fe90] [00000010] 0x10 (unreliable)
>>> [cf82fed0] [c00a9634] smp_call_function+0x3c/0x50
>>> [cf82fee0] [c0015d2c] flush_tlb_kernel_range+0x20/0x38
>>> [cf82fef0] [c001524c] mark_initmem_nx+0x154/0x16c
>>> [cf82ff20] [c001484c] free_initmem+0x20/0x4c
>>> [cf82ff30] [c000316c] kernel_init+0x1c/0x108
>>> [cf82ff40] [c000f3a8] ret_from_kernel_thread+0x5c/0x64
>>> Instruction dump:
>>> 7c0803a6 7d808120 38210040 4e800020 3d20c052 812981a0 2f890000 40beffac
>>> 3d20c051 8929ac64 2f890000 40beff9c <0fe00000> 4bffff94 7fc3f378 
>>> 7f64db78
>>> ---[ end trace 7da7bdcf8b15ddb3 ]---
>>
>> Thanks.
>>
>> I guess the system still runs OK otherwise, you're just seeing the 
>> warning?
>>
> Yes, though I am not sure if that is because there is only one active 
> CPU (there is
> still only one if I say "-smp 4" on the qemu command line).
> 
>>> A complete log is available at:
>>> http://kerneltests.org/builders/qemu-ppc-master/builds/814/steps/qemubuildcommand/logs/stdio 
>>>
>>>
>>> Bisect points to commit 3184cc4b6f6a1dc0 ("powerpc/mm: Fix kernel RAM 
>>> protection
>>> after freeing unused memory on PPC32"). Bisect log is attached. A 
>>> quick look
>>> suggests that mark_initmem_nx() is called with interrupts disabled, 
>>> which
>>> triggers the traceback.
>>
>> Hmm. Yes the MSR says you have interrupts disabled (EE missing).
>>
>> But I don't see why. start_kernel() did local_irq_enable(), so I don't
>> understand why we got to mark_initmem_nx() with them disabled. I'll hope
>> that Christophe has some idea.
>>
> Good question. I only see this with one of 9 ppc emulations, with 
> 85xx/mpc85xx_cds_defconfig
> +CONFIG_DEVTMPFS=y +CONFIG_SMP=y. Maybe there is a platform specific 
> init function
> which leaves interrupts disabled. Question is which one that might be.
> 

Unfortunatly no, I have no idea. My three platforms (860, 885 and 8321) 
are not SMPs so that warning would not appear, but I added a WARN_ON(1) 
just become calling mark_initmem_nx(), and I can confirm that MSR has EE 
set on all three at that time.

So as you suggest, there must be a platform specific stuff leaving the 
interrupts disabled.

Christophe


> Guenter

  reply	other threads:[~2017-09-21 18:44 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-19 18:24 Traceback due to 'powerpc/mm: Fix kernel RAM protection...' when running ppc image in qemu Guenter Roeck
2017-09-20  3:05 ` Michael Ellerman
2017-09-20  3:45   ` Guenter Roeck
2017-09-21 18:44     ` Christophe LEROY [this message]
2017-09-24 16:05       ` Guenter Roeck
2017-09-25  6:36         ` Christophe LEROY

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=41b8af14-ada8-448f-5da7-92640ea8c3e7@c-s.fr \
    --to=christophe.leroy@c-s.fr \
    --cc=benh@kernel.crashing.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=paulus@samba.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).