LinuxQuestions.org
Support LQ: Use code LQ3 and save $3 on Domain Registration
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Hardware
User Name
Password
Linux - Hardware This forum is for Hardware issues.
Having trouble installing a piece of hardware? Want to know if that peripheral is compatible with Linux?

Notices

Reply
 
Search this Thread
Old 08-22-2006, 07:33 AM   #1
tvynr
Member
 
Registered: Apr 2004
Distribution: Debian
Posts: 143

Rep: Reputation: 15
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!
 
Old 08-22-2006, 08:09 AM   #2
bigrigdriver
LQ Addict
 
Registered: Jul 2002
Location: East Centra Illinois, USA
Distribution: Debian Squeeze
Posts: 5,747

Rep: Reputation: 301Reputation: 301Reputation: 301Reputation: 301
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).
 
Old 08-22-2006, 11:28 AM   #3
tvynr
Member
 
Registered: Apr 2004
Distribution: Debian
Posts: 143

Original Poster
Rep: Reputation: 15
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.
 
Old 10-28-2006, 02:10 AM   #4
MykilX
Member
 
Registered: Apr 2003
Location: East Coast USA
Distribution: Slackware
Posts: 59

Rep: Reputation: 16
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?
 
Old 10-28-2006, 02:21 AM   #5
tvynr
Member
 
Registered: Apr 2004
Distribution: Debian
Posts: 143

Original Poster
Rep: Reputation: 15
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:
Code:
Drive       2.6.14.6     2.6.17.9
U           /dev/sdc     /dev/sde
V           /dev/sdd     /dev/sdf
W           /dev/sda     /dev/sdc
X           /dev/sdb     /dev/sdd
Y           /dev/sde     /dev/sda
Z           /dev/sdf     /dev/sdb
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:
Code:
title           Debian GNU/Linux, kernel 2.6.17-2-amd64 Default
root            (hd0,0)
kernel          /boot/vmlinuz root=LABEL=root ro console=tty0
initrd          /boot/initrd.img
savedefault
boot
and my fstab looks like this:
Code:
# Hard drive mounts
LABEL=root      /               ext3    defaults,errors=remount-ro,acl 0 1
LABEL=swap      none            swap    sw              0       0
UUID=a253bb41-37c0-4d07-a1eb-d5b473d90ddc /data ext3 defaults,errors=remount-ro,acl 0 1
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!
 
Old 10-28-2006, 01:45 PM   #6
MykilX
Member
 
Registered: Apr 2003
Location: East Coast USA
Distribution: Slackware
Posts: 59

Rep: Reputation: 16
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
 
Old 10-28-2006, 01:57 PM   #7
MykilX
Member
 
Registered: Apr 2003
Location: East Coast USA
Distribution: Slackware
Posts: 59

Rep: Reputation: 16
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.
 
Old 10-29-2006, 01:13 AM   #8
tvynr
Member
 
Registered: Apr 2004
Distribution: Debian
Posts: 143

Original Poster
Rep: Reputation: 15
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!
 
Old 10-30-2006, 08:16 AM   #9
soggycornflake
Member
 
Registered: May 2006
Location: England
Distribution: Slackware 10.2, Slamd64
Posts: 249

Rep: Reputation: 31
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.

Quote:
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.
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.
 
Old 11-01-2006, 07:29 PM   #10
MykilX
Member
 
Registered: Apr 2003
Location: East Coast USA
Distribution: Slackware
Posts: 59

Rep: Reputation: 16
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.
 
  


Reply

Tags
kernel, libata, nvidia, sata


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
IBM NetVista no boot order in BIOS true_atlantis Linux - Hardware 5 04-04-2008 12:01 PM
Have to change boot order in BIOS to boot ubuntu/winxp Minn3h Linux - Software 7 04-01-2006 05:17 PM
cosole constantly flooded with nv_sata messages Devrethman Debian 1 08-29-2005 07:01 AM
USB boot order BIOS settings NovaBurst Linux - Hardware 1 03-27-2005 11:23 PM
need Bios driver to exec custom on board bios code wmain Linux - Software 0 09-03-2004 08:32 AM


All times are GMT -5. The time now is 08:34 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration