nv_sata driver order doesn't agree with BIOS
 

I'm having what I think to be an issue with the nv_sata driver in the Linux kernel and I'm not sure what to do about it. After half an hour of fruitless Googling without finding anything that really looked like my problem, I thought I'd post here in the hopes of finding some direction.

I'm using Debian Etch AMD64 with a Linux 2.6.14.6 custom kernel. The motherboard is an ASUS A8N-SLI Deluxe. The first SATA controller is an nVidia chipset.

The odd thing about this is that the first SATA drive (at least, that which the BIOS thinks is first) is /dev/sdc. GRUB agrees with the BIOS, calling it hd0. The second drive (which GRUB calls hd1) is /dev/sdd; the third drive (hd2) is /dev/sda; the fourth drive (hd3) is /dev/sdb. As a note, the markings on my motherboard which mark the ports things like SATA1, SATA2, etc. agree with the BIOS (of course).

If I remove, say, the fourth drive (fourth; hd3; /dev/sdb), the ordering changes completely. Now, first corresponds to hd0 and /dev/sdb; second corresponds to hd1 and /dev/sdc; and third corresponds to hd2 and /dev/sda.

So it would seem that the kernel driver is scanning the third and fourth ports first, followed by the first and second ports. I am unsure if this is a configuration issue on my end or a kernel driver bug. If it is a bug, I do not know how to determine whether or not it has already been reported or how to report it if it hasn't. Does anyone have any recommendations?

Thanks!

Do you have more than one SATA controller on the board? If yes, you may have the cables plugged into the wrong controller (i.e., crossed cables). I suggest that possibility because of the name order of the drives you give. The drives you think of as first and second are connected as third and fourth (sdc and sdd). The drives you think of as third and fourth are connected as first and second (sda and sdb).

Hi, and thanks for responding. :)

Actually, I do have another SATA controller on board (Silicon Image), but I'm quite clear as to the difference between them; there are six SATA drives connected to this machine and five are participating in a RAID5. Also, when I use the term "first" and "second" in my original post, I'm actually referring to the content of my BIOS post screen, which looks something like this:

First SATA Drive: WD7400blahblah
Second SATA Drive: WD32000blahblah
Third SATA Drive: WD32000blahblah
Fourth SATA Drive: WD32000blahblah

So it's straight from the BIOS that I get this designation (as well as from GRUB and the motherboard manual). Nonetheless, the 74Gb Raptor you see about in the "First SATA Drive" position is /dev/sdc by the time I am booted.

As a note, I later see the SiI SATA controller which has the other two drives on it, each set up in a hokey single-drive hardware RAID (called JBOD?) so that the controller will admit that they're there.

I'm having a similar problem on my MSI K8N Diamond Plus. Raptor hooked to port1 is sda, if i hook a secong drive to port 2, the raptor turns into sdb and the port 2 drive becomes sda. I was hoping there would be an answer in this post :/ This happens with slack 10.2, 11, slamd64, and dapper64.

Have you been able to fix this tvynr?

MykilX:

Indeed no, I have not. As a matter of fact, I only complicated the problem. Naming the drives arbitrarily as U, V, W, X, Y, and Z (where U is the Raptor, V is the second drive according to the BIOS, etc.), my drive layout varies dependeing upon the kernel I use:
This apparently happens because 2.6.17.9 not only looks at the drives on my nVidia controller in the "wrong" order, it looks at the drives on my Silicon Image controller before the ones on the nVidia controller. So things get even more scrambled.

While I've not found a way around this, I have found a way to circumvent the problem. The real issue at hand for me was getting GRUB and fstab to properly recognize which drive was root, which drives were part of my RAID device, and so on. Rather than mounting my drives by device name, I have taken to mounting them using volume labels or UUIDs. For instance, my GRUB config looks like this:
and my fstab looks like this:
As it turns out, you can set the device labels on both ext3 partitions and swap partitions, so I named the ext3 on my Raptor "root" (using e2label) and the swap is named "swap" (using mkswap -L). The RAID is mounted by volume UUID because mount sees the label on both md0 and some of the RAID devices and gets confused.

Lemme know if I can be of further assistance. :) Cheers!

:scratch: I have the same problem if i use the si controller. The raptor magically becomes sdb or even sdc sometimes. (This using the si controller as regular drives not raid.)

I wonder if lilo supports labels? The other thing is I'm using reiser3. So I'll have to find out if lilo and reiser supports labels.

I do have a little more weirdness to add to this. I finally got my box to boot with the raptor on port 1 and one of my 400GB jobs on port 2. They are recognized properly as sda and sdb. The thing is, neither fdisk or cfdisk will recognize sdb as a valid harddrive. I did however set up a 1 gig swap space and another partition on the drive using some other partitioning tool awhile back. So just as an experiment I tried mounting a few of the sdb devs. I was able to mount sdb2 and it seems it is a 40 GB partition.

I really think this is a kernel issue, and probably more specifically a lib_ata thing. I would rather figure out why this is happening instead of using you great work around, but my kernel knowledge is pretty small. Maybe an email to the lib_ata maintainer would be warranted.

Another thing to add. When I was testing this out the other day, I fired up ubuntu Dapper64 to see if it had the same problem. I checked out the device manager, and the 2 400GB drives were being recognized as being on the nvidia sata controller, while the Raptor was being recognized as being on a genereric "SCSI Host Adapter" Maybe lib_ata is recognizing the raptor as a "real" SCSI drive?


I suppose as long as I can use all my hd space i don't care what the drive is recognized as, but would like to fix this as opposed to applying bandaids.

If I find anything out, I'll post back.

Thanks for looking back at this thread :)

Hmm seems i was wrong about sdb2, it is a vfat partition that is on the raptor! wtf why is it sdb2?? and not on sda. :(

Not the faintest clue about that, honestly. But like I said, I never really fixed the problem; I just added a layer of indirection by using volume labels or UUIDs. Now the driver can flip out all it wants and as long as my drives actually exist, I don't care. :)

I would expect ReiserFS to support either labels or UUIDs, if not both. I don't think you really need LILO to support label booting at all... the string "root=LABEL=root" in my config gets blindly passed to init, AFAIK, so GRUB never actually analyzes it or does anything with it. I would expect LILO to do the same.

Cheers, and good luck!

You might also use udev to persistenly assign the device nodes as you want them. Of course, you can rename them too. Thus, instead of /dev/sda1, /dev/sdb3, etc, you can use /dev/home, /dev/var, and so on.

This is indeed the case. LILO knows nothing about dirves, the sectors to load are hard-coded into second stage loader (that's what running /sbin/lilo does). Grub also is only interested in it's own device naming scheme. Command line options are passed blindly on, as you say. Neither of them care one jot what names/devices the kernel uses.

I thought about using udev, but the issue is lower level than that. The drive misnaming happens before udev is known about. It has to be something with lib_ata or how my drive is telling lib_ata to handle it. I've had to work so I haven't been able to futz with this anymore. I hope to work on it more tomorrow.