Archives for: 2009


Permalink 11:15:47 am, by jbarnes Email , 531 words, 46140 views   English (US)
Categories: Announcements [A]

So I followed Paul Mundt into this narrow alley...

Back from Japan at last (I think United lost my sleep schedule on the way home though, trying to retrieve it this weekend has been a challenge).

Both KS and JLS went well I thought. It was really good to connect with some of the Japanese developers that until now I’ve only interacted with through email.

The summit went well this year I thought. We didn’t have a big set of controversial issues to discuss, but we did sort out some development process issues. The highlight for me was the two customer panels. On the first day we had some people from TV and other vendors talk about how they’re using the kernel and other open source software. It’s interesting that some of them are stuck way back on 2.4 and very early 2.6 kernels. Part of the reason is long product development cycles, but mostly it’s because the SoCs used in many products only have support in a limited set of kernels (usually custom patches for specific kernels provided by companies like Montavista). The “platformization” work done by tglx and the x86 team recently (partly motivated by Intel “Moorestown” support, but also in preparation for more x86 based SoCs in the future) should help with this for x86 stuff. We definitely want to avoid an ARM-like situation where each SoC requires a specific kernel with incompatible firmware and hardware support. I had some good discussions with Linus and Paul on that topic; the tricky part will be ensuring that vendors adhere to some level of standardization in their platform and firmware support. Doing so will have big benefits: upstream kernel support should be better and much more flexible (good for the SoC vendors and their customers), and the platform maintainers should have a much easier job integrating support for new platforms without a huge set of ifdefs and incompatible firmware interfaces. Managed to get a few bugs fixed at KS as well, Ted & Dirk didn’t have anywhere to run when I wanted them to test some patches for problems they’d reported!

The JLS conference was interesting too, with a few good talks on things like barcode delivery of oops info and btrfs

Tokyo is a pretty amazing city. This was my first trip to Japan and a few of us were fortunate enough to have Paul Mundt guide us for a couple of evenings to explore the city. The narrow alleyways and tiny bars in the Shinjuku (at least I think that’s where we ended up) were really fun. We even checked out a Mexican bar called Bonita; Mexican stuff outside the southwest US and Mexico is always interesting, but the Japanese mix made things even more so. Overall a fun night including Japanese Denny’s food, passed out salarymen, and an everything store with some bizarre costumes, including some furry outfits we were tempted to buy… A bit later in the week we had a contrasting experience by going to Seamon (one of the dozens of one star Michelin sushi restaurants in Tokyo) and a high end scotch and cigar bar afterwards.

Ok now back to catching up on the huge backlog of patches that have accrued due to travel neglect.


Permalink 01:51:25 pm, by jbarnes Email , 194 words, 14859 views   English (US)
Categories: Announcements [A]

Off to Portland

Heading off to Portland tomorrow for Plumber’s (Wed-Fri) and XDC (following Mon & Tue).

I’m hoping we can get the compositing & GLX architectural improvements for X nailed down (see and our talk outline at My implementation of some of those features is already limping along and I’m hoping we can land it soon and start on some compositor improvements to take advantage of the new features.

The merge window has been busy so far, with a few good PCI improvements landed (including VGA arbitration, finally!), and a bunch of gfx related stuff: a slew of power management improvements (dynamic render, display and refresh rate controls, framebuffer compression, RAM self-refresh mode enabling and a bunch of clock gating enables), several stability improvements (GEM memory shrinker, bug fixes for our ring management, reloc range checking, automatic GPU reset support), and a few performance improvements (madvise support for GPU buffers). Overall very busy and very cool stuff. I’m still holding out hope we can land the page flipping and execbuf2 code this cycle; if the merge window stays open through Plumbers that should be possible.


Permalink 04:17:14 pm, by jbarnes Email , 18 words, 13846 views   English (US)
Categories: Announcements [A]



Permalink 12:57:16 pm, by jbarnes Email , 1331 words, 27890 views   English (US)
Categories: Announcements [A]

Morning in America^WLinuxland

It’s been about two months since my last update. Most of last month was spent travelling, first to UDS in Barcelona (one of my favorite cities btw), then to London to work at OTC Europe on Moblin, and then on to Oregon to meet with the greater graphics team. In between flights and whenever I had time I also got some good work done; working through PCI patches, improving the error detect/collection code, testing the GPU reset patch a bit more, working on 3D tiling for pre-965 chipsets, and doing general bug fixing. But first things first.

UDS Barcelona

This was the second UDS in Spain I attended (first was in Sevilla a couple of years ago). Overall I found it to be a bit more organized and productive than the first. Probably a sign that the Ubuntu community and Canonical have grown a bit since then…

As I said, I thought this UDS was particularly productive, and ambitious to boot. Scott set an aggressive 10s boot time target for Karmic, and the desktop team decided to pull some very new technologies like KMS and DRI2 into the Karmic release. This is great news for users due to the improved feature set, but also makes life much better for upstream developers, since supporting the new code is much easier than dealing with old DRI1 stuff.

Another huge development (which actually pre-dates this UDS) is the xorg edgers repo. It’s a PPA containing packages of the graphics stack (kernel, libdrm, Mesa, X server and drivers) directly from git. Having this available means testing and development are greatly accelerated; now when users report a bug in the Karmic repos, we can ask them to quickly and easily test the xorg edgers bits to see if their issue has been fixed. If so, we know a backport may be needed, and if not we have a good bug report to feed upstream. I run this repo myself, typically updating every morning, and have found and fixed quite a few bugs as a result of finding them early. Robert and the rest of the edgers team deserve huge thanks from everyone in the Linux community for their work on this repo. I hope their example is followed by other projects, maybe for audio, bluetooth or wireless stacks, which also have large kernel and userland components.

Some other cool stuff got demoed at UDS this time, including some cool Android on Ubuntu work and an Ubuntu spin of Moblin! The latter is especially cool, and I’m hoping to install it on one of my Netbooks soon.

Graphics stuff

The London trip was something of a last minute affair. I was already in Barcelona, and our OTC Europe team in London was in the middle of working on some graphics related Moblin stuff, so they sent Eric, Ian and myself over there to help out. It turned out to be a very productive week; we fixed some major issues while there and overall improved performance by about 50% on some workloads. Some of that work will make its way into our next release and future kernels.

One of the big issues we worked on over there was implementing tiling for 3D textures. We did this awhile ago for some of the major buffers (front, back, depth), but doing it for textures is a bit more involved. Eric quickly got 965+ tiling working, but pre-965 turned out to be a bit more of a pain due to its fencing requirements. The 2D and display engines on pre-965 chips need fence registers to cover tiled regions in order to blit or scan them out. The 3D engine can handle tiled surfaces directly, without fences. The current execbuffer code (the central command submission mechanism) will always allocate fence registers for tiled surfaces however, and on chips with only 8 fence regs (915 and prior) that can be a problem. Not only are fence registers scarce, but mapping and unmapping objects with them can be an expensive operation. So I came up with the execbuffer2 interface, which adds a new relocation type to handle the fence register requirement. Commands using 2D blits for example can use a reloc type that indicates a fence register is required, while purely 3D commands can avoid it. There’s potential for more improvement if we remove 2D blits from the DRI driver, though that may involve more overhead than we’d like, due to the higher setup costs. As it stands, tiling textures can give us a ~20% performance boost on some workloads…

Another thing I had some time to work on at UDS and in London was GPU error handling. Our GPUs have some error handling capabilities we haven’t really taken advantage of until recently. Eric and Carl recently improved the GPU dumping utility significantly, which really makes GPU hang debugging possible. To make things even easier, I put together a patch to use the GPU error interrupt to trigger a error state capture and generate a uevent. The idea here is to capture the error state from the first error, then tell userspace it should capture a full ring & batch buffer dump as soon as possible. This should allow for automated reporting, ala kerneloops, of GPU related errors. The second part of the work involves automatically resetting the GPU when a hang is detected. I posted working patch for that aspect of error handling, but it still needs a little work on the hang detection side before we can push it upstream. I’m hoping both that and the execbuffer2 stuff will land in 2.6.32 (since it’s a bit late for big stuff to land in 2.6.31); the reset patch should be fairly easy to backport though.

Oh yeah, BUGS! The past couple of months have seen unprecedented bug fixing activity on the Intel graphics stack. The removal of the DRI1, XAA, EXA and much of the non-memory manager code is really started to pay off. We’ve been fixing bugs left and right lately, really stabilizing the drivers in both KMS and non-KMS configurations. Not having to worry as much about breaking some weird configuration possibility is a big help (though the non-DRM case still bites us from time to time). In short, things are really looking good on the graphics front these days; the major architectural changes are complete now, and we can really focus on making things solid.

PCI queue

And on the belated “what’s up with PCI this cycle” front, we had one major issue this time around. In an effort to keep the kernel from using BIOS reserved areas, we started using the ACPI _CRS (current resource settings) data from root bridges at boot time, to describe the set of resources on the root bus. Turns out some BIOSes list a ton of resources in _CRS, including legacy VGA and I/O port space. This can be helpful (since the alternative is having a huge list of chipsets and what ranges they’re hardcoded or programmed to decode), but the PCI layer isn’t quite ready to handle arbitrary numbers of bus resource ranges and types. So early in the cycle Linus had to revert the move to using _CRS by default; that said we did get some good fixes from Gary and Yinghai for the _CRS case, so eventually we should be able to use that data in some form.

Of course, eventually I’m hoping to add something like TJ’s resource management code to Linux. Unfortunately TJ seems to have disappeared, and he never did post his code. Fortunately he did leave a good set of notes on his website about what he’d discovered (e.g. which bits of info are reliable and how other OSes use ACPI data etc). The hard part is finding time to implement such a large change and get it tested well enough to feed upstream. The other perennial topic is VGA arbitration. Tiago recently updated his patchset for that, but I haven’t seen it formally submitted to the linux-pci mailing list yet…


Permalink 08:23:56 pm, by jbarnes Email , 802 words, 56274 views   English (US)
Categories: Announcements [A]

pageflipping, blocking, etc.

Lots of activity lately: Eric just landed a major cleanup to the 2D driver, there’s been lots of bug activity, and I’ve been hacking some more on the page flipping & DRI2 swap buffers support.


We still have way too many bugs open (but isn’t that always the case when the bug count is > 0?), but I spent a lot of time the last couple of weeks closing stuff out, fixing issues and generally troubleshooting configuration issues people have been having with the bleeding edge KMS, UXA and DRI2 code.

One particularly annoying issue was reported by Mateusz Kaduk. While we were debugging it recently, we found that for some reason IER (the interrupt enable reg of the GPU) was getting cleared sometime after the kernel driver was loaded (and had enabled it successfully!). During that time Dariush discovered that running vbetool to save the graphics state seemed to trigger the bug. So the VBIOS (which is ultimately what vbetool ends up running) disables interrupts behind our back, ouch! Take this as yet more evidence that the VBIOS really shouldn’t be run after you’ve booted and loaded a proper driver. Mateusz and I also worked out a workaround for the problem, which I posted here; not sure if we’ll actually ship that yet though, since the distro configs that called vbetool at boot time seem to have been fixed.


tear free shampoo

On the page flipping and swap buffers front, I’ve been having heavy discussions with Jakob Bornecrantz and Kristian Høgsberg lately about how things ought to work. I’m actually using one set of my code on the machine I’m typing on now, and it seems solid, but it has a few shortcomings we’d like to address. Overall there were a couple of issues we felt were important:

  • no blocking - that is, a call to glXSwapBuffers shouldn’t block until the swap completes. Either the swap should occur immediately (as in the case of a less than full screen swap which is just a blit) or it should be queued and the process should be allowed to continue rendering. My last patch set was only partially asynchronous; it would return once the front buffer base address had been updated but before it had taken effect, but this had the side effect of flushing any oustanding rendering, which could be quite expensive.
  • no double rendering - with page flipping, a glXSwapBuffers call switches the back & front buffers. So the caller (if it continues to render) will perform any new rendering in the old front buffer. This can’t be allowed to actually hit the old front buffer unless it’s not currently being displayed. My last patchset waited on flips, but only on the same object, so in certain cases could have allowed rendering after two quick flips to hit the still displayed front buffer.

Beyond that there are the implementation details of how the new DRI2 protocol looks and what the exact sequence looks like on the display server and client side. Kristian is re-working things to require more of the display server (which should help Wayland), so hopefully we’ll see this work committed soon. It’s about time we had a way to enable tear-free compositing window managers.

Update: forgot to mention which bits I’m using:

  • dri2-swapbuffers branches of dri2proto, mesa, xserver and xf86-video-intel
  • kms-pageflip from the drm tree
  • i915-dri2-swapbuffers-15.patch from the “[RFC] DRI2 swapbuffers (yes yet again)” thread on

other features

And since that wasn’t keeping me busy enough, I’ve been hacking on some other features lately, namely GPU reset and framebuffer compression for KMS. The first feature is tied in with some of the error handling improvements we’ve wanted for a long time. Recent GPU hangs (which are just plain hard to figure out) have motivated us to create some tools for dumping GPU command buffers, and to improve our handling of errors in the kernel. So I’ve got some code to capture error state when the GPU detects a failure, and also some code to reset the GPU which we can use if we encounter a hang or other fatal error. They both need a little more work though; we want to capture an error record right when we receive an error interrupt, so I need to create an error structure and export it through debugfs. Once that works reliably, I should be able to hook up the GPU reset code. That should make GPU hangs non-fatal; and if we’re lucky won’t even be noticeable to the end user. Framebuffer compression also needs a little more work; right now it just supports 965 and before; I need to add support for the G4x series and do some more testing to make sure it’s working as expected. Ah the fun never ends.


Permalink 06:44:51 pm, by jbarnes Email , 114 words, 25750 views   English (US)
Categories: Announcements [A]

with apologies to Shakespeare

Alas, poor SGI! I knew it, intarweb: a company of infinite jest, of most excellent fancy: it hath borne me on its back a thousand times; and now, how abhorred in my imagination it is! my gorge rims at it. Here mounted were those chips that I have programmed I know not how oft. Where be your gibes now? your gambols? your songs? your flashes of genius, that were wont to set the industry on a roar? Not one now, to mock your own grinning? quite chap-fallen? Now get you to my lady’s chamber, and tell her, let her paint an inch thick, to this favour she must come; make her laugh at that.


Permalink 07:12:17 pm, by jbarnes Email , 571 words, 13488 views   English (US)
Categories: Announcements [A]

vacation etc

Wow has it already been a month since my last post? Time flies…

So what’s happened in the last month? Well my wife and I vacationed in Australia for a friend’s wedding (apparently he’s even worse than me at keeping his blog fresh). And I spent a good amount of time working on my new office; the floor is in now and the baseboard trim is cut. Just need to stain it, cut a few cope joints, and nail it up then I can move in (pictures & celebration will ensue). Oh and work; lots of KMS and other bug fixing.

PCI pile

So for 2.6.30 there’s a pretty significant set of PCI changes queued up. In no particular order, SR-IOV (basically PCI device virtualization) support, multiple MSI support, and some big hotplug related changes, which make the PCI core much more hot plug aware.

I was hoping the SR-IOV stuff would make it into 2.6.29 but things didn’t come together in time (there were some issues with the patches and there were no client drivers ready), so it got put off until this merge window. Yu has been very responsive though, so I expect the merge will go fairly smoothly and make a lot of the v12n folks happy.

Matthew made some significant changes to the way the PCI layer handles message signalled interrupts (MSIs), allowing multiple interrupts to be assigned to a given device, which can really help with performance in some cases. There are some AHCI patches to take advantage of the feature out there already apparently, and I hope others (FC adapters, NICs) will shortly follow.

Finally, Alex Chiang, through some heroic efforts (which have left him nearly lifeless this week, or so I hear) turned the PCI core into something resembling a hot plug aware subsystem. His work includes a bunch of restructuring of core code (making it both more readable and more robust) and a few new interfaces for dealing with hotplug and bus rescanning. It’s pretty exciting stuff; hope nothing blows up when I send it off to Linus!

Drinking island, part 2

Kernel mode setting is in 2.6.29! I celebrated this once already when it went into Linus’s tree, but now it’s time to celebrate again. Some distros are already using KMS on Intel and other chips, so there’s been a stream of bug reports as the code gets more use, and people like Arjan are already starting to optimize things a bit, to make boot up and mode setting faster (I have some ideas on this front too).

I’ve also been working on stabilizing things for the 2.7 release of xf86-video-intel. We have way too many bugs open in my opinion, but there’s only so much time in the day, and feature work is usually more fun. But we’ve been making some progress anyway; looks like I’ve been resolving 5-10 bugs per week for a while now. Unfortunately with our current bug report rate that only barely keeps my head above water, bug wise (ah for the days of <20 bugs; now I have over 50!).

Once the 2.7 release is out, I’ll finish the page flipping work. The 2D portion should be small enough and backward compatible, so I hope people will be able to try it out with a 2.7.1 release (along with more bleeding edge Mesa, X server and kernel bits). After that, hopefully I’ll have time for some 8xx stabilization and KMS feature work.


Permalink 12:47:02 pm, by jbarnes Email , 943 words, 15917 views   English (US)
Categories: Announcements [A]

distro change & pain^Wpageflipping


So I finally moved away from Fedora as my main desktop distro. Though I still have some Fedora machines, including my home server, I finally gave up on it as a desktop; mainly because I use KDE, which seems to get even less attention on Fedora than it used to. Audio rarely worked well (always had to do stuff by hand like start Pulseaudio or fix perms to get everything going), and updates nearly *always* broke something. One of the reasons I moved from Debian to Fedora in the first place was to get fresher code, and newer packages. But that’s a double edged sword; the Fedora folks do so much of the upstream development in the first place that at times it feels more like a testing ground than a real desktop distro. And note I’m not talking about rawhide, this was all F9/F10. On top of that, I prefer KDE (for several reasons, see below), which is at best a second class citizen in the Fedora world. I’m sure if I used GNOME things would tend to work much better, since it’s likely that most of the Fedora developers use it and therefore find/fix problems more quickly there. But I don’t, and I got tired of things breaking, so now I’m using Kubuntu.

So why KDE? I tried GNOME out for awhile while during the KDE4 debacle, for a few reasons:

  • bugs - lots of bugs surfaced in KDE4, app crashes, poor integration with KDE3 apps, lots of Konqueror regressions (many sites that used to work no longer did)
  • UI weirdness - I really missed my desktop, and at least early in KDE4 I couldn’t even customize the panel like I wanted
  • missing app features - konsole was funky (and still is a bit; I really miss being able to set the default size for new windows; now if I change any of them all the new ones inherit that size), kmail was missing from Fedora
  • various other annoyances

but I couldn’t stay with it. KDE just has too many killer features I’ve come to rely on:

  • klipper - being able to bind a clipboard regex to an action is great; I just highlight a series of 4-7 digits and klipper will ask me which bug reporting system I’d like to open the bug in
  • url shortcuts - alt-f2, wp:foo, can’t live without it. alt-f2, gg:bar, can’t live without it.
  • the apps - why use GNOME if I’m going to use KMail, Amarok, Konversation, Okular, etc.? And I’m definitely *not* switching to Evolution; I already need to use Outlook for work and I don’t want to use anything else that reminds me of it.
  • konqueror - it’s so fast… startup is instant and it works (well used to) with most every site I need to use. I just wish it would move to using a better supported rendering engine like Gecko or Webkit though (well really I just wish it worked with more sites; it seems to have regressed a lot recently and using a more common rendering engine seems like a way to avoid that).

Not to mention a vague feeling that KDE is just better designed & integrated than GNOME (admittedly this is a vestigial feeling based on some early work trying to get both running on IRIX, though there are more recent examples of this, like the infamous “yes/no” swap a few years back). The philosophy is a bit different too; GNOME seems to hide a lot of reconfigurability from the user, making them use a registry editor to change even simple things (again this is probably a dated feeling, but there are recent examples, take a look at the desktop effects config window on KDE and GNOME, the former allows much more control).

So anyway, I’m on Kubuntu now and it seems fine so far (though I do miss the simplicity of “yum list foo*", apt-cache search isn’t quite the same). It’s unfortunate though (for myself and other KDE users) that most of the distros have chosen to focus their development & integration efforts on GNOME, since it usually means that desktop infrastructure happens second or not at all on the KDE side (e.g. where’s knetworkmanager for KDE4? what about full bluetooth integration?).


When I’m not wasting time switching distros or working on bugs, I’ve been working on adding page flipping support to DRI2. It’s slowly coming together; I have a hacked up version of compiz that unconditionally does a swapbuffers without tearing now, which is pretty great. The concept is pretty simple too: I added a new DRI2 protocol request (DRI2 uses a protocol between Mesa clients and your display server, e.g. X or Wayland, to perform updates to your display buffer) to allow DRI2 to ask your display server to swap your GL front & back buffers. This request eventually makes its way down to your display driver (in this case xf86-video-intel), where I added code to detect whether the swap was for a full screen buffer. If it is, we queue a flip of the whole display buffer in the kernel (which in turn queues it directly to the hardware). The flip is of course synchronized to the vertical blank period, so no tearing occurs, yay! I’m still working through a few bugs in the kernel and X code, but people are starting to use it successfully already, which is encouraging. I’m targetting this feature at our Q1 driver release; so if things go well we’ll have a way to avoid tearing on that release; fixing one of our most frequently reported bugs.


Permalink 07:38:49 pm, by jbarnes Email , 405 words, 33425 views   English (US)
Categories: Announcements [A]

dri2, performance, and tiling

We recently started supporting DRI2 in xf86-video-intel and the Mesa drivers, but since then people have started to report performance problems, especially on pre-965 chips (and even crashes on older chips).

I recently looked into those problems, with a couple of theories in mind. Some of the problems reported were so bad, I thought for sure there must be another vblank related bug hiding somewhere, causing apps to timeout and hang for a few seconds. Another theory was that our lack of tiled rendering on pre-965 was at least partly responsible. Turns out that a real win, especially on low end platforms (going from ~5fps to ~30fps on some platforms & apps).

On pre-965 chips though, in order to render to tiled surfaces, so-called fence registers must be set up surface’s properties (stride, size, tiling mode and address). Until recently we didn’t have a way of making fence registers available in the kernel, but with that code (added to support GTT based mapping in userspace), it was a small effort to get tiled rendering going on pre-965. However, only X tiling is supported at the moment. Mesa uses standard blits to copy data around in some cases, and on pre-965 only X tiled objects can be blitted with the 2D engine. Once we change that we can see how much of a win Y tiling will be on pre-965 (almost surely not as much as going from no tiling to X tiling, but it could be worth a few fps).

But that’s not all. With GEM, tiling parameters need to be known so that software based tiled access can work. Unfortunately on some machines the necessary configuration information (which is stored in the MCH memory config registers) isn’t available, since the BIOS may disable the registers or not allocate I/O space for them. My Eee is one such machine, so I was able to code and test a patch to make the MCH data available where it wasn’t otherwise (additional testing appreciated, see the archives for the patch).

On the KMS front, things are coming together. X comes up *much* faster with KMS enabled, and VT switch is nearly instantaneous. All this is great, but there are still some bugs related to framebuffer resize and rotate, and suspend/resume is a little off when mode setting is enabled. Hopefully we can fix most of these before 2.6.29 proper comes out.


Permalink 05:03:57 pm, by jbarnes Email , 43 words, 8808 views   English (US)
Categories: Announcements [A]

I hate spam

I’ve been really bad at dealing with spam on this blog, but I just went through the posts from the last few months and cleaned things up. So if you’ve made comments, you might actually see them now and maybe even see replies…

Permalink 03:45:13 pm, by jbarnes Email , 270 words, 13814 views   English (US)
Categories: Announcements [A]

back from drinking island

It’s been an exciting few weeks since my last post (well ok 6 weeks):

  • DRM KMS merged (woo-hoo!)
  • Wayland running on top of DRM KMS - had fun with Kristian on this one while we were both visiting Hillsboro for Intel meetings
  • lots and lots of bug activity

The downside of the KMS merge is a boatload of new kernel bugs :p but that’s to be expected. We still have quite a few 2D bugs open and those will start to migrate over to the kernel side as more and more people use the code. I’ve got some cleanups to the libdrm doxygen markup as well, but nothing I’m ready to push out (it seems there’s always a more important bug or feature to work on so docs keep getting delayed, so dear lazyweb please write it for me etc etc).

On the home front things have been fun too; my new office (a shed in the back yard I’ve been remodeling) is nearly ready to move in to, just a few more weekends worth of work to go. It’s been a fun project, but I’m really ready for it to be done now, since I need the space and freedom from distraction it should bring. The holidays were great as well. Our little family visited my parents for the week of Christmas and had a lot of fun with the clan (grandparents, great grandparents, aunts, uncles, cousins from all over came to visit). Then for new year’s my sister finally got to visit us up here in Arcata.

Well anyway, back to herding PCI patches and fixing up the KMS bits.

Virtuous blogs

 << Current>>
Jan Feb Mar Apr
May Jun Jul Aug
Sep Oct Nov Dec



XML Feeds

What is RSS?

Who's Online?

  • Guest Users: 24

powered by b2evolution free blog software