My bug's life.

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
hw.setperf=100
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
sean@craptop:~$apm
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
sean@craptop:~$apm
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.'