[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150603182503.GD6460@roeck-us.net>
Date: Wed, 3 Jun 2015 11:25:03 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: Timur Tabi <timur@...eaurora.org>
Cc: fu.wei@...aro.org, Suravee.Suthikulpanit@....com,
linaro-acpi@...ts.linaro.org, linux-watchdog@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-doc@...r.kernel.org, tekkamanninja@...il.com,
graeme.gregory@...aro.org, al.stone@...aro.org,
hanjun.guo@...aro.org, ashwin.chaugule@...aro.org, arnd@...db.de,
vgandhi@...eaurora.org, wim@...ana.be, jcm@...hat.com,
leo.duran@....com, corbet@....net, mark.rutland@....com,
catalin.marinas@....com, will.deacon@....com, rjw@...ysocki.net
Subject: Re: [PATCH v4 5/7] Watchdog: introduce ARM SBSA watchdog driver
On Wed, Jun 03, 2015 at 01:16:41PM -0500, Timur Tabi wrote:
> On 06/01/2015 11:05 PM, fu.wei@...aro.org wrote:
> >+ if (wdd->pretimeout)
> >+ /* The pretimeout is valid, go panic */
> >+ panic("SBSA Watchdog pre-timeout");
>
> The problem with this is that WS1 will still occur. So a few seconds after
> the panic() call, the hardware will reset. There won't be any time to debug
> or log anything.
>
In general the idea here would be to use a crashdump kernel, which,
when loaded, would reset the watchdog before it fires. This kernel
would then write a core dump to a specified location.
If arm64 doesn't support a crashdump kernel, it might still be possible
to log the backtrace somewhere (eg in nvram using pstore if that is
supported via acpi or efi).
Is there reason to believe that this all won't work on arm64 ?
Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists