dmraid hangs trying to start ICH9R RAID 5

What do you mean it failed to mount? What does ls /dev/mapper show? And sudo dmraid -ay?

I mean that it failed to mount my raid arrays. Using sudo dmraid -ay only causes it to set there on the terminal with a blinking cursor doing nothing. I can type in it like it's waiting for something, but it's to no avail.
As for ls /dev/mapper, it only shows the file control.

Update to messages: When I try to run ubuntu without the nodmraid option and quiet enabled, I receive a message "device-mapper: table 252:5: raid45: Invalid RAID device offset parameter". Something tells me that the problem isn't so much in dmraid itself as much as the RAID45 module.

Okay everyone, it goes deeper! I tried recompiling the Linux kernel to incorporate a few changes and to see if I could get dmraid to work correctly. The following is my result:

ubuntu/built-in.o: In function `dm_rh_dec':
/home/erick/Desktop/linux-source-2.6.35/ubuntu/dm-raid4-5/dm-region-hash.c:527: multiple definition of `dm_rh_dec'
drivers/built-in.o:/home/erick/Desktop/linux-source-2.6.35/drivers/md/dm-region-hash.c:535: first defined here
ubuntu/built-in.o: In function `dm_rh_delay':
/home/erick/Desktop/linux-source-2.6.35/ubuntu/dm-raid4-5/dm-region-hash.c:673: multiple definition of `dm_rh_delay'
drivers/built-in.o:/home/erick/Desktop/linux-source-2.6.35/drivers/md/dm-region-hash.c:687: first defined here
ubuntu/built-in.o: In function `dm_rh_recovery_in_flight':
/home/erick/Desktop/linux-source-2.6.35/ubuntu/dm-raid4-5/dm-region-hash.c:661: multiple definition of `dm_rh_recovery_in_flight'
drivers/built-in.o:/home/erick/Desktop/linux-source-2.6.35/drivers/md/dm-region-hash.c:675: first defined here
ubuntu/built-in.o: In function `dm_rh_update_states':
/home/erick/Desktop/linux-source-2.6.35/ubuntu/dm-raid4-5/dm-region-hash.c:431: multiple definition of `dm_rh_update_states'
drivers/built-in.o:/home/erick/Desktop/linux-source-2.6.35/drivers/md/dm-region-hash.c:437: first defined here
ubuntu/built-in.o: In function `dm_rh_start_recovery':
/home/erick/Desktop/linux-source-2.6.35/ubuntu/dm-raid4-5/dm-region-hash.c:707: multiple definition of `dm_rh_start_recovery'
drivers/built-in.o:/home/erick/Desktop/linux-source-2.6.35/drivers/md/dm-region-hash.c:708: first defined here
ubuntu/built-in.o: In function `dm_rh_mark_nosync':
/home/erick/Desktop/linux-source-2.6.35/ubuntu/dm-raid4-5/dm-region-hash.c:393: multiple definition of `dm_rh_mark_nosync'
drivers/built-in.o:/home/erick/Desktop/linux-source-2.6.35/drivers/md/dm-region-hash.c:395: first defined here
ubuntu/built-in.o: In function `dm_region_hash_destroy':
/home/erick/Desktop/linux-source-2.6.35/ubuntu/dm-raid4-5/dm-region-hash.c:230: multiple definition of `dm_region_hash_destroy'
drivers/built-in.o:/home/erick/Desktop/linux-source-2.6.35/drivers/md/dm-region-hash.c:235: first defined here
ubuntu/built-in.o: In function `dm_rh_region_to_sector':
/home/erick/Desktop/linux-source-2.6.35/ubuntu/dm-raid4-5/dm-region-hash.c:118: multiple definition of `dm_rh_region_to_sector'
drivers/built-in.o:/home/erick/Desktop/linux-source-2.6.35/drivers/md/dm-region-hash.c:122: first defined here
ubuntu/built-in.o: In function `dm_rh_dirty_log':
/home/erick/Desktop/linux-source-2.6.35/ubuntu/dm-raid4-5/dm-region-hash.c:255: multiple definition of `dm_rh_dirty_log'
drivers/built-in.o:/home/erick/Desktop/linux-source-2.6.35/drivers/md/dm-region-hash.c:260: first defined here
ubuntu/built-in.o: In function `dm_rh_stop_recovery':
/home/erick/Desktop/linux-source-2.6.35/ubuntu/dm-raid4-5/dm-region-hash.c:697: multiple definition of `dm_rh_stop_recovery'
drivers/built-in.o:/home/erick/Desktop/linux-source-2.6.35/drivers/md/dm-region-hash.c:698: first defined here
ubuntu/built-in.o: In function `dm_rh_bio_to_region':
/home/erick/Desktop/linux-source-2.6.35/ubuntu/dm-raid4-5/dm-region-hash.c:124: multiple d...

Okay, I'm going over the code now. I'm a novice so I might be wrong here. But, I've changed uint32_t to unsigned long int and I've added a LOT of semi-colons to void and struct statements. I think a number of structs could have been changed to typeref, but I'm not a programmer. If someone would go over this and double check for me, I would really appreciate it. I'll upload my changed dm-region-hash.c file later when I finish.

Well, I finished (sort of) and it wasn't pretty to say the least. Basically, it needs to have a few punctuations moved and needs to have the code refined quite a bit. There's also a problem with incompatible types in one of the declared variables. If someone that knows what they're doing would fix this for me, I would appreciate it.

cannot install Ubuntu Server 10.10 on Intel fakeRAID5.
i get this message:

"ERROR: device-mapper target type "raid45" not in kernel".

Did you recompile or use a non-standard kernel than what came with Ubuntu?

Here is the output of dmraid from my terminal:

erick@ubuntu:~$ sudo dmraid -ay -vvvv -dddd
WARN: locking /var/lock/dmraid/.lock
NOTICE: /dev/sde: asr discovering
NOTICE: /dev/sde: ddf1 discovering
NOTICE: /dev/sde: hpt37x discovering
NOTICE: /dev/sde: hpt45x discovering
NOTICE: /dev/sde: isw discovering
DEBUG: not isw at 1000204884992
DEBUG: isw trying hard coded -2115 offset.
DEBUG: not isw at 1000203803136
NOTICE: /dev/sde: jmicron discovering
NOTICE: /dev/sde: lsi discovering
NOTICE: /dev/sde: nvidia discovering
NOTICE: /dev/sde: pdc discovering
NOTICE: /dev/sde: sil discovering
NOTICE: /dev/sde: via discovering
NOTICE: /dev/sdd: asr discovering
NOTICE: /dev/sdd: ddf1 discovering
NOTICE: /dev/sdd: hpt37x discovering
NOTICE: /dev/sdd: hpt45x discovering
NOTICE: /dev/sdd: isw discovering
DEBUG: not isw at 1000204884992
DEBUG: isw trying hard coded -2115 offset.
DEBUG: not isw at 1000203803136
NOTICE: /dev/sdd: jmicron discovering
NOTICE: /dev/sdd: lsi discovering
NOTICE: /dev/sdd: nvidia discovering
NOTICE: /dev/sdd: pdc discovering
NOTICE: /dev/sdd: sil discovering
NOTICE: /dev/sdd: via discovering
NOTICE: /dev/sdc: asr discovering
NOTICE: /dev/sdc: ddf1 discovering
NOTICE: /dev/sdc: hpt37x discovering
NOTICE: /dev/sdc: hpt45x discovering
NOTICE: /dev/sdc: isw discovering
DEBUG: isw metadata found at 320072932352 from probe at 320072932352

NOTICE: /dev/sdc: isw metadata discovered
NOTICE: /dev/sdc: jmicron discovering
NOTICE: /dev/sdc: lsi discovering
NOTICE: /dev/sdc: nvidia discovering
NOTICE: /dev/sdc: pdc discovering
NOTICE: /dev/sdc: sil discovering
NOTICE: /dev/sdc: via discovering
NOTICE: /dev/sdb: asr discovering
NOTICE: /dev/sdb: ddf1 discovering
NOTICE: /dev/sdb: hpt37x discovering
NOTICE: /dev/sdb: hpt45x discovering
NOTICE: /dev/sdb: isw discovering
DEBUG: isw metadata found at 320072932352 from probe at 320072932352

NOTICE: /dev/sdb: isw metadata discovered
NOTICE: /dev/sdb: jmicron discovering
NOTICE: /dev/sdb: lsi discovering
NOTICE: /dev/sdb: nvidia discovering
NOTICE: /dev/sdb: pdc discovering
NOTICE: /dev/sdb: sil discovering
NOTICE: /dev/sdb: via discovering
NOTICE: /dev/sda: asr discovering
NOTICE: /dev/sda: ddf1 discovering
NOTICE: /dev/sda: hpt37x discovering
NOTICE: /dev/sda: hpt45x discovering
NOTICE: /dev/sda: isw discovering
DEBUG: isw metadata found at 320072932352 from probe at 320072932352

NOTICE: /dev/sda: isw metadata discovered
NOTICE: /dev/sda: jmicron discovering
NOTICE: /dev/sda: lsi discovering
NOTICE: /dev/sda: nvidia discovering
NOTICE: /dev/sda: pdc discovering
NOTICE: /dev/sda: sil discovering
NOTICE: /dev/sda: via discovering
DEBUG: _find_set: searching isw_cjgjfegeba
DEBUG: _find_set: not found isw_cjgjfegeba
DEBUG: _find_set: searching isw_cjgjfegeba_Light
DEBUG: _find_set: searching isw_cjgjfegeba_Light
DEBUG: _find_set: not found isw_cjgjfegeba_Light
DEBUG: _find_set: not found isw_cjgjfegeba_Light
DEBUG: _find_set: searching isw_cjgjfegeba_Darkness
DEBUG: _find_set: searching isw_cjgjfegeba_Darkness
DEBUG: _find_set: searching isw_cjgjfegeba_Da...

How are you compiling the Ubuntu kernel source?

You will need to use dpkg as there will be a lot of debian/ubuntu patches to the main source!
This will quite often leave you with errors like you got above.

I'm compiling it using the source from synaptic. But this bug isn't about compilation errors; it's about the startup error. I only put the compilation error there as a point of reference should the source need to be looked at.

I'm guessing nobody's going to be working on this anytime soon. For some reason, it's still having trouble identifying my isw drive. I think we might need to go about a different means of identifying and adapting to it.

I've found the problem and a work-around. dmraid is incapable of handling metadata which is written into RAID arrays by Intel's Matrix program. dmraid errors on the metadata and crashes. If someone would be so kind as to code something into dmraid to either ignore or utilize the metadata, it would correct the problem many people are having and allow the raid arrays to be utilized. Thank you!

No, dmraid certainly supports Intel's Matrix Raid. If it crashes with your specific metadata, please post the exact command and output. I notice that you appear to have the array divided up into two named volumes, Light and Darkness. Last I heard there were problems with doing that. I will try and debug it with the metadata you attached.

Actually, I don't have the array itself divided into two volumes, I have the three drives divided into two raid 5 arrays. Darkness doesn't get used as much as it used to be my XP partition. However, I found that I used my Vista and, later, Win 7 more often so I removed XP and left it as a partition for backups. But I can understand how it would have difficulty with the two raid 5 arrays sharing the three drives. The reason I thought it was the metadata was because of some similar issues with Fedora. I've decided to try mdadm to see if it reads them correctly or not. Once dmraid can handle my dual raid arrays, I'll switch back.

Hrm... the attached files only seem to contain the record for darkness and so are incomplete and unrecognizable. Please run this and attach the resulting file:

for f in sda sdb sdc ; do sudo dd if=/dev/$f of=$f.dat skip=625142320 ; done ; tar cjf metadata.tar.bz2 sd[abc].dat

As requested sir, here is your metadata.

I'm starting to think this is a bug in the raid4-5 driver. I'm seeing this in my kernel log:

Dec 22 21:56:30 faldara kernel: [ 1939.397600] device-mapper: ioctl: device doesn't appear to be in the dev hash table.
Dec 22 21:56:30 faldara kernel: [ 1939.417446] quiet_error: 9 callbacks suppressed
Dec 22 21:56:30 faldara kernel: [ 1939.417455] Buffer I/O error on device dm-9, logical block 0
Dec 22 21:56:30 faldara kernel: [ 1939.417470] Buffer I/O error on device dm-9, logical block 1
Dec 22 21:56:30 faldara kernel: [ 1939.417480] Buffer I/O error on device dm-9, logical block 2
Dec 22 21:56:30 faldara kernel: [ 1939.417489] Buffer I/O error on device dm-9, logical block 3
Dec 22 21:56:30 faldara kernel: [ 1939.417498] Buffer I/O error on device dm-9, logical block 4
Dec 22 21:56:30 faldara kernel: [ 1939.417507] Buffer I/O error on device dm-9, logical block 5
Dec 22 21:56:30 faldara kernel: [ 1939.417516] Buffer I/O error on device dm-9, logical block 6
Dec 22 21:56:30 faldara kernel: [ 1939.417525] Buffer I/O error on device dm-9, logical block 7
Dec 22 21:56:30 faldara kernel: [ 1939.417543] Buffer I/O error on device dm-9, logical block 0
Dec 22 21:56:30 faldara kernel: [ 1939.417552] Buffer I/O error on device dm-9, logical block 1
Dec 22 21:56:30 faldara kernel: [ 1939.419218] device-mapper: table: 252:10: raid45: Invalid RAID device offset parameter
Dec 22 21:56:30 faldara kernel: [ 1939.419230] device-mapper: ioctl: error adding target to table

And then the dmraid process becomes stuck in the uninterruptable state.

Can you check your kernel log for similar entries, and if dmraid -ay becomes stuck, hit alt-sysrq-w and it should add lines to the log that look something like:

Dec 22 21:57:06 faldara kernel: [ 1975.682785] SysRq : Show Blocked State
Dec 22 21:57:06 faldara kernel: [ 1975.682796] task PC stack pid father
Dec 22 21:57:06 faldara kernel: [ 1975.682864] dmraid D 0000000100028e87 0 3700 3475 0x00000004
Dec 22 21:57:06 faldara kernel: [ 1975.682874] ffff880064a77ce8 0000000000000086 ffffffff00000000 0000000000015980
Dec 22 21:57:06 faldara kernel: [ 1975.682883] ffff880064a77fd8 0000000000015980 ffff880064a77fd8 ffff88006743c4a0
Dec 22 21:57:06 faldara kernel: [ 1975.682892] 0000000000015980 0000000000015980 ffff880064a77fd8 0000000000015980
Dec 22 21:57:06 faldara kernel: [ 1975.682901] Call Trace:
Dec 22 21:57:06 faldara kernel: [ 1975.682918] [<ffffffff81588175>] schedule_timeout+0x195/0x310
Dec 22 21:57:06 faldara kernel: [ 1975.682931] [<ffffffff810702f0>] ? process_timeout+0x0/0x10
Dec 22 21:57:06 faldara kernel: [ 1975.682940] [<ffffffff8158830e>] schedule_timeout_uninterruptible+0x1e/0x20
Dec 22 21:57:06 faldara kernel: [ 1975.682949] [<ffffffff81071420>] msleep+0x20/0x30
Dec 22 21:57:06 faldara kernel: [ 1975.682958] [<ffffffff81457dba>] __dm_destroy+0x9a/0x150
Dec 22 21:57:06 faldara kernel: [ 1975.682965] [<ffffffff81457ea3>] dm_destroy+0x13/0x20
Dec 22 21:57:06 faldara kernel: [ 1975.682974] [<ffffffff8145d570>] dev_remove+0x90/0x110
Dec 22 21:57:06 faldara kernel: [ 1975.682981] [<ffffffff8145d4e0>] ? dev_remove+0x0/0x110
Dec 22 21:57:06 faldara kernel: [ 1975...

Adding linux target since this is a kernel bug.

Consider yourself verified. Also, see my previous comment about my attempt at recompiling my kernel and how it failed at the ../ubuntu/dm-raid4-5/dm-region-hash.c file. It's comment #5 to be exact.

Dec 30 03:05:11 ubuntu kernel: [ 22.205128] hda-intel: IRQ timing workaround is activated for card #1. Suggest a bigger bdl_pos_adj.
Dec 30 03:05:03 ubuntu kernel: [ 23.474918] hda-intel: IRQ timing workaround is activated for card #2. Suggest a bigger bdl_pos_adj.
Dec 30 03:05:12 ubuntu kernel: [ 31.860004] eth0: no IPv6 routers present
Dec 30 03:06:28 ubuntu kernel: [ 107.804182] device-mapper: table: 252:0: raid45: Invalid RAID device offset parameter
Dec 30 03:06:28 ubuntu kernel: [ 107.804185] device-mapper: ioctl: error adding target to table
Dec 30 03:09:03 ubuntu kernel: [ 263.086864] SysRq : Show Blocked State
Dec 30 03:09:03 ubuntu kernel: [ 263.086868] task PC stack pid father
Dec 30 03:09:03 ubuntu kernel: [ 263.086900] dmraid D 00000000fffff192 0 3362 2816 0x00000000
Dec 30 03:09:03 ubuntu kernel: [ 263.086905] ffff880087935ce8 0000000000000086 ffff880100000000 0000000000015980
Dec 30 03:09:03 ubuntu kernel: [ 263.086909] ffff880087935fd8 0000000000015980 ffff880087935fd8 ffff880078838000
Dec 30 03:09:03 ubuntu kernel: [ 263.086913] 0000000000015980 0000000000015980 ffff880087935fd8 0000000000015980
Dec 30 03:09:03 ubuntu kernel: [ 263.086917] Call Trace:
Dec 30 03:09:03 ubuntu kernel: [ 263.086924] [<ffffffff81588175>] schedule_timeout+0x195/0x310
Dec 30 03:09:03 ubuntu kernel: [ 263.086929] [<ffffffff810702f0>] ? process_timeout+0x0/0x10
Dec 30 03:09:03 ubuntu kernel: [ 263.086933] [<ffffffff8158830e>] schedule_timeout_uninterruptible+0x1e/0x20
Dec 30 03:09:03 ubuntu kernel: [ 263.086936] [<ffffffff81071420>] msleep+0x20/0x30
Dec 30 03:09:03 ubuntu kernel: [ 263.086940] [<ffffffff81457dba>] __dm_destroy+0x9a/0x150
Dec 30 03:09:03 ubuntu kernel: [ 263.086943] [<ffffffff81457ea3>] dm_destroy+0x13/0x20
Dec 30 03:09:03 ubuntu kernel: [ 263.086946] [<ffffffff8145d570>] dev_remove+0x90/0x110
Dec 30 03:09:03 ubuntu kernel: [ 263.086950] [<ffffffff8145d4e0>] ? dev_remove+0x0/0x110
Dec 30 03:09:03 ubuntu kernel: [ 263.086953] [<ffffffff8145ddb5>] ctl_ioctl+0x1a5/0x250
Dec 30 03:09:03 ubuntu kernel: [ 263.086956] [<ffffffff8145de73>] dm_ctl_ioctl+0x13/0x20
Dec 30 03:09:03 ubuntu kernel: [ 263.086960] [<ffffffff81162f0d>] vfs_ioctl+0x3d/0xd0
Dec 30 03:09:03 ubuntu kernel: [ 263.086963] [<ffffffff811637e1>] do_vfs_ioctl+0x81/0x340
Dec 30 03:09:03 ubuntu kernel: [ 263.086967] [<ffffffff8158db2e>] ? do_page_fault+0x15e/0x350
Dec 30 03:09:03 ubuntu kernel: [ 263.086970] [<ffffffff81163b21>] sys_ioctl+0x81/0xa0
Dec 30 03:09:03 ubuntu kernel: [ 263.086974] [<ffffffff8100a0f2>] system_call_fastpath+0x16/0x1b
Dec 30 03:09:03 ubuntu kernel: [ 263.086978] Sched Debug Version: v0.09, 2.6.35-24-generic #42-Ubuntu

What I'm trying to get at is that I'm pretty certain that the source of the leak is in the ubuntu patches. Specifically, ../ubuntu/dm-raid4-5/dm-region-hash.c
Mr. Susi, if you could please take a look at my compilation output from above and see if that helps track the error, I would appreciate it.

I have no idea what you were trying to compile or why you got errors, but yes, the problem is obviously in the dm-raid4-5 driver, which is an experimental driver that Ubuntu added. Upstream is working on getting a proper raid456 driver into 2.6.38, but that will be for natty+1.

What I was attempting to compile above was the Ubuntu kernel from the sources provided by Synaptic. Once it hit the experimental Ubuntu dm-raid4-5 driver you mentioned, it errored very specifically on the dm-region-hash.c file. Looking at the compilation output, it seems that most, if not all of, the variables in the source were uninitialized or undefined prior to use. I don't know if it was the case, but I tried taking a look at the code myself to see if I could fix it by initializing the values with typeref or something, however I only really know bash and bat coding so it went horribly wrong.

This bug also affects Ubuntu 11.04 currently in Beta production.

Isn't the raid4-5 driver deprecated?
Ubuntu hasn't used it for 2 releases which is why you had to manually compile it.

It has now been replaced in the linux kernel by the new kernel driver 'raid456' hasn't it?

Dmraid probably needs to be re-worked to use this newer driver for it to accept raid5 in 11.04.

Ignore my previous comment, I hadn't read the last couple of comments!

There is still heinz's dm-raid45 module in the ubuntu kernel.

When you say it doesn't work in 11.04 is that with this module or the one you tried to compile?

dm-raid45 doesn't work correctly in 11.04 with the default module. It will not load my RAID arrays. I believe it may have difficulty distinguishing between the two RAID 5 arrays which both share 3 drives.

As for the one I attempted to compile, that was back in 10.10 when the module still didn't work and I thought I might be able to rework some of the code to correct it. Before reworking, dmraid4-5 was giving me all sorts of compilation errors. I have not since tried to recompile dmraid. This error goes back to the late version 9.xx Ubuntu and hasn't been resolved since.

On a slightly related note, Mr. Wood, I've noticed that many of the problems previously resolved in updates to 10.10 have returned in 11.04 which indicates to me that some modules here and there have, in fact, been reverted. So raid456 may very well be in the kernel, but, as you've stated, it isn't being used. I've also mentioned another error involving display hardware that could be taken advantage of as a security risk, but someone marked it as not important and not a risk. So I don't know what to think about some of the module issues at this point.

As phillip previously said there is a dm-raid456 on the way (dm-raid is the module and it exists in 2.6.38 but is still listed experimental).

I believe that most standard RAID5 arrays do work or we would see more bugs (RAID5 is a common setup with dm).
Obviously yours is a special case and requires some work to get the dmraid driver working correctly.

What are the errors with 11.04?

Ubuntu at the end of a the day is a 'bleeding edge' distrobution, many of the new features included in it have not been tested longer than a few months and although most bugs are fixed before release some of the lesser used features can end up with regressions. You can always choose a more stable distro like debian if you are looking for ultimate stability.

I've done some investigating on my second array by poking around with mdadm. It seems that there was a slight offset with the partition allignment that COULD have been the problem. It was offset by 33280 bytes. mdadm seems to allow me to access both of the arrays correctly though. So I can't figure out what's different between the two programs' methods of access that causes one to work flawlessly in accessing both arrays and the other to completely fail to load either.
So I have determined that the Linux kernel IS capable of reading the arrays.

mdadm is for software raid, dmraid is for fakeraid. The two do not mix. You have been using fakeraid so mdadm should not have anything to do with it. Did you have mdadm create a software raid array?

Honestly, I don't know why or how it worked, but it did. I used the --examine --scan to see if it would even recognize the array. Once I realized it recognized it, I told it to scan and run the array. It told me there were no super blocks, but it loaded it right up and I was able to mount my array for use in the disk manager. Unfortunately, I was forced to use this method to actually recover my data from my degraded (and corrupted) RAID 5 array after my bios decided it didn't want to recognize it as existing anymore. But yeah, apparently mdadm can recognize and run degraded fakeraid Level 5 arrays as well.
So, the answer to your question is no; I didn't have it create the array, I had it take the two working drives from my 3 drive array and run the arrays it found on them. We might look at this as a viable solution if it continues to work right.

Would you like a screenshot or a verbose log of the examine results produced by mdadm as verification?

Yes, the output of mdadm -E and -D would be interesting.

As you wish. Attached are the files Examine, Detail and even Detail-Platform so you know specifically what I'm working with. Unfortunately, since my main RAID 5 array became corrupted, I decided it was time to consolidate both arrays into one so I won't be able to verify any fix of the code that may come about. You may be delighted to know that it is verified that dmraid does work with arrays not sharing drives with other arrays as it recognizes my single RAID 5 array flawlessly. So the bug is recognizing multiple arrays on shared drives. You also might be happy to hear that mdadm has difficulty with array names containing spaces. So that's a plus for dmraid. Also, the array shows in Disk Utility as inactive under Ubuntu (Live CD) but active under Fedora so there's that compatibility problem as well. But there you have it.

One thing that has me twitching about my output here is the Detail-Platform file where it states that the Max Disks is 6. I wonder, if someone were to utilize a SATA port multiplier, if it would register a higher maximum or if it would assume that the # of on-board ports = # of Max Disks? That's something to test when I get the time and money to do so.

Oops, forgot to attach...