If you are using the ATI Mach64 drm driver on DragonFly, Francois Tigeot would like to know. He’s done something that breaks it, but he’s making the educated guess that this more-than-10-years-old card is no longer in use.
Category: Device support
If you have a DragonFly system with an iwn wireless chipset, and you are having trouble connecting and running in the 5Ghz part of the spectrum only, here’s a tip: the -ht switch may fix it.
There’s been good progress in Francois Tigeot’s work on Haswell graphics support in DragonFly. If you have one of those newer units, you should be able to use the i915 driver with it now – as long as you keep acceleration off. (You won’t notice any difference in 2D anyway.)
If you have a i915 video chipset (which appears to be most every recent laptop), Francois Tigeot would like you to try his huge patch. It doesn’t support Haswell chips yet, though it lays some of the groundwork for it.
A frequent question people ask when trying Hammer is “How can I do software RAID to cover a disk failure?” Hammer provides for streaming one volume to another, so you can duplicate drives, but there isn’t an automatic failover mechanism as there is with a RAID setup. The first answer is usually “get hardware RAID“; my preferred solution. The remaining software solutions are vinum, ccd, and lvm for DragonFly.
If you were looking for something to do, finishing Francois Tigeot’s sound update would help a lot of people. He’s currently tied up with i915 support work. The patches need device cloning to work with devfs, and midi removal.
Tethering now works via the urndis(4) device, from a patch contributed by Sascha Wildner/tested by Yellow Rabbit.
(Updated for correct attribution)
Francois Tigeot has been working on making i915 video support work better; with his latest update, it’s worth trying the Intel-specific driver instead of vesa if you have both the 915 chipset and are running X.
Matthew Dillon changed powerd on DragonFly so that the system is set to max performance if powerd is killed. Now you’ll know why your fans turned on!
The mfi(4) driver has had some data corruption problems on “Thunderbird” series RAID controllers. There’s a newer driver, mrsas(4), that replaces mfi(4) for these controllers and does not have these issues, but switching may mean new drive locations and therefore some work to get booting correctly again. Sascha Wildner has an extensive writeup about what this entails, and how to switch now if you have that hardware (recommended).
The max number of CPUs on DragonFly just went from 63 to 64. This is really just a side effect of preparation to move up that limit, but I am entertained by the single-digit bump.
Did you try to install DragonFly relatively recently and it never made it past the bootloader? Apparently there’s a bug in some BIOS when using a smaller USB drive to install. The loader checks multiple places for information, and if it checks somewhere that’s ‘farther’ than the end of the disk (i.e. 6G on a 4G USB key), the machine locks up.
Matthew Dillon and Kyle Davis spent a good number of hours figuring this out today, and Matt committed a fix. So, if you were bit by this problem, try a -LATEST image about 24 hours from now and see if it works.
Sascha Wildner has added the mrsas(4) driver, which works on a variety of LSI Thunderbolt devices – a variety of RAID cards, names for which are listed in the commit message. Note that as of right now, these devices by default get taken by the mfi(4) driver, so you need to take extra steps to get mrsas(4) used.
If you have DragonFly on a laptop, and a docking station for that laptop, it may be better supported now. (no, I don’t know exactly what acpi_dock does.)
A relatively calm week – probably because there were many people at BSDCan.
- DiscoverBSD’s summary for 2014/05/19.
- Undeadly has a summary post linking to all the OpenBSD presentations at BSDCan.
- OpenBSD and the little Mauritian contributor. Hey, Loganaden was in the DragonFly GSoC… 3 years ago? It blurs together.
- Julio Merino’s trip to BSDCan 2014 and his thoughts on Jenkins and Kyua after. I completely agree with what he says about BSD conventions: being around so many other people all excited about the same topic really energizes you.
- CoovaChilli on FreeBSD.
- NetBSD has support for the HYT-221/271/939 humidity/temperature I2C sensor.
- Hey, that was nice of Mediatek to provide a free license for rum(4) in OpenBSD.
- The EuroBSDCon papers deadline is extended a bit.
- You can now see what your battery is supposed to have for capacity on OpenBSD.
- Apache 1.3 and 2.0 are already depreciated and probably coming out of pkgsrc.
- FreeBSD gains a driver for the Intel 40G Ethernet Controller XL710. There’s a long discussion on the list about the nonstandard i40evf name breaking things.
- FreeBSD has sendmail 8.14.9.
- FreeBSD has gained CUSE support. I can read what it does but don’t know where it’s used.
Matthew Dillon brought in Adrian Chadd’s sleep state changes for the ath(4) driver from FreeBSD to DragonFly; you may see reduced power usage if you have the appropriate hardware.
If you’re using DragonFly in qemu, virtualbox, whatever – but not VMWare – there’s a new virtio-net driver to try out.
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.