Sascha Wildner has
added the PCI IDs for various recent ichsmb(4) devices. This I think just means a correct device name in dmesg, but unidentified smbus devices has plagued me for years, even with other operating systems.
If you’re running an
em(4)/emx(4) network card on DragonFly, Sepherosa Ziehau’s updated to the 7.7.8 release of the driver from Intel, and added a few more chipsets too.
If you have a Broadcom BCM57785/BCM5718 series network card, supported by the
bnx(4) driver, there’s some new models supported. There’s some fixes for other models, too.
I am not sure if
these Radeon cards are tested on DragonFly, but it’s a good base to start from.
If you edit /etc/fstab, and then later change something like the proc filesystem from OpenJDK, you might not boot normally. Antonio Olivares has a
solution for you.
MAP_VPAGETABLE has been removed in DragonFly because of conflicts with recent pmap work. This has the unfortunate effect of breaking vkernel(7), but vkernels can be resurrected with changes to use hardware virtualization support.
Note that running DragonFly as a VM is unaffected; that’ll still work just fine. This breakage is DragonFly-vkernel-on-DragonFly specific.
It took me a while to figure out you have to press down on the switch, not rotate.
So, if you find yourself in possession of an ADM-3A terminal, and want to attach it to a DragonFly machine, here is the /etc/ttys config (viewed on the ADM-3A itself of course) and the front switch settings that worked for me.
Remember, ^h deletes.
DRM in DragonFly has been updated to
match Linux 4.15.18, along with recognizing some new hardware.
I realized I never followed up on the
call for testing: re(4) driver updates from Sepherosa Ziehau were indeed tested and found good, so the driver has been updated.
If you have a Realtek network card supported by the
re(4) driver, Sepherosa Ziehau has a new driver for you to test.
If you’ve got a Zen 2 /
Ryzen 4000 APU, the amdsmn(4)/ amdtemp(4) drivers in DragonFly now support it.
Well, it doesn’t fix anything, but it seems like an answer that almost always helps:
running sysmouse usually fixes most X11 mouse problems.
If you buy a Lenovo Yoga 500, or any laptop with an
iwm(4) chipset, here’s how to get it going with DragonFly.
Apparently DragonFly used to disable IOAPIC when booting in a virtual machine. This helped with some old virtual machines, but broke newer ones.
It’s now enabled, which helps boot DragonFly on Google Cloud.
If you’ve got a newer i219 ethernet chipset – it’s now
supported in DragonFly.
I didn’t know this, but the label in
disklabel(8) is called “pack ID” in the man page, and there’s only one way to update it right now in DragonFly. You may only need to know this a few times in your life.
Something I didn’t know but also never tried: ttyv0, the base terminal when booting up DragonFly, can
extend to a max of 160 characters. Given that I am used to 80, that seems like overkill.
For those with a different keyboard layout – different than US English, I mean – and running xorg 1.20 or later:
setxkbmap is the command you need.
If you have an AMD processor, support for the
System Management Network and CPU temperature readings are now available in DragonFly as amdsmn(4) and amdtemp(4).
If you’re running a very recent HP laptop,
this recent DMAP change may get DragonFly to boot on it.
EDIT: this MSIX fix, too.