OpenBSD Journal

My bug's life.

Contributed by sean on from the yet another one to squash dept.

Recently I bit the bullet and submitted a bug report for a quirk I've found. The following is a short tale of the experience and how the problem was resolved.

I was readying myself for DefCon and I didn't want to bring my primary laptop with me (for obvious reasons) so I started prepping my $work supplied OBSD laptop (affectionately named 'craptop').

This laptop (a Dell C610) is an old beast. Purchased refurbished for very cheap with a used battery and I've never used it untethered for longer than 5 minutes so I had to re-think my options. After updating to 4.1 current and setting up all kinds of bits and bobbles that I would need to communicate with $work (for the inevitable emergency), I starting worrying about battery life. I then remembered about SpeedStep and the OBSD support for it. I tried it when I first got the laptop and forgot about it.

You can see if your CPU is supported by checking out the hw.setperf sysctl as follows:

sean@craptop~$: sysctl hw.setperf
sysctl: hw.setperf: value is not available

Wait... not available? I'm sure it worked before. With that I dismissed the issue as 'user error' during the update and with running out of time decided to go to DefCon without the aid of a computer.

After I got back the problem languished for a while (as I was still unpacking) and computer problems were the last thing I cared to deal with. Eventually things settled down and I decided to look into the issue.

My first step was updating to -current (4.2-current specifically). Problem persisted. Popped in my 4.0 CD's and it worked which led me to believe something changed in the time between 3.9 and now. I rolled up my sleeves hoping to get in some diff action but then realized I had absolutely no clue where to look. Did a few greps the source tree only to find myself more lost and confused.

At this point I knew I had a bug and had no idea how to fix it so my last resort was to report the bug. Given the 'have a problem? send a patch' culture of OBSD I was leary to submit an incomplete bug report. I've filed bug reports in the past to other 'free software' projects only to find the experience more trouble than it was worth. On a whim and a prayer I gathered my notes and submitted the bug report.

I sat back and waited for the torrent of flames and 'send a patch' messages but none seem to come. While lurking online I noticed gwk@ mention my bug so I contacted him and asked if there was more info I could provide. He gave me a few diffs to apply (to get the stepping info and other chip identity data) and no more than a few days later he sent over a patch which corrected the problem.

sean@craptop:~$sysctl hw.setperf
sean@craptop:~$md5 -t
MD5 time trial.  Processing 10000 10000-byte blocks...
Digest = 52e5f9c9e6f656f3e1800dfa5579d089
Time   = 0.720812 seconds
Speed  = 138732429.537799 bytes/second
sean@craptop:~$sudo sysctl -w hw.setperf=1
hw.setperf: 100 -> 1
sean@craptop:~$md5 -t
MD5 time trial.  Processing 10000 10000-byte blocks...
Digest = 52e5f9c9e6f656f3e1800dfa5579d089
Time   = 1.080001 seconds
Speed  = 92592506.858790 bytes/second
Battery state: high, 100% remaining, 382 minutes life estimate
A/C adapter state: connected
Performance adjustment mode: manual (1199 MHz)
sean@craptop:~$sudo sysctl hw.setperf=1  
hw.setperf: 100 -> 1
Battery state: high, 100% remaining, 382 minutes life estimate
A/C adapter state: connected
Performance adjustment mode: manual (799 MHz)

This version of SpeedStep only supports two settings (full and reduced) so the above proves that is working for my instance. Unfortunately I don't have any other Intel machines so I couldn't try it on other chipsets but the bug was fixed and I'm a happy camper.

When I asked him for more information about the problem (I don't enjoy being clueless) he pointed me towards this SpeedStep Enhanced Whitepaper.

Shortly after that conversation gwk@ submitted the patch to tech@ looking for testing. The patch was then committed into current. Later beck@ closed the bug.

The experience was everything opposite of what I was expecting and I will be far less hesitant to submit bugs in the future.

That being said, a few things to remember before submitting bugs.

  1. Verify the issue persists between the previous release and the current stable release.
  2. Verify the issue persists while using a GENERIC kernel config. Using custom kernels is totally unsupported and makes developer's lives difficult.
  3. Make some notes on what you tried, how you tested and generally be as verbose as possible regarding your installation and your approach to the problem.
  4. Try things out on -current before reporting as the bug you found may have already been found and fixed.
  5. Check the mailing lists, news groups and Google to make sure that either there is no mention of your bug or anything close to it.
  6. Submit your bug report with note of all the above.
  7. Don't expect immediate response. The developers are busy people and your bug is just another drop in the bucket. But at the same time, if you do your homework it will make it that much easier for them to help you quicker.
  8. Finally, be proactive. The bug won't fix itself but at the same time don't sit back and assume the developers will just take care of it all. Try to find any way you can help or better yet fix it yourself and 'submit a patch.'

(Comments are closed)

  1. By Brynet (Brynet) on

    Nicely written, great job Sean :)

  2. By Anonymous Coward ( on

    Great job, great post and in the end, great results!

    Glad you took the step to submit a bug report and not be intimidated by expecting to get flamed or such.

    Not all of us are developers and regardless of what some people 'may' think, it's great that people like you (including myself and others) take the leap and submit bug reports so long as it's done properly such as in the various documentation provided for this - this is all part of testing and helping everyone, one way or another.

    I'm really glad to see that someone posting an article like this - it should really help and encourage other people to do the same.

    Thank you, and all others involved in fixing this.

  3. By Teguh Iskanto ( on

    One thing that I've noticed from the diff especially on the heuristic section, is how clear and readable OpenBSD codes are (compared with Linux codes, as this heuristic was coming from linux driver before it's been patched). This really proves the maturity of OBSD developers and the O/S it self beyond the marketing hype

  4. By Darrin Chandler (dwc) on

    Very nice work! OpenBSD is solid and well written, but bugs happen. Taking some time to pin down the trouble and submitting the bug is something more people should do. Finding, fixing and submitting a patch is completely cool, and I'm sure the busy devs appreciate it. Nice work, Sean!

  5. By Marc Espie ( on

    Not much of a discussion thread here, but this is a very nice article.
    Explains quite nicely on a simple example how fixing bugs actually happens.


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 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.]