* kexec on panic
@ 2017-02-10 8:14 Denys Fedoryshchenko
2017-02-18 7:42 ` Jon Masters
0 siblings, 1 reply; 3+ messages in thread
From: Denys Fedoryshchenko @ 2017-02-10 8:14 UTC (permalink / raw)
To: linux-kernel, kexec
Hello,
After years of using kexec and recent unpleasant experience with modern
(supposed to be blazing fast to boot) hardware that need 5-10 minutes
just to pass POST tests,
one question came up to me:
Is it possible anyhow to execute regular (not special "panic" one to
capture crash data) kexec on panic to reduce reboot time?
Thanks!
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: kexec on panic
2017-02-10 8:14 kexec on panic Denys Fedoryshchenko
@ 2017-02-18 7:42 ` Jon Masters
2017-02-18 8:09 ` Denys Fedoryshchenko
0 siblings, 1 reply; 3+ messages in thread
From: Jon Masters @ 2017-02-18 7:42 UTC (permalink / raw)
To: Denys Fedoryshchenko, linux-kernel, kexec
Hi Denys,
On 02/10/2017 03:14 AM, Denys Fedoryshchenko wrote:
> After years of using kexec and recent unpleasant experience with modern (supposed to be blazing fast to boot) hardware that need 5-10 minutes just to pass POST tests,
> one question came up to me:
> Is it possible anyhow to execute regular (not special "panic" one to capture crash data) kexec on panic to reduce reboot time?
Generally, you don't want to do this, because various platform hardware
might be in non-quiescent states (still doing DMA to random memory, etc.)
and other nastiness that means you don't want to do more than the minimal
amount in a kexec on panic (crash). We've seen no end of fun and games
even with just regular crash dumps while hardware is busily writing to
memory that it shouldn't be. An IOMMU helps, but isn't a cure-all.
Jon.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: kexec on panic
2017-02-18 7:42 ` Jon Masters
@ 2017-02-18 8:09 ` Denys Fedoryshchenko
0 siblings, 0 replies; 3+ messages in thread
From: Denys Fedoryshchenko @ 2017-02-18 8:09 UTC (permalink / raw)
To: Jon Masters; +Cc: linux-kernel, kexec
On 2017-02-18 09:42, Jon Masters wrote:
> Hi Denys,
>
> On 02/10/2017 03:14 AM, Denys Fedoryshchenko wrote:
>
>> After years of using kexec and recent unpleasant experience with
>> modern (supposed to be blazing fast to boot) hardware that need 5-10
>> minutes just to pass POST tests,
>> one question came up to me:
>> Is it possible anyhow to execute regular (not special "panic" one to
>> capture crash data) kexec on panic to reduce reboot time?
>
> Generally, you don't want to do this, because various platform hardware
> might be in non-quiescent states (still doing DMA to random memory,
> etc.)
> and other nastiness that means you don't want to do more than the
> minimal
> amount in a kexec on panic (crash). We've seen no end of fun and games
> even with just regular crash dumps while hardware is busily writing to
> memory that it shouldn't be. An IOMMU helps, but isn't a cure-all.
>
> Jon.
Well, i have to try, even sometimes i am facing issues with non-booting
hardware even on regular kexec, but having at small customer HP server
that need almost 6 minutes to boot,
no hot-spare(and hard to do by many reasons, no spare 10G ports, cost of
hardware and etc) and some nasty bugs that is not resolved yet - forcing
me to search way to reduce reboot time.
If i will find way to save backtrace and reboot fast, it will help a lot
to debug kernels with minimal downtime, if bug is reproducible only on
live system.
What i did now, might be insanely wrong, but:
diff -Naur linux-4.9.9-vanilla/kernel/kexec_core.c
linux-4.9.9/kernel/kexec_core.c
--- linux-4.9.9-vanilla/kernel/kexec_core.c 2017-02-09
07:08:40.000000000 +0000
+++ linux-4.9.9/kernel/kexec_core.c 2017-02-17 12:54:49.000000000 +0000
@@ -897,6 +897,10 @@
machine_crash_shutdown(&fixed_regs);
machine_kexec(kexec_crash_image);
}
+ if (kexec_image) {
+ machine_shutdown();
+ machine_kexec(kexec_image);
+ }
mutex_unlock(&kexec_mutex);
}
}
Then
kexec -l /mnt/flash/kernel --append="intel_idle.max_cstate=0
processor.max_cstate=1"
and
echo c >/proc/sysrq-trigger
worked even on busy network router, but i'm not sure it will be same on
real networking stack crash.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2017-02-18 8:56 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-02-10 8:14 kexec on panic Denys Fedoryshchenko
2017-02-18 7:42 ` Jon Masters
2017-02-18 8:09 ` Denys Fedoryshchenko
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).