If you have an AM4 motherboard and also can’t EFI boot DragonFly on it, this recent change may fix that for you.
Also, if you are using a Corsair keyboard, this commit may be useful to you.
If you have an AM4 motherboard and also can’t EFI boot DragonFly on it, this recent change may fix that for you.
Also, if you are using a Corsair keyboard, this commit may be useful to you.
It’s supported, and given how well DragonFly supports SMP and the number of processors Zen 2 supports, it’s a no-brainer if you’re in the market for a new server.
Francois Tigeot has updated the radeon driver in DragonFly to match what’s in Linux kernel 3.19.8. No, wait, I took too long to post this cause there’s been so many things, so now it’s up to 4.4.180.
If you are running an em(4) or igb(4) device in DragonFly, Sepherosa Ziehau has updated the drivers. This brings it to Intel driver versions em-7.7.4 and igb-2.5.6.
This could be an In Other BSDs item, but it’s worth highlighting: saugns is a “Scriptable AUdio GeNeration System”; a utility for generating sounds – specifically FM modulation, in a way that will make you think “synthesizers!” There’s a whole language behind it, and the program, as the author, Joel K Pettersson, points out, compiles with no trouble on every BSD.
The module formerly known as ‘radeonkms’ is now just plain ‘radeon’. There have been changes in other commits, but this is the only usage change.
‘evdev‘, a driver for input device events, is now built by default in the DragonFly kernel. Update your custom config to match, if you have one.
You’ll all be happy to know ACPI errors are less noisy now. (And it was updated to 20190509, before the 5.6 release.)
Francois Tigeot updated ttm and radeon DRM in DragonFly to match what’s in I assume the Linux 3.18 kernel. Please try if you have the appropriate hardware. This was at the start of May, so you may have already done so without realizing if you run -current. It’ll be in the 5.6 release, too.
Remember the commit that autocreates human-readable disk device names under /dev? (Here’s a reminder.) It’s now in 5.4 – technically, since 5.4.2. Anyway, it will automatically identify the root USB disk when you boot from a USB .img file, so you no longer have to guess which /dev/daX file it was – usually da8 but sometimes you got a surprise instead.
This timer fix enables booting DragonFly on AWS. Well, that and the ena(4) driver. I haven’t tried it yet.
Sepherosa Ziehau has an update for em(4)/igb(4) network cards, for you to test if you have the matching hardware. It looks like this is an update from the vendor, Intel, going by the version numbers.
If you want to hear nothing at all from ACPI, no matter what, set debug.acpi.silence_all to 1. In related news, DragonFly has just updated to Intel’s ACPICA version 20190329.
The show subcommand for gpt(8) has had some improvements including a way to connect it to the device UUID; I link to it cause depending on the age of your machine, you may have never even needed to use gpt yet.
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.