Contributed by jcr on from the too-much-exercise dept.
Bob Beck (beck@) said, "We're actually a hiking club with a software development problem," so you can hopefully grasp how important it is to have reasonably portable systems. The down-side of most developers using reasonably portable and reasonably powerful systems is the lack of diversity. The majority of the laptops used by developers are either 32-bit or 64-bit x86 systems (i386 or amd64 respectively). Just because OpenBSD will run on a monstrous VAX and said VAX will be very useful for finding bugs unseen on other platforms, it doesn't mean you'll want to carry one around with you. Diversity of supported platforms and constantly doing native builds on them makes OpenBSD more robust.
Porting the entire OpenBSD operating system to a new platform would be a lot of fun but requires a great deal of skill and a significant amount of time. Even if you're seeking FUN, you may not have time and skill to do a full OS port, so most people would want to pick one of the already supported platforms. If you pick the right system, there will still be plenty of FUN to be had in adding or improving support for some of the unsupported or under-supported parts. Depending on your personal requirements and how much FUN you want to have with it, you always have a number of great choices available within the realm of supported platforms.
[c2k10] Article Series: 1 2 (more to follow)
The MIPS based systems designed by SGI are just beautiful, and they are far more powerful than most people would ever expect. Some people claim that SGI made laptops because they've seen them in the movies, but unfortunately, those movie props are fakes, and were only created because SGI had the contract to provide all computer props for the given movies. It's claimed that some of the SGI engineers had their own midnight side-project of creating an O2 based laptop, but sadly, this unsanctioned prototype never made it into production. The image of the O2 Laptop Prototype is used with permission of Jesse Newcomb. Thanks!
I have *ALWAYS* wanted one of the super sweet sparc64 based Bullfrog v2 laptops made by Tadpole (now General Dynamics). There are two huge problems with the idea; (1) I can't afford one, and (2) even if I could afford one, documentation is not available, so getting OpenBSD running on it would be painful if even possible. I actually worked on the PCB designs of the Bullfrog for Tadpole and have an Non-Disclosure/Non-Compete Agreement (NDA/NCA) in place with them, so I might be able to get the needed docs. But therein lies a worse problem; Even if I got the docs and had the skill to add the needed support to OpenBSD, everyone else would be screwed if I got hit by a truck. No one else would have access to the docs needed to maintain the code. Given my personal requirement of FREE if at all possible, the right answer is to refuse to purchase from a hostile vendor. Oh well.
There are a few 32-bit SPARC laptops out there, but most of them are made by Tadpole, and they are fairly slow by modern standards. OpenBSD does have some support for some of these laptops but whether or not all the various internal devices are fully working is not known.
It's a little known fact that HPPA/PA-RISC laptops really do exist. They are fairly old and under-powered by todays standards, so they don't meet my requirement of FAST, but even if they were fast, it wouldn't matter. The PA-RISC laptops were, once again, made by Tadpole and required documentation, once again, is not available. Yep, same problems as above caused by a short sighted vendor.
The only available alpha processor based laptop, the AlphaBook, is from 1995-1996, and as with the others above, was made, once again, by Tadpole. Though I love alpha based systems, and OpenBSD does have support for the AlphaBook, the support may be limited and it's a poor fit for testing work.
Arm based systems like the Zaurus are fun, lots of fun, and very portable. They are tiny, well supported and great for light tasks, but they are not designed for raw compute power. Not only would it fail to meet my FAST requirement, but I also wouldn't get enough exercise hauling it around.
The Loongson processor, particularly the still unreleased high-clock multi-core versions, has a very interesting MIPS64LE (Little Endian) design. As of OpenBSD 4.7 we do have support for some loongson based systems like the Lemote Yeeloong, Fuloong and Lynloong, as well as the EMTEC Gdium Liberty 1000 netbook. Unlike other system vendors, the Lemote and EMTEC systems are very intentionally friendly to open source and most all of the hardware documentation is freely available. This is great for developers and means we should be able to maintain OpenBSD support for a loong time if you pardon the pun. (note: I'm resisting the urge to make less appropriate "loong time" jokes). Though a Yeeloong or Gdium would be great for a simple, easily portable laptop, they don't meet my FAST requirement. When the mythical high-clock multi-core versions of the Loongson processor finally make their way into designs, this type of system could become viable in the FAST department, but at present, they just don't have the raw speed I want.
There are more than a few somewhat fast 32-bit x86 laptops out there, but if you need FAST, you are better off with a 64-bit x86 system. Though OpenBSD i386 has great support for various bits of hardware, you still need to be careful about the FREE aspect of things. There's tons of open source unfriendly undocumented crap put into laptops. You should also be careful about the too-cheaply-made systems since they're just not built to last. If you stick to a good and well supported vendor and do some research, you should bypass most of the junk on the market.
I've finally reached the "default" place that most people hit when looking for a new laptop, namely 64-bit x86 systems. The general rules above for avoiding junk 32-bit x86 systems all apply here as well. If you are concerned with having existing OpenBSD support, you'll need to do a bit more research and ask around since the x86-64 systems are newer and may contain unsupported parts.
Even when a system is not listed as "officially supported" on the various platform pages, it may actually be able to run OpenBSD to some degree. The only way to find out is to test it and report your findings. Similarly, even some of the systems listed as officially supported may have devices still in need of support. Usually this is due to either missing documentation or not having access to the needed hardware for testing and development.
The way I even found out about the Dell/Alienware M17x was by trying to find a good laptop with an ATI graphics chipset to avoid the nVidia headaches. Though it is a supposedly portable gaming rig, the M17x offers something very unique in the way of graphics, namely it gives you a pair of ATI Mobility Radeon HD 4870 cards on a PCIe Gen2 bus in a CrossFireX configuration. As far as I know, no other laptop on the planet has this feature, so the decision was easy. The odd aspect of the design is in addition to the pair of ATI CrossFireX cards, it also has an on-board nVidia graphics chipset for when you don't have access to a wall outlet for power. On boot, the system will detect if it's plugged into an outlet and if the power supply brick is adequate, then make a decision on which graphics chips it should use. A typical laptop power supply brick is about 60 Watts, while this beast normally uses a 240 Watt power supply but can also be used with smaller power supplies.
With all the awesome ATI CrossFireX hardware, you'd expect to have an equally awesome display. The M17x meets expectations with a very clean, low latency 17" 1920x1200 (1200p) display. This takes care of the FEATURE needed for testing video playback, camera output, BluRay support and similar. Though it's not exactly a "Professional Grade" display for testing video, it's as close as one can get in a laptop form factor.
Keeping with needed video output FEATURES, the M17x has three outputs in addition to the main display. The first is a typical VGA output, the second is HDMI output, and the third is a DisplayPort output. In one laptop, I could provide test coverage on everything except DVI, and if need be could configure it for multi-head use.
Since gamers are also notorious for wanting high-end sound systems to hear their last dying breath, one would expect the M17x to be well equipped for audio and again, expectations are met. The M17x has a full featured azalia audio system, including 7.1 surround sound, microphone and similar outputs, so it should suffice for the FEATURES needed in audio testing.
Another important feature of the M17x is ESATA support. Not only was testing ESATA hot-plug support on list of needed features, but on a test system you have to plan on wiping the main hard drive by reinstalling repeatedly. This means you won't have your usual configured home directory and archive of needed packages, so you need a place to store your stuff. Though you can do this with either external USB or SD storage, ESATA is much faster, and with a decent hard drive, much bigger and cheaper. I could have just used the second in-system hard drive for my home dir, but since I'd be using multiple systems for testing and loaning out systems to any developer who wanted to work on them, having my home be on an attachable disk (ESATA/USB enclosure) meant I could move things around quickly and easily.
In addition to all the other needed FEATURES in the M17x, I found out I could stuff a BluRay burner into it fairly cheaply. Since one of the hackathon goals of Peter Hessler (phessler@) was adding BluRay support to cdio, I had to be prepared to help out with it. I located a big reseller on eBay with the correct Dell BluRay burner, got it ordered and delivered, but did not get a chance to get it installed before the hackathon. I just brought it with me and installed it when I got the time.
Lastly, since this is a very new laptop model and has probably never been used with OpenBSD, one could expect to find bugs and problems from the very start. The most interesting and useful aspect of high-end systems is the stuff that is "high-end" today will eventually become common place in the coming months/years. This means finding a squashing bugs on the new high-end gear means we'll already have solid support when the bleeding edge hardware eventually becomes mainstream.
As one might expect, the Dell/Alienware M17x was good for testing but it was also great for lot a lot of laughs and pithy comments from the other developers at the hackathon. When I offered the system to another developer to test something, with a smile Theo said, "But we don't work on systems that large." It was both a joke and a statement of fact. The M17x was definitely out of place in the hack room amongst all the other small portable laptops, and the silly green glowing keyboard made it stand out even more. By his look of disgust, I think I offended Owain Ainsworth's (oga@) fashion sense when I told him the green glowing keyboard could be changed to any color including a rainbow across the whole thing. As they say, "Fashion Is My Only Conscience."
One Is Never Enough
I had three other test laptops I was planning on bringing to the hackathon. The first laptop was an ancient mid 90's, 400MHzzzz Toshiba Sattelite Pro 4260. Though the build times would undoubtedly suck, it's smart to have a very slow system around when testing since you can often find strange and unusual timing bugs with a slow system that never appear on faster systems.
The second laptop was a Fujitsu LifeBook U820 touch tablet/netbook based on the Intel Atom Z530 1.6GHz processor. With the amount of RAM, processor speed and Intel fake-core Hyper Threading nonsense, this could handle the needs of building the i386 tree for both itself and the ancient Toshiba. Additionally, it has a brutally twisted and unfree form of graphics hardware, an Intel System Controller Hub (SCH) US15W with GMA500 graphics but is actually a proprietary PowerVR chipset known as SGX 535. Oddly enough, the touch screen actually kind of works by default with our xenocara but could probably be made fully functional with a bit more effort.
The third laptop was an Apple PowerBook G3. This is a system is I never use, and mostly sits around collecting dust but it could be real useful for testing something other than just x86. Again, build times would suck, but it was the best non-x86 system I had available.
I had already ordered the Dell/Alienware M17x when the request for donations of HP laptops was made. The needed HP laptop models are fairly inexpensive, so I was both surprised and disappointed when no one was willing to fulfill this requested donation. The OpenBSD development efforts on ACPI, AML, ASPM and similar are very important. Absolutely everyone using a somewhat modern system is affected by how good our ACPI support is, so seeing no one willing to help out with supplying the needed hardware was very unfortunate. Additionally, improving our support of HP laptops in general is also very important. As you hopefully know, putting the required hardware in the hands of the developers is often the only way for development to happen.
I had already gone through significant expense to get one extremely fast test system for the hackathon, but few people understand how critical specific requests for hardware donations really are. Since no one else in the world would make the needed donation, it made sense to make sure the needed hardware as at least available during the hackathon. I could not afford to give another laptop to the project developers, but providing access to one during the hackathon was better than nothing, and hopefully I'd find use for it in business when I got home.
NOTE: The developers are still in need of a donation of HP laptops.
Unlike the M17x which was built for gamers, the HDX18T was designed for multimedia users, either those working on creation of video/audio or those doing multimedia presentations. The big surprise was finding out HDX18T is actually bigger than M17x. I didn't think that was possible, but the beautiful, high-quality 18.4" 1920x1080 (1080p) display takes up a ton of room. Keeping with the all the good natured jokes about these uncommonly large laptops, Eric Faurot (eric@) asked, "Do they make a laptop version of that?"
The specs of this HDX18T are very similar to the M17x. It uses the same Intel QX9300 processor, is configured with 8GB of RAM. It also has similar dual Dual SATA 3.0 GiBit/s hard drives, SATA BluRay optical disc, mini-PCIe slot (internal), as well as lots of important ports like SD, 5.1 channel audio, VGA, HDMI, ESATA and other widget ports. As for the obvious question of, "What kind of person needs a laptop with a built-in subwoofer?" I really have no clue, but since I'd be testing audio, it might come in handy. An even more dubious question is, "What kind of person needs a laptop with a remote control?" as pictured partially ejected from ExpressCard slot on the left. One could have a lot of fun if they figured out how to hack the remote control, like slipping a risque DVD in drive of a friends system and starting it remotely during their presentation, but I'll save this idea for another day. The only real down side of the HDX18T is it only having an nVidia graphics chipset, but other than that it is an equally excellent test system.
With the Dell/Alienware M17x being marketed towards gamers with more money than sense as the "Worlds Fastest Gaming Laptop," the price of even refurbished machines was excessive. The most amazing thing about the HP HDX18T is it not only every bit as good as the M17x, but has a better screen and was half the price.
When you intentionally buy uncommon or unsupported systems, there should be absolutely no surprise (or complaints) when you realize some of the hardware is not supported by OpenBSD. Even if you were trying to buy something already having full OpenBSD support, the choice was yours, so everything still in need of support is your responsibility. If you are unwilling to contribute to the development and testing process in a polite and friendly way, then open source is simply not for you.
All machines brought to a hackathon should already be as fully setup as possible with OpenBSD so you don't lose a day or two at the hackathon getting them running. Sure, when dealing with adding support for currently unsupported hardware, having everything running when you arrive will not always be possible, but you just do you best. My first attempt to install the June 10th snapshot on the Dell/Alienware M17x resulted in a brutal hang on boot. I had entered the system BIOS, loaded the defaults, made sure the CD-ROM was the first boot device, saved the settings and shut down the system. On the next boot, I loaded the OpenBSD snapshot CD-ROM an got:
probing: pc0 mem[631K 2557M 5632M a20=on]
disk: hd0+* cd0
>> OpenBSD/amd64 CDBOOT 2.1
booting cd0a:/4.7/amd64/bsd.rd: 2902368-
Yep, it just stopped right there and refused to continue booting the kernel. Since this should not happen, it was both disturbing and cause for serious concern. There was now at least a potential the new system I just bought would be totally worthless for running OpenBSD. All of the time and expense I had just gone through to get prepared and equipped for the hackathon may have been for nothing. If this turned out to be a show-stopper, then the mistake would have been mine, and I'd have no one to blame but myself. When you're trying to push the leading edge of support forward, these sorts of things happen. It's just one of the risks you take.
On the other hand, this uncommon and unsupported hardware being unable to boot the kernel may have just discovered an otherwise unknown bug in OpenBSD. When you can't even boot a kernel on a supported platform, there are really only two possibilities; either (1) the system/bios was designed incorrectly, or (2) there's a bug in OpenBSD. As mentioned above, without people actively testing unknown, esoteric hardware and configurations, bugs or bad systems cannot be found, and improvements cannot be made.
The first thing you do when you're faced with a problem is read the documentation, and code, then start experimenting so you can understand the problem better. I started by once again making sure the default BIOS settings were loaded and making sure the first boot device was the optical drive. I was quite surprised when this seconded attempt, which should have been (in theory) identical to the first, actually succeeded in booting the kernel from the CD. This made no sense at all. Why did the first attempt fail, but the second identical attempt succeed?
Something must have changed between the first and second attempts but I could not figure out what it was. Since by some bit of luck I had gotten to the start of the installation routine, the smart thing to do is grab a dmesg. I exited the installation script with ^C, plugged in a USB stick, mounted it, and saved the dmesg to it.
OpenBSD 4.7-current (RAMDISK_CD) #466: Thu Jun 10 00:51:27 MDT 2010
real mem = 2681995264 (2557MB)
avail mem = 2598961152 (2478MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xf0310 (32 entries)
bios0: vendor Alienware version "A02" date 08/21/2009
bios0: Alienware M17x
... (full dmesg)
Looking at the dmesg in more detail shows 22 devices with a status of "not configured" so there is a lot of work to be done here once we get past the mysterious boot problem. Now here's the really fun bit for those who were not paying attention while reading the dmesg; there are no disks. Even the CD-ROM it booted to is not listed, so those small but annoyingly important things like being able to get the CD-ROM out of the slot loader drive with eject(1) would not work, let alone the more obvious problem of having nowhere to install OpenBSD. The problem is simple; support for the SATA disk controller, nVidia MCP79, is failing to work in AHCI mode. The short term dirty work-around is to change the controller settings in the BIOS to force it to run in the slower ATA mode. The long term correct fix is, of course, adding AHCI support for the SATA controller.
When faced with a weird problem like the mystery boot issue, it's wise to make sure you're running the most recently available firmware/BIOS for the system. If there was some unstated bug in the system BIOS, it may have already been fixed. In my case, updating the BIOS from revision A02 to the most recent revision A04 changed very little. All it did was change the number of AHCI DMA channel failures.
The mystery boot problem was a real pain. Some times it would boot fine, and other times it would hang while trying to load the kernel. Switching over to using a bootable USB stick for the installation didn't fix this intermittent problem. It certainly was not a matter of BIOS revision or BIOS settings, but it finally dawned on me that the thing that was changing between working and non-working attempts was using the "boot device selection" feature. Every time I manually selected the boot device on a cold boot, it would boot just fine, but if I just let the boot process run normally to the default device, it would hang. This made no sense at all but along with switching over to ATA mode to make the disks usable, it was enough to get OpenBSD installed.
As later pointed out by Tobias Weingartner (toby@ or weingart@), getting the machine to boot correctly was simply a matter of touching a key, any key, on the keyboard during the POST. The esoteric hardware had indeed found an unknown bug in OpenBSD, and Toby congratulated me on finding the first real stumper he'd seen in a very long time. Though this bug is still being researched and corrected, by the time this kind of esoteric boot/hardware configuration is seen in more common hardware, the bug will already be fixed. At the moment, the situation has been improved to only rebooting constantly from locking up on boot, and there have been plenty of other fixes as seen in the most recent dmesg.
initial dmesg only shows 14 "not configured" devices. and some of these have since been fixed as seen in the most recent dmesg.
The most insightful anecdote involving a fix on the HDX18T is in the audio subsystem. Within just a few hours of the start of the hackathon Jacob Meuser (jakemsr@) was able to isolate and fix a long standing bug in audio on HP laptops. He had tried to fix this bug before, and even sent a patch out to a complaining end user, but the end user never replied back on the success or failure of the patch. Without access to the needed hardware jakemsr@ was unable to fix the problem for almost a year until at the hackathon he finally had access to the HDX18T.
Though I could continue to go line by line through the dmesg's and bug by bug through the issues found and resolved on both of the laptops, it would not add very much to the main point of the article; Developers need access to hardware and everyone needs to be willing to put in the effort to test patches. As individuals following their passion to write the very best operating system, the developers simply cannot afford to purchase all of the hardware they need. When you see requests for hardware donations such as those on want.html they are very important to the project as a whole and everyone running OpenBSD.
(Comments are closed)