March 23, 201313 yr I'm about to throw my entire system against the wall. This is my second go at getting unraid to run in ESXi. I have 3 controllers...2x AOC-SASLP-MV8 and a port onboard Marvell controller with the same exact chipset as the MV8s. I am able to disable the INT 13h on the onboard controller without issue. My problem is with the MV8s. I am able to set INT 13h = Disable, but, after a reboot they revert back to Enable. Both of them!!! Does anyone have any idea what the hell is going on? I am going to pop one of the MV8s into another PC and try to disable it there. Maybe the onboard controller is messing with it? Is there anything that I need to do in the BIOS to make this stick? TIA! John
March 23, 201313 yr Author I need more beer! So...apparently...I had to first disable the onboard Marvell SAS/SATA controller. I could then set INT 13h = Disable on each of the MV8s and it stuck after a reboot. The real test of course was when I re-enabled the onboard controller. Thank god the MV8s still retained the config! Now to see if this solves my issues. If not, I will be posting again. LOL John
March 23, 201313 yr Author Still having the same issues...gui non-responsive...seeing "Disabling IRQ #19" (and #16 and #19) in the console. I ended up disabling the onboard SAS/SATA controller and everything is now working as expected! My buddy gave me a Dell Perc H310 card but since it has an LSI chipset I believe I will need to flash it to IT Mode. Going to start reading now. John
March 23, 201313 yr Based on what I read by another user (You'll want to get someone who knows what INT13 is, I just know it's a way to control the disks, nothing more), all disabling INT13 does is not initialize the drives until the BIOS passes over to the first boot device (E.G. unraid) and this stops accidental booting into non-bootable drives. If the above is correct, just leave INT13 on and if you ever have a problem with booting, check your boot order. If it's not, then can someone tell me what it really does?
March 23, 201313 yr Author Based on what I read by another user (You'll want to get someone who knows what INT13 is, I just know it's a way to control the disks, nothing more), all disabling INT13 does is not initialize the drives until the BIOS passes over to the first boot device (E.G. unraid) and this stops accidental booting into non-bootable drives. If the above is correct, just leave INT13 on and if you ever have a problem with booting, check your boot order. If it's not, then can someone tell me what it really does? Thx Automatic. My ESXI/unRAID has been stable thus far so I am not going to mess with it. I am now back to trying to find out how to flash the Dell Perc H310 that I have to IT Mode. As far as I can tell, it has the same LSI chipset as the M1015 so I can follow thoe instructions. However, I have hit a brickwall. I need the SAS Address and the H310 does not have a sticker on it with this information. Is there any other way to get it? I looked in the BIOS Utility (CTRL+R) but don't see it any where in there. Maybe ESXi (or a putty command) will tell me? John
March 23, 201313 yr Author So, I pulled the heatsink off of the LSI chip on the card and this is what I see... LSI 500002730 LSISAS2008 1221 EAP21C82 Taiwan My question...is the SAS Address a combination of 500002730 + EAP21C82 = 500002730EAP21C82? John
March 23, 201313 yr No, that's too long - it should be 16 characters. Have you tried getting it out of the card prior to flashing? sas2flsh -listall will list adapters and their current SAS ID's. Not sure what a Perc H310 is originally though and whether this would work. Perhaps it's worth looking for some Dell software for it that might show you the current SAS ID if sas2flsh doesn't do the trick.
March 23, 201313 yr Author No, that's too long - it should be 16 characters. Have you tried getting it out of the card prior to flashing? sas2flsh -listall will list adapters and their current SAS ID's. Not sure what a Perc H310 is originally though and whether this would work. Perhaps it's worth looking for some Dell software for it that might show you the current SAS ID if sas2flsh doesn't do the trick. I didn't even make it as far as the poinnt where you have to provide the SAS Address. All of my attempts to flash the H310 in teh sam e manner as the M1015's have failed. I even contacted Dell support to see if they had any information. The tech was very helpful but was unaware of the ability to put that particular card into IT Mode. I think I need to flash with an actual LSI firmware (not Dell) to do this but everything I downloaded didn't work. So, if someone could point me to the correct files, that would be awesome. Option #2: What is a good 4 port SAS/SATA card that plays well with unRAID inside ESXi? If worse comes to worse I'll just buy an M1015 but I really only need 4 ports to replace the ones that I had turn off on the MB (Norco RPC-4220 so I am limited to 20 drives). FYI...the theird PCIe slot on the MB I am using is x4 in case that matters. John ps. Just to make sure I wasn't going goofy, I booted directly into unRAID (no ESXi) and none of the drives that were attached to the H310 were visible.
March 24, 201313 yr Author The saga continues...but in a good way! I have given up on trying to flash the Dell Perc H310 to IT Mode using an LSI firmware. I just couldn't find a working combination. So, I decided to try and work through the onboard SATA issue. For those unfamiliar, I planned on running unRAID (RC11 at the time) in an ESXi VM with 2 AOC-SASLP-MV8 cards + the onboard SAS/SATA RAID controller (same exact Marvell chipset as the MV8s) to give me 20 drives...perfect for my Norco RPC-4220. Anyway, I went through all of the normal routine required (Mv8 hack) to use the MV8s in passthrough mode in ESXi...but...I forgot to do it for the onboard controller. To my surprise, unRAID seemed completely happy. I let parity check run for about 30 minutes with no errors. Then I remembered that I had not performed the MV8 hack on the onboard controller. So, I stopped the parity check, stopped the array, powered down the unRAID VM and aplied the MV8 hack. I started the unRAID VM again and almost immediately I started to see the "Disabling IRQ #" messages in the console! Within 10 minutes, the webgui would become unresponsive. So, I went "Hmmmm". I decided shut down the unRAID VM and remove the MV8 hack for the onbaord controller from the VMX. I started the unRAID VM and watched the console...no nasty IRQ messages or ESXi events! I logged into the webgui and started a parity check. The parity check is now 20% completed and runing @ 118MB/s!!! W00t!!! (fyi...I have never seen speeds as high as this). I'm pretty certain that I would have seen the IRQ messages by now. I won't think I am completely out of the woods until unRAID has been stable for a few days. Beyond that, I still need to keep an eye out for ESXI PSODs. From memory, these did not show up until about 30 - 45 minutes after ESXi was satrted without the hacks. The fact that the onboard controller is not using the hack still worries me a bit in regards to PSODs. I plan on posting this in the Atlas forum since I know that gets a lot of attention and may help someone else. John
Archived
This topic is now archived and is closed to further replies.