Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1222423 > unrolled thread

Re: [PATCH v4 5/7] Watchdog: introduce ARM SBSA watchdog driver

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v4 5/7] Watchdog: introduce ARM SBSA watchdog driver Jon Masters <jcm@redhat.com> - 2015-09-11 00:50 +0200
    Re: [PATCH v4 5/7] Watchdog: introduce ARM SBSA watchdog driver Pratyush Anand <panand@redhat.com> - 2015-09-14 06:30 +0200
      Re: [PATCH v4 5/7] Watchdog: introduce ARM SBSA watchdog driver Fu Wei <fu.wei@linaro.org> - 2015-09-14 17:30 +0200
    Re: [PATCH v4 5/7] Watchdog: introduce ARM SBSA watchdog driver Catalin Marinas <catalin.marinas@arm.com> - 2015-09-14 11:00 +0200
    Re: [PATCH v4 5/7] Watchdog: introduce ARM SBSA watchdog driver Fu Wei <fu.wei@linaro.org> - 2015-09-15 05:20 +0200

#1222423 — Re: [PATCH v4 5/7] Watchdog: introduce ARM SBSA watchdog driver

On 06/03/2015 02:53 PM, Timur Tabi wrote:
> On 06/03/2015 01:25 PM, Guenter Roeck wrote:
>> 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.
> 
> What is the mechanism for resetting the watchdog?  The only code that 
> knows about the hardware registers is this driver.  Does the crashdump 
> kernel call the watchdog stop function?
> 
>> 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).

Just to go back and explicitly answer this, arm64 does have support for
crashdump, using the standard kexec/kdump approach, exactly as on x86.
There's still some more work to be done to get the ACPI case fully
upstream (e.g. on X-Gene platforms such as the HP ProLiant Moonshot m400
we need non-PSCI CPU parking protocol offlining when booting in
UEFI/ACPI mode), but it's what we are doing in RHEL(SA) and the goal is
to help clean up the remaining pieces upstream there.

Jon.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1223830

On 10/09/2015:06:45:17 PM, Jon Masters wrote:
> On 06/03/2015 02:53 PM, Timur Tabi wrote:
> > On 06/03/2015 01:25 PM, Guenter Roeck wrote:
> >> 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.

And this is what we do in fedora or RHEL. There had been some work ongoing in
fedora [1][2] which will help to reset any active watchdog in kdump kernel(if
the watchdog driver has been registered to watchdog_class). It will eventually
help a watchdog on ARM64 platform as well.

[1] https://lists.fedoraproject.org/pipermail/kexec/2015-September/002295.html
[2] https://github.com/pratyushanand/kexec-tools/commits/watchdog_fmaster

~Pratyush
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1224247

Hi Pratyush,

Great thanks for your help on some update for watchdog framework.

For " Fix parent of watchdog_devices", I will update my patchset.
For the upstreaming patchset"Sysfs status read support", will make a
patch. But upstream it when your patchset is merged.

On 14 September 2015 at 12:21, Pratyush Anand <panand@redhat.com> wrote:
> On 10/09/2015:06:45:17 PM, Jon Masters wrote:
>> On 06/03/2015 02:53 PM, Timur Tabi wrote:
>> > On 06/03/2015 01:25 PM, Guenter Roeck wrote:
>> >> 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.
>
> And this is what we do in fedora or RHEL. There had been some work ongoing in
> fedora [1][2] which will help to reset any active watchdog in kdump kernel(if
> the watchdog driver has been registered to watchdog_class). It will eventually
> help a watchdog on ARM64 platform as well.
>
> [1] https://lists.fedoraproject.org/pipermail/kexec/2015-September/002295.html
> [2] https://github.com/pratyushanand/kexec-tools/commits/watchdog_fmaster
>
> ~Pratyush



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1223936

On Thu, Sep 10, 2015 at 06:45:17PM -0400, Jon Masters wrote:
> On 06/03/2015 02:53 PM, Timur Tabi wrote:
> > On 06/03/2015 01:25 PM, Guenter Roeck wrote:
> >> 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.
> > 
> > What is the mechanism for resetting the watchdog?  The only code that 
> > knows about the hardware registers is this driver.  Does the crashdump 
> > kernel call the watchdog stop function?
> > 
> >> 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).
> 
> Just to go back and explicitly answer this, arm64 does have support for
> crashdump, using the standard kexec/kdump approach, exactly as on x86.

Just a clarification - this is not (yet) supported in mainline, not even
with DT.

-- 
Catalin

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1224616

Hi Jon,

On 11 September 2015 at 06:45, Jon Masters <jcm@redhat.com> wrote:
> On 06/03/2015 02:53 PM, Timur Tabi wrote:
>> On 06/03/2015 01:25 PM, Guenter Roeck wrote:
>>> 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.
>>
>> What is the mechanism for resetting the watchdog?  The only code that
>> knows about the hardware registers is this driver.  Does the crashdump
>> kernel call the watchdog stop function?
>>
>>> 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).
>
> Just to go back and explicitly answer this, arm64 does have support for
> crashdump, using the standard kexec/kdump approach, exactly as on x86.
> There's still some more work to be done to get the ACPI case fully
> upstream (e.g. on X-Gene platforms such as the HP ProLiant Moonshot m400
> we need non-PSCI CPU parking protocol offlining when booting in
> UEFI/ACPI mode), but it's what we are doing in RHEL(SA) and the goal is
> to help clean up the remaining pieces upstream there.

Great thanks for your info.

I have tried kexec/kdump on a real aarch64 hardware, that works well.
Although it's still under development and upstreaming, the support is there.

After discussing with some kexec/kdump  developer, I think this driver
can cooperate with kexec/kdump.

>
> Jon.
>



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web