Page MenuHomeFreeBSD

Enable kernel dump options on most architectures.
ClosedPublic

Authored by markj on May 17 2018, 5:22 PM.

Details

Test Plan

Will do a tinderbox build.

Diff Detail

Repository
rS FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

markj created this revision.May 17 2018, 5:22 PM
markj edited the test plan for this revision. (Show Details)May 17 2018, 5:22 PM
cem accepted this revision.May 17 2018, 5:58 PM
This revision is now accepted and ready to land.May 17 2018, 5:58 PM
manu added a comment.May 17 2018, 7:54 PM

It seems that dump on arm64 currently doesn't work so I can't say if any of this options will be a benefit or not on this platform.

markj added a comment.May 17 2018, 7:57 PM
In D15465#326427, @manu wrote:

It seems that dump on arm64 currently doesn't work so I can't say if any of this options will be a benefit or not on this platform.

Hopefully that'll be fixed before 12.0?

Can we not split KDB and DDB with NETDUMP?
Ie, put it after the options MALLOC_DEBUG_MAXZONES=8 # Separate malloc(9) zones
would keep all the KDB, GDB, DDB, etc in one lump, followed by dumping stuff, perhaps with one line of white space

markj added a comment.May 17 2018, 8:36 PM

Can we not split KDB and DDB with NETDUMP?
Ie, put it after the options MALLOC_DEBUG_MAXZONES=8 # Separate malloc(9) zones
would keep all the KDB, GDB, DDB, etc in one lump, followed by dumping stuff, perhaps with one line of white space

Wouldn't that make it look like the "turn off in stable branch" comment applies to the new options? Or am I misunderstanding your suggestion?

Can we not split KDB and DDB with NETDUMP?
Ie, put it after the options MALLOC_DEBUG_MAXZONES=8 # Separate malloc(9) zones
would keep all the KDB, GDB, DDB, etc in one lump, followed by dumping stuff, perhaps with one line of white space

Wouldn't that make it look like the "turn off in stable branch" comment applies to the new options? Or am I misunderstanding your suggestion?

That would be a good reason to seperate it with a blank line. Why I am asking to move it this seems to split the "Debugging Support" and "Full Debugging Support" part of the config with the "Dump". I suppose one could say that dump is part of debugging support, but I think dump as more of a post failure analysis tool, rather than KDB/DDB/GDB which are active online debugging support.

markj added a comment.May 17 2018, 9:46 PM

Can we not split KDB and DDB with NETDUMP?
Ie, put it after the options MALLOC_DEBUG_MAXZONES=8 # Separate malloc(9) zones
would keep all the KDB, GDB, DDB, etc in one lump, followed by dumping stuff, perhaps with one line of white space

Wouldn't that make it look like the "turn off in stable branch" comment applies to the new options? Or am I misunderstanding your suggestion?

That would be a good reason to seperate it with a blank line. Why I am asking to move it this seems to split the "Debugging Support" and "Full Debugging Support" part of the config with the "Dump". I suppose one could say that dump is part of debugging support, but I think dump as more of a post failure analysis tool, rather than KDB/DDB/GDB which are active online debugging support.

"post failure analysis" seems like a fancy term for a specific type of debugging, but I'm fine with moving it.

markj updated this revision to Diff 42677.May 17 2018, 9:51 PM

Move options into a separate block.

This revision now requires review to proceed.May 17 2018, 9:51 PM
rgrimes accepted this revision.May 17 2018, 9:54 PM

Thanks

This revision is now accepted and ready to land.May 17 2018, 9:54 PM

It looks like the GENERIC configs that you're not updating are for ARM, RISC-V, and PPC64. Why are they being excluded?

cem added a comment.May 17 2018, 11:52 PM

It looks like the GENERIC configs that you're not updating are for ARM, RISC-V, and PPC64. Why are they being excluded?

PPC64 is not excluded. That's powerpc/conf/GENERIC64.

ARM, MIPS, and RISC-V are excluded. Probably because GENERIC doesn't really exist on these platforms? Possibly also because these are low performance, low memory systems, where the CPU overhead of compression is more expensive, kernel text size is more expensive, and dump sizes are smaller relative to disk size (or there is no writable dump partition at all).

In D15465#326493, @cem wrote:

It looks like the GENERIC configs that you're not updating are for ARM, RISC-V, and PPC64. Why are they being excluded?

PPC64 is not excluded. That's powerpc/conf/GENERIC64.

<Blink> Time for new glasses. :-/

ARM, MIPS, and RISC-V are excluded. Probably because GENERIC doesn't really exist on these platforms?

They might not be super useful by themselves, but they do exist.

Possibly also because these are low performance, low memory systems, where the CPU overhead of compression is more expensive, kernel text size is more expensive, and dump sizes are smaller relative to disk size (or there is no writable dump partition at all).

That's a reasonable answer. I just wanted to make sure it wasn't due to an oversight. Please note that when you commit.

markj added a comment.May 18 2018, 4:53 AM
In D15465#326493, @cem wrote:

Possibly also because these are low performance, low memory systems, where the CPU overhead of compression is more expensive, kernel text size is more expensive, and dump sizes are smaller relative to disk size (or there is no writable dump partition at all).

That's a reasonable answer. I just wanted to make sure it wasn't due to an oversight. Please note that when you commit.

There's a fairly strong argument to be made for enabling netdump on such platforms, but until someone has done some testing and added support for some common NIC drivers on such platforms (mge(4)?), I'm not planning on enabling it.

manu accepted this revision.May 19 2018, 6:27 PM

Ok for me on arm64, dump is in zstd format and compress ok (kgdb coredump but it does it too for standard dumps so the issue is elsewhere)

This revision was automatically updated to reflect the committed changes.