Monthly Archives: February 2009

WIP: Ubiquity’s router station

So it has been a month since last post about this device and I think it's time to announce current state of affairs.

  • UART: just works
  • PCI controller: kind of works. Proper interrupt handling/routing required.
  • On-board ethernet controller: WAN port works fine. Mounts NFS root/loads init. Some minor work should be done in order to get both ports working.
  • Integrated OHCI controller: kernel detects and initializes it. Need USB cable to connect something to headers on the board and test if it actually works.
  • Integrated EHCI controller: in progress. Some refactoring of current MIPS bus_space implementation required.
  • GPIO: to be done
  • Flash memory: to be done

At the moment further progress was blocked with something that looks like memory corruption. It's hard to trace with ktr(4) and printf(9) so I ordered Flyswatter JTAG adapter and MIPS14 adapter from Tin Can Tools. I was warned that Flyswatter/MIPS combination is not supported by OpenOCD but I'd better spend some time making it work then tracing obscure memory corruptions in the wild.

WIP: Ubiquity’s router station

So it has been a month since last post about this device and I think it's time to announce current state of affairs.
  • UART: just works
  • PCI controller: kind of works. Proper interrupt handling/routing required.
  • On-board ethernet controller: WAN port works fine. Mounts NFS root/loads init. Some minor work should be done in order to get both ports working.
  • Integrated OHCI controller: kernel detects and initializes it. Need USB cable to connect something to headers on the board and test if it actually works.
  • Integrated EHCI controller: in progress. Some refactoring of current MIPS bus_space implementation required.
  • GPIO: to be done
  • Flash memory: to be done
At the moment further progress was blocked with something that looks like memory corruption. It's hard to trace with ktr(4) and printf(9) so I ordered Flyswatter JTAG adapter and MIPS14 adapter from Tin Can Tools. I was warned that Flyswatter/MIPS combination is not supported by OpenOCD but I'd better spend some time making it work then tracing obscure memory corruptions in the wild.

WIP: Ubiquity’s router station

So it has been a month since last post about this device and I think it's time to announce current state of affairs.

  • UART: just works
  • PCI controller: kind of works. Proper interrupt handling/routing required.
  • On-board ethernet controller: WAN port works fine. Mounts NFS root/loads init. Some minor work should be done in order to get both ports working.
  • Integrated OHCI controller: kernel detects and initializes it. Need USB cable to connect something to headers on the board and test if it actually works.
  • Integrated EHCI controller: in progress. Some refactoring of current MIPS bus_space implementation required.
  • GPIO: to be done
  • Flash memory: to be done

At the moment further progress was blocked with something that looks like memory corruption. It's hard to trace with ktr(4) and printf(9) so I ordered Flyswatter JTAG adapter and MIPS14 adapter from Tin Can Tools. I was warned that Flyswatter/MIPS combination is not supported by OpenOCD but I'd better spend some time making it work then tracing obscure memory corruptions in the wild.

anholt @ 2009-02-24T14:55:00

Things have been pretty quiet on the intel graphics driver front for a while. After all the churn of FBOs, GEM, DRI2, and KMS, we've been settling down to seriously stabilizing the driver. Things are looking pretty good -- KMS is now suspending/resuming, resizing framebuffers, supporting rotation, and generally looking relatively correct on the machines we're testing on. A number of DRI2 performance regressions are fixed. We've fixed some tricky little bugs in GEM cache handling. Big thanks goes out to the RH guys (airlied and krh) for pushing so hard on this code and fixing a bunch of the sharp edges instead of just filing bugs, and to ickle for reviewing and fixing piles of error path problems in the DRM. I love working with this community.

We're now ramping up for the Q1 release, which means we're switching from what has been nearly 100% time on bug and regression fixing to 100% bug and regression fixing. I just pushed out xf86-video-intel 2.6.2 to get some of our stable fixes into the world so people have a better base for testing KMS. By the end of March we should have a new release out with current 2D, a new Mesa tarball with the latest fixes since 7.4, and hopefully a kernel 2.6.29 with KMS.




In my spare time I've been working on a GL backend for cairo. My assertion for some time has been that anything we're doing with accelerating Render, we could do with less developer time and faster runtime with GL. It took about 2 weeks of me flailing around learning how to do GL, and I got cairogears up and running at about 4 times the speed of Render, on various 965s.

The code's still pretty rough -- it doesn't check for extensions it needs, relies on NPOT textures when it could use rectangular textures, doesn't do shaders for gradients, etc. But actually most of the time on the code has been spent fixing our 3D driver. There were some texture upload issues, BO cache explosion issues, drawpixels issues, DRI2 viewport overhead issues, and my current one is that the latest commit in cairo-gl ends up hanging both 915s and 965s after a while in cairogears.

I'm hoping some other people interested in this stuff might feel like picking it up and playing with it. It's not terribly complicated code, I don't think, there are other backends to compare to, and cairo's test suite is wonderful for validating what you're trying out. The code is in:

git://people.freedesktop.org/~anholt/cairo on the gl branch
git://people.freedesktop.org/~anholt/cairogears on the gl branch

anholt @ 2009-02-24T14:55:00

Things have been pretty quiet on the intel graphics driver front for a while. After all the churn of FBOs, GEM, DRI2, and KMS, we've been settling down to seriously stabilizing the driver. Things are looking pretty good -- KMS is now suspending/resuming, resizing framebuffers, supporting rotation, and generally looking relatively correct on the machines we're testing on. A number of DRI2 performance regressions are fixed. We've fixed some tricky little bugs in GEM cache handling. Big thanks goes out to the RH guys (airlied and krh) for pushing so hard on this code and fixing a bunch of the sharp edges instead of just filing bugs, and to ickle for reviewing and fixing piles of error path problems in the DRM. I love working with this community.

We're now ramping up for the Q1 release, which means we're switching from what has been nearly 100% time on bug and regression fixing to 100% bug and regression fixing. I just pushed out xf86-video-intel 2.6.2 to get some of our stable fixes into the world so people have a better base for testing KMS. By the end of March we should have a new release out with current 2D, a new Mesa tarball with the latest fixes since 7.4, and hopefully a kernel 2.6.29 with KMS.




In my spare time I've been working on a GL backend for cairo. My assertion for some time has been that anything we're doing with accelerating Render, we could do with less developer time and faster runtime with GL. It took about 2 weeks of me flailing around learning how to do GL, and I got cairogears up and running at about 4 times the speed of Render, on various 965s.

The code's still pretty rough -- it doesn't check for extensions it needs, relies on NPOT textures when it could use rectangular textures, doesn't do shaders for gradients, etc. But actually most of the time on the code has been spent fixing our 3D driver. There were some texture upload issues, BO cache explosion issues, drawpixels issues, DRI2 viewport overhead issues, and my current one is that the latest commit in cairo-gl ends up hanging both 915s and 965s after a while in cairogears.

I'm hoping some other people interested in this stuff might feel like picking it up and playing with it. It's not terribly complicated code, I don't think, there are other backends to compare to, and cairo's test suite is wonderful for validating what you're trying out. The code is in:

git://people.freedesktop.org/~anholt/cairo on the gl branch
git://people.freedesktop.org/~anholt/cairogears on the gl branch

isc.FreeBSD.org Cluster Update

The FreeBSD project has three racks hosted by ISC with various servers. The use of the systems have been limited by the fact that there was no firewall in front of the systems, so each host had to have local firewall and/or access control rules.

To use the isc.FreeBSD.org systems better we have now installed a firewall in front of the systems. This means that the FreeBSD project can better use the facilities provided by ISC and the servers donated by various people and companies.

The firewall is in fact two separate Soekris net5501-70 systems running FreeBSD 7. They use pf for packet filtering and CARP to provide redundancy between the two systems. The redundant setup is done to reduce the risk of taking all the isc.FreeBSD.org systems offline due to hardware or software failure in one firewall.

The two Soekris net5501 systems were sponsored by the FreeBSD Foundation. The 1U rack mount case and flash cards were donated by Brad Davis. Brad also handled the initial configuration and installation of the systems at ISC. Peter Losher helped out from the ISC side with getting additional IP addresses, DNS, and other logistics. So a big thanks to all the before mentioned for helping making this possible, and to ISC in general for hosting the servers.

10.140 MHz QRSs beacon

Got samples from analog.com.brNow to put them into use:

1) get geda installed

2) check/find the schematic symbols

3) check/find the pcb footprint

4) draw the schematc

5) layout a pcb

6) ask a friend to make the pcb

7) go into soldersmoke ( is a podcast actually)
8) make program for a pic or simply control it with an USB to lpt converter

#1 is done, to #2 though symbols needs to be created.

Stalking Keramida


Quick tip for finding if keramida’s been active in a machine the last few days.

Run the command:

% ps xau | sed -n -e 1p -e /sed/d -e '/keramida.*emacs.*daemon/p'

Watch for activity in the Emacs daemon, and if you see any, well… you know that keramida is active :-)

Posted in Computers, Emacs, Free software, FreeBSD, GNU/Linux, Linux, Open source, Software Tagged: Computers, Emacs, Free software, FreeBSD, GNU/Linux, Linux, Open source, Software

Short updates

A couple of (lagged!) updates on my FreeBSD/PmcTools work:

  • In Nov'08, I added support for Intel™ Core 2™ PMCs to PmcTools (SVN #185363 and later changesets).

    More recently, Nokia, via Jeff Roberson, contributed basic support for the PMCs in the Core/i7™ CPU, the next member in the Core™ family of CPUs (SVN #187761).

    With these additions PmcTools supports most Intel CPUs that have PMCs in them. (I have plans to finish support for 166Mhz Pentium MMX™ CPUs soon.)

  • A couple of tricky bugs were tracked down and fixed:

    • The NMI handler code I had written for the amd64 architecture needed to be more robust than it was. Fixed in SVN #188065.

    • A bug in callchain capture code that would appear only under high loads and only on SMP machines. Fixed in SVN #186037.

    Thanks to Artem Belevich, Fabien Thomas, George Neville-Neil and Jeff Roberson for their assistance with debugging.

Short updates

A couple of (lagged!) updates on my FreeBSD/PmcTools work:

  • In Nov'08, I added support for Intel™ Core 2™ PMCs to PmcTools (SVN #185363 and later changesets).

    More recently, Nokia, via Jeff Roberson, contributed basic support for the PMCs in the Core/i7™ CPU, the next member in the Core™ family of CPUs (SVN #187761).

    With these additions PmcTools supports most Intel CPUs that have PMCs in them. (I have plans to finish support for 166Mhz Pentium MMX™ CPUs soon.)

  • A couple of tricky bugs were tracked down and fixed:

    • The NMI handler code I had written for the amd64 architecture needed to be more robust than it was. Fixed in SVN #188065.

    • A bug in callchain capture code that would appear only under high loads and only on SMP machines. Fixed in SVN #186037.

    Thanks to Artem Belevich, Fabien Thomas, George Neville-Neil and Jeff Roberson for their assistance with debugging.

Contributing to FreeBSD


As part of the FreeBSD team, I often get asked the same question: “How can I get started as a FreeBSD contributor?”

There are usually two reasons why a new contributor feels overwhelmed by the idea of getting started. One of them is that he or she feels that it is difficult to find out exactly how to start contributing to a free software project. The second reason is usually a feeling of impotency, the notion that “I am such a newbie, how could I ever make a difference in such a large project?”

Both of these concerns can be addressed quite easily. This post is my attempt at recording what I have learned by being a part of the FreeBSD team for almost a decade now, so let me start by the most serious one of these two obstacles to becoming a FreeBSD contributor: the feeling of being too small to make a difference.

 

You Can Make a Difference!

The best response I can think to the idea that a new contributor is too small to do something important for FreeBSD is a short story by one of the Argentinian authors I love. A story by Jorge Bucay:

The Story of the Chained Elephant

When I was a small boy, I loved going to the circus. Animal acts were my favorite. I was quite impressed by the elephant, who is — as I found out later — the favorite animal of all children. The elephant’s part of the show was a display of his huge weight, his immense size and power… Then, as the show was approaching its end, slightly before the elephant had to return to his tent, he was standing tied to a tiny wooden stake driven partially into the ground. A chain was wrapped around his feet.

The size of the stake was very small, and the part of it that was driven into the ground was even smaller. The chain that was wrapped around the legs of the elephant was quite large, but it seemed quite obvious, even to my childish mind, that an animal whose power was so large, so immense that it could rip trees off the ground and hurl them to others, was more than enough to let the elephant just rise and walk away.

That was the mystery of the elephant.

What sort of immense force could keep the elephant tied to that tiny stake?

Why didn’t he rise and walk away?

When I was five or six years old, I put great trust in the wisdom of the elder people. So I asked my teacher, my father, and my uncle about the mystery of the elephant. I don’t remember anymore who gave me the particular answer, but one of the replies was that the elephant doesn’t run away because he is “tame”.

Then I asked the obvious question: “If he’s tame, why do they have to chain him?” I don’t think I ever got a satisfactory answer to this question.

As time went by, I forgot all about the mystery of the huge elephant and the tiny stake. The mystery would only resurface when I was at the company of others who had wondered about the same thing.

Then, a few years ago, I discovered that someone knew why the elephant doesn’t run away.

The elephant doesn’t run away because they have been tying him to a similar stake ever since he was very very small too.

I closed my eyes, and I tried to imagine the small, newborn elephant, chained to the ground. The small elephant would push, pull and struggle with all his strength, trying to free himself, but he would fail. Despite all his efforts, he would fail again and again, because that stake and chain was too big for his strength.

The elephant would sleep exhausted from all his efforts to free himself, and would wake up the next day. All his struggles would fail the next day too, and a third day, and a fourth, and many tiresome, exhausting days after those. Then one day would come — a horrible day for the history of our elephant — a day that he would just give up, and accept his fate, deciding that he was too weak to escape, that his strength was not enough and would never be enough.

The huge and immensely powerful elephant that we see in the circus does not run away because the poor animal believes that he cannot do that.

The memory of the lack of strength he felt a little after his birth is now deeply engraved to his very soul and spirit.

The worst of it all is that he has never tried to free himself since.

He never ever tried to test his powers again.

The story of the circus elephant is often why new people do not try to contribute to FreeBSD. They have this strange idea that they are, for some odd reason, “not good enough”; that they cannot really stand side to side with the giants who have built this enormous, immensely huge system; that their feeble attempts to improve their favorite OS will be met with scorn, or contemptuous laughter by the super smart alien beings that are behind such a complex beast of a system.

This is, fortunately, not true. FreeBSD has been developed by humans, by people like me and, most importantly, you, the new contributor who is passionate about his favorite OS. We are not superhuman entities from outer space, but we like what we are doing, and we try to develop, improve and extend the operating environment that we all love.

We have all tried to do many things about FreeBSD and with FreeBSD. Some of them have worked, and a small percentage of what has worked later became a part of the official FreeBSD system. But there have also been thousands of times that we failed. Utterly and unrecoverably failed. We went down the wrong path for a long time. We tried things that were risky, amusing but also very very easy to break; to do funny, or silly things, or even to just explode in our face.

If you are a new FreeBSD contributor then try to avoid getting stuck in that tiny stake and chain that keeps the circus elephant from being free. We have all failed in out attempts to do something that improves FreeBSD. We have failed not once, not twice, but many times over and over again.

But we keep trying our strength, and in the end we do find our place in the team that makes FreeBSD the wonderful system that it is today and the amazing system that it will be tomorrow :)

 

Finding Out How to Get Started

So you decided that you do want to help, but there’s a tiny obstacle that has to be overcome first. You don’t know where to get started and learn more about FreeBSD, how it works, how it is developed, and how you can contribute to make it a better system.

First of all, congratulations for wanting to contribute to FreeBSD! We always need more hands to work on the open bugs, to answer questions of new users, to write documentation, to test new drivers, to debug and fix old drivers, and so on.

There are many things you can do to help FreeBSD. You can start with easy tasks, and move to more difficult ones as you pick up the details of how everything works.

My suggestion would be to start by reading the latest version of the “Contributing to FreeBSD” article. You can find it online at:

http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing/

If you are interested in helping us with the FreeBSD Ports Collection, one of the major selling points of FreeBSD, there is a separate article that may give you some ideas to get started: “Contributing to the
FreeBSD Collection
“. This one is available at:

http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing-ports/

The “FreeBSD Development Projects” page is a third option you have. This is a a list of interesting, active and/or useful things we could do to extend, improve and adapt FreeBSD to do new or just more cool things. The list of projects is visible online at:

http://www.freebsd.org/projects/

Some of the most interesting projects are listed separately in that page, under the “Project Ideas” section:

http://www.freebsd.org/projects/ideas/

All these pages are public information, accessible to anyone who wants to know about ways to help FreeBSD. So you are most welcome to have a look at these pages, and look for something that seems interesting for you.

When you do find something interesting, you will probably have a few questions about how to work on the idea, where to grab the sources of FreeBSD, where to submit patches, how to do that, and so on. Our large collection of mailing lists is going to be helpful at this point. Visit the mailing list information page at:

http://lists.freebsd.org/mailman/listinfo/

Look for a mailing list that matches the work you are doing, and then either post directly to the list, or subscribe to it. One of the lists that is probably going to be useful for general questions about FreeBSD (questions like “where do I get the source of the ls(1) utility?”) is the freebsd-questions mailing list:

http://lists.freebsd.org/mailman/listinfo/freebsd-questions

If you can’t locate the correct list for something you are working on, if you have questions that don’t seem to fit neatly into the topics of another list, or even if you just want to ask something quick about FreeBSD but you don’t have the time to seek the right mailing list to do that, the freebsd-questions list should be your fallback choice.

Posted in Computers, Free software, FreeBSD, Open source, Programming, Software Tagged: Computers, Free software, FreeBSD, Open source, Programming, Software