Re: Buildworld fails due to WITHOUT_CRYPT (3 issues)
I fixed 2/3 of the issues in the following commits: 1. https://svnweb.freebsd.org/changeset/base/276319 3. https://svnweb.freebsd.org/changeset/base/276318 Thanks for the e-mail Garret. Before I proceed to file PR, I'd like some input as to what to do about these problems which I had mentioned in subsequent emails and which I can confirm persist after a fresh buildworld run (removed Herbert's patch) on Rev: 276354. PROBLEM-1: ctld. Not shure how much CAM and ZFS are related. Not using anything CAM afaik, as netiher kernel (device ctl) nor loadr.conf have ctld. So I assume this is a no big deal level issue? === usr.sbin/ctld (all) cc -O2 -pipe -I/asp/git/src/usr.sbin/ctld -I/asp/git/src/usr.sbin/ctld/../../sys -I/asp/git/src/usr.sbin/ctld/../../sys/cam/ctl -I/asp/git/src/usr.sbin/ctld/../../sys/dev/iscsi -DNDEBUG -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -o ctld ctld.o discovery.o isns.o kernel.o keys.o log.o login.o parse.o pdu.o token.o -lbsdxml -ll -lsbuf -lutil discovery.o: In function `discovery_target_filtered_out': /asp/git/src/usr.sbin/ctld/discovery.c:(.text+0x45b): undefined reference to `chap_authenticate' login.o: In function `login': /asp/git/src/usr.sbin/ctld/login.c:(.text+0x628): undefined reference to `chap_new' /asp/git/src/usr.sbin/ctld/login.c:(.text+0x648): undefined reference to `chap_get_challenge' /asp/git/src/usr.sbin/ctld/login.c:(.text+0x654): undefined reference to `chap_get_id' /asp/git/src/usr.sbin/ctld/login.c:(.text+0x7a0): undefined reference to `chap_receive' /asp/git/src/usr.sbin/ctld/login.c:(.text+0x7cc): undefined reference to `chap_authenticate' /asp/git/src/usr.sbin/ctld/login.c:(.text+0x8e2): undefined reference to `rchap_new' /asp/git/src/usr.sbin/ctld/login.c:(.text+0x8f3): undefined reference to `rchap_receive' /asp/git/src/usr.sbin/ctld/login.c:(.text+0x903): undefined reference to `rchap_get_response' /asp/git/src/usr.sbin/ctld/login.c:(.text+0x90e): undefined reference to `rchap_delete' cc: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 PROBLEM-2: MK_PKGBOOTSTRAP === usr.sbin/pkg (all) cc -O2 -pipe -I/asp/git/src/usr.sbin/pkg/../../contrib/libucl/include -DNDEBUG -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c /asp/git/src/usr.sbin/pkg/pkg.c /asp/git/src/usr.sbin/pkg/pkg.c:54:10: fatal error: 'openssl/err.h' file not found #include openssl/err.h PROBLEM-3: No /usr/sbin/mtree after # installworld Other than these 3, there's also the persistent problem involving ccache, which again is no big deal, just FYI. Regards -- FreeBSD_amd64_11-Current_RadeonKMS pgpS5A799pkd7.pgp Description: OpenPGP digital signature
Re: r276200: EFI boot failure: kernel stops booting at pci0: ACPI PCI bus on pcib0
El 28/12/14 a les 22.37, Adrian Chadd ha escrit: Hah sweet! You found the commit! Would you please file a PR so it doesn't get lost? Thanks! -adrian On 28 December 2014 at 12:09, Ian Lepore i...@freebsd.org wrote: On Sun, 2014-12-28 at 20:57 +0100, O. Hartmann wrote: Am Fri, 26 Dec 2014 12:23:42 -0700 Ian Lepore i...@freebsd.org schrieb: On Fri, 2014-12-26 at 08:48 -0800, Adrian Chadd wrote: On 26 December 2014 at 04:01, O. Hartmann ohart...@zedat.fu-berlin.de wrote: Am Thu, 25 Dec 2014 11:40:47 -0800 Adrian Chadd adr...@freebsd.org schrieb: Would you be able to narrow it down to a small range of commits? that'll make it easier to chase down. :) Thanks! -adrian On 25 December 2014 at 10:42, O. Hartmann ohart...@zedat.fu-berlin.de wrote: Since 23rd's update of CURRENT, the kernel fails to boot on systems that boot via EFI. Systems with legacy booting seem not to be affected. I just ran today into the problem updating a notebook with a Intel Haswell Intel i5-4200M CPU (Haswell) on a Lenovo ThinkPad E540, bboting via UEFI, CURRENT r276200. The very same caode base is running on several other boxes which boot via legacy method. The very same failure showed up at the lab on an older HP Compaq 8300 system, based on H81 chipset equipted with an Ivy-Bridge CPU, booting also via EFI. That box stops at the exact same spot as the notebook does. The systems in question, also the legacy booting systems (aka the oldstyle loader boot method), load drm2, i915kms. Booting old kernel/modules (via boot kernel.old), at CURRENT r275896 is all right. What is happening here? Hello, Sorry for not noticing this earlier, I've been without a computer for some days. Do you get a panic message, or the system just freezes? Can you please post the full boot output with boot_verbose enabled? Thanks, Roger. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r276200: EFI boot failure: kernel stops booting at pci0: ACPI PCI bus on pcib0
El 29/12/14 a les 12.41, Roger Pau Monné ha escrit: Hello, Sorry for not noticing this earlier, I've been without a computer for some days. Do you get a panic message, or the system just freezes? Can you please post the full boot output with boot_verbose enabled? I'm not able to reproduce the problem with Qemu and OVMF, and I don't have any box right now that uses UEFI. I'm guessing that this is due to some memory reservation conflict, so I'm attaching a patch that should help diagnose it. Could you provide the information requested above with this patch applied? Thanks, Roger. diff --git a/sys/x86/x86/nexus.c b/sys/x86/x86/nexus.c index 0663602..d563c36 100644 --- a/sys/x86/x86/nexus.c +++ b/sys/x86/x86/nexus.c @@ -367,6 +367,10 @@ nexus_alloc_resource(device_t bus, device_t child, int type, int *rid, struct rman *rm; int needactivate = flags RF_ACTIVE; + if (type == SYS_RES_MEMORY) + printf(%s: RSV range 0x%lx - 0x%lx size %lu\n, + device_get_name(child), start, end, count); + /* * If this is an allocation of the default range for a given * RID, and we know what the resources for this device are ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r276200: EFI boot failure: kernel stops booting at pci0: ACPI PCI bus on pcib0
On Mon, Dec 29, 2014 at 05:55:28PM +0100, Roger Pau Monné wrote: El 29/12/14 a les 12.41, Roger Pau Monné ha escrit: Hello, Sorry for not noticing this earlier, I've been without a computer for some days. Do you get a panic message, or the system just freezes? Can you please post the full boot output with boot_verbose enabled? I'm not able to reproduce the problem with Qemu and OVMF, and I don't have any box right now that uses UEFI. I'm guessing that this is due to some memory reservation conflict, so I'm attaching a patch that should help diagnose it. You'll probably want to nuke RF_ACTIVE so the resources are marked as taken but in case of vt_efifb(4), the memory isn't mapped twice. I don't not know whether the latter actually is a problem for x86, though, it'll likely at least replace the VM_MEMATTR_WRITE_COMBINING mapping done in vt_efifb_remap(). Removing RF_ACTIVE in turn might not be sufficient for the Xen bits to mark the resource as reserved, this should be fixed in the FreeBSD/Xen code then, however. Also end = size - 1, see the attached patch. Marius Index: dev/vt/hw/efifb/efifb.c === --- dev/vt/hw/efifb/efifb.c (revision 276343) +++ dev/vt/hw/efifb/efifb.c (working copy) @@ -211,8 +211,8 @@ res_id = 0; pseudo_phys_res = bus_alloc_resource(dev, SYS_RES_MEMORY, res_id, local_info.fb_pbase, - local_info.fb_pbase + local_info.fb_size, - local_info.fb_size, RF_ACTIVE); + local_info.fb_pbase + local_info.fb_size - 1, + local_info.fb_size, 0); if (pseudo_phys_res == NULL) panic(Unable to reserve vt_efifb memory); return (0); Index: dev/vt/hw/vga/vt_vga.c === --- dev/vt/hw/vga/vt_vga.c (revision 276343) +++ dev/vt/hw/vga/vt_vga.c (working copy) @@ -1275,8 +1275,8 @@ res_id = 0; pseudo_phys_res = bus_alloc_resource(dev, SYS_RES_MEMORY, - res_id, VGA_MEM_BASE, VGA_MEM_BASE + VGA_MEM_SIZE, - VGA_MEM_SIZE, RF_ACTIVE); + res_id, VGA_MEM_BASE, VGA_MEM_BASE + VGA_MEM_SIZE - 1, + VGA_MEM_SIZE, 0); if (pseudo_phys_res == NULL) panic(Unable to reserve vt_vga memory); return (0); ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r276200: EFI boot failure: kernel stops booting at pci0: ACPI PCI bus on pcib0
On Mon, Dec 29, 2014 at 08:12:42PM +0100, Marius Strobl wrote: On Mon, Dec 29, 2014 at 05:55:28PM +0100, Roger Pau Monné wrote: El 29/12/14 a les 12.41, Roger Pau Monné ha escrit: Hello, Sorry for not noticing this earlier, I've been without a computer for some days. Do you get a panic message, or the system just freezes? Can you please post the full boot output with boot_verbose enabled? I'm not able to reproduce the problem with Qemu and OVMF, and I don't have any box right now that uses UEFI. I'm guessing that this is due to some memory reservation conflict, so I'm attaching a patch that should help diagnose it. You'll probably want to nuke RF_ACTIVE so the resources are marked as taken but in case of vt_efifb(4), the memory isn't mapped twice. I don't not know whether the latter actually is a problem for x86, though, it'll likely at least replace the VM_MEMATTR_WRITE_COMBINING mapping done in vt_efifb_remap(). Removing RF_ACTIVE in turn might not be sufficient for the Xen bits to mark the resource as reserved, this should be fixed in the FreeBSD/Xen code then, however. Also end = size - 1, see the attached patch. Err, end = start + size - 1 that is. Marius ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: Enabling vt(4) by default
Hi, FreeBSD 11-current: I had a panic, that VT tries to drain a callout while a mutex is locked rooting down from somewhere: vt_late_window_switch() When starting X11. Try to apply my kernel timeout work in progress patch in the new [RFC] kern/kern_timeout.c rewrite in progress thread and you will see right away. I can get full backtrace if you can't figure this out. Just out of time right now. Thank you! --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[RFC] kern/kern_timeout.c rewrite in progress
Hi,
I recently came across a class of errors which lead me into
investigating the kern/kern_timeout.c and its subsystem. From what I
can see new features like the SMP awareness has been added instead of
fully integrated. When going into the cornercases I've uncovered that
the internal callout statemachine can sometimes report wrong values via
its callout_active() and callout_pending() bits to its clients, which in
turn can make the clients behave badly. I further did an investigation
on how the safety of callout migration between CPU's is maintained. When
I looked into the code and found stuff like volatile and while()
loops to figure which CPU a callout belongs I understood that such logic
completely undermines the cleverness found in the turnstiles of mutexes
and decided to go through all of the logic inside kern_timeout.c. Also
static code analysis is harder when we don't use the basic mutexes and
condition variables available in the kernel.
First of all we need to make some driving rules for everyone:
1) A new feature called direct callbacks which execute the timer
callbacks from the fast interrupt handler was added. All these callbacks
_must_ be associated with a regular spinlocks, to maintain a safe
callout_drain(). Else they should only be executed on CPU0.
2) All Giant locked callbacks should only execute on CPU0 to avoid
congestion.
3) Callbacks using read-only locks for its callback should also only
execute on CPU0 to avoid multiple instances pending for completion on
multiple CPU's, because read-only locks can be entered multiple times.
From what I can see, there are currently no consumers of this feature
in the kernel.
Secondly, we need a way to drain callbacks asynchronously, for example
like in the TCP stack. Currently the TCP shutdown sequence for a
connection looks like this:
...
void
pcb_teardown(pcb)
{
lock(pcb);
callout_stop(pcb-c1);
callout_stop(pcb-c2);
callout_stop(pcb-c3);
unlock(pcb);
free(pcb);
}
I guess some of you see what is wrong: Use after free.
...
With a new function I've added, scenarios like this can be solved more
elegantly and without having to fear use after free situations!
static void
pcb_callback(void *pcb)
{
lock(pcb);
do_free = (--(pcb-refcount) == 0);
unlock(pcb);
if (do_free == 0)
return;
destroy_mtx(pcb);
free(pcb);
}
void
pcb_teardown(pcb)
{
lock(pcb);
pcb-refcount = 4;
if (callout_drain_async(pcb-c1, pcb_callback, pcb) == 0)
pcb-refcount--;
if (callout_drain_async(pcb-c2, pcb_callback, pcb) == 0)
pcb-refcount--;
if (callout_drain_async(pcb-c3, pcb_callback, pcb) == 0)
pcb-refcount--;
unlock(pcb);
pcb_callback(pcb);
}
Please find attached a patch for 11-current as of today. Comments and
feedback is appreciated.
BTW: Happy New Year everyone!
--HPS
Index: sys/kern/kern_timeout.c
===
--- sys/kern/kern_timeout.c (revision 276240)
+++ sys/kern/kern_timeout.c (working copy)
@@ -125,36 +125,56 @@
u_int callwheelsize, callwheelmask;
/*
- * The callout cpu exec entities represent informations necessary for
- * describing the state of callouts currently running on the CPU and the ones
- * necessary for migrating callouts to the new callout cpu. In particular,
- * the first entry of the array cc_exec_entity holds informations for callout
- * running in SWI thread context, while the second one holds informations
- * for callout running directly from hardware interrupt context.
- * The cached informations are very important for deferring migration when
- * the migrating callout is already running.
+ * The callout CPU exec structure represent information necessary for
+ * describing the state of callouts currently running on the CPU and
+ * for handling deferred callout restarts.
+ *
+ * In particular, the first entry of the array cc_exec_entity holds
+ * information for callouts running from the SWI thread context, while
+ * the second one holds information for callouts running directly from
+ * the hardware interrupt context.
*/
struct cc_exec {
- struct callout *cc_next;
+ /*
+ * The cc_curr points to the currently executing callout and
+ * is write protected by the cc_lock spinlock. If no
+ * callback is currently executing it is equal to NULL.
+ */
struct callout *cc_curr;
-#ifdef SMP
- void (*ce_migration_func)(void *);
- void *ce_migration_arg;
- int ce_migration_cpu;
- sbintime_t ce_migration_time;
- sbintime_t ce_migration_prec;
-#endif
- bool cc_cancel;
- bool cc_waiting;
+ /*
+ * The cc_restart_args structure holds the argument for a
+ * deferred callback restart and is write protected by the
+ * cc_lock spinlock. The structure is only valid if
+ * cc_restart is true. If cc_restart is false the
+ * information in the cc_restart_args structure shall be
+ * ignored.
+ */
+ struct callout_args cc_restart_args;
+ bool cc_restart;
+ /*
+
Re: [RFC] kern/kern_timeout.c rewrite in progress
On Dec 29, 2014, at 12:03, Hans Petter Selasky h...@selasky.org wrote: Hi, … Hi HPS, Could you please send this to -arch instead and CC jhb? Thanks! signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [RFC] kern/kern_timeout.c rewrite in progress
On 12/29/14 21:04, Garrett Cooper wrote: On Dec 29, 2014, at 12:03, Hans Petter Selasky h...@selasky.org wrote: Hi, … Hi HPS, Could you please send this to -arch instead and CC jhb? Thanks! Done! --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r276200: EFI boot failure: kernel stops booting at pci0: ACPI PCI bus on pcib0
On Mon, December 29, 2014 20:12, Marius Strobl wrote: On Mon, Dec 29, 2014 at 05:55:28PM +0100, Roger Pau Monné wrote: El 29/12/14 a les 12.41, Roger Pau Monné ha escrit: Hello, Sorry for not noticing this earlier, I've been without a computer for some days. Do you get a panic message, or the system just freezes? Can you please post the full boot output with boot_verbose enabled? I'm not able to reproduce the problem with Qemu and OVMF, and I don't have any box right now that uses UEFI. I'm guessing that this is due to some memory reservation conflict, so I'm attaching a patch that should help diagnose it. You'll probably want to nuke RF_ACTIVE so the resources are marked as taken but in case of vt_efifb(4), the memory isn't mapped twice. I don't not know whether the latter actually is a problem for x86, though, it'll likely at least replace the VM_MEMATTR_WRITE_COMBINING mapping done in vt_efifb_remap(). Removing RF_ACTIVE in turn might not be sufficient for the Xen bits to mark the resource as reserved, this should be fixed in the FreeBSD/Xen code then, however. Also end = size - 1, see the attached patch. Hi, I tried this patch on my Acer. I does not help. Legacy boot (BIOS) still works. Jakob ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Build failed in Jenkins: Build-UFS-image #797
See https://jenkins.freebsd.org/job/Build-UFS-image/797/ -- [...truncated 11191 lines...] https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/openssl/man/man3/i2d_DSA_SIG.3.gz - https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/openssl/man/man3/d2i_DSAPublicKey.3.gz https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/openssl/man/man3/d2i_PKCS8PrivateKey_bio.3.gz - https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/openssl/man/man3/d2i_PKCS8PrivateKey.3.gz https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/openssl/man/man3/d2i_PKCS8PrivateKey_fp.3.gz - https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/openssl/man/man3/d2i_PKCS8PrivateKey.3.gz https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/openssl/man/man3/i2d_PKCS8PrivateKey_bio.3.gz - https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/openssl/man/man3/d2i_PKCS8PrivateKey.3.gz https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/openssl/man/man3/i2d_PKCS8PrivateKey_fp.3.gz - https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/openssl/man/man3/d2i_PKCS8PrivateKey.3.gz https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/openssl/man/man3/i2d_PKCS8PrivateKey_nid_bio.3.gz - https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/openssl/man/man3/d2i_PKCS8PrivateKey.3.gz https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/openssl/man/man3/i2d_PKCS8PrivateKey_nid_fp.3.gz - https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/openssl/man/man3/d2i_PKCS8PrivateKey.3.gz https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/openssl/man/man3/i2d_RSAPublicKey.3.gz - https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/openssl/man/man3/d2i_RSAPublicKey.3.gz https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/openssl/man/man3/d2i_RSAPrivateKey.3.gz - https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/openssl/man/man3/d2i_RSAPublicKey.3.gz https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/openssl/man/man3/i2d_RSAPrivateKey.3.gz - https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/openssl/man/man3/d2i_RSAPublicKey.3.gz https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/openssl/man/man3/d2i_RSA_PUBKEY.3.gz - https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/openssl/man/man3/d2i_RSAPublicKey.3.gz https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/openssl/man/man3/i2d_RSA_PUBKEY.3.gz - https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/openssl/man/man3/d2i_RSAPublicKey.3.gz https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/openssl/man/man3/i2d_Netscape_RSA.3.gz - https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/openssl/man/man3/d2i_RSAPublicKey.3.gz https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/openssl/man/man3/d2i_Netscape_RSA.3.gz - https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/openssl/man/man3/d2i_RSAPublicKey.3.gz https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/openssl/man/man3/i2d_X509.3.gz - https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/openssl/man/man3/d2i_X509.3.gz https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/openssl/man/man3/d2i_X509_bio.3.gz - https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/openssl/man/man3/d2i_X509.3.gz https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/openssl/man/man3/d2i_X509_fp.3.gz - https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/openssl/man/man3/d2i_X509.3.gz https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/openssl/man/man3/i2d_X509_bio.3.gz - https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/openssl/man/man3/d2i_X509.3.gz https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/openssl/man/man3/i2d_X509_fp.3.gz - https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/openssl/man/man3/d2i_X509.3.gz https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/share/openssl/man/man3/i2d_X509_ALGOR.3.gz -
