Adding Marvell controller messes up /dev/adaxx for controller on motherboard

J

jphartmann

I added a Rocket 640L controller to my system (9.1) to get ports for more SATA disks. If I plug any disks into this controller my existing system setup is messed up somewhat royal because the new Marvell controller gets ahead of the one on the motherboard. I can boot if I unplug the new disks, but that is hardly an acceptable solution.

So, is there a way to create links in /dev to identitites that are related to the disk serial number rather than its position on the controller (and the controller on the PCI bus and the PCI bus on the ...) so that one can arrange for a predictable set of disks (not to mention zfs pools).

From dmesg:

Code: 
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
pcib1: <ACPI PCI-PCI bridge> irq 16 at device 1.0 on pci0
pci1: <ACPI PCI bus> on pcib1
ahci0: <Marvell 88SE9230 AHCI SATA controller> port 0xe050-0xe057,0xe040-0xe043,0xe030-0xe037,0xe020-0xe023,0xe000-0xe01f mem 0xfe410000-0xfe4107ff irq 16 at device 0.0 on pci1
ahci0: AHCI v1.20 with 8 6Gbps ports, Port Multiplier not supported
ahcich0: <AHCI channel> at channel 0 on ahci0
ahcich1: <AHCI channel> at channel 1 on ahci0
ahcich2: <AHCI channel> at channel 2 on ahci0
[...]

Then much later:

Code: 
pcib2: <ACPI PCI-PCI bridge> at device 30.0 on pci0
pci2: <ACPI PCI bus> on pcib2
isab0: <PCI-ISA bridge> at device 31.0 on pci0
isa0: <ISA bus> on isab0
ahci1: <Intel Cougar Point AHCI SATA controller> port 0xf0d0-0xf0d7,0xf0c0-0xf0c3,0xf0b0-0xf0b7,0xf0a0-0xf0a3,0xf060-0xf07f mem 0xfe521000-0xfe5217ff irq 19 at device 31.2 on pci0
ahci1: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported
ahcich8: <AHCI channel> at channel 0 on ahci1
ahcich9: <AHCI channel> at channel 1 on ahci1
ahcich10: <AHCI channel> at channel 2 on ahci1
ahcich11: <AHCI channel> at channel 3 on ahci1

And much much later

Code: 
ada0 at ahcich8 bus 0 scbus8 target 0 lun 0
ada0: <WDC WD30EFRX-68AX9N0 80.00A80> ATA-9 SATA 3.x device
ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes)
ada0: Command Queueing enabled
ada0: 2861588MB (5860533168 512 byte sectors: 16H 63S/T 16383C)
ada0: Previously was known as ad20
ada1 at ahcich9 bus 0 scbus9 target 0 lun 0
ada1: <WDC WD30EFRX-68AX9N0 80.00A80> ATA-9 SATA 3.x device
kbd2 at ukbd0
ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes)
ada1: Command Queueing enabled
ada1: 2861588MB (5860533168 512 byte sectors: 16H 63S/T 16383C)
ada1: Previously was known as ad22
ada2 at ahcich10 bus 0 scbus10 target 0 lun 0
ada2: <V4-CT128V4SSD2 S5FAMM22> ATA-8 SATA 2.x device
ada2: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes)
ada2: Command Queueing enabled
ada2: 122104MB (250069680 512 byte sectors: 16H 63S/T 16383C)
ada2: Previously was known as ad24

That last one is my boot disk.
 
This is exactly why labels are good. If the disk is MBR partitioned, use filesystem labels. If it's GPT, use GPT labels (see gpart(8)) that will appear in /dev/gpt/.

A short-term solution is to switch SATA cables to the drives.
 
Thanks. In this particular case I cannot switch cables because the last two ports are slow, so the boot device has to stay there.
 
In case anyone should wind up here having the same problem, this is what you do to fix up what the default installation of 9.1 did to the disk you gave it to use:

gpart list will show you that the disk has three partitions, index 1 is boot, index 2 is root, and index 3 is swap. You don't need to worry about the boot partition as it is not mounted. For the two other ones (assuming the disk is ada5), you need to:

Code: 
[root@fb91 ~]# gpart modify -i 2 -l 91root /dev/ada5
ada5p2 modified
[root@fb91 ~]# gpart modify -i 3 -l 91swap /dev/ada5
ada5p3 modified
[root@fb91 ~]#

Note that the geometry you modify is the full disk rather than the partition. The partition number is specified as the index (-i). Then modify /etc/fstab to mount the labeled partitions:

Code: 
/dev/gpt/91root /               ufs     rw,noatime      1       1
/dev/gpt/91swap none            swap    sw      0       0

(I have added noatime because the disk is a SSD.)

When the system boots, /dev/gpt will contain files corresponding to your labels. But here is the astonishing part: They go away as you mount the partitions regardless of the way you mount them. In short, you can only see the labels in /dev if you boot a live system (the installation medium you used to install FreeBSD).

Now pull out the cable to one of your new drives and verify that you can boot the system.
 
Warren pointed out off the forum that you can actually see the missing labels by

Code: 
[root@fb91 ~]# gpart show -l
=>       34  250069613  ada6  GPT  (119G)
         34        128     1  91boot  (64k)
        162  241172352     2  91root  (115G)
  241172514    8388608     3  91swap  (4.0G)
  249561122     508525        - free -  (248M)

[root@fb91 ~]#

(We are back on ada6 because I plugged in all disk cables.)

But you wouldn't guess this from reading the man page.

But wait. Now the labels are visible in /dev/gpt:

Code: 
[root@fb91 ~]# ls -l /dev/gpt
total 0
crw-r-----  1 root  operator    0, 112 Feb 23 08:21 91boot
crw-r-----  1 root  operator    0, 115 Feb 23 09:21 91root
crw-r-----  1 root  operator    0, 117 Feb 23 09:21 91swap
[root@fb91 ~]#

Code: 
[root@fb91 ~]# mount
/dev/gpt/91root on / (ufs, NFS exported, local, noatime, journaled soft-updates)
devfs on /dev (devfs, local, multilabel)

The mind boggles.
 
As I understand it, GEOM hides labels on mounted devices except the ones that were used to mount them. My guess is that this is to prevent those alternate labels from being used to mount a device that is already mounted. It's just a guess, though.
 
You must log in or register to reply here.
Back
Top