From: hauke@hauke-m•de (Hauke Mehrtens)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH v3 1/3] ARM: BCM5301X: initial support for the BCM5301X/BCM470X SoCs with ARM CPU
Date: Thu, 01 Aug 2013 23:51:06 +0200 [thread overview]
Message-ID: <51FAD84A.4070701@hauke-m.de> (raw)
In-Reply-To: <20130731103507.GF23681@mudshark.cambridge.arm.com>
On 07/31/2013 12:35 PM, Will Deacon wrote:
> On Tue, Jul 30, 2013 at 09:54:04PM +0100, Hauke Mehrtens wrote:
>> On 07/30/2013 03:36 PM, Will Deacon wrote:
>>> On Sat, Jul 27, 2013 at 08:49:16PM +0100, Arnd Bergmann wrote:
>>>> On Friday 26 July 2013, Will Deacon wrote:
>>>>>>> At least, we need a pretty good explanation of what exactly is causing
>>>>>>> these spurious aborts before we start ignoring them unconditionally like
>>>>>>> this. You're effectively masking an extremely serious error indicator with
>>>>>>> this change.
>>>>>>
>>>>>> This fault occurs once every boot sometime early in the boot process,
>>>>>> but the actual time this happens varies randomly.
>>>>>
>>>>> Well that's interesting in itself. It sounds like we don't know *for sure*
>>>>> whether the abort is triggered by Linux. Since the abort is imprecise, the
>>>>> timing will vary.
>>>>
>>>> It might be possible to find out the culprit if you just enter an endless loop
>>>> in the early kernel boot code. If you enter the loop before Linux does something
>>>> wrong, it won't crash, otherwise it will. After that, you could bisect the
>>>> boot process by moving the busy loop around.
>>>>
>>>> If it even crashes at the point where Linux gets entered, it's a bug in the
>>>> boot loader.
>>>
>>> Can you give Arnd's suggestion a go please Hauke?
>>
>> Hi
>>
>> I just tried that, but it did not crash in the loop. :-(
>
> Turn that frown around -- this is a useful result! It means that the abort
> is likely caused by the kernel, rather than the boot loader (although we
> still can't rule it out, it depends where you put the loop).
>
>> Now, with 3.11-rc3 it crashed reproducible after Freeing unused kernel
>> memory, see this:
>>
>> [ 0.859198] Freeing unused kernel memory: 1124K (c0260000 - c0379000)
>> [ 0.866298] Unhandled fault: imprecise external abort (0x1c06) at
>> 0xb6f8b005
>> [ 0.873538] Kernel panic - not syncing: Attempted to kill init!
>> exitcode=0x00000007
>>
>> Do you have some more informations about this type of error?
>
> Hmm, so that's now exploding on a user address. Is this an A9-based SoC? If
> so, can you try disabling PL310 (CONFIG_CACHE_L2X0) and see if it makes a
> different please?
This is a A9-based SoC.
I already had PL310 disabled, now I tried to activate it, but I do not
see any difference.
[ 1.049381] Freeing unused kernel memory: 1128K (c0261000 - c037b000)
[ 1.056501] Unhandled fault: imprecise external abort (0x1c06) at
0xb6f34005
[ 1.063738] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x00000007
Hauke
next prev parent reply other threads:[~2013-08-01 21:51 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-25 22:42 [PATCH v3 0/3] ARM: BCM5301X: initial support for the BCM5301X/BCM470X SoCs with ARM CPU Hauke Mehrtens
2013-07-25 22:42 ` [PATCH v3 1/3] " Hauke Mehrtens
2013-07-26 1:00 ` Domenico Andreoli
2013-07-26 8:55 ` Will Deacon
2013-07-26 14:39 ` Hauke Mehrtens
2013-07-26 16:53 ` Will Deacon
2013-07-27 19:49 ` Arnd Bergmann
2013-07-30 13:36 ` Will Deacon
2013-07-30 20:54 ` Hauke Mehrtens
2013-07-31 10:35 ` Will Deacon
2013-08-01 21:51 ` Hauke Mehrtens [this message]
2013-08-02 9:55 ` Will Deacon
2013-08-05 6:36 ` Afzal Mohammed
2013-07-25 22:42 ` [PATCH v3 2/3] ARM: BCM5301X: add early debugging support Hauke Mehrtens
2013-07-25 22:42 ` [PATCH v3 3/3] ARM: BCM5301X: add dts files for BCM4708 SoC Hauke Mehrtens
2013-07-26 1:01 ` Domenico Andreoli
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=51FAD84A.4070701@hauke-m.de \
--to=hauke@hauke-m$(echo .)de \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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