If you are so lucky as to have an ixgbe(4) card, the version 3.3.6 driver (from Intel) are in DragonFly.
Note that I’ve managed to catch up to March commits! There’s been a lot.
If you are so lucky as to have an ixgbe(4) card, the version 3.3.6 driver (from Intel) are in DragonFly.
Note that I’ve managed to catch up to March commits! There’s been a lot.
On DragonFly, booting from a USB stick means your boot volume is usually /dev/da8. That’s a rather arbitrary distinction. As a bonus from the recent part-by-label device change, you can now find the boot disk in /dev/part-by-label/, named by the booted kernel rather than a device number. The commit message has a slightly better explanation.
There’s a bounty entry for Aarch64 support for DragonFly, on the bounties page. This is a difficult goal, but I think worth it. Add to it if you agree.
That somewhat symmetric title is to note a new device feature on DragonFly: if you use disklabel to label a disk, its parts will automatically appear under /dev. So, if you label a disk MYVOLUME, and it has 3 parts, a, b, and d, you will automatically gain a /dev/part-by-label/MYVOLUME.a, /dev/part-by-label/MYVOLUME.b, and a /dev/part-by-label/MYVOLUME.d.
Sepherosa Ziehau’s improvements to re(4), bringing it to Realtek’s 1.95 release, have been committed.
(Does Realtek have a public repo for this? A few minutes of Googling did not turn one up for me.)
Do you have Realtek hardware for your network link? Specifically, re(4)? Then Sepherosa Ziehau has a patch for you to try.
Some time back, Ján Su?an fixed up some firmware issues on DragonFly. He’s published a first stab at attaching firmware information to files; it’s up for review now and he’d like feedback. Please tell him what you think, if you’re interested in this topic.
If you were having trouble booting a DragonFly installer – or rather, you could boot but never find a disk to install on, this commit adding support for Sunrise Point, Lewisburg, Union Point, and Cavium ThunderX chipsets may fix your issue.
Two links I yoinked from conversation in EFNet #dragonflybsd: there’s a “powersave” power management page on dragonflybsd.org that for some reason wasn’t linked in the main documentation page. I fixed that, and you may want to look at it and change your mwait settings, or look at the corepower(4) module. (From ivadasz’s comments; thanks!)
There’s also an older page on DragonFly and grub2 that may be interesting to anyone looking to boot. (From aly’s comments; thanks!)
An oddly uplifting batch of BSD stories this week.
If you happen to have a Intel Centrino advanced 6035 wireless card, it now works on DragonFly, thanks to Tobias Heilig.
I’m actually surprised this wasn’t already there: Aaron Li added terminfo entries for tmux and tmux-256color into DragonFly’s terminfo(5) file. I’ve been using tmux without issue for some time on DragonFly… but I may not be exercising it as hard as I could.
There’s a section of the DragonFly website (a wiki) that records success with various laptops and DragonFly. The latest addition: Lenovo IdeaPad Y500.
arp(8) can now be limited to a particular interface on DragonFly; a minor change but I mention it because otherwise you may not realize it.
I should have mentioned this before, but: here’s how to use the virtio balloon memory driver in DragonFly, which is timely because it’s now in base.
I like to repeat this from time to time: loading the appropriate sound driver on DragonFly consists of loading all the sound kernel modules and seeing which one sticks, in dmesg . Chances are good it’s snd_hda anyway.
Did you use the digi(4), rp(4) and si(4) serial device drivers in DragonFly? I don’t think so, but you definitely can’t now.
If you are running DragonFly in a virtual environment, ‘ddegroot’ has put together a virtio_balloon driver for handling memory usage. (An explanation of the term) Try it if you can; he wants testers.
In case it’s useful to you, here’s several laptop recommendations for DragonFly.
Matthew Dillon recently fixed a TRIM bug, where a TRIM command was being issued unconditionally, regardless of the mount flag, and duplicating the action if it was set normally. It’s fixed now. This would only have any significant slowdown on UFS, which means it would only affect installworld – the rest of your mounted volumes are HAMMER, right?