SafeXcel EIP-97 only registering AES-CBC with OCF on SG-2100 (pfSense Plus 24.03)
-
SafeXcel EIP-97 not fully accelerating on SG-2100 - Only AES-CBC working
Hey everyone,
I've been doing some deep digging into why my SG-2100 Max isn't using the SafeXcel EIP-97 crypto accelerator to its full potential on pfSense Plus 24.03 and wanted to share what I found and ask if anyone has a solution.
The Problem
The SafeXcel chip on the SG-2100 should be able to accelerate a wide range of algorithms including AES-GCM, AES-XTS, SHA256, SHA512, and HMAC. But it's only accelerating AES-CBC:
Cipher AES-128-CBC, driver=safexcel0 (hw accelerated) Cipher AES-192-CBC, driver=safexcel0 (hw accelerated) Cipher AES-256-CBC, driver=safexcel0 (hw accelerated)Everything else falls back to software crypto which defeats the purpose of having dedicated hardware acceleration.
What I Tried
I spent a lot of time investigating this and here's what I found:
On 23.05.1
The SafeXcel driver was missing OCF registration hooks entirely —
crypto_registerwasn't even compiled in. Upgrading to 24.03 fixed that part.On 24.03
The OCF hooks are present but
armv8crypto(the ARM CPU's built-in AES instructions) was compiled directly into the kernel and claiming AES-GCM and AES-XTS before SafeXcel could register them.I fixed that by adding this to
/boot/loader.conf.local:hint.armv8crypto.0.disabled="1"After that SafeXcel finally attached without competition — but it still only registered AES-CBC. Checking the compiled driver confirmed why:
strings /boot/kernel/safexcel.ko | grep -iE "AES|GCM|XTS|SHA|CTR" # Only shows basic AES and HMAC-SHA strings # No GCM, XTS, CTR, CCM at allThe driver was compiled with minimal algorithm support.
Attempting a Fix
I cloned the upstream FreeBSD source and confirmed it has full algorithm support — AES-GCM, AES-XTS, HMAC, SHA all present with proper OCF registration. I cross-compiled it for aarch64 and ran into a symbol mismatch:
link_elf: symbol bus_release_resource_old undefinedNetgate's kernel uses the newer 2-argument
bus_release_resource()but upstream uses the old 4-argument version. I patched the source to fix this and rebuilt. All undefined symbols in the patched module have been verified to exist in Netgate's kernel. Currently testing the patched module.
What I'm Asking
- Has anyone else run into this and found a solution?
- Is Netgate intentionally limiting SafeXcel to AES-CBC only?
- Could Netgate please either provide a fully compiled
safexcel.kofor 24.03 or make the source available so we can build it ourselves?
The hardware is fully capable of accelerating AES-GCM, AES-XTS, SHA256, SHA512, and HMAC — it would make a big difference for IPsec and OpenVPN throughput on the SG-2100.
System Info
Item Value Hardware Netgate SG-2100 Max Version pfSense Plus 24.03 Architecture FreeBSD 15.0-CURRENT aarch64 kern.osreldate 1500012 Kernel plus-RELENG_24_03-n256311-e71f834dd81
Thanks in advance for any help!
-
Update - Patched Module Test Results
Hey everyone, wanted to post an update with my findings after attempting to load the patched upstream
safexcel.ko.
What I Did
After verifying all undefined symbols existed in Netgate's kernel, I attempted to safely load the patched module by stopping all services that use crypto first:
killall openvpn /usr/local/etc/rc.d/snort stop sleep 3 fstat /dev/crypto # confirmed empty - nothing holding it open kldunload safexcel.ko kldload /boot/safexcel_v3.ko
The Crash
Loading the patched module caused a kernel panic and automatic reboot. From dmesg after recovery:
safexcel0: detached KLD safexcel_upstream.ko: depends on kernel - not available or version mismatch KLD safexcel_upstream.ko: depends on kernel - not available or version mismatch safexcel0: <SafeXcel EIP-97 crypto accelerator> mem 0x90000-0xaffff irq 18,19,20,21,22,23 on simplebus1 safexcel0: detached link_elf: symbol bus_release_resource_old undefined link_elf: symbol bus_release_resource_old undefined link_elf: symbol bus_release_resource_old undefined link_elf: symbol bus_release_resource_old undefined link_elf: symbol bus_release_resource_old undefined
What I Fixed
The
bus_release_resource_oldsymbol doesn't exist in Netgate's kernel — they use the newer 2-argument signature. I patched all 4 calls insafexcel.c:Before (4 args - old signature, not in Netgate kernel):
bus_release_resource(dev, SYS_RES_IRQ, rman_get_rid(sc->sc_intr[i]), sc->sc_intr[i]); bus_release_resource(dev, SYS_RES_MEMORY, rman_get_rid(sc->sc_res), sc->sc_res);After (2 args - matches Netgate kernel):
bus_release_resource(dev, sc->sc_intr[i]); bus_release_resource(dev, sc->sc_res);
Current Status
Rebuilt module (
safexcel_v3.ko) with:
__FreeBSD_versionset to1500012matching pfSense 24.03-
bus_release_resource_oldpatched to new signature - All undefined symbols verified present in Netgate's kernel:
lse_supportedrijndaelEncryptbus_dmamap_load_crp- All other symbols
Pending safe test load
Build Environment
- Build host: FreeBSD 14.1-RELEASE aarch64 VM (UTM on Apple M1)
- Source: Upstream FreeBSD main branch
- Cross-compiled for: aarch64
- Patch:
bus_release_resource4-arg → 2-arg signature - Version override:
__FreeBSD_version 1500012
Still Needed
The core issue remains — Netgate's compiled
safexcel.koonly registers AES-CBC with OCF. The upstream driver has full support for:- AES-GCM
- AES-XTS
- AES-CTR
- AES-CCM
- SHA256/SHA512
- HMAC-SHA256/SHA512
Without Netgate providing either a fixed
safexcel.koor access to theplus-RELENG_24_03source, users are stuck with AES-CBC only on hardware that is fully capable of much more.Netgate — could you please provide either a fixed driver or the source for this kernel build?
System Info
Item Value Hardware Netgate SG-2100 Max Version pfSense Plus 24.03 Architecture FreeBSD 15.0-CURRENT aarch64 kern.osreldate 1500012 Kernel plus-RELENG_24_03-n256311-e71f834dd81 -
if anyone has any pointers hints... anything to help me get this going please let me know. I do know its slower... I am trying to free up the cpu with safexcel, I am not concerned about it being a bit slower.. I want the multitasking abilities again
-
safexcel0: detached
safexcel0: <SafeXcel EIP-97 crypto accelerator> mem 0x90000-0xaffff irq 18,19,20,21,22,23 on simplebus1
Fatal data abort:
x0: 0xffffa000016cd4b0
x1: 0xffffa000010abb00
x2: 0x0000000000000003
x3: 0x0000000000000000
x4: 0x0000000000000000
x5: 0xffffffffffffffff
x6: 0x0000000000000001
x7: 0x0000000000000002
x8: 0x0000000000000003
x9: 0xffff00000216da08 (bus_alloc_resource_desc + 0x0)
x10: 0xffff00000216da08 (bus_alloc_resource_desc + 0x0)
x11: 0xffff00000212de08 (ofw_bus_get_devinfo_desc + 0x0)
x12: 0x0000000000000000
x13: 0xff01000000010003
x14: 0x0000000000000000
x15: 0x0000000000000000
x16: 0xffff00000024c570 (simplebus_alloc_resource + 0x0)
x17: 0xffff0000006a4110 (bus_alloc_resource + 0x0)
x18: 0xffff0000af3ca1f0
x19: 0xffffa0000147b100
x20: 0x0000000000000002
x21: 0x0000000000000000
x22: 0x0000000000000003
x23: 0xffffa000010abb00
x24: 0xffffffffffffffff
x25: 0x0000000000000000
x26: 0x0000000000000001
x27: 0xffffa000016cc680
x28: 0xffff000002241000
x29: 0xffff0000af3ca1f0
sp: 0xffff0000af3ca1f0
lr: 0xffff00000024c5d8 (simplebus_alloc_resource + 0x68)
elr: 0xffff00000024c5e0 (simplebus_alloc_resource + 0x70)
spsr: 0x0000000060000045
far: 0x0000000000000000
esr: 0x0000000096000004
panic: vm_fault failed: 0xffff00000024c5e0 error 1
cpuid = 1--- ## Analysis The panic occurs in `simplebus_alloc_resource + 0x70` with: - `far: 0x0000000000000000` — **null pointer dereference** - `esr: 0x0000000096000004` — data abort on instruction fetch This is happening during `bus_alloc_resource_any` when SafeXcel tries to allocate its memory and IRQ resources at attach time. The root cause is a **struct layout mismatch** between upstream FreeBSD 16 headers used to build the module and Netgate's private FreeBSD 15.0 kernel fork. The `struct resource` fields are at different offsets, causing the null pointer dereference inside `simplebus_alloc_resource`. -
What do you see in 25.11.1? Or 26.03-RC?
It's never going to fixed in 24.03 at this point.
-
This post is deleted! -
@stephenw10 Thank you for the quick response! Unfortunately I'm unable to upgrade to 25.11.1 right now as I have an NVMe drive that loses its driver in newer versions which leaves me without storage access.
I've done all the hard work already — cross-compiled a patched upstream module, fixed the bus_release_resource symbol mismatch, verified all undefined symbols exist in the kernel — the only thing stopping me is a struct resource layout difference between upstream FreeBSD headers and your private fork.
Could you please help with either:The three files: sys/sys/rman.h, sys/sys/bus.h, sys/dev/safexcel/safexcel.c
or maybe just a pre-compiled safexcel.ko for 24.03 with full OCF registration so I can use it
I'm so close — just need these files to cross the finish line. Thank you!
root@freeBSD_M1:~/freebsd-src # git diff sys/dev/safexcel/safexcel.c diff --git a/sys/dev/safexcel/safexcel.c b/sys/dev/safexcel/safexcel.c index 0e45c213c..f831b809d 100644 --- a/sys/dev/safexcel/safexcel.c +++ b/sys/dev/safexcel/safexcel.c @@ -1112,10 +1112,8 @@ safexcel_alloc_dev_resources(struct safexcel_softc *sc) out: for (i = 0; i < SAFEXCEL_MAX_RINGS && sc->sc_intr[i] != NULL; i++) - bus_release_resource(dev, SYS_RES_IRQ, - rman_get_rid(sc->sc_intr[i]), sc->sc_intr[i]); - bus_release_resource(dev, SYS_RES_MEMORY, rman_get_rid(sc->sc_res), - sc->sc_res); + bus_release_resource(dev, sc->sc_intr[i]); + bus_release_resource(dev, sc->sc_res); return (error); } @@ -1125,11 +1123,9 @@ safexcel_free_dev_resources(struct safexcel_softc *sc) int i; for (i = 0; i < SAFEXCEL_MAX_RINGS && sc->sc_intr[i] != NULL; i++) - bus_release_resource(sc->sc_dev, SYS_RES_IRQ, - rman_get_rid(sc->sc_intr[i]), sc->sc_intr[i]); + bus_release_resource(sc->sc_dev, sc->sc_intr[i]); if (sc->sc_res != NULL) - bus_release_resource(sc->sc_dev, SYS_RES_MEMORY, - rman_get_rid(sc->sc_res), sc->sc_res); + bus_release_resource(sc->sc_dev, sc->sc_res); }this is the changes I made so far
-
@stephenw10 is there anyway to just get a .ko file because it is already compiled maybe ?
-
I can get you the kernel module from 24.03 but you already have that. I have no way to compile anything new against the 24.03 code base though.
-
@stephenw10 thanks I am just wondering if mine is bad from updates or something
-
From the device you can fetch the kernel package from the current repo like:
pkg fetch -o /root pfSense-kernel-pfSenseYou will then see it in /root/All and that pkg has all the kernel modules in it.
-
@stephenw10 Dang they are the same
-r--r--r-- 1 root wheel 42840 Apr 18 2024 /tmp/kernel_extract/boot/kernel/safexcel.koShell Output - ls -la /boot/kernel/safexcel.ko
-r--r--r-- 1 root wheel 42840 Apr 18 2024 /boot/kernel/safexcel.koShell Output - strings /tmp/kernel_extract/boot/kernel/safexcel.ko | grep -iE "GCM|XTS|SHA|CTR|probesession|newsession|crypto_register"
auth_hash_hmac_sha2_512 auth_hash_hmac_sha2_256 cryptodev_probesession_desc cryptodev_newsession_descI was able to get a debug file maybe that might help Ill keep you updated
-
@stephenw10 The file I made cross complied crashed and killed one of my Boot environments so bad that I had to use a usb recovery drive
I had no loader.lua anymore after it did a huge crash
======================================================================== PFSENSE PLUS ZFS BOOT RECOVERY GUIDE (ERROR: cannot open loader.lua) ======================================================================== 1. ACCESSING THE RECOVERY ENVIRONMENT ------------------------------------- At the 'OK' loader prompt (with pfSense Plus Installer USB plugged in): OK run usbboot Once the USB installer loads, select: (S)hell 2. MOUNTING THE ZFS POOL ------------------------ Identify and import your existing pool (usually named 'newpfSenseBackup' or 'zroot'): # zpool import -f -R /mnt newpfSenseBackup 3. FINDING A WORKING BOOT ENVIRONMENT ------------------------------------- List all available environments to find a known-good one (example., IPV6_HOST_ACTIVE): # zfs list -r newpfSenseBackup/ROOT 4. APPLYING THE FIX (MANUAL ACTIVATE) ------------------------------------- Force the pool to boot from the working environment: # zpool set bootfs=newpfSenseBackup/ROOT/IPV6_HOST_ACTIVE newpfSenseBackup 5. VERIFYING AND REBOOTING -------------------------- Confirm the 'bootfs' property matches your desired environment: # zpool get bootfs newpfSenseBackup Unmount the pool to save changes and restart: # zpool export newpfSenseBackup # reboot 6. POST-RECOVERY (CLEANUP) -------------------------- Once logged back into the pfSense WebGUI: - Navigate to: System > Boot Environments - Locate the "bad" environment (e.g., the one ending in ...20250113135850) - Select it and click the 'Trash' icon to prevent future boot loops. ========================================================================Here is the crash report
bus_generic_driver_added() at bus_generic_driver_added+0xac devclass_driver_added() at devclass_driver_added+0x48 devclass_add_driver() at devclass_add_driver+0x13c module_register_init() at module_register_init+0xdc linker_load_module() at linker_load_module+0xb00 kern_kldload() at kern_kldload+0x100 sys_kldload() at sys_kldload+0x64 do_el0_sync() at do_el0_sync+0x634 handle_el0_sync() at handle_el0_sync+0x48 --- exception, esr 0x56000000 db:1:pfs> ps pid ppid pgrp uid state wmesg wchan cmd 977 99 26 0 S+ nanslp 0xffff0000024b088d sleep 976 764 26 0 R+ CPU 1 kldload 966 653 653 0 S accept 0xffff0000b03f5250 php-fpm 959 653 653 0 S accept 0xffff0000b03f5250 php-fpm 958 1 958 0 Ss select 0xffffa00042bc46c0 devd 764 26 26 0 S+ piperd 0xffff0000b12292d8 php-cgi 762 760 760 0 S kqread 0xffffa000026fe500 check_reload_status 760 1 760 0 Ss kqread 0xffffa0004297f100 check_reload_status 655 653 653 0 S accept 0xffff0000b03f5250 php-fpm 654 653 653 0 S accept 0xffff0000b03f5250 php-fpm 653 1 653 0 Ss kqread 0xffffa000026fd700 php-fpm 295 0 0 0 DL geli:w 0xffffa0004217fc00 [g_eli[1] gpt/swapUS] 294 0 0 0 DL geli:w 0xffffa0004217fc00 [g_eli[0] gpt/swapUS] 99 1 26 0 S+ wait 0xffffa00002594a90 sh 26 1 26 0 Ss+ pause 0xffffa000025920b0 sh 25 0 0 0 DL aldslp 0xffff0000024552b0 [ALQ Daemon] 24 0 0 0 DL syncer 0xffff0000024e2ca0 [syncer] 23 0 0 0 DL vlruwt 0xffffa00001606a90 [vnlru] 22 0 0 0 DL (threaded) [bufdaemon] 100117 D psleep 0xffff0000024e1b88 [bufdaemon] 100123 D - 0xffff000002243c00 [bufspacedaemon-0] 100124 D - 0xffff000002244100 [bufspacedaemon-1] 21 0 0 0 DL psleep 0xffff000002527150 [vmdaemon] 20 0 0 0 RL (threaded) [pagedaemon] 100115 RunQ [dom0] 100121 D launds 0xffff000002500144 [laundry: dom0] 100122 D umarcl 0xffff000000af68e4 [uma] 19 0 0 0 DL mmcsd d 0xffffa000024c6c00 [mmcsd0boot1: mmc/sd] 18 0 0 0 DL mmcsd d 0xffffa000024c5100 [mmcsd0boot0: mmc/sd] 17 0 0 0 DL mmcsd d 0xffffa000024e7100 [mmcsd0: mmc/sd card] 9 0 0 0 DL mx25jq 0xffffa00002494300 [task: mx25l flash] 8 0 0 0 RL [rand_harvestq] 7 0 0 0 RL [pf purge] 6 0 0 0 DL (threaded) [zfskern] 100078 D t->zthr 0xffffa0000147a248 [arc_evict] 100079 D t->zthr 0xffffa00001479048 [arc_reap] 100080 D - 0xffffa0000160bc00 [dbu_evict] 100081 D dbuf_ev 0xffff000002bad428 [dbuf_evict_thread] 100082 D - 0xffffa0000160ba80 [z_vdev_file_0] 100083 D - 0xffffa0000160ba80 [z_vdev_file_1] 100084 D - 0xffffa0000160ba80 [z_vdev_file_2] 100085 D - 0xffffa0000160ba80 [z_vdev_file_3] 100086 D - 0xffffa0000160ba80 [z_vdev_file_4] 100087 D - 0xffffa0000160ba80 [z_vdev_file_5] 100088 D - 0xffffa0000160ba80 [z_vdev_file_6] 100089 D - 0xffffa0000160ba80 [z_vdev_file_7] 100090 D - 0xffffa0000160ba80 [z_vdev_file_8] 100091 D - 0xffffa0000160ba80 [z_vdev_file_9] 100092 D - 0xffffa0000160ba80 [z_vdev_file_10] 100093 D - 0xffffa0000160ba80 [z_vdev_file_11] 100094 D - 0xffffa0000160ba80 [z_vdev_file_12] 100095 D - 0xffffa0000160ba80 [z_vdev_file_13] 100096 D - 0xffffa0000160ba80 [z_vdev_file_14] 100097 D - 0xffffa0000160ba80 [z_vdev_file_15] 100098 D l2arc_f 0xffff000002bac7a0 [l2arc_feed_thread] 100099 D - 0xffffa0000160b600 [zfsvfs] 100100 S zevent_ 0xffff000002bada78 [sysevent] 100160 D - 0xffffa00002590000 [z_zvol] 100161 D - 0xffffa00002591d80 [z_metaslab] 100162 D - 0xffffa00002591c00 [z_prefetch_0] 100163 D - 0xffffa00002591c00 [z_prefetch_1] 100164 D - 0xffffa00002591a80 [z_upgrade_0] 100165 D - 0xffffa00002591a80 [z_upgrade_1] 100168 D - 0xffffa00002591780 [dp_sync_taskq_0] 100169 D - 0xffffa00002591780 [dp_sync_taskq_1] 100170 D - 0xffffa00002591600 [dp_zil_clean_taskq_] 100171 D - 0xffffa00002591600 [dp_zil_clean_taskq_] 100172 D - 0xffffa00002591480 [z_zrele_0] 100173 D - 0xffffa00002591480 [z_zrele_1] 100174 D - 0xffffa00002591300 [z_unlinked_drain_0] 100175 D - 0xffffa00002591300 [z_unlinked_drain_1] 100191 D tx->tx_ 0xffffa000026f9810 [txg_thread_enter] 100192 D tx->tx_ 0xffffa000026f97f0 [txg_thread_enter] 100193 D mmp->mm 0xffff000040d7b458 [mmp_thread_enter] 100194 D t->zthr 0xffffa000030b5948 [raidz_expand] 100195 D t->zthr 0xffffa000031c2048 [z_indirect_condense] 100196 D t->zthr 0xffffa000027c3d48 [z_livelist_destroy] 100197 D t->zthr 0xffffa000027c3e48 [z_livelist_condense] 100198 D t->zthr 0xffffa000027f4648 [z_checkpoint_discar] 100199 D vd->vde 0xffff0000af44add0 [vdev_autotrim_threa] 16 0 0 0 DL (threaded) [usb] 100057 D - 0xffff00009c0f7440 [usbus0] 100058 D - 0xffff00009c0f7498 [usbus0] 100059 D - 0xffff00009c0f74f0 [usbus0] 100060 D - 0xffff00009c0f7548 [usbus0] 100061 D - 0xffff00009c0f75a0 [usbus0] 100063 D - 0xffff000040f4acf0 [usbus1] 100064 D - 0xffff000040f4ad48 [usbus1] 100065 D - 0xffff000040f4ada0 [usbus1] 100066 D - 0xffff000040f4adf8 [usbus1] 100067 D - 0xffff000040f4ae50 [usbus1] 5 0 0 0 DL - 0xffff000002527db0 [busdma] 4 0 0 0 DL (threaded) [cam] 100044 D - 0xffff00000227a380 [doneq0] 100045 D - 0xffff00000227a280 [async] 100110 D - 0xffff00000227a0d0 [scanner] 3 0 0 0 DL (threaded) [crypto] 100041 D crypto_ 0xffff0000024fd628 [crypto] 100042 D crypto_ 0xffffa0000147a630 [crypto returns 0] 100043 D crypto_ 0xffffa0000147a680 [crypto returns 1] 15 0 0 0 DL seqstat 0xffffa000014ff888 [sequencer 00] 14 0 0 0 DL (threaded) [geom] 100035 D - 0xffff000002453e88 [g_event] 100036 D - 0xffff000002453e90 [g_up] 100037 D - 0xffff000002453e98 [g_down] 13 0 0 0 DL (threaded) [ng_queue] 100032 D sleep 0xffff0000021b1c60 [ng_queue0] 100033 D sleep 0xffff0000021b1c60 [ng_queue1] 2 0 0 0 RL (threaded) [clock] 100029 Run CPU 0 [clock (0)] 100030 I [clock (1)] 12 0 0 0 WL (threaded) [intr] 100012 I [swi6: task queue] 100013 I [swi6: Giant taskq] 100015 I [swi5: fast taskq] 100031 I [swi1: netisr 0] 100046 I [gic0,s0: spi0] 100047 I [gic0,s1: iichb0] 100048 I [gic0,s2: iichb1] 100049 I [swi0: uart] 100050 I [gic0,s42: mvneta0] 100053 I [gic0,s45: mvneta1] 100056 I [gic0,s3: xhci0] 100062 I [gic0,s17: ehci0] 100068 I [gic0,s26:-ci_xenon0] 100069 I [gic0,s27: ahci0] 100070 I [pcib0,0: nvme0] 100103 I [swi1: pf send] 100104 I [swi1: pfsync] 100125 I [swi1: netisr 1] 11 0 0 0 RL (threaded) [idle] 100003 CanRun [idle: cpu0] 100004 CanRun [idle: cpu1] 1 0 1 0 SLs wait 0xffffa000014d7000 [init] 10 0 0 0 DL audit_w 0xffff0000024fdb30 [audit] 0 0 0 0 DLs (threaded) [kernel] 100000 D swapin 0xffff0000024543e0 [swapper] 100005 D - 0xffffa000013ffd80 [softirq_0] 100006 D - 0xffffa000013ffc00 [softirq_1] 100007 D - 0xffffa000013ffa80 [if_io_tqg_0] 100008 D - 0xffffa000013ff900 [if_io_tqg_1] 100009 D - 0xffffa000013ff780 [if_config_tqg_0] 100010 D - 0xffffa000013ff600 [pci_hp taskq] 100011 D - 0xffffa000013ff480 [kqueue_ctx taskq] 100014 D - 0xffffa000013ff000 [thread taskq] 100016 D - 0xffffa000013fec00 [aiod_kick taskq] 100017 D - 0xffffa000013fea80 [deferred_unmount ta] 100018 D - 0xffffa000013fe900 [inm_free taskq] 100019 D - 0xffffa000013fe780 [in6m_free taskq] 100020 D - 0xffffa000013fe600 [linuxkpi_irq_wq] 100021 D - 0xffffa000013fe480 [linuxkpi_short_wq_0] 100022 D - 0xffffa000013fe480 [linuxkpi_short_wq_1] 100023 D - 0xffffa000013fe480 [linuxkpi_short_wq_2] 100024 D - 0xffffa000013fe480 [linuxkpi_short_wq_3] 100025 D - 0xffffa000013fe300 [linuxkpi_long_wq_0] 100026 D - 0xffffa000013fe300 [linuxkpi_long_wq_1] 100027 D - 0xffffa000013fe300 [linuxkpi_long_wq_2] 100028 D - 0xffffa000013fe300 [linuxkpi_long_wq_3] 100034 D - 0xffffa000013fe180 [firmware taskq] 100039 D - 0xffffa00001609d80 [crypto_0] 100040 D - 0xffffa00001609d80 [crypto_1] 100052 D - 0xffffa0000160aa80 [mvneta0: tx_taskq(0] 100054 D - 0xffffa0000160a900 [mvneta1: tx_taskq(0] 100055 D - 0xffffa0000160a780 [e6000sw0 taskq] 100071 D - 0xffffa0000160a300 [nvme taskq_0] 100072 D - 0xffffa0000160a300 [nvme taskq_1] 100073 D - 0xffffa0000160a180 [system_taskq_0] 100074 D - 0xffffa0000160a180 [system_taskq_1] 100075 D - 0xffffa0000160a000 [system_delay_taskq_] 100076 D - 0xffffa0000160a000 [system_delay_taskq_] 100077 D - 0xffffa0000160bd80 [arc_prune] 100101 D - 0xffffa00002493900 [ip_mroute_tskq task] 100105 D - 0xffffa00002494480 [acpi_task_0] 100106 D - 0xffffa00002494480 [acpi_task_1] 100107 D - 0xffffa00002494480 [acpi_task_2] 100109 D - 0xffffa0000160ad80 [CAM taskq] 100126 D - 0xffffa0000258f900 [z_null_iss] 100127 D - 0xffffa0000258f780 [z_null_int] 100128 D - 0xffffa0000258f600 [z_rd_iss_0] 100129 D - 0xffffa0000258f600 [z_rd_iss_1] 100130 D - 0xffffa0000258f600 [z_rd_iss_2] 100131 D - 0xffffa0000258f600 [z_rd_iss_3] 100132 D - 0xffffa0000258f600 [z_rd_iss_4] 100133 D - 0xffffa0000258f600 [z_rd_iss_5] 100134 D - 0xffffa0000258f600 [z_rd_iss_6] 100135 D - 0xffffa0000258f600 [z_rd_iss_7] 100136 D - 0xffffa0000258f480 [z_rd_int] 100137 D - 0xffffa0000258f300 [z_wr_iss] 100138 D - 0xffffa0000258f180 [z_wr_iss_h_0] 100139 D - 0xffffa0000258f180 [z_wr_iss_h_1] 100140 D - 0xffffa0000258f180 [z_wr_iss_h_2] 100141 D - 0xffffa0000258f180 [z_wr_iss_h_3] 100142 D - 0xffffa0000258f180 [z_wr_iss_h_4] 100143 D - 0xffffa0000258f000 [z_wr_int] 100144 D - 0xffffa00002590d80 [z_wr_int_h_0] 100145 D - 0xffffa00002590d80 [z_wr_int_h_1] 100146 D - 0xffffa00002590d80 [z_wr_int_h_2] 100147 D - 0xffffa00002590d80 [z_wr_int_h_3] 100148 D - 0xffffa00002590d80 [z_wr_int_h_4] 100149 D - 0xffffa00002590c00 [z_fr_iss] 100150 D - 0xffffa00002590a80 [z_fr_int] 100151 D - 0xffffa00002590900 [z_cl_iss] 100152 D - 0xffffa00002590780 [z_cl_int] 100153 D - 0xffffa00002590600 [z_ioctl_iss] 100154 D - 0xffffa00002590480 [z_ioctl_int] 100155 D - 0xffffa00002590300 [z_trim_iss_0] 100156 D - 0xffffa00002590300 [z_trim_iss_1] 100157 D - 0xffffa00002590300 [z_trim_iss_2] 100158 D - 0xffffa00002590300 [z_trim_iss_3] 100159 D - 0xffffa00002590180 [z_trim_int] db:1:pfs> alltrace Tracing command kernel pid 0 tid 100000 td 0xffff000002454940 sched_switch() at sched_switch+0x890 mi_switch() at mi_switch+0xf8 sleepq_timedwait() at sleepq_timedwait+0x2c _sleep() at _sleep+0x1a4 swapper() at swapper+0x80 mi_startup() at mi_startup+0x244 virtdone() at virtdone+0x68I really want that chip working. I was thinking if devs at pfsense can't get it going what makes you think I am going to do it .... well, I can see why its avoided like the plage
-
@JonathanLee said in SafeXcel EIP-97 only registering AES-CBC with OCF on SG-2100 (pfSense Plus 24.03):
At the 'OK' loader prompt (with pfSense Plus Installer USB plugged in):
OK run usbbootThat should be at the uboot (Marvell>>) prompt.
