1) Raid 0 stripe created on 3 different motherboards
1a) Gigabyte (see Rapid Storage Technology//message/534010# 534010 Intel Raid 10 Failed - 2 out of 4 drives became non-members of array)
1b) Supermicro S7Z370 (mine)
1c) Asus Maximus VIII Hero (mine)
2) Reset CMOS
3) Initial boot, after reset, shows RAID 0 stripe as FAILED and some disks as "Non-RAID Disk"
Easily recreated on S7Z370. RAID 0 Stripe was only 2 SSDs. Second one comes up aa "Non-RAID Disk" every time following a CMOS reset.
Common denominator is IRST firmware.
I think what is happening is IRST fw, being restarted in AHCI mode, is deciding to destroy the RAID Stripe. This is wrong, even if started in AHCI mode, the data on the disks MUST NOT BE TOUCHED.
Then you can switch modes to IRST, reboot, and RAID stripes should be fine.
Why does IRST fw destroy RAID 0 Stripe when booted in AHCI mode?
I tried recreating the stripe to see if the data was still there. I thought it was when I saw Win10 booting up, but, it was booting from DVD setup disk.
I deleted my last reply that indicated data was OK. Data was truly destroyed by CMOS reset. Sorry about confusion if you saw my last reply(since deleted).
Thank you for joining this Intel Community.
I understand that RAID 0 is deleted after you clear CMOS to reset BIOS settings. I would like to provide more information about this.
In this case, if clearing CMOS deletes a RAID 0 volume and changes the SATA mode in BIOS, it means that motherboard manufacturers should look into this in order to fix it. As you already know, it is worth mentioning that we are trying to assist you on this thread: https://communities.intel.com/thread/123887?start=15&tstart=0 https://communities.intel.com/thread/123887?start=15&tstart=0
If there is an issue that has to be addressed, system manufacturers will surely contact us, business-to-business, to fix it as soon as possible.
I'm sorry, but this is not a logical response.
First, it is happening on 3 different motherboard manufactured by 3 different companies. There would have to be the same bug, in 3 different pieces of code if it was the motherboard manufacturer doing it. For all practical purposes, this is impossible.
Second, there is not way that the mobo BIOS is changing data on any customer disk.
The only common denominator and the only logical suspect is the Intel RAID Controller firmware.
If you think about this for a bit, I am sure you will see this is the case.
Please contact Intel's RAID Controller firmware team and ask them their opinion.
The fact that this is happening on three different motherboards means diddly. Almost all of the board vendors are basing their BIOS on the AMI BIOS core and thus, if it is seen on one, it will likely be seen on others.
That other thread you mentioned was started by Vane. I commented on it, but it is not mine.
Can you contact the RAID firmware team and get their opinion on this matter?
I appreciate your patience.
I know that this is your thread, but other people are also working on the thread you originally posted your concern on. Please check the other thread and let us know if you have any other questions.
In short, we attempted to replicate the issue your RAID setup experiences after a CMOS reset on Intel® NUC, but we did not run into it.
Thanks for taking the time to try and reproduce the issue.
However, the NUC motherboards are stripped down to bare minimum I don't think this is an apples-apples test and doesn't prove that
the Intel RAID hardware or firmware in a Z370, or comparable modern full function motherboard, are not failing.
Can you run the test on a z370 motherboard?
Thank you for your reply.
The RAID structure is stored in the hard drives. For this reason, performing a clear CMOS should not remove the RAID structure from the hard drives. In other words, it should affect the BIOS settings, only. The best course of action would be to contact the motherboard manufacturer so that they can attempt to replicate this issue using the exact same motherboard model. If they find that this problem is the BIOS of the system, then they should fix it. If not, then they will definitely report it (business-to-business) to us to fix it as soon as possible.
It is worth mentioning that we attempted to replicate this problem using Intel® NUC to confirm that this is most likely a BIOS issue.
> The RAID structure is stored in the hard drives.
I know. The motherboard BIOS would not write to a hard drive for any reason.
The RAID Controller routinely writes to the hard drives. In fact, this happens when the RAID stripes are created, the RAID fw writes to the hard drives.
Do you really believe the motherboard BIOS is just randomly destroying data on the hard drives?
In your ignorance, you have poopooed the NUCs, but the fact is, they are NOT stripped down boards; they are as full-featured as any of your 3rd-party motherboards and they certainly host the same chipset and BIOS support for RAID and Optane that these motherboards do. The fact that the various NUC BIOSs do not have this issue tells us that the bug is in the 3rd-party boards' BIOS implementation. This is not opinion; this is a proper, logical conclusion.
Bottom line, Wanner cannot escalate this issue when he is staring at proof that directly contradicts your reports. He is correct; the next-step that is required is for you, the owners of these boards, to go back to these 3rd-party manufacturers and tell them that they need to look closely at their implementations (or to have their IBV do so). Now, if they do find that they think the issue *is* in Intel's bailiwick (or they simply do not understand what is going wrong), they, as premiere customers, have paths to rapidly escalate these issues back to Intel and directly to the groups(s) in question.
At the same time, let me say this (hopping up on my soapbox): It is completely inappropriate for these manufacturers to be telling you guys to bring these problems to Intel. That's just them avoiding having to do their jobs. I honestly do not understand how you folks can continue to purchase products from companies that are obviously not interested in providing their customers with the quality and support that they deserve. So often folks end up coming to Intel because they are the only ones who will even listen to their problems. Actually, now that I think about it, I think I do understand. It's like flying. The airlines all uniformly treat everyone like livestock; squeezing in as many as they can. Folks are so used to it that being livestock has become their normal. Oh, they complain about it right and left, but they don't do anything about it the way that they actually should, namely with where they spend their money. Worse, if an airline breaks away and tries to do the right thing, the others all gang up on it and either destroy it completely or force it to adhere to their definition of normal. Hopping down off my soapbox now...
I checked your login profile, it says you used to work for Intel in BIOS development.
I have searched for a while, but cannot find anyway to determine the RAID controller hardware and firmware(NOT device driver or IRST) version of a Z370 chipset.
Is the RAID controller hardware part of the Z370 bridge chip itself?
How can I display and upgrade the RAID controller firmware?
PS Just to be clear, any device driver or IRST software runs after the OS is loaded. I am looking for the firmware that runs when you do a CTRL-I during boot.
Yes, I did (amongst *many* other things), but I do not consider myself to be a "BIOS Engineer", per se (that would be insulting some of the amazing BIOS experts that I worked with).
Yes, it is part of the Z370 chipset (is a feature of the PCH component).
I believe (but don't hold me to it) that this firmware is updated as part of the larger firmware updates that are loosely referred to these days as BIOS updates. I base this on seeing RAID/AHCI version entries in the BIOS Release Notes for various Intel NUC products. I will see if I can hit up one of these amazing BIOS experts and get a confirmation of this...
Oh, I just noticed your P.S. When you do a CTRL-I, you are invoking the RAID OpROM. This is definitely part of the larger firmware packages (BIOS Updates) that you receive. Your vendor's BIOS Release Notes should tell you what version is being included. Some BIOSs have a status display that includes such version numbers. Now, understand that an OpROM (Option ROM) package adds an extension to the BIOS; it is not standalone firmware like you would see executed by Embedded Controllers (ECs) like the Management Engine (ME) or that included in newer Super I/O (SIO) components.