Thread (41 messages) flat view 41 messages, 8 authors, 2017-03-27
STALE3420d

Revision v33 of 7 in this series.

Revisions (7)
  1. v33 [diff vs current]
  2. v33 [diff vs current]
  3. v33 [diff vs current]
  4. v33 [diff vs current]
  5. v33 [diff vs current]
  6. v33 [diff vs current]
  7. v33 current

[PATCH v33 00/14] add kdump support

From: dwmw2@infradead.org (David Woodhouse)
Date: 2017-03-21 09:42:23
Also in: kexec

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
after we're done taking the CPUs down? As things stand, we now have
*three* different methods of taking down all the CPUs... and *none* of
them allow a platform to override it with an NMI-based or STONITH-based 
method, which seems like something of an oversight.
If you can agree, I would like to modify this disputed warning code to:
?
+	BUG_ON(!in_kexec_crash && (stuck_cpus || (num_online_cpus() > 1)));
+	WARN(in_kexec_crash && (stuck_cpus || smp_crash_stop_failed()),
+		"Some CPUs may be stale, kdump will be unreliable.\n");
That works; thanks.

FWIW I'm currently blaming my platform's firmware for my sporadic
crash-on-CPU#1 failures. If your testing includes crashes on non-boot
CPUs (perhaps using the sysrq hack I posted) and it reliably passes for
you, then let's ignore that for now.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4938 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170321/3266da88/attachment-0001.bin>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help