Archive for September, 2006

Buggy motherboards

Monday, September 25th, 2006

I’d love to know how large motherboard manufacturers manage to produce buggy boards. Just as we’re putting two new servers into production at work, I discover an annoying problem: if there is a sustained data transfer over the network for about 10 minutes, the systems reboot. No warning, no error messages, just a reboot. Having poked around I discovered that changing the kernel’s interrupt timer frequency (i.e. setting how often Linux checks for interrupts) changes the amount of time it takes for the system to reboot during data transfer. Set to 100Hz, the system reboots immediately as soon as the transfer is started. At 250Hz, you get a few seconds before the reboot. At 1000Hz (the default), you get 5-10 minutes. So knowing that the problem was related to interrupts, I suspected it may be the APIC on the motherboard at fault, as it seems relatively common for motherboard manufacturers to stuff it up.

So I went into the BIOS and disabled the APIC (after first having to disable hyperthreading), rebooted and alas all is well: no more reboots.
My theory about the exact cause of the problem is that for some reason interrupts were being generated faster than the OS could handle them, possibly due to spurious interrupts being generated at the APIC. Interrupt controllers receive interrupts from components within the system and essentially queue them. Then at a pre-defined interval (between 100-1000Hz on Linux, 100Hz on Windows) the OS checks for interrupts, acknowledges them (causing the interrupt controller to remove them from the queue) then goes away to handle them. I believe that so many interrupts were being generated that the interrupt controller’s queue was getting full. When this happens the motherboard logic says ‘bloody hell this shouldn’t happen and I can’t recover from it’ and reboots the machine.

So if you are the unlucky owner of a Supermicro P4SCT+ motherboard, beware!

Video goodness with Python and GStreamer

Thursday, September 14th, 2006

I’ve been working on a project for some time which involves using Python and GStreamer to display some video. The lack of documentation has been a PITA and I’ve been trying for some time to figure out how you get GStreamer to display its video output within a GTK widget. Well today, I figured it out. Thanks to this blog post by Jono Bacon I learned a lot more about GStreamer which motivated me to start looking at the problem again. His post urges everyone who can to document what they’re doing in Python and GStreamer, so here’s some example code to display some video within a GTK widget. The code is based on Jono’s example for an audio player.

#!/usr/bin/python
import pygst
pygst.require(“0.10″)
import gst
import pygtk
import gtk

class Main:
 def __init__(self):

  # Create GUI objects
  self.window = gtk.Window()
  self.vbox = gtk.VBox()
  self.da = gtk.DrawingArea()
  self.bb = gtk.HButtonBox()
  self.da.set_size_request(300,150)
  self.playButton = gtk.Button(stock=’gtk-media-play’)
  self.playButton.connect(“clicked”, self.OnPlay)
  self.stopButton = gtk.Button(stock=’gtk-media-stop’)
  self.stopButton.connect(“clicked”, self.OnStop)
  self.quitButton = gtk.Button(stock=’gtk-quit’)
  self.quitButton.connect(“clicked”, self.OnQuit)
  self.vbox.pack_start(self.da)
  self.bb.add(self.playButton)
  self.bb.add(self.stopButton)
  self.bb.add(self.quitButton)
  self.vbox.pack_start(self.bb)
  self.window.add(self.vbox)

  # Create GStreamer pipeline
  self.pipeline = gst.Pipeline(“mypipeline”)
  # Set up our video test source
  self.videotestsrc = gst.element_factory_make(“videotestsrc”, “video”)
  # Add it to the pipeline
  self.pipeline.add(self.videotestsrc)
  # Now we need somewhere to send the video
  self.sink = gst.element_factory_make(“xvimagesink”, “sink”)
  # Add it to the pipeline
  self.pipeline.add(self.sink)
  # Link the video source to the sink – xv
  self.videotestsrc.link(self.sink)
  self.window.show_all()

  def OnPlay(self, widget):
   print “play”
  # Tell the video sink to display the output in our DrawingArea
   self.sink.set_xwindow_id(self.da.window.xid)
   self.pipeline.set_state(gst.STATE_PLAYING)

  def OnStop(self, widget):
   print “stop”
   self.pipeline.set_state(gst.STATE_READY)

  def OnQuit(self, widget):
   gtk.main_quit()

start=Main()
gtk.main()

Download this code

We start off by creating our objects. Unlike Jono I’m not using glade to create the GUI because, for some reason, it won’t allow me to access the full range of functions/properties associated with the objects – perhaps my own fault. This part should be pretty self-explanatory for anyone who’s done GUI programming in other languages such as Java.
To understand the basics of GStreamer and pipelines, sources, sinks etc. refer to Jono’s post.

Here I’m using the videotestsrc which produces a testcard. To decode an actual file, you’d instead use a filesrc and decodebin and link them together. I then create an xvimagesink which will display the video using the xv functionality of X. There is also a sdlvideosink and a glvideosink – which you use will depend on what’s installed on the system of the user, but generally xvimagesink is the best choice. By default, any of the video/image sinks will simply create a new window in which to display their output, but we want to display it in the DrawingArea we created earlier.

This is achieved in the OnPlay function, where we get the DrawingArea’s ID using the window.xid property and pass it to the video sink we created earlier using the set_xwindow_id function. This tells the video sink to not create a new window, but use the DrawingArea instead. Note that we can’t get the window.xid property until after the window has been created, which is why we do it in the OnPlay function rather than before when we’re setting up the pipeline. Once that’s done, we can start the playback and enjoy the GStreamer video goodness. Note that this only displays video though – any audio content will be ignored. Getting audio and video playback working together is my next task and I shall endeavour to document that here once I figure it out.

Unfortunately I can’t show you a screenshot of the working script due to the way xv works using overlay – if you take a screen shot, you just get nothingness where the video is.

Simply RISC

Thursday, September 14th, 2006

This is really cool – a group called Simply RISC have taken Sun’s UltraSPARC T1 design from OpenSPARC, stripped away 7 of the 8 cores to simplify the design and released the whole lot in a ready-to-go package to work with the Free Icarus Verilog suite that runs on Linux. Now that some of the complexity has been removed, the whole codebase is more managable (and it’ll fit onto smaller (read: cheaper) FPGAs, too). They’ve also added a Wishbone bridge, which makes it easy to add extra Wishbone-compliant modules from OpenCores.

I’m constantly frustrated by the lack of decent media centre motherboards out there (the best is the Via Epia-M series which feature on-board MPEG decoding, but unfortunately the MPEG hardware is seemingly not supported by ANY software AT ALL) so one day it’d be nice to see someone add MPEG decoding to Simply RISC on-chip and start selling motherboards featuring it. Sure this is probably about as commercially-viable as suing every Linux user on the planet in terms of a business model, but I live in hope… I’d love to be able to design and build such a thing myself, but I suspect I will always lack the necessary resources (read: money) :-(