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. 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.
Hey chap… I’m experiencing exactly the same problems with my nvidia chipset and SATA Samsung DVD burner…
Let’s hope someone gets that thing to work. I wonder, have you tried using the drive via another SATA Controller? IIRC, my board has nvidia as well as a JMicron Controller on board – which should be applicable to most Nvidia boards (?), so if it’s really a kernel issue (like i suspected as well), we might have a chance by switching controllers. Let me know whether or not you tried that and whether the JMicron PATA driver in kernel works and is as fast as the nvidia driver used to be
I’ll keep my fingers crossed!
@Martin:
My chipset predates yours by a bit — mine is for an AMD system, and as far as I know, that JMicron PATA/SATA controller is only manufactured for Intel-based systems. I only have nVidia SATA and IDE controllers, no secondary JMicron.
My motherboard dates back to the glory days of 2006, when AMD processors combined with nVidia chipsets to make the best damn platforms, period. It predates the Core/Core2 introduction by a few months, and those brought in the weird JMicron controllers.
So unless I want to spend more money by buying a PCIe SATA card with a different chipset, and plugging my drives into that, I’m outta luck until the kernel code gets fixed. And the application code. Bother.
I re-checked my board after your post and you’re correct. I don’t have a JMicron either, I guess I had that on board the ASrock board that I used before I had to send it back (mainboard was crap and after 2 weeks, it was garbage) so that now I have the K9N Neo-F by MSI, which, indeed, only has 4 SATA by Nvidia. Damn.
So let’s hope the Bug Report gets somewhere.. I also keep thinking – the breakage must’ve happened between 2.24-gentoo-r5 (or 4) and -r8, right? As I only use my drive for ripping my Audio CDs every once in a while (e.g. have new CDs => need to put on HD) I am unsure when exactly things broke.
Also, I can’t put my finger on the “bad guy”, since you had the problems with an IDE drive, whereas I had the same issues with an SATA drive, it doesn’t seem to be the standard nvidia SATA driver – and I don’t use the PATA driver, naturally… I’m confused atm..