Re: Question on online/present/possible CPUS

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



----- "Jeffrey Hagen" <Jeffrey.Hagen@xxxxxxxxxxxx> wrote:

> Paranoia is usually a good thing in this industry and you know this code
> far better that I do...
> 
> For the older kernels that don't have cpu_present_map, if they still
> have the x8664_pda structure, the code my patch changes shouldn't get
> executed.  It's the deprecation of the x8664_pda structure (between
> SLES10 and SLES11 in our case) that exposes this issue.

True...

> 
> The setting of the other CPU's to offline (IPI REBOOT_VECTOR) is done in
> native_smp_send_stop [arch/x86/kernel/smp.c] called by panic().  Note
> that the SLES11 version of the 2.6.32 kernel allows calling
> crash_kexec() after calling  atomic_notifer_call_chain() in panic().

Ah-ha!  That makes sense -- I was under the impression that all of the
other distros would follow upstream with crash_kexec() being called
before, and therefore preventing, the subsequent smp_send_stop() call.

So given that this would happen whenever panic() gets called directly
in a SLES kernel, is the SLES version of the crash utility patched to do
something similar to your patch?  

Petr?
 
> The flow during an oops or keyboard induced crash does not use this same
> code.  In this case crash_kexec() is called by oops_end() which is
> called by die().

OK, I'm going to give your patch a run-through with ~150 or so x86_64 
dumpfiles I've kept as examples over the years, and see if anything
interesting happens.

Thanks Jeff,
  Dave

--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility


[Index of Archives]     [Fedora Development]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]

 

Powered by Linux