[c2k8]:Hackathon Summary Part 10

c2k8 General Hackathon (Part 10) - June 7-15, 2008, Edmonton, Alberta, Canada I would like to diverge a little from past articles and give a little background on how these stories evolve and eventually get published; a little behind the scenes perspective, if you will. The output of these stories has slowed since the c2k8 hackathon. At the rate I'm going, c2k9 will be just around the corner after I'm done.

Read on to get the scoop and more from the c2k8 developers:

There's a lot involved when publishing an article besides writing it. I didn't realise how much work was involved until my partner in crime, Mike Erdely (merdely@), took a much needed vacation. At that point (Part 2) onwards, I was on my own and my workload literally doubled. I've been a fan of Mike for a long time and really happy that he is maintaining YAIFO. His website has got a lot of useful information on it. He was also really awesome to work with during the n2k8 series. I would just give him the articles and pictures and he would do his magic to publish them. Only now do I know that this magic was very time consuming. This is not the reason that Mike needed a vacation. Life was getting in the way of undeadly and he needed a little break. Not to worry, he'll be back but for the time being, I've got his HTML template that has helped me keep up the look and feel of a merdely published article.

Ryan McBride (mcbride@) noticed that I was slowing down a bit after Part 5 and asked how long it actually takes to publish an article, "an hour?". He asked in earnest but it made me realise that people don't know how much is actually involved in publishing an article. Ryan and I are pretty close so he only got a light Judo whippin'. Actually, it takes a few days to get everything just right, not including writing the actual article. I also have to sift through all the photos and do the flickr thing but other than that it's just me, my X40, vi, lots of coffee and a relaxing couch to hunker down in. Oh, and this is all done in my spare time.

When I think that I'm ready to put up an article, I log into Undeadly and submit a story. An automated email is then sent out to all the undeadly editors so that they are notified that an article has been posted for review. The editors are really thorough at finding the typos, grammar and syntax errors besides helping to improve the article and linkify man pages. English is not one of my strengths and so I'm extremely grateful for their help. Thanks Jason Dixon, Johan M:son Lindman, Paul 'WEiRD' de Weerd, Janne Johansson, Mike Erdely, Owain Ainsworth, Marco Peerboom and Ray Lai. Now back to some more c2k8 coverage.

Constantine A. Murenin (cnst@) has been doing a lot of work on sensors. He also gave a wonderful presentation at this year's BSDCan2008.

If you didn't know already, both David Gwynne (dlg@) and Marco Peerboom (marco@) have also done presentations on the subject. The sensors framework in OpenBSD is awesome! Think of all that sensor tools in OpenBSD: sysctl(3), systat(1), sensorsd(8), ntpd(8), and snmpd(8) besides remote monitoring tools. The number of supported drivers that hook into OpenBSD's sensors framework is really impressive.

Here is what Constantine had to say about his work and time at the c2k8 hackathon:

At c2k8, Theo suggested that I take a look into the ipmi(4), specifically, on why it appears to have started to conflict with acpi(4) on some machines. Not having any machines with IPMI at home, I ‘booked’ some of the server machines downstairs from the hackroom.

After enabling IPMI in all of the machines which I could lay my hands on, it just worked. But it exposed and reminded me of one expected behaviour that was new to 4.3, specifically, the delayed ipmi0 thread. It creates the ipmi0 sensors after the system goes multi-user, so that you don't have to wait in your console during the boot time until ipmi discovers all of its sensors (can take a minute or two on many machines). It was a delay that was very apparent during the boot time. Anyhow, our sensorsd lacked support for hotpluggable sensors, and these ipmi(4) sensors are in a sense hotpluggable, since they are not present when sensorsd is started from the rc(8) script.

So I've spent some time on adding an original hotplugging mechanism to sensorsd. In order to test some of the logic, for example, in the case where a sensor device disappears or is replaced by some other device, I asked mbalmer@ about his timedelta sensors, which are amongst the few unpluggable devices that have sensors on them. ckuethe@ lent me a receiver and mbalmer@ gave me a crash-course on ldattach(8), and after testing it out, the hotplugging functionality was committed. The only case which turned out not to have been tested is when sensorsd starts with no sensors available. Luckily, one of the sparc64 machines downstairs, which kettenis@ was using earlier, turned out to not have any sensors, and I've noticed a small bug in the new logic, which was quickly fixed. (Of course, testing the no-sensors scenario was also possible on those machines that do have sensors, by disabling them, but since most machines have so many sensors, disabling them may take a bit of time, and after all, testing in real-life conditions is always more fun than simulating such conditions.) By the way, you can still compile and run the new sensorsd on OpenBSD 4.1, since there were no changes to the underlying API since the introduction of the two-level addressing (although the ABI did change for 4.2).

After our IPMI specialist marco@ arrived, we've tried figuring out what might be the problem with ipmi on certain machines. I took some of marco's suggestions about the timing in the delay function, but it didn't appear to make much difference. The matter was complicated by not having ready access to those problematic machines, and the whole problem wasn't too clear either, so we've left it for some other time to figure it out.

As a summary, ipmi(4) is once again enabled, and now you can once again get sensorsd to automatically report on any state changes in ipmi(4) by automatically starting sensorsd from the system startup script, by specifying sensorsd_flags="" in /etc/rc.conf.local. Hotpluggable timedelta sensors are now fully supported by sensorsd, too, of course.

Constantine.

Gordon Willem Klok (gwk@) has been working on old Macs, AMD's powernow, amd64 and i386 setperf and ACPI. I don't have any old Macs but I do have him to thank for setperf and ACPI. Unfortunately, I didn't see Gordon that much at the hackathon. I think that he had another conference that he was committed too right in the middle of c2k8. As such, I only found two pictures of him throughout the event and sadly I didn't get an opportunity to talk with him.

Nevertheless, here is what Gordon had to say about his work and time at the c2k8 hackathon:

During c2k8 I chose to work on something that I had been meaning to do for a long time: allow the openbsd enhanced speed step driver to make use of ACPI.

The original speed step driver made use of values found in data sheets, however more than a few years ago Intel stopped publishing the values in the processors data sheets requiring the drivers to retrieve state information from ACPI. The problem is that the ACPI cannot directly support changing the core frequency of the processor using powernow or enhanced speedstep as ACPI has no notion of processor registers, only addresses in memory or I/O ports. Intel suggested a solution to the bios makers consisting of code running in SMM that mimics the original speedstep which the operating system used by writing to an I/O port on the south bridge, Intel solution was then to have the SMM code trap writes to this I/O port and then write the correct values into the registers the downside being that transitioning to SMM is very expensive compared to the speed of a native EST change.

Intel did however provide a way for ACPI aware operating system with a proper enhanced speedstep driver to make proper use of the speedstep settings by way of the _PDC object. You evaluate the _PDC object and declare what capabilities the operating system has to manage processor power management, then the code running in SMM (System Management Mode) disengages. The operating system can then evaluate the PSS tables which contain the frequencies the processor can scale to and the important part the value that we need to write in to the register to actually change the processor speed.

I wrote the code for setting the _PDC and altered the est driver to interface to the acpicpu code much like the powernow drivers do for AMD processors, however it did not work at first. canacar@ and I poked around examining the AML then jordan@ arrived, and I showed the problem to him and he quickly realized the problem was a missing opcode that OpenBSD's AML interpreter did not implement. Jordan created a patch to implement the missing opcode and then my code could do its thing, my x60 test machine could now find and use 4 states. I took another day or so to clean this proof of concept up into committable code for the amd64 port and finish a version that will work on i386 which I will soon be mailing to tech for the i386 architecture so please watch for it and test.

gwk

Thanks to Constantine and Gordon for their great work with IPMI, ACPI, sensors and the other tools that take advantage of them for our benefit.

(c2k8 hackathon summary to be continued)