This patch series adds kdump support on arm64.
To load a crash-dump kernel to the systems, a series of patches to
kexec-tools[1] are also needed. Please use the latest one, v6 [2].
For your convinience, you can pick them up from:
https://git.linaro.org/people/takahiro.akashi/linux-aarch64.git a
On Wed, 2017-03-15 at 18:56 +0900, AKASHI Takahiro wrote:
> This patch series adds kdump support on arm64.
>
> To load a crash-dump kernel to the systems, a series of patches to
> kexec-tools[1] are also needed. Please use the latest one, v6 [2].
> For your convinience, you can pick them up from:
On Wed, Mar 15, 2017 at 11:41:18AM +, David Woodhouse wrote:
> On Wed, 2017-03-15 at 18:56 +0900, AKASHI Takahiro wrote:
> > This patch series adds kdump support on arm64.
> >
> > To load a crash-dump kernel to the systems, a series of patches to
> > kexec-tools[1] are also needed. Please use
On Thu, 2017-03-16 at 09:23 +0900, AKASHI Takahiro wrote:
>
> I double-checked but saw no warnings like these neither for v32 nor v33.
> I'm afraid that you might have done something wrong in backporting,
> particularly patch#5.
Then I apologise for the noise. Thanks for checking.
smime.p7s
Desc
On Wed, 2017-03-15 at 18:56 +0900, AKASHI Takahiro wrote:
> This patch series adds kdump support on arm64.
>
> To load a crash-dump kernel to the systems, a series of patches to
> kexec-tools[1] are also needed. Please use the latest one, v6 [2].
> For your convinience, you can pick them up from:
On Fri, 2017-03-17 at 11:43 +, David Woodhouse wrote:
>
> Is this one going to be be my fault too?
Looks like it isn't my fault. In ipi_cpu_crash_stop() we don't modify
the online mask. Which is reasonable enough if we want to preserve its
original contents from before the crash, but it does
On Fri, Mar 17, 2017 at 02:02:53PM +, David Woodhouse wrote:
> On Fri, 2017-03-17 at 11:43 +, David Woodhouse wrote:
> >
> > Is this one going to be be my fault too?
>
> Looks like it isn't my fault. In ipi_cpu_crash_stop() we don't modify
> the online mask. Which is reasonable enough if
On Fri, Mar 17, 2017 at 02:02:53PM +, David Woodhouse wrote:
> On Fri, 2017-03-17 at 11:43 +, David Woodhouse wrote:
> >
> > Is this one going to be be my fault too?
>
> Looks like it isn't my fault. In ipi_cpu_crash_stop() we don't modify
> the online mask. Which is reasonable enough if
On Fri, Mar 17, 2017 at 03:47:08PM +, David Woodhouse wrote:
> On Fri, 2017-03-17 at 15:33 +, Mark Rutland wrote:
> No, in this case the CPUs *were* offlined correctly, or at least "as
> designed", by smp_send_crash_stop(). And if that hadn't worked, as
> verified by *its* synchronisation m
On 17/03/17 16:24, Mark Rutland wrote:
> On Fri, Mar 17, 2017 at 03:47:08PM +, David Woodhouse wrote:
>> On Fri, 2017-03-17 at 15:33 +, Mark Rutland wrote:
>> No, in this case the CPUs *were* offlined correctly, or at least "as
>> designed", by smp_send_crash_stop(). And if that hadn't work
On 17/03/17 16:59, Marc Zyngier wrote:
> On 17/03/17 16:24, Mark Rutland wrote:
>> On Fri, Mar 17, 2017 at 03:47:08PM +, David Woodhouse wrote:
>>> On Fri, 2017-03-17 at 15:33 +, Mark Rutland wrote:
>>> No, in this case the CPUs *were* offlined correctly, or at least "as
>>> designed", by s
On Wednesday 15 March 2017 03:26 PM, AKASHI Takahiro wrote:
This patch series adds kdump support on arm64.
To load a crash-dump kernel to the systems, a series of patches to
kexec-tools[1] are also needed. Please use the latest one, v6 [2].
For your convinience, you can pick them up from:
h
On Fri, Mar 17, 2017 at 04:24:21PM +, Mark Rutland wrote:
> On Fri, Mar 17, 2017 at 03:47:08PM +, David Woodhouse wrote:
> > On Fri, 2017-03-17 at 15:33 +, Mark Rutland wrote:
> > No, in this case the CPUs *were* offlined correctly, or at least "as
> > designed", by smp_send_crash_stop(
I tested this patch set on a QDT2400 device with 4k 4-level setup. This
patchset worked fine with maxcpus=1 on the first kernel.
I don't think this is an issue with the patchset, I am still triaging this
issue further.
On 3/15/2017 3:56 AM, AKASHI Takahiro wrote:
> This patch series adds kdump
On Tue, 2017-03-21 at 16:34 +0900, AKASHI Takahiro wrote:
> Yes, it is intentional. I removed 'offline' code in my v14 (2016/3/4).
> As you assumed, I'd expect 'online' status of all CPUs to be kept
> unchanged in the core dump.
I wonder if it would be better to take a *copy* of it and put it back
On Fri, 2017-03-17 at 15:33 +, Mark Rutland wrote:
>
> We can certainly log a better message, e.g.
>
> bool kdump = (image == kexec_crash_image);
> bool stuck_cpus = cpus_are_stuck_in_kernel() ||
> num_online_cpus() > 1;
>
> BUG_ON(st
On Fri, 2017-03-17 at 17:10 +, Marc Zyngier wrote:
>
> > > >
> > > > FWIW if I trigger a crash on CPU 1 my kdump (still 4.9.8+v32) doesn't
> > > > work.
> > > > I end up booting the kdump kernel on CPU#1 and then it gets distinctly
> > > > unhappy...
> > > >
> > > > [0.00] Booting
17 matches
Mail list logo
