Hi All

 

I have recently built my unRaid server. It configuration is :

 

- X8SIL-F

- 4 G RAM

- Intel Xeon X3440

- 3 SASLP-MV8 PCIe cards

- Norco 4220 case

- 5 WD Cav Black 1TB (parity + 4 data drives)

- 3 WD Cav Green 2TB (not allocated yet just chilling and waiting for the day when there will be the ability to have 2 unRaids....so for backup)

- WD Cav Green 500GB as cache drive (running off the MB)

- All but the cache drive are running of the 3 MV8 PCIe cards

- unRaid Pro

 

It looks to be working ok, but I have a few questions so if someone can help me with them that would be great:

- Is there a cheat sheet on the best settings for BIOS?

- After the initial bulk transfers of data to the new system the sync check returned 13 errors. Is there anyway of finding out what may or may not have been affected from a file perspective so we can check? Note follow-up check found zero errors

- Can I share at a sub folder, or are all shares at the top level eg if I have  top level share SHARE1 with folders under there...can I share any of those folders separately with their own permissions?

- Rebooted to clear the pipes so to speak and noticed the following errors in syslog (this section repeated twice in one boot). Has anyone seen this before? :

 

Feb  1 09:15:08 odyssey kernel: ------------[ cut here ]------------

Feb  1 09:15:08 odyssey kernel: WARNING: at fs/proc/generic.c:590 proc_register+0x11c/0x14b() (Minor Issues)

Feb  1 09:15:08 odyssey kernel: Hardware name: X8SIL

Feb  1 09:15:08 odyssey kernel: proc_dir_entry 'scsi_tgt/mvst_scst' already registered (Drive related)

Feb  1 09:15:08 odyssey kernel: Modules linked in: mvsas(+) libsas scst scsi_transport_sas (Drive related)

Feb  1 09:15:08 odyssey kernel: Pid: 940, comm: modprobe Tainted: G        W  2.6.32.9-unRAID #8 (Errors)

Feb  1 09:15:08 odyssey kernel: Call Trace: (Errors)

Feb  1 09:15:08 odyssey kernel:  [<c102449e>] warn_slowpath_common+0x60/0x77 (Errors)

Feb  1 09:15:08 odyssey kernel:  [<c10244e9>] warn_slowpath_fmt+0x24/0x27 (Errors)

Feb  1 09:15:08 odyssey kernel:  [<c109cf0e>] proc_register+0x11c/0x14b (Errors)

Feb  1 09:15:08 odyssey kernel:  [<c109d0cc>] proc_mkdir_mode+0x2f/0x43 (Errors)

Feb  1 09:15:08 odyssey kernel:  [<c109d0ef>] proc_mkdir+0xf/0x11 (Errors)

Feb  1 09:15:08 odyssey kernel:  [<f83f5a36>] scst_build_proc_target_dir_entries+0x55/0xdc [scst] (Routine)

Feb  1 09:15:08 odyssey kernel:  [<f83dcca9>] __scst_register_target_template+0x16c/0x3af [scst] (Routine)

Feb  1 09:15:08 odyssey kernel:  [<f845ad5d>] mvst_init+0x3b/0x5b [mvsas] (Errors)

Feb  1 09:15:08 odyssey kernel:  [<f845f895>] mvs_pci_init+0xaa5/0xaf7 [mvsas] (Errors)

Feb  1 09:15:08 odyssey kernel:  [<c10062d9>] ? dma_generic_alloc_coherent+0x0/0xdb (Errors)

Feb  1 09:15:08 odyssey kernel:  [<c1142050>] local_pci_probe+0xe/0x10 (Errors)

Feb  1 09:15:08 odyssey kernel:  [<c11426ad>] pci_device_probe+0x48/0x66 (Errors)

Feb  1 09:15:08 odyssey kernel:  [<c1194956>] driver_probe_device+0x79/0xed (Errors)

Feb  1 09:15:08 odyssey kernel:  [<c1194a0d>] __driver_attach+0x43/0x5f (Errors)

Feb  1 09:15:08 odyssey kernel:  [<c11940a7>] bus_for_each_dev+0x39/0x5a (Errors)

Feb  1 09:15:08 odyssey kernel:  [<f8467000>] ? mvs_init+0x0/0x45 [mvsas] (Errors)

Feb  1 09:15:08 odyssey kernel:  [<c119482f>] driver_attach+0x14/0x16 (Errors)

Feb  1 09:15:08 odyssey kernel:  [<c11949ca>] ? __driver_attach+0x0/0x5f (Errors)

Feb  1 09:15:08 odyssey kernel:  [<c119451c>] bus_add_driver+0x9f/0x1c5 (Errors)

Feb  1 09:15:08 odyssey kernel:  [<f8467000>] ? mvs_init+0x0/0x45 [mvsas] (Errors)

Feb  1 09:15:08 odyssey kernel:  [<c1194ccf>] driver_register+0x7b/0xd7 (Errors)

Feb  1 09:15:08 odyssey kernel:  [<f8467000>] ? mvs_init+0x0/0x45 [mvsas] (Errors)

Feb  1 09:15:08 odyssey kernel:  [<c1142882>] __pci_register_driver+0x39/0x8c (Errors)

Feb  1 09:15:08 odyssey kernel:  [<f8467000>] ? mvs_init+0x0/0x45 [mvsas] (Errors)

Feb  1 09:15:08 odyssey kernel:  [<f8467030>] mvs_init+0x30/0x45 [mvsas] (Errors)

Feb  1 09:15:08 odyssey kernel:  [<c1001139>] do_one_initcall+0x4c/0x131 (Errors)

Feb  1 09:15:08 odyssey kernel:  [<c1042e6e>] sys_init_module+0xa7/0x1dd (Errors)

Feb  1 09:15:08 odyssey kernel:  [<c1002935>] syscall_call+0x7/0xb (Errors)

Feb  1 09:15:08 odyssey kernel: ---[ end trace 91fec388289de032 ]---

HEADER OF THE SECOND BIT

Feb  1 09:15:08 odyssey kernel: ------------[ cut here ]------------

Feb  1 09:15:08 odyssey kernel: WARNING: at fs/proc/generic.c:590 proc_register+0x11c/0x14b() (Minor Issues)

Feb  1 09:15:08 odyssey kernel: Hardware name: X8SIL

Feb  1 09:15:08 odyssey kernel: proc_dir_entry 'scsi_tgt/mvst_scst' already registered (Drive related)

Feb  1 09:15:08 odyssey kernel: Modules linked in: mvsas(+) libsas scst scsi_transport_sas (Drive related)

Feb  1 09:15:08 odyssey kernel: Pid: 940, comm: modprobe Tainted: G        W  2.6.32.9-unRAID #8 (Errors)

Feb  1 09:15:08 odyssey kernel: Call Trace: (Errors)

...................

Many thanks

 

Jim

Those messages indicate the driver for the disk controller card is already in memory

(translation, you have two disk controller cards of the same type installed)

It is harmless, you can ignore it.

Joe, Thanks for the response to the error message.

 

Does anyone have comments with respect to the other questions ie

 

- Is there a cheat sheet on the best settings for BIOS?

- After the initial bulk transfers of data to the new system the sync check returned 13 errors. Is there anyway of finding out what may or may not have been affected from a file perspective so we can check? Note follow-up check found zero errors

- Can I share at a sub folder, or are all shares at the top level eg if I have  top level share SHARE1 with folders under there...can I share any of those folders separately with their own permissions?

 

Thanks

I have the same motherboard (almost - X8SIL without the "F") and 3 SASLP-MV8 controllers as you do. I was not able to get my system to boot due to the conflict between the BIOSes of the 3 cards existing together on same motherboard, so I had to disable "option ROM" for all 3 PCIe slots in the motherboard BIOS. I am curious, did you do the same thing, or something different, or did your system boot just fine with all 3 cards in place at the same time? My system would boot just fine using defaults if any 2 cards were installed, but would not boot with all 3 cards installed.

 

 

Oddwun,

 

Yes if you allow option ROMs then only two cards will activate. From memory the middle one was the one that would fail to start (not sure why). I have logged an issue Supermicro with no real answer back ie I got this

 

"It could be related to limit on option ROM space. If you remove SATA DVD would that help? What onboard SATA mode is set in BIOS, is it compatible mode, or using AHCI/RAID mode? If using Enhanced AHCI/RAID mode, please change to compatible mode to see.

 

And you are saying that it has nothing to do with that card? Any 2 cards out of 3 will work, as long as you don't put in 3rd card?"

 

I think the bold red bit is the issue. What I have found is that if you disable the ROMs its no big deal. As soon as the drivers load the cards (and subsequently) the drive come up. I found this to be the case for unRaid and WHS.

I think the bold red bit is the issue. What I have found is that if you disable the ROMs its no big deal. As soon as the drivers load the cards (and subsequently) the drive come up. I found this to be the case for unRaid and WHS

Yes, like I said, that was what I did also...and I had gotten a similar reply from Supermicro. My response to them was "Don't you think that it would be a good idea to ensure that 3 of YOUR cards will work properly, with BIOSes enabled, in YOUR motherboard, especially considering the fact that both products are aimed at people building servers and the chances are quite high that people will want to use 3 cards in their servers?"

 

I agree, with the ROMs disabled, the server boots up a lot quicker and works just fine, but it irks me that I had to figure that out just to get the server to boot.

 

Sorry I can't help with your questions...I'm new at this too.

This might not be related but with my mobo listed below there was an issue with not enough option rom to load the SASLP. Downgrading the SASLP to .15 firmware sorted the problem out as I believe the firmware is a lot smaller so needed less option rom. I've got a fix and details posted in the post.

 

If you search the boards for my mobo and SASLP you should find the post.

 

With my mobo choosing IDE instead of ACHI also worked as that must have allowed more option rom if that is the way it works. ASUS have no solution for the problem.

 

Josh

All, if your interested, latest from Supermicro and my response as well

 

-------------------------

 

Actually this is a known limit for Marvell chipset, please see below feedback from our lab:

 

The customer issue here is they cannot see all 3 controllers and all 24 HDD during controller initialization. This is just a limitation that Marvell BIOS cannot allocate all 3 controllers in BIOS and it is actually not a major issue. Once OS and driver is up it will see all 3 controllers with all 24 HDD.

 

The customer needs to understand that if they are not booting from the controller, it is not required to have all controllers initialized during post for them to work. They just need to concern that all controllers and HDD are detected in OS.

 

Even if they are booting from the controller only one controller initialized is sufficient.  Because this is non-RAID controller they can just boot from one of the HDD. I don’t think they will keep changing and booting from different HDD off the 24 HDD every time. We should let customer know and educate them.

 

-------------------------

 

Hi,

 

I agree with almost all of it, except that if you turn off the ROM in bios for say two of the cards and leave one on to enable you to boot of one of the drives on the card. .....the same issue occurs. Its as if once the ROM loads for one of the cards, it sees the other two and tries to bring them into the fold. Then your back to square one with only two of the cards being visible to the OS.

 

If I switch all the ROMs off and boot of say a thumb drove then yes the OS sees all of the cards.

 

-------------------------

 

Hi

 

Im going to mark this thread as solved but thought I would re-list some of the questions that were not answered to see if anyone had any further comment.

 

- Is there a cheat sheet on the best settings in BIOS for an unRaid system (not just for sata but all aspects of bios eg PnP aware os, virtualisation features, other cpu features, ACPI, etc etc etc)?

- After the initial bulk transfers of data to the new system the sync check returned 13 errors. Is there anyway of finding out what may or may not have been affected from a file perspective so we can check? Note follow-up check found zero errors

- Can I share at a sub folder, or are all shares at the top level eg if I have  top level share SHARE1 with folders under there...can I share any of those folders separately with their own permissions? I think the answer is no but just checking.

 

Many thanks