Bug 7172

Summary:	NVRaid SATA does not detect discs in the proper order.
Product:	IO/Storage	Reporter:	Arturo Mann (arturo.mann)
Component:	Serial ATA	Assignee:	Tejun Heo (htejun)
Status:	REJECTED WILL_NOT_FIX
Severity:	normal	CC:	htejun, kernel
Priority:	P2
Hardware:	i386
OS:	Linux
Kernel Version:	Kernel 2.6.17 (using gentoo patchset)	Subsystem:
Regression:	---	Bisected commit-id:
Attachments:	Dmesg of affected system

Description Arturo Mann 2006-09-20 10:01:28 UTC

Most recent kernel where this bug did not occur: UNKNOWN
Distribution: Gentoo 2006.1 Amd64
Hardware Environment: System based on Asus A8N-SLI Deluxe Mainboard with AMD64
X2 4600+ cpu
Software Environment: Linux!
Problem Description:
Using kernel:
Linux Gemini 2.6.17-gentoo-r4 #13 SMP PREEMPT Mon Aug 28 16:36:01 CDT 2006
x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 4600+ AuthenticAMD GNU/Linux

And an nVidia based ASUS A8n SLI-Deluxe,

The driver in the kernel does *not* detect the sata ports correctly, even after
jogging my wiring around.
The disk which is connected to SATA 0 (And confirmed by the BIOS), is detected
as /dev/sdc. Of course, I am using three sata ports.  But it would be nice to
know what is going on here.
Gentoo has asked that this bug be filed against the mainline kernel. So, here it is.

I am adding a dmesg output.
Steps to reproduce:
Boot the computer, and it will not detect the discs in the appropiate order.

Comment 1 Arturo Mann 2006-09-20 10:01:57 UTC

Created attachment 9056 [details]
Dmesg of affected system

Comment 2 Daniel Drake 2006-09-20 11:17:49 UTC

Original report: http://bugs.gentoo.org/show_bug.cgi?id=145431
Apart from the addition of some PCI ID's (pulled from 2.6.18-rc kernels) there
are no modifications to sata_nv in the 2.6.17 Gentoo kernel releases

Comment 3 Tejun Heo 2006-09-21 07:30:06 UTC

Hello,

If the BIOS order is 1,2,3,4, is the detected order 3,4,1,2?

These chipsets use two PCI devices to implement four SATA ports and it seems
like BIOS and the kernel are using different PCI ordering.  If that's the case,
maybe we can do something about it w/ pci quirks and some tricks in
nv_init_one(), but I'm not sure whether the change would fix or break more.  The
probing order has been like that for all 2.6 kernels and I guess people are used
to it by now (including me).

Is it causing a lot of headache for you?  Doesn't gentoo use LABEL= trick yet?

Comment 4 Arturo Mann 2006-09-21 07:47:58 UTC

Hallo there
If it will break the hell out of everything, I guess it would be inappropiate to
make it a "mainline fix", but the fact is that at this point I had to order my
discs in the 1,2,3 slots to get the order detected as 3,1,2. But my 4th is
attached to an eSata adapter to hook up external discs. If i add anything to
that channel, it completely messes up the ordering AGAIN.
What's the label trick?

Comment 5 Tejun Heo 2006-09-21 08:09:04 UTC

The LABEL= thing works by giving unique string names to each filesystem.  For
ext2/3, you can set it w/ "tune2fs -L blahblah /dev/sda1".  Then, you can use
"LABEL=blahblah" almost whereever you would use "/dev/sda1".  Most FS related
userland tools recognize the format and will handle it properly no matter which
device node the drive ends up with.

For the root partition, the kernel itself doesn't recognize the format but most
if not all initrd images from distributions recognize it, so if your boot
process includes initrd, you can simply say "LABEL=my_root_fs" on the kernel
parameter line.  Many distributions default to such method nowadays.

Comment 6 Arturo Mann 2006-10-03 17:23:31 UTC

So, just to recap, my / is on XFS, named "rootfs", how do i play the labeltrick?

Comment 7 Daniel Drake 2006-10-03 17:34:14 UTC

You need to use an initrd which will process the LABEL argument and use it to
find the root device. I'm not sure if genkernel-generated initrd's do this just
yet, if they don't it would certainly be a valid feature enhancement request for
http://bugs.gentoo.org

Comment 8 Arturo Mann 2006-10-03 17:38:55 UTC

I do not use genkernel. I am using the normal make menuconfig method to generate
everything. I therefore also do not use a RamFS to boot, straight into primary
rootfs for my computer. This may pose a problem, I think ? ^_^

Comment 9 Daniel Drake 2006-10-03 18:09:43 UTC

You can't do it with the standard kernel boot system, as far as I know. Maybe
this will change when klibc is merged, although thats a complete guess.