Category: Device support
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.
Sascha Wildner has committed Markus Pfeiffer’s port of USB4BSD to DragonFly. USB network, input , audio, and storage devices (including xhci/USB3 items) may work, though there’s no guarantee for each driver. This is added but not on by default, so see the first link for instructions on how to rebuild your kernel to use it. This will be in (but not default) the DragonFly 3.2 release.
(This is shaping up to be a much bigger release than I anticipated!)
Much of this new document has been around in other forms for a while, but now, there’s a brief guide on porting drivers to DragonFly in the source tree.
I noticed that this recent commit from Sepherosa Ziehau is a bug fix for jme(4). The commit thanks a JMicron employee for help. It’s always appreciated when a vendor is helpful to an open-source project for hardware support. It’s also something you should consider the next time you are shopping for computer parts.
Pierre Abbat is curious about using Hammer on an SSD. The discussion that came from that has some useful points, including notes that a straightforward SSD as disk works for most anything with Hammer other than very intensive database use, due to the history retention. If space is an issue, swapcache on the SSD and attaching a normal HDD is a fine alternative. A SSD with Hammer can leave some features off, though I’d argue that dedup is totally worth is. Also, SSD speed is directly correlated with size.
Sepherosa Ziehau’s added TSO support (that’s TCP Segmentation Offloading”, or “Large Segment Offload” going by Wikipedia) within IPv4 on DragonFly, pushing segmentation work from the CPU to the network card. There’s also some DragonFly-specific improvements.
There’s been a lot of commits from him lately focused around network card improvements; they haven’t been easily summarizable, but it’s worth watching if you are interested in high-bandwidth usage and the hardware to support it.
Not all flavors of Atom CPU support frequency scaling, as Sven Gaerner found out. This means more heat and more power usage. There’s further details scattered through the thread, but Sascha Wildner found what seems to be the definitive answer of which variants do and do not.
Someone trying DragonFly couldn’t get it to start, and appeared to have a confused disk. It looks like the system BIOS were at fault, and Matt Dillon has an explanation of this minefield. (Including some comments on 4k physical disk sectors.)
New company Gainframe is offering up OpenBSD dmesg/pcidump/usbdevs output for every system they build. I was originally going to link to this in a Lazy Reading entry, but then I realized it’s also a new company specializing in BSD-compatible hardware. Read the interview; I met Michael Dexter at the last NYCBSDCon and he is a decent guy.
We need more of this sort of specifically targeted work. Sites that rely on crowd-sourced contribution are good, but it’s not necessarily comprehensive, and you need a very large crowd for it to work.
If you are having USB issues on boot with DragonFly, Sepherosa Ziehau’s sysctl suggestions may help you.
Venkatesh Srinivas posted an explanation of the virtio update he’s working on. I linked to the work before, but not his explanation, which goes into the ‘vm_balloon’ device.
Sascha Wildner has updated mfi(4), the LSI MegaRAID SAS driver , via FreeBSD and LSI. SAS2208-based controllers are now supported.
I’ve seen a few people complain about poor video performance in DragonFly, in Xorg. If you see a bunch of “contigmalloc_map: failed …” errors in your dmesg, your video card needs more contiguous memory allocated. Set vm.dma_reserved to 32M in /boot/loader.conf and you should be set. If that doesn’t work, try 64M.
Notice how the 2.12 release never really happened, and 3.0 came out about 6 months later than usual? A lot of that delay was caused by a vigorous search for a weird bug. Multi-threaded buildworlds would crash, seemingly randomly and rarely. It turns out we have confirmation from AMD that it is, indeed, a CPU hardware bug.
Is it possible to boot with only 48M of RAM in a DragonFly system? Probably not. 128M would be better. I usually talk about the lower memory limit for Hammer, since it’s so relatively low for a snapshotting file system, but the converse applies here. 128M is probably the comfortable lower limit, though it’s pretty hard to find a system that would limit you that way without doing it on purpose. 128M sticks of RAM are practically disposable these days, really.