I have noticed something strange with BIOS configuration/settings as related to SATA drives.

This seems to have an affect on the messages sent by udev which in turn can have an impact on hot-swapping drives in FoxyRoxyLinux.

Most PC mainboard architectures have what is referred to as a NorthBridge and SouthBridge chipset. In general terms the NorthBridge chipset handles all of the super high speed stuff like the CPU interface to the memory and video subsystems. The NorthBridge chip also has an interface to the SouthBridge chipset. The SouthBridge chipset handles the interface between the fast NorthBridge chipset and the slower devices such as hard disks, USB ports and the like. While SATA drives are somewhat faster than older ATA or IDE drives, they are still a slow device from the CPUs point of view, therefore Hard Drives of pretty much any type, are typically interfaced/connected via the SouthBridge chipset.

While we still use the word chipset, this is more of a carry over from when there was more than one physical IC (chip) required to build a NorthBridge or a SouthBridge. Nowadays, in most instances the NorthBridge is one chip and the SouthBridge is another. Using some current numbers or family names, in Intel nomenclature, P31, P33, P45, SandyBridge etc, are typically the NorthBridge chip, whereas devices such as ICH7, ICH9, ICH10 etc and their R for raid variants, are typically the SouthBridge. It is not uncommon for many motherboards to have other devices attached to the SouthBridge chip to provide things like sound, networking, and other features.

My primary FoxyRoxyLinux development machine is based on an Intel Atom which contains the NorthBridge and CPU inside a single chip and uses an Intel NM10 SouthBridge chip. The NM10 has 2 x 3Gb SATA ports, and this particular board also has a Jmicron JMB363 which has an additional 2 x 3Gb SATA ports.

Now for the fun stuff. The mainboard BIOS for machines with SATA support, typically allow you to select either IDE or AHCI mode for the SATA ports. The mode you choose here can have an impact on how the SATA devices are capable of being used by your system. Typically, if you select IDE mode, your system will see the SATA drives as any other drive, and if you select AHCI then it is not uncommon for some BIOS extensions to be added which you will often see during power-on as the extensions will typically look for SATA drives. If you don't have any SATA drives connected, this could result in the machine appearing to hang or get stuck at power-up. If you do have SATA drives connected, it can often take a long time (anywhere from 10 to 90 seconds) to move past this part of the power-up sequence.

So, which do you choose?Sadly, there is no sure-fire selection to be made here, as each mainboard, chipset, and BIOS behaves differently. You may even notice subtle differences between various chips/devices on the same mainboard if your mainboard has multiple devices as does my GA-D525TUD, which has been the catalyst for this thread. On the GA-525TUD, I have noticed that to get hot-swapping of SATA drives working properly, the best setup is to configure the Intel NM10 chipset SATA drives for AHCI mode, whereas the JMB-363 works better if the SATA drives are configured for IDE mode.

In the machine BIOS, these are configured in the [Integrated Peripherals] section.The first option in the menu [SATA AHCI Mode] is for the NM10 SATA devices ... Set to AHCIThe eight option in the menu [OnBoard SATA/IDE Ctrl Mode] is for the JMB-363 SATA devices ... Set to IDE

One way to test and confirm that hot-swap/plugging of SATA drives is working properly, is as follows:

You should now have a good map of what drives are plugged in, what partitions are visible (/proc/partitions) and what devices are mounted (/proc/mounts), with the XFE window showing this from a typical users point of view.

The following assumes that your SATA drive is sdaIn the cat /proc/mounts terminal, type spindown sda

The following should occur....In the XFE window, the drive or mount point should vanish.- Note: sometimes you need to click the refresh button

In the udevadm monitor window, you will see some messages which will decode to show you that the device has changed and been removed from the filesystem. It has not been physically removed yet.

In the cat /proc/partitions terminal, press up-arrow <enter> to repeat the cat /proc/partitions command. The sda and sda1 partitions should still show as being "available"

In the terminal you used to spindown sda press up-arrow (twice), then <enter> to repeat the cat /proc/mounts command, and you should see that there are no partitions associated with the sda device mounted.

Now unplug or remove the physical drive from the system.

After about 5 or 10 seconds, you should see some more messages in the udevadm monitor terminal session, this time indicating that the device has been removed from the system. In the cat /proc/partitions terminal session, repeat the command again and you will see that the sda device has vanished. There won't be any changes in the XFE or cat /proc/mounts[i] screens as the drive was already logically unplugged from them when we issued the [i]spindown command.

Now plug the drive back in again.

After about 5 or 10 seconds, you will see more messages in the udevadm monitor terminal session. These messages will show that the device has been added to the system and you will also be able to see the device name. At this point, you may also notice that XFE is now showing that the device has been mounted in the /media directory, which can be confirmed in the cat /proc/mounts terminal session, and the cat /proc/partitions terminal session will also show the partitions as being known and available.

While the udevadm monitor terminal session is the most critical one, in so far as if you don't get any messages here, then there is something wrong, you can also use the command dmesg | tail to see other system messages associated with removing and adding drives.

I usually use the cat /proc/mounts terminal session as my "live typing" terminal, although you can use whichever you prefer, provided you just leave the udevadm monitor terminal session alone while it is in "monitor" mode.

You can also use this combination of screen tools, to see what is happening when you plug various USB sticks, and other devices in.

If you don't get a message appearing in the udevadm monitor terminal session, then FoxyRoxyLinux won't mount the device, because it hasn't generated a udev message, which is what FoxyRoxyLinux is monitoring to do the auto-mount stuff. If you don't get a udev message, then chances are that the BIOS settings for the device may be wrong. This is something that dmesg may be able to help you work out, or you could just try changing the mode of the device in your BIOS.

I really do suggest that before you start hot-swapping drives in FoxyRoxyLinux, that you take an hour or two even if it takes that long, to confirm that everything is working as you think, want, intend it to. A little bit of time spent up-front can save you hours of pain and grief later.

If you discover any strange things while checking out your mainboard (as I did), please drop a note here as it may help someone else in the future.

This NM10 chipset does not support the use of Port Multipliers on the 2 x SATA ports. At this point in time, I am not sure if this is a limitation of the Linux Drivers, or the chipset.Either way, I do not expect this will ever be addressed or resolved.

If you have a GigaByte GA-D525TUD mainboard, and want to use port multipliers so as to have more than 4 SATA drives, you will need to connect the port multipliers to the JMB363 (SATA-2) ports. While you can theoretically cascade these, I have not tested this. I have tested basic port multiplication with a 5-port multiplier on each of the 2 x JMB363 (SATA-2) ports to have 10 x SATA drives in the one machine, with another hot-swap drive on the primary NM10 SATA port.

A quick note regarding GigaByte mainboards based on the Intel P33 chipset.

The BIOS' in these boards appears to have a glitch, whereby the machine will not boot from a USB FashDrive. While searching for a solution, this problem seems to exist in all GigaByte P33 chipset based boards, and has been known for some time. Therefore, it is unlikely that this issue will ever be resolved.