- User Since
- Mar 11 2014, 8:46 PM (248 w, 3 d)
Same fixes as in rS332891 :)
Thu, Dec 13
Sorry, I missed the last upload of this.
Wed, Dec 12
Tue, Dec 11
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.
Mon, Dec 10
FWIW, this did fix the multi-hour delay in a formal model simulator.
I also think it is worth it.
Sun, Dec 9
Fri, Dec 7
FYI, this booted in a very simple MFS root (no real networking other than lo0)
Thu, Dec 6
This is inspired by PR 231515?
Wed, Dec 5
Drop ChangeLog diff.
Sat, Dec 1
Fri, Nov 30
- 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.
Thu, Nov 29
Tue, Nov 27
One nit: s/sigaltstack/sigonstack/ in the commit message.
Some sample output:
Mon, Nov 26
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.
Sun, Nov 18
Fri, Nov 16
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.
- Add a read-only sysctl for first_msi_irq.
Thu, Nov 15
This was committed in the noted commit.
Is this one ready to be reviewed?
Nov 14 2018
- 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.