From: m-karicheri2@ti•com (Murali Karicheri)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH] ARM: keystone: add a work around to handle asynchronous external abort
Date: Tue, 18 Aug 2015 16:25:44 -0400 [thread overview]
Message-ID: <55D394C8.7070605@ti.com> (raw)
In-Reply-To: <20150818081334.GK7557@n2100.arm.linux.org.uk>
Russell,
On 08/18/2015 04:13 AM, Russell King - ARM Linux wrote:
> On Mon, Aug 17, 2015 at 08:09:17PM -0700, santosh.shilimkar at oracle.com wrote:
>> From the logs this seems to be mostly clock related issue for some
>> peripheral. If the bootloader clock enable all hack still exists,
>> may be you can try that out.
>>
>> Another way to debug this is to start disabling peripheral drivers
>> from the kernel 1 by 1 and see if the issue goes away.
>
> Highly unlikely to make any difference. As the failure happens soo early
> with the patch applied, the kernel hasn't had much of a chance to touch
> the hardware - about the only things are the decompressor and the kernel
> touching the early console. As they seem to be working, it suggests
> that's not the cause.
>
> It seems to be pointing towards something in the boot loader...
>
> Normally, uboot will hook itself into the vectors to report errors, but
> I wonder whether uboot enables asynchronous aborts while it's running.
> Don't forget to make sure that the aborts are disabled again prior to
> calling the kernel.
>
Thanks for your input.
The patch works now once I move the local_abort_enable() to later just
before calling reserve_crashkernel() in setup_arch(). The abort handler
gets called right after enabling it which means it has happened even
before reaching here.
I have added the abort handler to u-boot code and I get the same abort
which means the root cause is u-boot or ROM boot loader. I would try to
debug if root cause is u-boot. If it is ROM boot loader, I will have to
add a work around in u-boot or Linux. Is there a preference of one over
the other? The exception handling in u-boot is premature and will
require more work to add a work around. Is there still a possibility of
adding the work around in Linux?
--
Murali Karicheri
Linux Kernel, Keystone
next prev parent reply other threads:[~2015-08-18 20:25 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-11 19:13 [PATCH] ARM: keystone: add a work around to handle asynchronous external abort Murali Karicheri
2015-08-14 14:04 ` Murali Karicheri
2015-08-14 14:09 ` Russell King - ARM Linux
2015-08-14 14:20 ` Lucas Stach
2015-08-14 21:55 ` Murali Karicheri
2015-08-14 21:56 ` Russell King - ARM Linux
2015-08-17 14:09 ` Murali Karicheri
2015-08-14 15:14 ` santosh shilimkar
2015-08-14 21:53 ` Murali Karicheri
2015-08-14 21:56 ` Russell King - ARM Linux
2015-08-17 22:12 ` Murali Karicheri
2015-08-17 22:47 ` Russell King - ARM Linux
2015-08-18 3:09 ` santosh.shilimkar at oracle.com
2015-08-18 8:13 ` Russell King - ARM Linux
2015-08-18 8:28 ` Lucas Stach
2015-08-18 12:06 ` Afzal Mohammed
2015-08-18 8:28 ` Jisheng Zhang
2015-08-18 14:49 ` Murali Karicheri
2015-08-18 20:25 ` Murali Karicheri [this message]
2015-08-15 0:01 ` santosh.shilimkar at oracle.com
2015-08-14 14:11 ` Lucas Stach
2015-08-17 14:11 ` Murali Karicheri
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=55D394C8.7070605@ti.com \
--to=m-karicheri2@ti$(echo .)com \
--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