Red Hat Bugzilla – Bug 474482
Harddisk attached to onboard Marvell SAS controller on Asus P6T Deluxe not detected under Fedora 10
Last modified: 2009-04-15 17:40:09 EDT
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:188.8.131.52) Gecko/2008111217 Fedora/3.0.4-1.fc10 Firefox/3.0.4
I am using an Asus P6T Deluxe mainboard for the new Intel Core i7 platform and the Seagate Cheetah 15k.6 SAS harddrive attached to the onboard Marvell 88SE6440 SAS controller isn't recognized under Fedora 10. Previous attempts to gain information regarding this problem brought no solution.
Steps to Reproduce:
1. Installing Fedora 10 on a SATA-HDD connected to a harddisk drive connected to one of the SATA-ports of the Intel ICH10R southbridge
2. Loading the necessary driver for the onboard SAS controller ("mvsas", moved into the kernel by version 2.6.25)
3.Trying to detect the attached HDD for using it
Harddrive (Seagate Cheetah 15k.6 146 GB Serial Attached SCSI) connected to the onboard Marvell SAS controller of the P6T Deluxe (manufacturer: Asus) is not detected by the OS (Fedora 10, latest updates installed). Neither using the standard F10 kernel modprobing the necessary "mvsas" module, nor compiling my "own" kernel with fixed support for the controller used makes the HDD visible to fdisk, gparted or comparable tools to create partitions for using the Cheetah as boot disk using the self-compiled kernel. Even the possibility to use the disk would be a big step forward.
lspci lists the controller correctly, the output of lsscsi only gives the SATA-HDDs (Seagate 7200.11 1,5 TB, Samsung F1 1 TB) and optical drives (Sony/NEC Optiarc DVD-device) attached to the SATA-ports of the Intel ICH10R southbridge. Output of these two programs will be attached to the report, also relevant dmesg output.
Marvell itself does not offer any support for their mass storage controllers on their web presence, only a press release saying the company is entering the SAS enterprise storage market could be found. Asus' homepage and manual also does not offer relevant information.
Seagate-support isn't very helpful either, but a paragraph in the knowledge base states that it might be neccessary to build a "Virtual Device" out of the correctly detected physical device, even if only one disk is installed.
The support section of Intel's website offers a PDF regarding another older SATA controller manufactured by Marvell. Reading this it seems mandatory to build a so called "Virtual Device" to get the Disk(s) detected by the operating system.
The BIOS of the Marvell SAS controller doesn't allow creating an array (thought about JBOD if anything outer fails) if not at least two disks are selected. According to reports on hardware enthusiast forums the use of a single disk is possible on the P6T Deluxe, though the posters used microsoft operating system. They state it makes no difference if building an 1 disk array (not possible for me, flashed the recent beta bios 0905 for the mainboard, but nothing changed here) or simlpy ignoring the message after spinup (takes place correctly, believing the report of the controller and the acoustics ;)). Like already said, the posters used WinXP or Vista, which are not a solution for me, because of personal needs, much better satisfied by Fedora or simply the circumstand that I do not own a licenso for any still supported microsoft os, so testing if the issue is caused by the controller or the driver/os isn't that trivial. Last possibility is to check ms.com for a trial version of NT 6 to see if it is a controller problem or os specific, but that doesn't bring me any step forward either.
The BIOS of my old Silicon Image 3114 SATA controller offered the possibility to choose between RAID and single drive SATA mode. Choosing RAID mode ended up with exactly the same symptoms i experience now. Neither the Asus-mainboard-Bios, nor the controller bios offer the possibility to change from RAID mode to single drive mode.
I don't know what to test next. An older Bugzilla report describes a problem regarding a Marvell PATA controller with similar symptoms. Blacklisting ahci solved the problem until a fix was released. I'll try this too, but it doesn't seem to be the perfect solution. ;)
"mvsas" should be the correct driver, but neither modprobing it, nor built-in kernel support let F10 detect the Cheetah.
The harddisk drive should be visible if executing fdisk -l or something. Creating a so called "Virtual Device" is only possible if at least two drives are connected to the controller, which shouldn't be the case for previous Marvell SATA controllers.
Fedora 10 x86_64 with recent updates.
"mvsas" driver with required dependencies either loaded as module or built in the kernel
Intel Core i7 920
Asus P6T Deluxe
2 x 2 GiB Crucial DDR3-1066-Memory
NV 9600GT graphics card
using onboard components for network and sound output
two SATA-HDDs and a Sony/NEC Optiarc optical drive connected to SATA-ports of ICH10R southbridge
Created attachment 325612 [details]
output of lspci
controller is listed correctly by lspci
Created attachment 325614 [details]
output of lsscsi
only devices connected to SATA ports of Intel ICH10R southbridge are listed
Created attachment 325615 [details]
relevant part of dmesg output
*** Bug 474483 has been marked as a duplicate of this bug. ***
I have a nearly identical system which does recognize a single sas drive on the built in Marvell controller. My drive is a Seagate ST373455SS (73 G 15k SAS). I'm also using an i7 920 on a Asus P6T-Deluxe with a couple of SATA drives as well.
There are some problems using the sas drive however because rc.sysinit and/or the init script in the initrd try to use it before the mvsas driver has finished making the device appear. This means that partitions on it may fail to fsck or logical volumes fail to appear during rc.sysinit, depending on the timing.
To fix this, what I needed to do was add a delay loop into rc.sysinit. In my case I just hacked a loop waiting for /dev/sdc to appear just before rc.sysinit does the "lvm vgchange -a y" to set up the logical volumes. This works fine.
To make the sas drive usable as the root file system we need a similar delay for the device to appear before init tries to mount it as the new root, otherwise the mount fails and the system will not boot. mkinitrd already has a list of drivers for which it turns on a "wait_for_scsi" loop in init, but mvsas isn't on the list. I added mvsas to the list, created a new initrd and now / is fine on the sas drive. I have not tried /boot on the sas drive yet.
This is all with the stock Fedora 10 kernel from the release DVD. No new kernel or modprobing required.
This may not be same as the originators problem however, since on my system the
drive does show up. lsscsi shows it as:
[0:0:0:0] cd/dvd HL-DT-ST DVD-RAM GH22NS30 1.01 -
[1:0:0:0] disk ATA ST3500320AS SD15 -
[2:0:0:0] disk ATA ST3500320AS SD15 -
[6:0:0:0] disk SEAGATE ST373455SS 0002 -
The one line patch to mkinitrd is attached below. The hack to rc.sysinit is not since I've just hardcoded it to wait for /dev/sdc rather than find a general solution.
Created attachment 326026 [details]
patch to mkinitrd
one line patch to mkinitrd to add mvsas to the list of modules to turn on "wait_for_scsi"
The kernel bug is fixed in 184.108.40.206 and later kernels. And mkinitrd doesn't have a list of modules any more, so it should not need any changes.