Let me try to contact George again.

Not an expert on these matter, but I have no problem with the change.
Thanks!

Or if a "boot pool" setup is used (kernel is loaded from one pool, root is mounted from another). Or if reboot -r has been run prior to zfsbootcfg.

At work we decided to use the approach of if_gif / if_gre.
So, we don't really need this change.
But if people find it useful (e.g. @ae) and no one objects (looking at @bz), then I would like to commit this change and to merge if we have a spare field.

correct description of the new sysctl

While here, I also fixed setting of the next state in the case of malloc failure in DA_STATE_PROBE_WP.

Unfortunately, I disagree with this change. I think that it is backwards.
illumos has already translated their zfs.1m and zpool.1m to mdoc format, so I assume that that's the direction they are moving in.
I'd rather help them with that in this case as well.
IMO, that would be a better way to overcome the divergence.

• add and make use of rman_{get,set}_irq_cookie() and a new field r_irq_cookie to back them
• slide up head

In D18420#392363, @ae wrote:

I'm inclined to agree. For tunneling interfaces I used global per-driver sx lock to prevent concurrent ioctl invocation. I think these drivers are not affected by this problem.

In D18420#392349, @ae wrote:

Can you provide an example, what another driver needs such method? Maybe it is enough to fix the problem locally in if_lagg for first time?

In D18420#392053, @bz wrote:

Sorry but my understanding is that this could possibly free the softc even before lagg_clone_destroy() has finished, couldn't it?

Maybe rather than removing the code it would be better to ifdef it out?
But not sure. What are plans for illumos in this respect?

In D17465#386206, @selwinsebastian_gmail.com wrote:

Scheduler should be aware of the topology of socket also as to keep threads in same socket if possible while migration as

I see what the change does but not why. Could you please provide some rationale?

In D17585#375321, @mav wrote:

I have no particular objections, just quietly sighing that this area remains so tangled. I haven't investigated the area much recently, but it seems like WDAT-based attach could be cleaner, if it is a widespread standard and does not conflict too badly with existing drivers. Having watchdog drivers enabled in FreeNAS for years we had huge number of complains, caused by random platform specifics, and obtaining some valid configuration directly from platform in face of this table could be priceless.

Another note is that the test system has a BIOS option to enable the watchdog support. That option does not seem to affect the hardware configuration in any way, but when it is enabled the firmware generates WDAT (WatchDog Action Table) ACPI table. I see that Linux now has a driver for that table:
https://github.com/torvalds/linux/commits/master/drivers/watchdog/wdat_wdt.c

Looks good to me.

LGTM. The change is trivial enough.

I am really happy that this simple change greatly reduces the chances of hitting the problem.
My understanding of it is in the bug report.

ZFS part looks good to me.

LGTM. Thank you!

• add a barrier function to ensure that the interrupt handling code sees that a handler is suspended after intr_event_suspend_handler() returns

Terry, thank you!

I've just tested this and I see a couple of issues.

rebase