My Asus A8V-MX VIA VT8251 bios offers these sata modes: DISABLED, SATA, AHCI, & RAID. There is also an option to ENABLE/DISABLE serial ATA BootRom but this option will only appear if the sata controller is set to RAID or AHCI.

Which one of these is best for a guy who wants to boot a sata drive & keep his pata (dev/hda) drive attached to the system as a non-bootable backup-storage drive ? My system is 100% ext3 Linux & will remain so after I migrate it to a Sata drive. I plan on doing the migration as soon as kernel-2.6.18 becomes available with sata support for my VT8251 controller. Thank you for reading this & I look forward to reading your replies.

You don't need to enable RAID if you're not building an array, and
might not for Linux anyway (haven't built a RAID array in Linux yet).

You should enable AHCI and probably SATA, also. If you can chose only
one of those, chose AHCI. Have you checked the manual for the board?

Have a read of these two pages:
http://linux-ata.org/driver-status.html#via
http://linux-ata.org/driver-status.html#ahci

My read of Jeff's pages says to use the AHCI kernel driver, rather than
the SATA driver. That one is already in my kernel, 2.6.17.8:
If you run "make xconfig" it's under:
Device drivers > SCSI device support > Serial ATA (SATA) support

Wish I could test a kernel for you, but I don't have that board.
I did look in 2.6.17.8 in ./drivers/scsi/ahci.c and do not see a
VIA chipset at all in the PCI IDs.

Have a look at this HCL product post. One of those guys might be
able to give you more up-to-date information.

Well. I quess I'll choose AHCI for my sata mode since it supports NCQ (Native Coommand Quering) on my VT8251 controller & especially because you say I don't have to construct a Disk Array. That array stuff is a little beyond any computing skills I have.

Here are the Kernel-2.6.18 configuration options I plan to use:

SCSI DRIVE SUPPORT:
config_scsi <y>
config_scsi_proc_fs <y>

SCSI SUPPORT TYPE (Disk Tape CD-ROM):
config_blk_dev_sd <y>

SCSI LOW-LEVEL DRIVERS:
config_scsi_sata <y>
config_scsi_sata_ahci <y>
config_scsi_sata_via <y>

These should compile Kernel-2.6.18 with the following built-in modules:

sd_mod.ko ....scsi upper-level device
scsi_mod.ko ....scsi mid-level communicator
ahci.ko ....scsi low-level ahci mode
sata_via.ko ....scsi low-level sata mode (optional)

I currently have libata.ko configured as a loadable module & I am aware that both achi.ko & sata_via.ko are dependant on it.

Should the libata.ko module be built into kernel-2.6.18 ? If so, what is the corresponding kernel configuration option ? I don't know what .config file entry is responsible for producing libata.ko as a loadable module in my current kernel-2.6.17.7.

Thank you for reading & responding to my post. Please let me know if you see anything wrong with planned kernel configuration options. I am also looking forward to finding out how a kernel gets the libata.ko configured.

NB: I'm not the expert, so keep your old kernel in place.

Jeff Garzik is the maintainer for libata, which is the driver (module) that handles all of this stuff.
I don't think you have to build libata.ko as a loadable module anymore. It's not in my system anywhere.

Did you read those two links I gave you about AHCI and VIA in regards to SATA? I quote:
That's why I said, "My read of Jeff's pages says to use the AHCI kernel driver, rather than the SATA driver."

So my advice is to compile the sata_ahci driver, and not sata_via.

I don't use CONFIG_SCSI_PROC_FS, and here's why:
Perhaps if you enable that option, you can enlighten me later.

Let's pray your kernel boots, the SATA drive works well, and you get fast transfer rates because of that AHCI controller. It looks good to me.

Just remember to keep your old kernel so you can boot if the new one fails; and build your / (root) filesystem in as well (Y != M).

I hesitated to post this, but I will. There is a Kernel Rebuild Guide that's brief, but contains what's necessary for rebuilding a kernel in Slackware, on my website. The options to configure, build, and install the kernel are the same for all distros; if you build from source.

I would also advise you to read the README file that Linus has written and is in the top level directory of the Linux kernel source.

Thanks again for your help & voice of support. I do plan to keep my ext2/3 (rootfs-driver) as a kernel-2.6.18 built-in module & my compile procedure will be:

download source --Place in /src/linux directory (don't use the /usr/src area)
tar -xjvf --unpacks to kernel-2.6.18 source directory
cd source directory
make mrproper --cleans up stale files (including .config)
cp .config --existing .config from a previous kernel-2.6.17.7 build
make silentoldconfig --if using a previous .config (only presents new options)
make
make modules_install

Also, I no-longer plan to build the sata_via.ko into the kernel. It is said to be for "older" via chips I was thinking it might support the VT8251 controller but w/o the NCQ feature.

Now I guess I will just keep an eye open for the release of kernel-2.6.18. I am aware that there is a pre-release kernel that supports the VT8251 controller & the new Ubunto-6.06.1 distribution is said to support this chip but I can afford to wait for an official stable kernel release. The experts at the Linux Kernel.org already fixed the digital sound problem on my A8V-MX motherboard via release of kernel-2.6.17 so I have no doubt they will get a sata drive to work

Originally posted by ssenuta
That step is not needed, because with new source there are no stale files,
and there is no .config file. The purpose of the "make (x)config" command
is to "make a .config file".

I'm a bit confused why you don't use 2.6.17.11? It's stable and the AHCI
module (sata_ahci) is already in the kernel.

To answer your question: it usually doesn't make a difference which mode you pick. The kernel driver will pick one for you anyway.

RAID on the VT8251 is pointless because it's implemented in the Windows-only driver which is a software implementation. You'll want to use Linux's own software RAID implementation instead.


Unfortunately, VIA failed to properly follow the AHCI specification with regards to NCQ, so NCQ is disabled for the VT8251 on every OS that implements AHCI (as of now, at least Linux and OpenBSD). It is not known whether or not VIA opted not implement NCQ or that they simply screwed up. In either case, without their assistance, we probably will never see it.