* Is OS_INFO_VMCOREINFO unimplemented? @ 2020-10-13 12:53 Petr Tesarik 2020-10-16 14:11 ` Philipp Rudo 0 siblings, 1 reply; 4+ messages in thread From: Petr Tesarik @ 2020-10-13 12:53 UTC (permalink / raw) To: linux-s390; +Cc: Michael Holzheu [-- Attachment #1: Type: text/plain, Size: 809 bytes --] Hi all, I've been looking into kernel crash dump analysis for some time now, and I've noticed that none of my sample dumps for z/Architecture sets OS_INFO_VMCOREINFO. Commit 4857d4bbe9821c8d732cb84455e18e12b3d79add suggests that the "os_info" structure should contain vmcoreinfo, but it seems that the corresponding fields are always zero, and a quick grep for OS_INFO_VMCOREINFO finds only code that tries to read this entry in the panic kernel, but no code that would initialize it in the old (crashed) kernel. In short, the panic kernel always prints an informational message that entry 0 is not available and falls back to get_vmcoreinfo_old(). Is this a bug, or is this interface used by a non-Linux operating system that I'm not aware of? TIA, Petr Tesarik SUSE HW Enablement [-- Attachment #2: =?unknown-8bit?q?Digit=C3=A1ln=C3=AD?= podpis OpenPGP --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Is OS_INFO_VMCOREINFO unimplemented? 2020-10-13 12:53 Is OS_INFO_VMCOREINFO unimplemented? Petr Tesarik @ 2020-10-16 14:11 ` Philipp Rudo 2020-10-16 15:24 ` Petr Tesarik 0 siblings, 1 reply; 4+ messages in thread From: Philipp Rudo @ 2020-10-16 14:11 UTC (permalink / raw) To: Petr Tesarik; +Cc: linux-s390, Michael Holzheu Hi Petr, sorry for the late reply. It's an interface for non-Linux systems for the stand-alone kdump. But that's all I'm sure of. I'm afraid only Michael knows the full history behind the implementation. Unfortunately he left IBM ~2 years ago so this piece of knowledge is lost... My theory is that originally it was planned to use this mechanism for the "normal" kdump as well. But for kdump common code "corrupts" the vmcoreinfo by adding the CRASHTIME shortly before kexec'ing the crash kernel. So the crash kernel would refuse to load the os_info anyway and thus it is never set. Hope this helps you at least a little Philipp On Tue, 13 Oct 2020 14:53:03 +0200 Petr Tesarik <ptesarik@suse.cz> wrote: > Hi all, > > I've been looking into kernel crash dump analysis for some time now, > and I've noticed that none of my sample dumps for z/Architecture sets > OS_INFO_VMCOREINFO. > > Commit 4857d4bbe9821c8d732cb84455e18e12b3d79add suggests that the > "os_info" structure should contain vmcoreinfo, but it seems that the > corresponding fields are always zero, and a quick grep for > OS_INFO_VMCOREINFO finds only code that tries to read this entry in the > panic kernel, but no code that would initialize it in the old (crashed) > kernel. > > In short, the panic kernel always prints an informational message that > entry 0 is not available and falls back to get_vmcoreinfo_old(). > > Is this a bug, or is this interface used by a non-Linux operating > system that I'm not aware of? > > TIA, > Petr Tesarik > SUSE HW Enablement ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Is OS_INFO_VMCOREINFO unimplemented? 2020-10-16 14:11 ` Philipp Rudo @ 2020-10-16 15:24 ` Petr Tesarik 2020-10-19 10:18 ` Philipp Rudo 0 siblings, 1 reply; 4+ messages in thread From: Petr Tesarik @ 2020-10-16 15:24 UTC (permalink / raw) To: Philipp Rudo; +Cc: linux-s390, Michael Holzheu [-- Attachment #1: Type: text/plain, Size: 2354 bytes --] Hi Philipp, On Fri, 16 Oct 2020 16:11:25 +0200 Philipp Rudo <prudo@linux.ibm.com> wrote: > Hi Petr, > > sorry for the late reply. No problem. ;-) > It's an interface for non-Linux systems for the stand-alone kdump. > > But that's all I'm sure of. I'm afraid only Michael knows the full history > behind the implementation. Unfortunately he left IBM ~2 years ago so this piece > of knowledge is lost... > > My theory is that originally it was planned to use this mechanism for the > "normal" kdump as well. But for kdump common code "corrupts" the vmcoreinfo by > adding the CRASHTIME shortly before kexec'ing the crash kernel. So the crash > kernel would refuse to load the os_info anyway and thus it is never set. Sure, the checksum would have to be recalculated after setting CRASHTIME. But that's perfectly possible. > Hope this helps you at least a little Yes, to some extent. The reason I asked was that I also implemented parsing of OS_INFO_VMCOREINFO in libkdumpfile a few years ago, but it has no test coverage. So, I looked around a bit and to my surprise all dump files contained a NULL pointer there, which looked somewhat suspicious. Anyway, if nobody knows for certain, then my plan is to add the necessary code to the Linux kernel. Patch coming soon on the mailing list. ;-) Thanks, Petr T > Philipp > > > On Tue, 13 Oct 2020 14:53:03 +0200 > Petr Tesarik <ptesarik@suse.cz> wrote: > > > Hi all, > > > > I've been looking into kernel crash dump analysis for some time now, > > and I've noticed that none of my sample dumps for z/Architecture sets > > OS_INFO_VMCOREINFO. > > > > Commit 4857d4bbe9821c8d732cb84455e18e12b3d79add suggests that the > > "os_info" structure should contain vmcoreinfo, but it seems that the > > corresponding fields are always zero, and a quick grep for > > OS_INFO_VMCOREINFO finds only code that tries to read this entry in the > > panic kernel, but no code that would initialize it in the old (crashed) > > kernel. > > > > In short, the panic kernel always prints an informational message that > > entry 0 is not available and falls back to get_vmcoreinfo_old(). > > > > Is this a bug, or is this interface used by a non-Linux operating > > system that I'm not aware of? > > > > TIA, > > Petr Tesarik > > SUSE HW Enablement [-- Attachment #2: =?unknown-8bit?q?Digit=C3=A1ln=C3=AD?= podpis OpenPGP --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Is OS_INFO_VMCOREINFO unimplemented? 2020-10-16 15:24 ` Petr Tesarik @ 2020-10-19 10:18 ` Philipp Rudo 0 siblings, 0 replies; 4+ messages in thread From: Philipp Rudo @ 2020-10-19 10:18 UTC (permalink / raw) To: Petr Tesarik; +Cc: linux-s390, Michael Holzheu Hi Petr, On Fri, 16 Oct 2020 17:24:19 +0200 Petr Tesarik <ptesarik@suse.cz> wrote: > Hi Philipp, > > On Fri, 16 Oct 2020 16:11:25 +0200 > Philipp Rudo <prudo@linux.ibm.com> wrote: > > > Hi Petr, > > > > sorry for the late reply. > > No problem. ;-) > > > It's an interface for non-Linux systems for the stand-alone kdump. > > > > But that's all I'm sure of. I'm afraid only Michael knows the full history > > behind the implementation. Unfortunately he left IBM ~2 years ago so this piece > > of knowledge is lost... > > > > My theory is that originally it was planned to use this mechanism for the > > "normal" kdump as well. But for kdump common code "corrupts" the vmcoreinfo by > > adding the CRASHTIME shortly before kexec'ing the crash kernel. So the crash > > kernel would refuse to load the os_info anyway and thus it is never set. > > Sure, the checksum would have to be recalculated after setting CRASHTIME. But that's perfectly possible. True. But it's not working out of the box and there's a working workaround. So let's live with the workaround and implement the proper solution at a later date. You know, the usual stuff... > > Hope this helps you at least a little > > Yes, to some extent. The reason I asked was that I also implemented parsing of OS_INFO_VMCOREINFO in libkdumpfile a few years ago, but it has no test coverage. So, I looked around a bit and to my surprise all dump files contained a NULL pointer there, which looked somewhat suspicious. > > Anyway, if nobody knows for certain, then my plan is to add the necessary code to the Linux kernel. Patch coming soon on the mailing list. ;-) Not to discourage you, but my long term goal was to remove the mechanism. Anyhow I'm willing to revisit this plan. You definitely got me curious :) Thanks Philipp > Thanks, > Petr T > > > Philipp > > > > > > On Tue, 13 Oct 2020 14:53:03 +0200 > > Petr Tesarik <ptesarik@suse.cz> wrote: > > > > > Hi all, > > > > > > I've been looking into kernel crash dump analysis for some time now, > > > and I've noticed that none of my sample dumps for z/Architecture sets > > > OS_INFO_VMCOREINFO. > > > > > > Commit 4857d4bbe9821c8d732cb84455e18e12b3d79add suggests that the > > > "os_info" structure should contain vmcoreinfo, but it seems that the > > > corresponding fields are always zero, and a quick grep for > > > OS_INFO_VMCOREINFO finds only code that tries to read this entry in the > > > panic kernel, but no code that would initialize it in the old (crashed) > > > kernel. > > > > > > In short, the panic kernel always prints an informational message that > > > entry 0 is not available and falls back to get_vmcoreinfo_old(). > > > > > > Is this a bug, or is this interface used by a non-Linux operating > > > system that I'm not aware of? > > > > > > TIA, > > > Petr Tesarik > > > SUSE HW Enablement > ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-10-19 10:18 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2020-10-13 12:53 Is OS_INFO_VMCOREINFO unimplemented? Petr Tesarik 2020-10-16 14:11 ` Philipp Rudo 2020-10-16 15:24 ` Petr Tesarik 2020-10-19 10:18 ` Philipp Rudo
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox