Developer Blog - jsing@: OpenBSD/sgi

I've always had an interest in SGI hardware, probably due to the fact that I spent a fair amount of time working on SGI O2's, running Irix, whilst completing my undergraduate degree. A few years back I had the opportunity to acquire one of these systems, which the university was auctioning off. I eventually got around to installing OpenBSD 4.0 which worked quite nicely, however the lack of a PS/2 port driver and graphics driver meant that access to the system had to be via serial console or SSH. As a result, I decided to set myself the challenge of developing the missing drivers.

After checking out a copy of the OpenBSD source code, I started to notice some serious stability issues with the 4.1-current code base. Firstly, I was unable to compile anything substantial without panicking the kernel. Secondly, establishing an interrupt handler on the ``miscellaneous sub interrupt'' line (IRQ 6), as needed for the PS/2 controller, would result in an interrupt storm after a period of time. Both of these issues made driver development slow and quite difficult. Despite these challenges, in July 2007 I eventually managed to get a working driver together for the PS/2 controllers (known as mkbc(4)). At this point I started working on a driver for the Graphics Back End (GBE) framebuffer, however did not make a lot of progress.

After posting details of the reproducible kernel panic to the tech@ mailing list, one of the OpenBSD developers, Miod Vallat (miod@), informed me that it was a known problem - so much so that OpenBSD/sgi missed the 4.2 release. In October 2007 the context switching code was reworked by Artur Grabowski (art@), which happened to fix (or at least minimize) the issue. This allowed me to upgrade to 4.2-current and continue development with fewer problems. Interrupt storms still occurred after the system had been running for a while and occasionally when the system was rebooted.

Further debugging revealed that the interrupt storm occurring on IRQ 6 was being caused by another device that shared the interrupt line, namely the count/compare timer. Since the count/compare timer is not used by OpenBSD, this was easily fixed by hardware masking the count/compare timer interrupt. Shortly after making this discovery I was invited to join the OpenBSD developer team. The mkbc(4) driver was committed on the 19th October 2007 and I became known as one of the `sgi' guys.

The boot time interrupt storm still remained - Miod and I added code to macebus(4) to detect spurious interrupts, which at least allowed the system to be shutdown cleanly from the ddb prompt (rather than having to yank the power cord). The interrupt storm was known to be caused by the on board MACE Ethernet controller. After some poking around I discovered that simply pinging the machine as you rebooted it would result in IRQ 4 being held high and the interrupt line could not be cleared irrespective of what device registers you read from or wrote to.

Having had enough of chasing interrupt storms I returned to work on the GBE driver. One of the biggest challenges was getting the video timing setup correctly, which was made difficult due to the lack of hardware documentation. Since the ARCS firmware initializes the framebuffer, I decided to make use of the existing video timing - an idea inspired by the NetBSD crmfb driver. This allowed development to continue more rapidly. Miod provided some code that he had written several years earlier in an attempt to support GBE. Using parts of this code and developing additional code resulted in the base gbe(4) driver being committed towards the end of November 2007.

By mid December console attachment code had been added to mkbc(4) and the machine dependent wscons(4) code was modified to add initial console support. The choice of serial or glass console is simply made at boot time based on the users selection within the ARCS firmware. This meant that the glass console could now be used, however because gbe(4) was still missing early console support, the kernel boot messages would not display until after gbe(4) attached, fairly late in the boot process.

Around this time Jasper Lievisse Adriaanse (jasper@) started work on power(4), a driver that would enable use of the soft power button to halt the system. After a bit of fiddling around we determined which interrupt line it was attached to and found out how to silence the interrupt once the button is pressed. This was also a good time to cleanup the code used for the DS1687 RTC, since the power button is attached to one of the alarm inputs. After a few more weeks of hacking, early console support was added to gbe(4), enabling boot messages to be displayed as soon as the kernel switches console. OpenBSD/sgi can now be installed without using the serial console! Support for mmap(2) and additional colour depths was also added, paving the way for Xenocara.

With the assistance of Matthieu Herrb (matthieu@), basic support was added to Xenocara so that the wscons framebuffer (wsfb) driver could be used with gbe(4). However, after enabling Xenocara builds on OpenBSD/sgi, the X server would crash whilst the wsfb driver was initializing. After several nights of playing within gdb I traced the problem down to symbols that were not being correctly resolved when shared libraries were dynamically loaded. It turns out that OpenBSD/sgi does not currently support lazy binding - a regression test for this was quickly added to CVS! Matthieu provided a work around by preloading the required modules - by early January 2008 OpenBSD/sgi had working X11, albeit in a non-accelerated form.

In mid January 2008 I returned to the boot time interrupt storm issue. After auditing most of the mec(4) code (and spending a lot of time testing various `fixes'), I realized that the DMA engine was left enabled when the device was stopped. Adding code to disable DMA on device shutdown resolved the issue - another reliability problem fixed. Other developers were reporting a number of stability issues, specifically when NFS was being heavily used. Miod spent a considerable amount of time throughout February and March tracking down and resolving these issues.

OpenBSD/sgi will be again available with the 4.3 release, obviously with a lot of improvements - it's now stable, has glass console support, working Xenocara and can be halted at the press of a button. But there's still a lot that needs to be done, including creation of an install ISO, improvements to disklabel(8)/sgivol(8) interaction and hardware acceleration for X, to name but a few. Also, the only hardware currently supported by the OpenBSD/sgi port are SGI O2 workstations - support for other SGI systems is in the pipeline, which will allow the port to be more widely used.

The learning curve over the last nine months has been significant, but highly enjoyable. Last but not least I would like to thank all of the OpenBSD developers, especially Miod, for their willingness to share their time and knowledge - I look forward to continued OpenBSD hacking!