Sascha Wildner has pushed smart battery support, based on a patch from Dmitry Komissaroff and FreeBSD. He asks people to try it out. It apparently provides for more accurate battery charge level readings?
Category: Device support
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.
Edward Berger found that using a LG/Hitachi DVD drive kept him from successfully booting a DragonFly install CD. Using other manufacturers worked out fine. What causes the problem? I don’t know, but it’s worth mentioning it out loud in case someone else gets bit by it.
I need to catch up on some older stuff, so here is a longer list of recent updates: libarchive to 3.0.2, xz to 5.0.3, mfi(4) and mfiutil(8) (LSI MegaRAID driver) updated, ATI SB7x0/SB8x0/SB9x0 AHCI devices (on motherboards I assume) updated, and the PHY ID for the Atheros F1 added. Thanks to everyone who did the work! I bet I missed something.
That’s Managed System Interrupts, for when your hardware is passing a lot of data and generating a lot of corresponding hardware interrupts. MSI is what deals with all that traffic. High-bandwidth (10G) network cards, for instance. Anyway, Sepherosa Ziehau’s made more commits than what I’m linking to here, for support with various devices.
There’s many other MSIs out there, oddly enough.
Sepherosa Ziehau has
added updated the ‘ecc’ device, for Intel E3-1200 series systems. What’s it do? It will report on memory errors, and potentially fix them.
You should have ECC memory in your server already. If not, you oughta.
Matthew Dillon has written a contiguous memory mapper, which is designed to fix problems with video cards and USB drives that need a big chunk of memory to keep. This can affect booting or later on, when disconnecting/reconnecting a USB drive. If this still doesn’t fix the problem for you, try adjusting the sysctl ‘vm.dma_reserved’ to something bigger, like 64M. It defaults to 16M.
(Normal mailarchive isn’t updating because of an ongoing upgrade to crater.dragonflybsd.org – sorry!)
It’s snowing in the northeast U.S., which makes me happy! Keep going, sky!
- Richard Stallman’s requirements when giving talks/lectures. (via) I read this not unreasonable but long list and thought about it. Every requirement on there probably has an experience/story behind it… (“If you can find a host for me that has a friendly parrot, I will be very very glad.” – so this)
- Continuing the famous computer people trend of dying, John McCarthy died. He invented LISP (((insert parentheses joke here))) among other things, and wrote this story. (also via)
- I mentioned issues over the time zone database previously, but there’s a new home, and we’re still getting updates in DragonFly.
- And, it’s Dennis Ritchie Day. (via) That linked article does a good job of describing just how universal his influence has been.
- 64-bit ARM chips. (design PDF) This is just the announcement, but I bet these will be a good porting target in the next year or two if these designs wander out into the general market. (via many places)
- I’ve linked to similar deals before, but this one’s quite cheap: the Power Squid power strip sold as surplus. I find the design and name both great.
- Speaking of names, “I think Dragonfly is the coolest, cuz of the name.“
- I like this article on web advertising just because it has blocked-out screenshots that show exactly how much space gets used up by ads.
That would be a recent ATI card, though I don’t know exactly which model name. Samuel Greear has imported David Shao’s DRM work, originally for Summer of Code, last year. Most newer Radeons should work (?).
I did not realize this, but MMC/SD cards are not supported in the default DragonFly kernel. Or at least, they weren’t until now. (also committed to 2.12)
Update: PCI-based MMC/SD readers, specifically. USB ones were already recognized as umass devices.
It looks like Sepherosa Ziehau is working on hardware support being split up per-CPU, judging by this commit – one of many, recently.
Some newer laptops have Intel integrated video chipsets that require GEM/KMS to work well; they are supported by the vesa driver in X, but performance isn’t great. Johannes Hofmann found this out the hard way. GEM/KMS support is on the way for various BSDs, but it’s not here yet. Just be aware of this if shopping for a new laptop in the next little while…
If DragonFly/x86_64 fails to install on your system, but DragonFly/i386 works, try again. Sepherosa Ziehau has a fix for the keyboard controller that may make x86_64 systems boot DragonFly when previously they did not.
It sounds like I’m about to mention something pirate-themed, doesn’t it? Brendan Kosowski needs the rum(4) driver, for (I think) Ralink RT2501USB and RT2601USB wireless. He’s willing to offer a bounty of $100 to anyone who can get it working before the next DragonFly release. Work on it if you can port, or add money if you can use it.
Sepherosa Ziehau has been making a lot more changes to the msk(4) driver for Marvell Ethernet chipsets. I link to this commit adding support for Yukon Supreme cards, but there’s a great deal of work from him, recently added.
17 different ISA device drivers have been removed by Sascha Wildner. The commit message has device descriptions. This may mean you need to change your kernel configuration file on the next buildkernel, since some of them were in the GENERIC kernel. If you need any of them, speak up. (I don’t think I’ve ever used any of them. Oh darn.)
Thanks to Michael Neumann, there’s more supported Broadcom network card chipsets. There’s some wierdness in setup, though, so look at his commit message.
If you happen to use a LG P-500 smartphone to get online via USB, as ‘Romick’ does, he’s got a patch that makes that device work under DragonFly. (Sorry, the original users@ email seems to have gone missing.)
Francois Tigeot has repeated his benchmarking, this time changing out the CPU instead of the operating system. There’s still more graphs, yay!
Do you have a DragonFly workstation? That you play audio on? Do you have headphones hooked up? Is it using Intel High Definition Audio? (snd_hda) Does connecting the headphones disable the system speaker?
You can probably guess exactly what I’m trying to troubleshoot given the above questions.
Here’s two items I meant to post and for some reason did not:
- Sven Gaerner posted a short description of how he migrated his DragonFly system from a hard disk to a SSD. This may be useful for anyone considering a move. Decent-sized SSDs are reaching low prices these days.
- Tim Bisson posted an update on his work on TRIM support for DragonFly. The code is available now if you’re feeling lucky.
Sepherosa Ziehau’s made it possible for uniprocessor kernels to use the LAPIC and IOAPIC functions on x86_64, which means better timer support, less need to fiddle with configs, and more supported hardware. A win all around! Set hw.lapic_enable=”0″ if there’s trouble. The same changes for i386 are on the way.
I haven’t covered recent disk encryption work evenly, here, so I’ll point at a recent discussion instead. Alex Hornung mentioned a cryptsetup(8) man page that may help, as does any dm-crypt tutorial out there on the Internet. (DragonFly has the same userland tools.) The DragonFly installer will create encrypted disks at install time, too.
The I/O APIC is now always on unless you say otherwise. This may not make a clear difference to you, but enabling that kernel option has always been a somewhat iffy thing; working for some configurations and not others. Now, it’s one less thing to worry about.
I posted something about this before, but now it’s definite: bleeding-edge users of DragonFly can boot a multiprocessor kernel on a single-processor machine.
If you’ve ever wanted to really make sure of all the network interfaces supported on your DragonFly system, you can create an exhaustive (and exhausting) list.
Samuel Greear has a totally untested update to the NVIDIA video driver available. It may not work, but it’s not like that’ll be any different than the current state of the driver.
Tim Bisson has inital TRIM support working for UFS. His lengthy posting talks about how it’s done, and shows how much it speeds things up. He’s looking for testers, so please try it if you have a SSD. (The usual warnings apply about testing code that specifically deletes things.)
For those not familiar with TRIM in SSD context, here’s the least annoying page with an explanation that I could find in a few seconds of Googling.
Francois Tigeot did some testing of various hardware RAID adapters (Areca, LSI, 3ware, and Adaptec) in DragonFly, and reported thoroughly on each. This may come as no surprise, but it sounds like Areca adapters are worth the money.