Josh Saddler

My AMD desktop workstation is dependable. It's always worked like a champ, with nary an issue. Until now. Now, I'm getting issues in spades.

Let me direct your attention to bug 221145, which contains the details of my woes. It started out as a simple (apparent) kernel issue, in which the newer libata subsystem can't be used with my IDE optical drive. I'd been using the old IDE subsystem. libata is supposed to work for SATA and PATA devices alike, so it should work with the IDE controller on my nVidia MCP55 chipset, right?

Wrong, apparently. Ah, but this was only the tip of the iceberg. Turns out that it's not just my kernel (or whatever it is), but my applications themselves aren't working with the drive. Especially gstreamer-based audio apps, and Gnome audio apps. Totem, Decibel, gnome-cd-player, and a few other gstreamer-based apps I briefly tried. Nope, none of them can play audio CDs. Or DVDs. The really weird thing is that they can see the media in the drive. Decibel will recognize the disc ID, get the info from CDDB, load up the tracklist, but then refuse to play the individual tracks. It doesn't really believe they exist. gnome-cd-player is hardcoded to look for /dev/hda apparently, and can't be changed to look for the correct drive.

It gets better. I switch to the 2.6.25 kernel, and now some CDs have a few playable tracks. But I can't play anything past track 4, or track 9, if I'm lucky.

The woes continue: I bought an Asus SATA DVDRW drive off Newegg, which I installed this morning. It seems that it'll use the same sata_nv drivers that my SATA hard drives use, so no kernel changes needed. Reboot the machine, fire up Decibel, and . . . you guessed it. Track info can be fetched, but nothing will play. So I tried booting with "libata.dma=1" appended to my kernel line, as suggested in the bug, but nothing changes.

This is really weird. A native SATA device that can't work with libata. Not an IDE device masquerading as a SATA drive, but the real deal. At least my SATA hard drives still work. Did I not get some memo on nVidia MCP55 chipsets not liking SATA drives? Or that the kernel code for 'em may not work? Or something.

I'm at my wit's end. If you've got any ideas that haven't been covered on the bug, I'm all ears.

* * *

In other rocks and hard places, I did have Xubuntu on my old Toshiba laptop for a coupla weeks or so. Installation went smoothly, but man . . . Synaptic is slow. Same for the Gnome apt frontend. Remember, this thing ain't for me, it's for my wife, so going to the commandline for packages is forbidden. Anyway, I spent two rather disappointing weeks trying to slim it down into something with better performance. I'd wanted to go for a lightweight WM-only environment, instead of the default Xfce. But Xubuntu is just too bloated; it's far too much work to trim down everything. As "light" as it is, compared to vanilla Ubuntu, it's still not a good place to start building a small system.

So I ended up installing SliTaz, as a new "cooking" edition was just released. Man, SliTaz is nice. There's no support for wireless, unfortunately, but that's about my only quibble. Oh, and there might not be essential Toshiba-specific packages available; I couldn't get working internet, so it's hard to tell. But still, I mentioned a few months ago that SliTaz was the most impressive of all the distros I'd tried, and that's still the case.

I may give it another shot, but in the mean time I've been downloading more ISOs, getting ready for the next batch of testing and reviews.

Coming soon: Damn Small Linux, Linpus Linux Lite (seems to be optimized for mini-laptops with specs not much better than mine), Shift Linux, OpenGEU (E17-based, which apparently performs better than the last time I tried it a few years ago), and another stab at NimbleX and Zenwalk.

Assuming, that is, that I can ever get my stupid optical drives to work. CURSES.