Chelsio T6225-CR has arrived

Boot messages for stable/11:

t6nex0: <Chelsio T6225-CR> mem 0xfac80000-0xfacfffff,0xf9000000-0xf9ffffff,0xfaff6000-0xfaff7fff irq 16 at device 0.4 on pci6
t6nex0: firmware on card ( is older than the version bundled with this driver, installing firmware on card.
cc0: <port 0> on t6nex0
cc0: Ethernet address: 00:07:43:XX:XX:X0
cc0: 4 txq, 4 rxq (NIC); 4 txq, 2 rxq (TOE)
cc1: <port 1> on t6nex0
cc1: Ethernet address: 00:07:43:XX:XX:X8
cc1: 4 txq, 4 rxq (NIC); 4 txq, 2 rxq (TOE)
t6nex0: PCIe gen2 x4, 2 ports, 14 MSI-X interrupts, 31 eq, 13 iq
pci6: <mass storage, SCSI> at device 0.5 (no driver attached)
pci6: <serial bus, Fibre Channel> at device 0.6 (no driver attached)

Output from ifconfig:

cc0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ether 00:07:43:XX:XX:X0
        hwaddr 00:07:43:XX:XX:X0
        media: Ethernet 25GBase-SR <full-duplex,rxpause,txpause>
        status: no carrier
cc1: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ether 00:07:43:XX:XX:X8
        hwaddr 00:07:43:XX:XX:X8
        media: Ethernet 25GBase-SR <full-duplex,rxpause,txpause>
        status: no carrier

None of the ports are connected. I’m waiting for SFP+ modules to arrive.


BTW. The Gutenberg Editor for WordPress is a nightmare in conjunction with the SyntaxHighlighter plugin. I went back to the Classic Editor which gives me far more control.

Chelsio T6225-CR and SM25G-SR

I recently ordered a Chelsio T6225-CR network interface card and a couple of SM25G-SR SFP28 optical modules.

The aim is to get a 10 Gbit/s connection to the LAN, utilise the off-load capabilities of the NIC, and of course utilise the on-board crypto accelerator. The latter will not be useable until the system moves to the upcoming stable/12 branch.

Speaking of stable/12, I look forward to encrypted crash dumps and linear ZFS scrubbing.

I hope both OpenSSH and OpenSSL will be able to use the crypto accelerator by ways of crypto(4). Imagine a crypto speed in excess of 30 Gbit/s. That’s pretty neat. If all goes well, another T6225-CR may find its way to a VPN router.

Kernel panic due to memory corruption

This is what a kernel panic may look like when facing memory corruption.

kernel: panic: solaris assert: arc_buf_alloc_impl(hdr, private, compressed_read, 1, &buf) == 0 (0x5 == 0x0), file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c, line: 5318
kernel: cpuid = 1
kernel: KDB: stack backtrace:
kernel: db_trace_self_wrapper() at 0xffffffff8046b52b = db_trace_self_wrapper+0x2b/frame 0xfffffe0122681380
kernel: vpanic() at 0xffffffff806c5ba6 = vpanic+0x186/frame 0xfffffe0122681400
kernel: panic() at 0xffffffff806c5a13 = panic+0x43/frame 0xfffffe0122681460
kernel: assfail3() at 0xffffffff8030987c = assfail3+0x2c/frame 0xfffffe0122681480
kernel: arc_read() at 0xffffffff80322ddc = arc_read+0x83c/frame 0xfffffe0122681510
kernel: dbuf_read() at 0xffffffff8032e918 = dbuf_read+0x678/frame 0xfffffe01226815c0
kernel: dmu_buf_hold_array_by_dnode() at 0xffffffff80338bf3 = dmu_buf_hold_array_by_dnode+0x203/frame 0xfffffe0122681630
kernel: dmu_read_uio_dnode() at 0xffffffff8033a167 = dmu_read_uio_dnode+0x37/frame 0xfffffe01226816a0
kernel: dmu_read_uio_dbuf() at 0xffffffff8033a10b = dmu_read_uio_dbuf+0x3b/frame 0xfffffe01226816d0
kernel: zfs_freebsd_read() at 0xffffffff803d7e80 = zfs_freebsd_read+0x660/frame 0xfffffe0122681780
kernel: VOP_READ_APV() at 0xffffffff80a7b77c = VOP_READ_APV+0x7c/frame 0xfffffe01226817b0
kernel: vn_read() at 0xffffffff807a0815 = vn_read+0x195/frame 0xfffffe0122681830
kernel: vn_io_fault1() at 0xffffffff8079e4e9 = vn_io_fault1+0x169/frame 0xfffffe0122681970
kernel: vn_io_fault() at 0xffffffff8079c6ac = vn_io_fault+0x18c/frame 0xfffffe01226819e0
kernel: dofileread() at 0xffffffff807291aa = dofileread+0xba/frame 0xfffffe0122681a20
kernel: kern_readv() at 0xffffffff80728db8 = kern_readv+0x68/frame 0xfffffe0122681a70
kernel: sys_read() at 0xffffffff80728d46 = sys_read+0x86/frame 0xfffffe0122681ac0
kernel: amd64_syscall() at 0xffffffff809d5f18 = amd64_syscall+0xa38/frame 0xfffffe0122681bf0
kernel: fast_syscall_common() at 

pkg add chokes on apparantly wrong OS version

I’m experimenting further with ports-mgmt/synth. I let synth create some packages for me and I then removed all installed packages, save the pkg package manager.

What a surprise I got when attempting to add my own metaport! Continue reading pkg add chokes on apparantly wrong OS version

Boot menu changes in base/head r325694

Update 2017-11-13
r325743 corrected the mistakes. The below no longer applies. Remove /boot/loader.rc.local if you created it.

/boot/loader.rc used to be copied from base/head/sys/boot/i386/loader/loader.rc on FreeBSD/amd64. With r325694 this changed to base/head/sys/boot/forth/loader.rc. Nothing was added to base/head/UPDATING, explaining this change.

As instructed in /boot/loader.rc, to regain our beloved boot menu, we must create and edit /boot/loader.rc.local, essentially redoing what was handled by the previous /boot/loader.rc.

include /boot/beastie.4th

portupgrade uninstall error, broken pipe

I too was bitten by the portupgrade uninstall error, due to broken pipes, on my laptop running FreeBSD/amd64 stable/10. Others have identified the file 5.26 utility as the culprit, introduced in stable/10 as r298920.

Watch PR 209211 for any progress. base/head was corrected at r299234, and stable/10 will follow soon. Continue reading portupgrade uninstall error, broken pipe

Memory leaks in recent stable/10 kernel

All FreeBSD systems under my care got upgraded last Friday to fix some NTP bugs. That upgrade introduced a new bug in the kernel. The bug first appeared at r298004 in base/head, and later at r298134 in base/stable/10. The i386-based systems were more notably affected than the amd64-based systems, as the former typically has less memory than the latter. Continue reading Memory leaks in recent stable/10 kernel

Replacing drives on AMANDA server

I spent some days last week converting our 32-bit AMANDA server to a 64-bit counterpart using spare but aged hardware. The former AMANDA server ran on very aged hardware in comparison. Going 64-bit also ment turning to ZFS-based storage.

Today, I replaced the two 320 GB first generation SATA drives with two 1 TB third generation SATA drives. The new drives, like their predecessors, are connected to the second generation SATA controller on the motherboard. Replacing the drives is nevertheless an improvement. Continue reading Replacing drives on AMANDA server

FreeBSD’s UEFI boot loader now supports ZFS pools

As of r294999 it’s possible to boot FreeBSD/amd64 stable/10 from ZFS pools on systems running UEFI firmware. Up until now I have booted my UEFI ZFS laptop using the older boot1.efi boot loader with /boot located on a UFS partition. Earlier today I updated my EFI System Partition (ESP), put /boot back where it belongs, in the ZFS pool, and scrapped the UFS partition. Thanks to everyone who made this happen.