Successes and failures

Despite taking it apart and lubricating every coarse mechanical track, linkage and pivot, I have been completely unable to cure the intermittent (roughly 50% of the time) tray jam on the LiteOn SATA DVD burner databeast gave me the last time he was up here. There is nothing visibly mechanically wrong, and nothing sticks when cycled by hand; nevertheless, at least half the time, when actually connected to a machine, the drive either fails to open, fails to lock closed, or fails to unlock.

Nevertheless, despite it's mechanical problems, its logic is working fine, and I was able to use it to confirm that the MSI6566E P4 board that lwj2 sent to us has not the slightest hesitation about attempting to boot from a SATA device connected to the SiI3124-based PCI SATA controller I bought when I first started trying to do a ground-up OS refresh on babylon5. This only deepens the mystery about why babylon5's ASUS A7V333 AthlonXP board will talk to that controller, and SATA devices connected to it, perfectly happily once it's booted, but utterly refuses to detect any SATA devices at boot time. I even tried installing a 16MB CF card on a PATA adapter with grub on it to boot from a SATA disk, and that didn't work, either. I can only conclude that, as the A7V333 motherboard (introduced in 2002) predates SATA (introduces in 2003), the BIOS contains no SATA support whatsoever, and for some reason none of the subsequent BIOS updates (the most recent, version 1017, dates from July 2006) has ever added any SATA support.

There's one post on the ASUS support forums about inability to get an A7V333 to boot from an add-in PCI SATA card, but it's never received any replies. Further research online finds occasional other posts of the same problem, none of which ends in a successful resolution. This appears to suggest that SATA on the A7V333 is a problem to which there is no known solution.

I guess that means I'm squarely behind the 8-ball on converting babylon5 to SATA¹, unless I also replace the motherboard. And therefore the CPU, and the RAM, and probably the graphics card...

Well, it has been seven years since I last did it. So I suppose that's not so bad.

[1] "Why not just use PATA?" Because PATA is brain-damaged, and because the board only has two PATA channels, and I like to run mirrored boot disks on all of my *nix boxen, which means two disks and an optical drive, which means some two of those three devices are going to have to share a PATA channel. And that's when PATA starts to REALLY suck, because bus contention is going to cut throughput on that channel by a factor of at least two. That's one of the major reasons why SATA was invented.