Contributed by johan on from the mips-that-flips dept.
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.
Thanks for the great work keeping this arch alive, Joel, et al!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!
(Comments are closed)
By Venture37 (venture37) venture37<A>hotmail.com on www.geeklan.co.uk
Comments
By Anonymous Coward (89.131.107.151) on
HAHA. Why always the OpenBSD stories don't mention the fact that almost all work has been based in the NetBSD efforts?
D00ds, I'm really surprised that you are always trying to get all awards while the NetBSD folks don't even get mentioned in the commit messages and/or the posts.
Isn't it time right now to give proper credit to the folks that really helped to make this possible?
For years that's what I've been seeing: NetBSD adds some code, and later OpenBSD creates a driver based in the NetBSD code and even not mentioning
the fact or respecting the BSD license. Too bad guys.
Comments
By Anonymous Coward (193.15.214.188) on
Troll.
While it's true at lot of code (or ideas for code) comes from the other BSDs, it's also true that many, many commit messages includes "From NetBSD" or similar.
Of course, the opposite is true as well. OpenBSD has been the source of many drivers and utilities that can be now found in the other BSDs, even Linux. Thats the whole idea of open source.
By Anonymous Coward (209.180.254.41) on
> Isn't it time right now to give proper credit to the folks that really helped to make this possible?
>
> For years that's what I've been seeing: NetBSD adds some code, and later OpenBSD creates a driver based in the NetBSD code and even not mentioning
> the fact or respecting the BSD license. Too bad guys.
cvs/CVSROOT/ChangeLog shows about 12 instances of "from NetBSD" on the ftp server and it only goes back to March 7. Sounds like plenty of attribution there. In fact the *BSDs do give each other credit. My hat is off to all of the developers.
By Anonymous Coward (85.216.49.100) on
Comments
By Anonymous Coward (2a01:348:108:155:20a:e4ff:fe2d:99ee) on
>
m'kay!
By mcmurphy (89.77.162.243) on
>
Define drugs. In this case, I think it's more a failure to take medication that seems to be the problem... Oops, the orderly is shouting my name agai... THWACK
Comments
By Tenderloin Fantastic (67.112.220.108) on
> > Drugs are bad for you...
> >
>
> Define drugs. In this case, I think it's more a failure to take medication that seems to be the problem... Oops, the orderly is shouting my name agai... THWACK
By Anonymous Coward (91.121.7.211) on
>
> HAHA. Why always the OpenBSD stories don't mention the fact that almost all work has been based in the NetBSD efforts?
>
> D00ds, I'm really surprised that you are always trying to get all awards while the NetBSD folks don't even get mentioned in the commit messages and/or the posts.
>
> Isn't it time right now to give proper credit to the folks that really helped to make this possible?
>
> For years that's what I've been seeing: NetBSD adds some code, and later OpenBSD creates a driver based in the NetBSD code and even not mentioning
> the fact or respecting the BSD license. Too bad guys.
Because it does not matter.
Theo helped founding NetBSD and even choosed the Name.. so of course OpenBSD lends code...
Get a life...
By Chris (24.76.123.149) on
>
> HAHA. Why always the OpenBSD stories don't mention the fact that almost all work has been based in the NetBSD efforts?
>
> D00ds, I'm really surprised that you are always trying to get all awards while the NetBSD folks don't even get mentioned in the commit messages and/or the posts.
>
> Isn't it time right now to give proper credit to the folks that really helped to make this possible?
>
> For years that's what I've been seeing: NetBSD adds some code, and later OpenBSD creates a driver based in the NetBSD code and even not mentioning
> the fact or respecting the BSD license. Too bad guys.
Yes, I too hate when Open Source works exactly as intended.
By nommy (203.206.173.91) on
Awesome post
There is an error with the mmap link in "Support for mmap(2) and additional colour depths was also added, paving the way for Xenocara." it points back to the original post :D
Comments
By Johan M:son Lindman (johan) on d'oh
>
> Awesome post
>
> There is an error with the mmap link in "Support for mmap(2) and additional colour depths was also added, paving the way for Xenocara." it points back to the original post :D
I've fixed that now, thanks for the report!
By Anonymous Coward (208.71.184.41) on
Why no one interested to develop ***good*** SMP support for MODERN hardware with AMD64/EMT64 CPU's. Never understand this about OpenBSD...
Comments
By Pablo Méndez Hernández (62.87.89.105) on
But the point is that if miod@ or jsing@ enjoy doing that kind of work, it's normal it'll be integrated (and i'm pretty sure they have easier access to that obsolyte hw than to the hardware you tell us).
My 0.02€
Comments
By Anonymous Coward (88.217.158.50) on
there is plenty of patches been sent for smp and general usability improvements but nobody in the project cares. people prefer to dig
their own shit and ignore problems that take effort to understand.
Comments
By Paul Yasuchenin (booler) on
>
> there is plenty of patches been sent for smp and general usability improvements but nobody in the project cares. people prefer to dig
> their own shit and ignore problems that take effort to understand.
Really? So did you offer help to Theo(!) with SMP (if you have
enough skill)?
Comments
By Anonymous Coward (88.217.158.50) on
> enough skill)?
more than you can possibly imagine.
and most certainly infinitely more than you ever did.
Comments
By Paul Yasuchenin (booler) on
> > enough skill)?
>
> more than you can possibly imagine.
> and most certainly infinitely more than you ever did.
May be you should stop offer help, and DO ready solution? You should contact with maintainer of kernel synchronization (i think, art@ or niklas@), or ask Theo for the commit rights (but i'm not sure that you get). Because I do not believe, that working patch was not committed.
Comments
By Anonymous Coward (151.136.100.22) on
> > > enough skill)?
> >
> > more than you can possibly imagine.
> > and most certainly infinitely more than you ever did.
>
> May be you should stop offer help, and DO ready solution? You should contact with maintainer of kernel synchronization (i think, art@ or niklas@), or ask Theo for the commit rights (but i'm not sure that you get). Because I do not believe, that working patch was not committed.
this obviously shows you have not done a single
change yourself ever.
Comments
By Paul Yasuchenin (booler) on
> change yourself ever.
Anyway i dont believe, that GOOD patch was not committed and not even considered. Rather, it's your problem ;)
Comments
By Anonymous Coward (151.136.100.2) on
> > change yourself ever.
>
> Anyway i dont believe, that GOOD patch was not committed and not even considered. Rather, it's your problem ;)
you are full of shit... sorry.
Comments
By Paul Yasuchenin (booler) on
> > > change yourself ever.
> >
> > Anyway i dont believe, that GOOD patch was not committed and not even considered. Rather, it's your problem ;)
>
> you are full of shit... sorry.
I thought you're man, before that your phrase.
By Brad (2001:470:8802:3:216:41ff:fe17:6933) brad at comstyle dot com on
Then you're stupid.
Comments
By Paul Yasuchenin (booler) on
>
> Then you're stupid.
If I am wrong, it means that developers are not cared about other people's problems and "prefer to dig their own shit and ignore problems that take effort to understand" as Anonymous said. You are really funny or you didnt understand me.
Comments
By Anonymous Coward (88.217.158.50) on
> >
> > Then you're stupid.
>
> If I am wrong, it means that developers are not cared about other people's problems and "prefer to dig their own shit and ignore problems that take effort to understand" as Anonymous said. You are really funny or you didnt understand me.
no it means that you are stupid.
By Anonymous Coward (71.139.226.159) on
> > enough skill)?
>
> more than you can possibly imagine.
> and most certainly infinitely more than you ever did.
Huh, I can't seem to find anything relevant on tech. Could you give a link or three?
Comments
By Anonymous Coward (151.136.100.2) on
> > > enough skill)?
> >
> > more than you can possibly imagine.
> > and most certainly infinitely more than you ever did.
>
> Huh, I can't seem to find anything relevant on tech. Could you give a link or three?
http://cvs.openbsd.org/query-pr.html
http://www.openbsd.org/cgi-bin/cvsweb/
http://openbsd.org/plat.html
Comments
By Anonymous Coward (71.139.239.164) on
>
> http://cvs.openbsd.org/query-pr.html
> http://www.openbsd.org/cgi-bin/cvsweb/
> http://openbsd.org/plat.html
Still don't see any of your work. Try being a little more specific there.
By Chris (24.76.123.149) on
>
> there is plenty of patches been sent for smp and general usability improvements but nobody in the project cares. people prefer to dig
> their own shit and ignore problems that take effort to understand.
It's almost as if volunteers doing a hobby are working on whatever they feel like.
How dare they!
Comments
By Anonymous Coward (151.136.100.2) on
> >
> > there is plenty of patches been sent for smp and general usability improvements but nobody in the project cares. people prefer to dig
> > their own shit and ignore problems that take effort to understand.
>
> It's almost as if volunteers doing a hobby are working on whatever they feel like.
>
> How dare they!
what's the point of this free software crap if only these "developers"
can change "the source"? how is it different from any other vendor?
Comments
By Chris Kuethe (76.191.185.172) ckuethe@ on
> can change "the source"? how is it different from any other vendor?
It's different because you can go get a copy of the code for yourself (for free) and hack it up all you like.
You're free to do what you wish to the code, and the people who worked on it are free to ignore you.
You're free to make your changes available to everyone, and depending on what terms you make your changes available under maybe people will care. If your changes are actually worthwhile, maybe people will use the changes.
Until proven otherwise (by diffs) you're just a whiny troll...
By phessler (phessler) on first undead, then not, then undead again.
> Why no one interested to develop ***good*** SMP support for MODERN hardware with AMD64/EMT64 CPU's. Never understand this about OpenBSD...
>
developing for some platforms helps to develop good support for other ones. writing portable code will help find all sorts of weird corner-cases, and various places to add improvement. the whole world is not dual core amd64....
By Lucas (194.74.206.75) on
> Why no one interested to develop ***good*** SMP support for MODERN hardware with AMD64/EMT64 CPU's. Never understand this about OpenBSD...
>
SGI MIPS processors have very high performance per MHZ, a 700mhz MIPS processor in a SGI fuel has similar floating point performance as a 3.0ghz Pentium IV processor.
Have a look here if you don't believe me.
http://en.wikipedia.org/wiki/SGI_Fuel
IRIX is not being developed anymore, If you have the pleasure of using such a solid machine as either the O2,Octane or a Fuel, Opensource (Linux or BSD) is your only option.
They are awesome machines which are pretty solid and perform adequately despite their age.
By Miod Vallat (miod) on
I don't have any AMD64 or EMT64 hardware, and I try to avoid developing for hardware I can't test on.
By Anonymous Coward (216.68.196.80) on
OpenBSD opens up doors for everything to work and finds those who sure can make everything work as well.
Would be interesting to read about what is the top video stuff these days, although probably the guys in the animation movie business probably are top notch.
Anyway an interesting read.
Comments
By Joel Sing (131.172.99.15) jsing@openbsd.org on
> with top notch graphic software like the NRO used to use, then I'll be
> especially happy.
It's in the pipeline - in fact Miod committed the first parts of IP30 (Octane) support last night. One of the biggest challenges with supporting other platforms is the lack of hardware documentation - it has taken us a long time just to get the basics working and there's still stuff that we're trying to figure out (by spending hours in the kernel debugger!)
As for the graphics software, I'll leave that to someone else :)
By Anonymous Coward (88.192.76.90) on
Comments
By Anonymous Coward (2a01:348:108:155:20a:e4ff:fe2d:99ee) on
It didn't, the article about ports is over here -> http://undeadly.org/cgi?action=article&sid=20080406171752&mode=flat
By Renaud Allard (renaud) renaud@llorien.org on
I was going to sell my Octane2 and my Fuel, but if OpenBSD is going to run on these, no way, I won't sell them..
By Anonymous Coward (80.248.254.241) on
Comments
By Joel Sing (58.6.65.97) jsing@openbsd.org on
At this stage we're more interested in getting the higher end hardware (IP27, IP30, IP35, etc) supported first. We'd certainly like to support IP22, however I'm not sure it will be in the immediate future. Plus I'd need to get my hands on an IP22 system...
Comments
By Matt Radtke (128.104.28.181) on
>
> At this stage we're more interested in getting the higher end hardware (IP27, IP30, IP35, etc) supported first. We'd certainly like to support IP22, however I'm not sure it will be in the immediate future. Plus I'd need to get my hands on an IP22 system...
Would you be interested in an IP20? I've got one that works fine that I can't seem to give away locally.
By Miod Vallat (miod) on
It's on my list (and code for these machines can be found in NetBSD), but IP27 and IP30 are a higher priority at the moment.
Comments
By Anonymous Coward (24.129.210.190) on
>
> It's on my list (and code for these machines can be found in NetBSD), but IP27 and IP30 are a higher priority at the moment.
Miod did you ever contacted SGI and asked for HW documentation?
And if so: What did they answered?
Comments
By Anonymous Coward (134.103.184.81) on
> >
> > It's on my list (and code for these machines can be found in NetBSD), but IP27 and IP30 are a higher priority at the moment.
>
> Miod did you ever contacted SGI and asked for HW documentation?
> And if so: What did they answered?
I send a mail to them and asked for documentation and further support.
I used this web-form so others here ma yalso request support or documentations (at least for older MIPS based Computers made by SGI):
http://www.sgi.com/cgi-bin/send/devprogram
I personaly was unable to find any specidifc documentation at their website. Their website alos looks a lil bit odd to me imho.
By Anonymous Coward (69.196.132.120) on
> >
> > It's on my list (and code for these machines can be found in NetBSD), but IP27 and IP30 are a higher priority at the moment.
>
> Miod did you ever contacted SGI and asked for HW documentation?
> And if so: What did they answered?
If you guys ever need help for the IP12/20/22/24 machines, do not hesitate to contact me (rumble at netbsd). The NetBSD code should be reasonably clear, but I had to stumble through enough that I'd really not like to see others have to do the same.
As for SGI, I used to talk to an engineer there occasionally who was generous with his time and willing to answer some basic questions, but I doubt he's still there. Generally, you're on your own. For much of the hardware the IRIX headers are good help, but it's still a hassle without documentation.
Comments
By Anonymous Coward (209.151.236.27) on
> > >
> > > It's on my list (and code for these machines can be found in NetBSD), but IP27 and IP30 are a higher priority at the moment.
> >
> > Miod did you ever contacted SGI and asked for HW documentation?
> > And if so: What did they answered?
>
> If you guys ever need help for the IP12/20/22/24 machines, do not hesitate to contact me (rumble at netbsd). The NetBSD code should be reasonably clear, but I had to stumble through enough that I'd really not like to see others have to do the same.
>
> As for SGI, I used to talk to an engineer there occasionally who was generous with his time and willing to answer some basic questions, but I doubt he's still there. Generally, you're on your own. For much of the hardware the IRIX headers are good help, but it's still a hassle without documentation.
Got the irix 6.5.5 sources.. if that helps.
By Anonymous Coward (208.48.231.12) on
Therefore, I would like to thank you for supporting this platform, I'm in the hopes that you will extend support to other SGI machines, such as the octane, origin or fuel, but meanwhile, I am very happy with the upcoming 4.3 release of OpenBSD/sgi and looking forward to install it.
Thank you.
Comments
By Anonymous Coward (209.151.236.27) on
>
> Therefore, I would like to thank you for supporting this platform, I'm in the hopes that you will extend support to other SGI machines, such as the octane, origin or fuel, but meanwhile, I am very happy with the upcoming 4.3 release of OpenBSD/sgi and looking forward to install it.
>
> Thank you.
Consider to contact SGI so they may release some documentation wich is propably the most helpfull for the developers and maintainers of the OpenBSD/SGI Port.
Comments
By Anonymous Coward (61.171.146.98) on
> Consider to contact SGI so they may release some documentation wich is propably the most helpfull for the developers and maintainers of the OpenBSD/SGI Port.
Would be nice if people had a clue before they opened their mouths. SGI wouldn't answer any questions from God Himself.
Comments
By Brad (2001:470:8802:3:216:41ff:fe17:6933) brad at comstyle dot com on
People actually having half a clue. *gasp* What is the world coming to. Am I dreaming? *pinch*