Same fixes as in rS332891 :)

Sorry, I missed the last upload of this.

It would be great to add "ccm" to tools/crypto/cryptocheck.c as well. It does comparisons of /dev/crypto vs OpenSSL's software algorithms. If the NIST-KAT tests include tests for AES-CCM it would also be good to update the nist-kat port to install those (if it doesn't already) and update the python opencrypto tests to run the CCM tests.

FWIW, this did fix the multi-hour delay in a formal model simulator.

I also think it is worth it.

FYI, this booted in a very simple MFS root (no real networking other than lo0)

This is inspired by PR 231515?

Thanks

Drop ChangeLog diff.

• Use patch from upstream commit.
• Bump PORTREVISION.

I've merged a similar change upstream to gdb in commit 93579f6f90. We can pull that into the port as a commit-<foo> patch.

One nit: s/sigaltstack/sigonstack/ in the commit message.

Some sample output:

In D18347#389943, @kib wrote:

In D18347#389623, @jhb wrote:

The difference is that the sigonstack() can override ss_flags. sendsig() functions call sigonstack() passing in the current stack pointer. I think this function tries to determine if the current stack pointer is already in the signal stack. If it is, it returns 0 to force a nested signal to use the normal thread stack instead of the signal stack.

Are you sure ? From my reading, it returns 1 if TDP_ALTSTACK is set _and_ current %sp is inside the alt stack address range. Well, it would be cleaner if the check was added for sp < ss_sp, otherwise it depends on ss_size comparision with unsigned overflow.

The difference is that the sigonstack() can override ss_flags. sendsig() functions call sigonstack() passing in the current stack pointer. I think this function tries to determine if the current stack pointer is already in the signal stack. If it is, it returns 0 to force a nested signal to use the normal thread stack instead of the signal stack.

So the device_disable() should have made the probe return of 0 vs ENXIO harmless since device_attach shouldn't have been called either way.

I've compiled kernels fine using mips-gcc. I've fixed the port to default to mips3 also, so I think this change is probably OBE. Also, march=mips32/64 is actually a much newer march than mips3.

Sample output:

• Add a read-only sysctl for first_msi_irq.

This was committed in the noted commit.

Is this one ready to be reviewed?

Rebase.

• Adjust other overflow checks.

It is perhaps debatable if we want this change since it will change the IRQ values users see (and users might be used to >= 256 meaning MSI), and I probably won't MFC it if we do decide we want it in HEAD for those reasons.

• Rework the Xen overflow check due to size_t promotion.

• Fixes from markj.
• Add overflow checks.

I agree that this seems like a workaround for some other problem. Without EARLY_AP_STARTUP the IRQs aren't actually moved until much later during boot (the late SI_SUB_SMP), so you can only see this earlier in boot if EARLY_AP_STARTUP is enabled, but then sched_bind should work fine. Useful strategies for debugging this would be to add KTR to your kernel config and break into DDB when it hangs and examine KTR traces. KTR_INTR and KTR_PROC are probably the useful masks to trace.