OpenBSD Journal

OpenBSD 4.8-current on a midrange laptop: Dell Studio 15

Contributed by weerd on from the studio-with-some-ports dept.

Ian Darwin (ian@) writes in with a story he did together with Holger Mikolon about their efforts to get OpenBSD running on new hardware.

OpenBSD developers have generally chosen laptops from makers other than Dell, perhaps due to the fact that you can't usually walk into a computer store to try out OpenBSD support for Dell notebooks: Dell sells most of their computers online. Sometimes, though, it makes sense to buy a brand-name computer and expect that not every peripheral will work on your favorite open-source operating system. As jcr@ already said on Undeadly when talking about portable systems: "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." Note that jcr@ settled on a larger and somewhat different Dell (Alien 17) for one of the laptops in that article.

By coincidence, within a month or so of each other, Holger Mikolon and I both purchased different models of the "Dell Studio 15" laptop for use with OpenBSD. Here are some of the things that we've learned about this machine. On a quest for a quad-core laptop for a specific project, I went to the dell.ca web site and picked out a Dell Studio 15 (1558), one of the few on the market at the time with quad core. My Studio 1558 was delivered at the end of August, 2010, with a quad-core Intel "Core i7 720QM" CPU. Holger was looking for a good screen (high resolution and good brightness) because it would be his main machine for every day use. He writes: "Secondly, power-saving led me to choose low-end (on-board) graphics card and the (high end) Intel P8600 cpu, which has a reasonably low thermal design power, compared to other CPUs available at the time. The rest of my choices were mainly a price-performance-ratio decision." Holger's model is a 1555. Both machines share the name "Dell Studio 15", the cabinet and keyboard and some other components, but have a different motherboard and quite a few internal differences. Compare the dmesg listings:

Holger adds: "I am glad that I listened to one of my friends, who said that I should order the laptop via phone (Dell Hotline). That way I could choose components more flexibly than is possible on Dell's web page (e.g. high-end display with low-end graphics card) and it was possible to negotiate the price as well ("and I want that as well ... for the same price", or "I don't need this super ultra for-free feature, can't I have this or that instead?")." I wish I had heard this before ordering from the web.

For a Dell, these machines work not too badly. On the 1555 two cpus show up in dmesg ("Core 2 Duo P8600") and they usually operate in the range 35-60°C. The 1558 has a Quad-core "Core i7" CPU (720QM), where each core is dual-threaded, so it shows up as 8 CPUs, and "make -j8" makes a difference! Except when very busy, this operates in the range 52-60°C, which is not unreasonable. The ACPI support is pretty good: with machdep.lidsusp=1 set in sysctl, closing the lid does the right thing - suspend works. Opening the lid resumes. After resume, however, the built-in trackpad/mouse was dead every time ("pckbc: command timeout"/ "pms: enable error"). Then, on September 21, 2010, Alexandr Shadchin posted to tech@ a patch to merge the pms and pmsi drivers into one. This not only worked for me, but solved the lockup problem too. The only problem left is that restarting X causes a mysterious hang; this is still being worked on.

Both machines' video cards work without an xorg.conf. The ATI video in the 1558 seems to support only up to 1366x768, although the driver support is a bit preliminary for this chipset. There is hardware support for "accelerated graphics", but the current Xenocara driver does not support it yet. The Intel video (GM45) in the 1555 supports up to 1920x1080, though there is no special acceleration hardware available.

One glitch with the 1558's ACPI is that the fans run continuously, even with "apmd -C". Not at maximum speed, but loud enough to be heard in a quiet home setting (this does not occur when running the Redmond OS). If you live an energy-rich lifestyle, it will blend in with the sound of the air conditioning or the roar of that 24-port 1000baseT switch you keep in your living room.

Ever since USB2 was released, USB controllers have been "dual-tailed" (the opposite of dual-headed?): each controller showed up both as an "ehci" (high speed) AND as an "ohci" or "uhci" (low-speed) controller, and devices or hubs would attach to the correct one magically. Intel has set out to change this with their new 'Intel Rate Matching Hubs'. These attach under the ehci controller, and are found on the 1558 but not the 1555; now also found on some models of HP and Thinkpads, OpenBSD as of 4.8 did not support these. The result is that, as of 4.8, external USB devices don't show up unless they are present at boot time because there is no ohci support. Internal devices such as the uvideo webcam and the internal hubs are always there at boot time, so they work. Plug in an external mouse, keyboard, or wireless and reboot, you're fine. Plug it in after you boot, forget it. Unless it's self-powered, in which case it will usually (cough) be back after resume (e.g., my Belkin KVM connecting an external keyboard and mouse, usually works). However, at the J2K10 hackathon, Takayoshi Sasano (sasano@) delved sufficiently into the Intel documentation to find out how to support the extra status information that these ports require. A fix was committed as r1.53 of uhub.c on Sept 21, 2010 (the same day the pms misadventure ended, coincidentally), and these hubs now work fully. Thanks sasano@!

The 1555 has a different set of issues. Suspend is not really usable with 4.8: even though the machine suspends (e.g. screen is black, fan is off, hdd off, etc.) it immediately wakes up again! Identical behavior when doing "zzz" or when closing lid (with sysctl machdep.lidsuspend=1). What does work: pressing the powerbutton does a clean shutdown, as it should. Audio on the 1555 (Intel 82801I HD Audio) works like a charm after a fix was commited in azalia_codec.c (r .1.140). A few days later the fix was generalized to apply to "all Dell machines with IDT 92HD71B7".

If you buy one of these from Dell, you probably want to order the Intel Wireless (iwn) upgrade ($40 with order), or else you will get to swap one in afterwards (available on eBay quite inexpensively; $55 from Dell if purchased later). By default you get a Broadcom 4313 (0x4727) that is not supported by OpenBSD 4.8; searching at the time revealed only a binary-blob driver for it on Linux, so support seemed unlikely to be descending upon our favorite OS anytime soon. If ordering it separately, make sure you get a half-height card. I tried to find someone competent at Dell, but after a long time on the phone they shipped the full-height one anyway. This should work in the vacant, full-height PCIe WWAN slot (PCIe is a standard after all), but the service manual has a nasty warning about not using the "Ultra Broadband" in that slot, meaning, either that card or that slot doesn't conform to the standard! I wasn't about to void the warranty just to find out which, and after another wasted hour I couldn't get Dell to confirm that it would work. So I sent it back with prejudice, and ordered one on eBay for about 40% of Dell's price. And then, mere hours after I hit "Confirm Purchase", Broadcom dropped the "O" bomb - they released a complete open-source driver for the 4313 and friends! Hopefully this will provide the information needed to eventually make these work on OpenBSD. After I removed the Broadcom, I promptly mailed it to damien@ so he will have hardware to work with in writing or extending a driver for these Broadcom wireless devices.

Holger's 1555 was ordered and arrived with the iwn adapter. He notes that the iwn is unreliable for him: sometimes ifconfig down/up helps. On a kernel that is one or two days older than the dmesg linked to above he's also very occasionally seen "iwn0: fatal firmware error".

The Studio 15 is Dell's higher end consumer line, but it is still a consumer line: the machine is not built like a tank, although it's solid enough for a reasonable amount of backpack or carry-on travel. A full lineup of connectors adorns both side panels - there are no connectors on the front or back of the case. On the left side we find (back to front) a locking cable slot, HDMI, VGA, wired gigabit Ethernet, USB + eSATA stacked one above the other, small Firewire/IEEE1394, and the usual three analog audio jacks. At the other side there is a power button hidden in the hinge, a power jack connector and USB immediately beside it - stupidly, too close to allow many of the wider USB peripherals, only a cable, when running on AC/mains power. This USB is also below the slot-loading optical drive, so no thick USB peripherals either if you want to change what's in your drive! Both USB slots are fairly close to their neighbours, but since Wireless is so popular and firewire doesn't work on OpenBSD yet, you can probably use the left-side USB with anything. Or buy a cheap USB hub. The USB connectors are the only ones that are so poorly arranged. The locking cable slot is angled to line up with the back of the case (see photo) which makes it a bit awkward to use with the combination-lock-based locking cable (you wind up holding the lock at a funny angle that makes it hard to read). Functionally it's fine, but the human factors are sub-optimal.

One other hardware irritation is that the Dell Studio has no LEDs: no disk activity LED, no "wireless enabled" LED, not even a caps-lock LED. This is only an irritation, but it will always be an irritation. Did I mention that I find this to be an irritation on the Dell?

On the plus side, the hardware has been designed to make consumer-replaceable parts easy to install. Three screws and a bit of prying is all it takes to remove the single "Base Cover" on the bottom and get access to memory, hard disk, wireless cards (there are claimed to be three Mini-PCIe slots - two full size and one half size - on the mother board, not all of which may have sockets soldered in depending upon factory options), etc. When I opened the 1558, I could only see one of each size. As mentioned, Dell will sell you the Intel Wireless card as a user-replaceable part, or you can buy it on eBay for 1/3 to 1/2 of their price, and not have to deal with Dell's customer service or tech support. Installation is vaguely detailed in the service manual and a different set of vague details comes with the Dell card. All you really need to know from the Dell you-install-it documentation is (a) take the main battery out, and ground yourself, and (b) the white wire goes to the antenna terminal with the white triangle, black with black, and so on. The third wire is conveniently hidden in a plastic channel just above the board slots, so you may have to look around for it.

The optical drive is not as easily user-replacable, although there are quite a lot of these for sale on eBay for the Studio 15/17, especially with BluRay support if you didn't order that as a factory option. You remove quite a bit more of the casing to change the optical drive. All of this is revealed in the service manual, which you can freely download from Dell's web site.

A reasonably full-sized keyboard awaits your fingers; there is plenty of room to type, the key layout and spacings are fairly conventional - the bottom row has CTRL, FN, WindowKey and Alt, then Space, then Alt, Ctrl, Menu and three of the four arrow keys. The top row has Escape and F1..F12, all but one of which are overloaded with use of FN. BIOS has a setting to make the overloads or the FN keys the default, though I think you'd only find that useful with Microsoft's OS unless you are plenty proficient with X keyboard mapping. The keyboard feels reasonably solid.

I kept the installed Redmond operating system (their seventh major try) for installing BIOS upgrades and getting support in case needed. My system came with a 500G SATA disk drive (sd0, under an Intel "ahci" controller). To make room for our favorite OS, I shrank the MS-Windows partition to about 60G. As per the current INSTALL.i386, the MS-Windows 7 Control Panel has a routine for easily shrinking partitions. It is kind of irritating that the Dell/Microsoft software uses up three of the four primary FDISK partitions, labelled OEM, Restore, and C: under MS-Windows. Here is an fdisk(8) output after shrinking the C partition (#2 below) and adding a real person's operating system in its favorite slot, id # 3:

Disk: sd0       geometry: 60801/255/63 [976773168 Sectors]
Offset: 0       Signature: 0xAA55
            Starting         Ending         LBA Info:
 #: id      C   H   S -      C   H   S [       start:        size ]
-------------------------------------------------------------------------------
 0: DE      0   1   1 -      4 254  63 [          63:       80262 ] Dell Maint
 1: 07      5   0   1 -   2299 140  22 [       80325:    36861952 ] NTFS
 2: 07   2299 172  55 -  10566  26   4 [    36944325:   132800107 ] NTFS
*3: A6  10566  38   1 -  60801  64  63 [   169745184:   807026976 ] OpenBSD

Speaking of those NTFS partitions, the NTFS filesystem code has been seeing a bit o' love lately, and this got committed to the amd64 and i386 GENERIC config file recently:

revision 1.302
date: 2010/09/08 16:04:35;  author: espie;  state: Exp;  lines: +2 -2
activate NTFS, let's hope it gets less experimental soon (as beck@ said)
okay'd by thib@, who now owns a spanking new ntfs image...
deraadt@ 'okay if thib@ lets you'
So I've mounted the C partition on /c, and have access to any Windows files I might need. I haven't actually needed any, but you never know.

How is performance? Here are some kernel build times, for "make clean; time make" with varying number of CPU's dedicated (the -j parameter to make).

1555:
-j15m7.73s
-j22m39.58s
-j42m40.06s
-j82m38.44s and it doesn't improve with -j12
1558:
-j16m19.07s
-j42m0.58s
-j81m30.75s
-j121m40s

We continue to find the machines useful, and hope they last for several years (especially the 1558, to repay the initial investment of being an "early adopter" of a quad-core Intel i7).

In addition to those mentioned, Ian would like to thank Ken Westerback (krw@) for help with with testing of some hardware issues.

(Comments are closed)


Comments
  1. By brynet (Brynet) brynet@gmail.com on

    I got an Acer Aspire 5551 back in September, no major incompatibilities.

    * Working athn(4) wireless, appeared in 4.8-current.
    * ACPI suspend started working after a suggestion/patch from mlarkin@, EHCI controllers don't come back from resume though.
    * Speed scaling is unavailable for this processor family (AMD K10), but I generally not far away from a power source.

    Went in blind, all I knew was that it had an AMD processor and ATI graphics.

    Great article.

  2. By Brad (brad) brad at comstyle dot com on

    I feel bad for you guys sticking with the Intel Wifi adapters. This stuff is pretty bad with the OpenBSD drivers as is.

  3. By Damien (damienb) damien dot bergamini at free dot fr on

    > On a kernel that is one or two days older than the dmesg linked to above he's also very occasionally seen "iwn0: fatal firmware error".

    If this is the NMI_INTERRUPT_WDG firmware error, try running a non-mp kernel, this will usually "fix" the issue. This watchdog triggers when the OS does not acknowledge interrupts fast enough; the firmware simply thinks the OS is dead and freaks out.

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]