What can I do to help this along?

Landed, with Konstantin's additional work (and Kirk's blessing) to avoid *CORRUPTION*, in r284887.

Committed in r284719.

Address kib's feedback; add B_INVAL comment, add failpoint.

In D2900#56463, @kib wrote:

I would add a comment explaining the reason for B_INVAL there.

Fixed in r284739, discarding this review.

Move olock calculation to only where it is needed.

Will fix.

In D2883#55943, @benno wrote:

This should be looked at by davidcs@. I'm going to email him to see if I can get him signed up for Phabricator.

Thanks. Can you commit this for me? I don't have a src bit yet.

Address the concern I brought up re: using stale errno value after fchdir(2).

Thanks!

Per Jilles' feedback, only set serrno value if fts_build actually fails.

Don't preserve errno from close(2)

Shuffle most new code to a separate file under dev/vt/; mostly use the word 'logo' in place of the word 'beastie' when referring to one of these things.

Committed as r283320. Thanks Konstantin, Peter.

My mistake. Sleeping with locks held in a way that thread_single() can interrupt is invalid. Thanks, kib@. Sorry for the spam, everyone.

Looks ok to me. There are some uncodified assumptions in the ACPI to vm_locality mapping that I'd prefer to see in some sort of ASSERT form. The printfs in the parsing probably go away or are cleaned up too.

In D2181#43862, @dumbbell wrote:

This feature is really cool!

Committed by @kostikbel in r282128.

This breaks reboot-from-panic when the panic CPU is not the BSP CPU. Discarding.

In D2181#12, @adrian wrote:

This is a really slow way of drawing things.

In D2181#10, @ed wrote:

I think one of the important things to do is to keep vt(4) simple. syscons(4) became so complex that nobody really understood how it worked anymore. I am afraid that patches that add gimmicks like these negatively affect the overall readability of vt(4) for little functional gain.

Ping. What can I do to help move this forward?

Drop disable_intr(); we're in NMI context and interrupts are disabled.

In D2250#5, @kostikbel wrote:

This means that CPU cannot be directed to make any further work.

r281175

r281175

In D323#5, @jhb wrote:

The in_panic change looks a bit interesting, but I'm curious if that is actually used. A userland process can't be scheduled to run to even invoke this sysctl if the system is panic'ing. Does Isilon use stack_save_thread() in other places?

Committed by kib@ in r281003. Thanks!

Move cleanup to the end of relocation; preloaded and runtime-loaded modules both go through this path.

Damnit, wrong patch. Just a sec.

Move cleanup to the end of relocation; preloaded and runtime-loaded modules both go through this path.

Updated to revert the SHN_FBSD_CACHED symtable changes after loading has completed, per (2) above.

In D2181#3, @emaste wrote:

How do you handle ncpu greater than the number of Beasties that fit on a row?

In D2181#3, @emaste wrote:

How do you handle ncpu greater than the number of Beasties that fit on a row?

In D1718#13, @kostikbel wrote:

Ok. There are two possibilities:

1. Introduce symbol cache used during the module load, and discarded afterward. You can use hash for the symbol names there, which would not help for the first lookup, but does provide more speedup for the duplicate lookups (more than your current patch).

In D1718#11, @kostikbel wrote:

What bug does the patch fix ?

In D1718#9, @kostikbel wrote:

This is hack.

Committed in r279362.

Per discussion on IRC. Move extern declaration into sys/vnode.h so we don't need to import devfs.h in vfs_subr.c.

Ping! Anything I can do to help further this along?

Closing as committed.

Thanks!

Ping! Can someone take and commit this? I don't have a bit and phabricator thinks I should do it.

Drop nmaskwords > 0; remove superfluous nmw_power2 variable.

Add 9999 context, drop fbt_powerpc.c modification (it has since been deleted or merged with fbt.c).

Sorry, forgot on this one. I'll regenerate.

Thanks!

LGTM.

LGTM.

Looks pretty good!

Changes between 3218 and 3220 LGTM.

Not a super thorough review, just passed over briefly. I'm not an expert on UCL nor newsyslog.

Most of the changes are mechanical, so I can do them myself if you like.

In D1263#8, @kostikbel wrote:

Can you enumerate the issues ?

In short, mappable holes between segments tends to be reused, which causes weird issues.

Er, mark reviewed. Phabricator is hard.

If you've tested it and it works, looks good to me. I just want this to be fixed, and every iteration seems like a basically adequate way of solving the problem to me.

Looks good to me.