If you’re using DragonFly in qemu, virtualbox, whatever – but not VMWare – there’s a new virtio-net driver to try out.
Category: Device support
In a thread about video cards on DragonFly, Francois Tigeot listed good ATI cards to try, and pointed out the VESA driver is probably your best bet right now with NVidia cards.
The acpi_thinkpad module (section? code?) has been updated. Update if you are on DragonFly 3.7, or be patient if you are on 3.6.
DragonFly has moved from the old USB stack to USB4BSD by default. That means:
- If you are already using USB4BSD, you will want to remove WANT_USB4BSD from your kernel config.
- If you have trouble, switch back to the old USB.
- There’s some drivers that are not yet converted; help with them would be appreciated.
- A full kernel/world build and ‘make upgrade’ will be needed in either case.
Sascha Wildner’s announcement email has all the gory details, including the kernel config changes to move back to the old USB setup. This is of course in master; 3.6 users are unaffected.
Sascha Wildner has updated arcmsr(4), which brings in support for the Areca ARC1214, ARC1224, ARC1264, ARC1284, and ARC1883 models, from FreeBSD. Please test if you have the appropriate hardware.
If you have i915 chipset-based video on DragonFly, and you get a “Output xxx has no Monitor section” complaint in your xorg logs, look at this fix using xrandr.
Here’s a potential DragonFly and Summer of Code project: adding support for more than 63 cores to DragonFly. Matthew Dillon has already outlined how.
It’s now possible to reach deeper power-saving C-states with DragonFly, thanks to work from Sepherosa Ziehau. It’s possible to have it auto-adjusted by setting two sysctls.
There’s been periodic commits updating the USB4BSD support in DragonFly; I haven’t been linking to them because they are generally incremental. However, it’s good to (re?)mention just how you can build DragonFly with that new USB support.
xf86-video-intel-2.21.15 should now work on your DragonFly system. I don’t see it in dports, yet, though.
With everyone buying tablets lately, the low end of computers is getting pretty low-cost indeed. Creating single-purpose computers is possible, and I was thinking of doing that to create a Go-testing system. (Though probably not necessary for me.) It got me to thinking, though…
How low-cost a system could run DragonFly? The master-slave and low system requirements of Hammer lead to some interesting possibilities. There’s no Arduino equivalent for DragonFly because there’s no DragonFly on ARM, despite all my wishing. DragonFly has been run on Soekris systems before, and might work on a PCEngines ALIX board. Ebay, my basement, or Craigslist are options too, but not as fun. Who has suggestions?
I didn’t post this before, and should have: Matthew Dillon posted a summary of all the trackpad improvements he added, and how to make use of the various features.
ISA device support is really gone. Well, except for keyboard and some spots where it can’t be be removed. I don’t think I’ve even seen an ISA card in some years…
If you’re planning to run DragonFly in KVM, remember this post from Matthew Dillon, giving the settings he uses. This will save you a bit of time.
I stole Sepherosa Ziehau’s email subject for the title of this post, because that’s exactly what has happened. Gigabit networking cards under DragonFly will perform very well under extreme load – all of them.
The Radeon KMS driver from FreeBSD has been imported to DragonFly by Francois Tigeot. It still has problems with ttm, but don’t let that stop you from taking advantage of it.
Francois Tigeot posted his work on the KMS driver for Radeon video cards. He’s looking for help since he’s low on time for the immediate future, and this is a project that could benefit everyone. (Well, everyone with the right video card.)
I’m just going to roll all these updates from Sepherosa Ziehau together into one post, because it’s a lot: He’s updated igb(4) to 2.3.10, updated em(4) to 7.3.8, merged the hardware abstraction layer of those two drivers, enabled TSO on all PCI-E em(4) chipsets, and added support for a whole slew of Realtek chipsets in the re(4) driver. Whew!
If you’ve got a MCP79 NVIDA-chipset board, Sascha Wildner’s commit of Ed Berger’s port from OpenBSD has you covered.
If you’re curious about the hardware being used for the colocated dragonflybsd.org servers (this includes the website, the repository, the mailing lists, dports build machines, etc.), here’s the ‘MicroCloud’ product page. DragonFly’s model was purchased from iXsystems. Apparently those Haswell processors have a fantastic power consumption to performance ratio. (via)
I’d be really surprised to find this affects anyone, but it’s possible: some kernel options specific to Cyrix processors have been removed, by Sascha Wildner.
If you have a computer with one of the very-very-new Haswell processors from Intel, Matthew Dillon has made some changes that will interest you. They shave off (in the example given) about 20% of CPU power usage without much effect on performance.
Thanks to the effort of a number of people, DragonFly (-current) now supports KMS and accelerated video on Intel 915 chipsets. It’s 2D and x86_64 only for now, but it’s much, much better than just using the vesa driver.
Thanks to the efforts of a large number of people, KMS support is showing up in DragonFly. This supports accelerated video on the new Intel graphics chipsets that seem to show up on many recent laptops.
From the man page: “The tpm driver provides support for various trusted platform modules (TPM) that can store cryptographic keys.” Crypto keys stored in hardware, where they are in theory unmangleable, instead of on the disk. At least, that’s my impression after 30 seconds of research.
John Marino brought up a point every operating system project will have to think about: when does support for i386 (i.e. 32-bit x86 processors) stop? Follow the thread for details. There’s no final answer, yet.
If you have a mfi(4) device – in other words, a LSI MegaRAID SAS driver – you can now see/import/clear/etc. foreign configurations, thanks to this commit from Sascha Wildner, tested by Francois Tigeot, and originally from FreeBSD.
For the confused, ‘foreign’ means any disk hooked to a RAID controller that isn’t part of a configuration the RAID device already knows about. A replacement disk, or more worryingly, a good disk gone bad/unrecognizable. (I’ve had both.)
If you have an ath(4), wpi(4) or iwi(4) wireless network link, and you’re running DragonFly-master, please update. Sepherosa Ziehau has pushed Johannes Hoffman’s wlan_serialize branch, which means bringing up wlan0 is a bit easier – and less crashy.
It needs to be tested for wpi(4) and iwi(4), however, so if you have success or failure with those devices, please say so in reply.
(new post category starting now: “Please test”)
It seems Sepherosa Ziehau won’t rest until he’s reached peak performance for every network card in DragonFly; he’s added multiple ring/MSI-X support for Broadcom 5709/5716 chipsets in DragonFly. In more concrete terms, this means better speeds when transmitting and receiving multiple streams of data.
(at least, I think so.)
Sepherosa Ziehau has posted more statistics on his ifnet/ifaddr per-CPU stats work. It’s doing so well that he’s very close to reaching the maximum physical capacity of the 4x gigabit ethernet hardware he’s using.
The emx(4) driver now has support for multiple TX queues, but it’s not on by default. There’s scenarios where multiple queues work out with that hardware, but you have to be sure you are actually in the right setup for that first. Check Sepherosa Ziehau’s commit message for the details.
Quick summary, the multiple TX queue support gives me: +200Kpps for 2 bidirectional normal IP forwarding (now 4.40Mpps) +160Kpps for 2 bidirectional fast IP forwarding (now 5.23Mpps)
Will Backman has a new BSDTalk episode up, with a bit of Peter Salus from BSDCan 2011 and a bit of Raspberry Pi on FreeBSD.
We need more fiddling-with-BSD-on-hardware stuff out there. That would be a good thing for Youtube – hint, hint.
Sepherosa Ziehau makes commits almost daily to DragonFly’s network infrastructure, but I have a hard time quantifying it into Digest posts in part because it’s often very technical. His most recent commits come with an explanation, however. He has done plenty of work to improve overall transmission speeds in DragonFly, and now he’s working on ‘fairness’. Fair, in this case, means ensuring that packet transmitting and receiving happen without either one monopolizing the connection. In real world terms, this translates to much more constant speeds. His recent commit details what he’s doing and some numbers to prove it.
Remember I said he’s improved speeds? Note that in his example, he’s reaching stable peaks of 981 Mbps. This is on a line that I assume theoretically maxes out at 1000.
I’m not sure what IFQ stands for, but Sepherosa Ziehau’s added it. It appears to be based on an idea from Luigi Rizzo called ‘netmap‘. In this case, network packets are grouped together before being placed onto the network interface’s hardware queue. That means better packet per second performance without a corresponding increase in CPU usage, as Sepherosa Ziehau’s report lists, along with needed sysctls.
Sepherosa Ziehau has been making a lot of commits to increase packet-per-second rates without increasing CPU usage. He’s published a sort of progress report/benchmark to show current performance levels. It sounds like he’s expecting even better performance in the future, though I’m not sure how much more he could push out of it, since the bulk performance appears to be close to the rated capacity of the copper…
Sascha Wildner has added system management BIOS (SMBIOS) support, visible with kenv, from FreeBSD. Use it for getting things like the BIOS revision, system manufacturer, and so on. For example:
smbios.bios.reldate="12/04/2006" smbios.bios.vendor="Dell Inc. " smbios.bios.version="2.1.0 "
This may seem minor, but this can be very helpful when dealing with hardware you aren’t physically able to access.
Sepherosa Ziehau is switching a number of network cards over to use ifpoll, which means they will have capabilities similar to MSI-X, even if the network card doesn’t support it. My suspicion is that it will make these cards perform better in busy situation where they would otherwise get bogged down… but that’s based on hunch rather than empirical testing. As Sepherosa Ziehau pointed out, it certainly can’t hurt.