Forum Home
Press F1
Thread ID: 58008	2005-05-18 12:14:00	Cannot boot anything if onboard SATA is given presedence over controller card SATA..	Growly (6)	Press F1

Post ID	Timestamp	Content	User
356461	2005-05-18 12:14:00	I have had enough. I have a server. It uses an Athlon XP 2800+, with an Asus A7V600 motherboard. That's right - it has an onboard VIA 8237 SATA controller. I also have a RAID 5 array of four 200GB Seagate SATA mofos, sitting on a Promise S150 SX4-M RAID Controller. Untill yesterday, I was running the operating system (Windows Server 2003) off a 2.1 GB Quantum Fireball (IDE) - while using the 600GB Array for storage. Everything worked fine, albeit a little slow. I then ordered a WD Raptor to speeds things up a bit, and intended to install the operating system on it... and that's where the fun begins. I can not, for the life of me, get the machine to boot ANYTHING past the device listings following POST. This is only if the machine is set to boot from the onboard SATA controller before the add-in Promise SATA controller. It gets as far as commencing the bootstrap load out of BIOS, but then stops. (Side note: That's the configuration in which it simply must work, because I do want to boot from the single Raptor, and not the four Seagates.) For example, the following things happen when the system is configured to boot from onboard rather than add on SATA: It goes up to, but not including, the Windows Server 2003 screen (with the scroll bars). That is to say that the screen just goes blank. It starts loading the WD data lifeguard tools, but freezes with no control of the mouse and no windows loaded. You cannot configure the onboard SATA controller when the system is configured as I have said - no commands work in the User Configuration menu, except for Esc. It will start the Windows Setup from a CD, but will freeze promptly after displaying "Setup is inspecting your computer's hardware configuration..." and going blank. It will tell me that NTLDR is missing should I leave it to its own devices. I've been looking around google, reading manuals, staring at BIOS screens and itching my arse for hours. WHY?!?! Why can't I boot anything if the machine is set to boot from the onboard controller first?! In the manual, such problems are blamed on ISA cards requiring IRQs that the Promise controller cannot share. Considering the fact that I don't have any ISA cards, and that all my devices are *supposed* to be PnP (on the mobo), this is ruled out. That's pretty much the complete extent to which I can find written documentation. I've tried: Changing the BIOS's PNP OS setting to "no" and "yes". Changing the slot that the controller is in, in accordance with the motherboard manual's IRQ sharing schema. Disabling unnecessary onboard devices and stealing their IRQs (i.e. LAN, Primary IDE, USB) Overclocking. Assigning IRQs manually Assigning IRQs manually and reserving them at the same time Praying Changing the channel the hard drive's are in Using the WD Data Lifeguard tools, which promptly failed to recognise the onboard controller. This was because I had set it to boot from the addon controller temporarily, so that it would boot into the Data Lifeguard disk in the first place. Installing the OS as on the Raptor when it acted as a secondary volume (i.e D: Drive). Expecting it to actually work, I was greeted with a windows "your disks are misconfigured you fat bastard" error. I forget what else I've tried. It's been 4 hours. Please. Please please please please ***PLEASE!!!!!*** Does anyone know what could be causing the system to freeze while booting an Operating system of any kind - while the system is set to boot from the onboard controller as opposed to the PCI slot controller? Given the nature of PnP, it is difficult to determine the order in which cards are booted, but I set the option in BIOS that says "boot from onboard ATA first"! Gar! If you have bothered to read this far, I commend you whole heartedly. I apologise, it is difficult to grasp my situation, and I thank you for endeavouring nonetheless.	Growly (6)
356462	2005-05-18 21:05:00	Well the board doesn't have the best sATA BIOS. The older ones are fiddly. The newer ones make it much easier. Doesn't help you - I know. So I would (if you haven't already): Take out the raid drives and install Windows on the new one while its the only drive. Then put the raid drives back.	pctek (84)
356463	2005-05-19 07:01:00	Thanks for the reply, I'm just about to try that - will get back to you on the outcome. Thanks again for taking the time :)	Growly (6)
356464	2005-05-19 09:15:00	It didn't work, same issue.	Growly (6)
356465	2005-07-03 22:37:00	Hi Growly I am having the same issue. Well, very similar one. I used to have the same Motherboard and I have double 160 G SATA disks configured to work with onboard SATA (as mirrored raid). So it was working fine. Today I have bought Promise S150 SX4-M RAID Controller with 4 Hitachi 250GB hard-disks. the trouble is: - in order to run the POST of Promise controller, the option in the BIOS must be set to N for the 'give preference to onboard SATA'. But in this case the onboard SATA will not be the device that will boot... which means that I cannot boot my OS. - so I set the above mentioned value to Y(es), and I still can boot the Windows just fine. But in this case the Promise PAM utility is behaving crazy and the Arrays that I create are not visible to the DeviceManager etc. Now, I also found some posting on the Promise support site here: www.promise.com It indicates that the POST event for the Promise controller must POST during motherboard POSTing. But since in my configuration (with Y) the Promise BIOS is not even coming up, I am not sure that this POST is performed during boot. But ... how could I possibly configure the BIOS so that it makes POST on other PCI devices even with my option set??? I am not an expert in hardware configuration, but I guess that the Device/Controller... configuration is then shifted somehow for you, which makes the windows not bootable and mine configuration not able to actually configure anything from the Promise controller. Any ideas on that? Ivan.	ivanoe (8154)
356466	2005-07-04 00:40:00	Growly, I personally haven't had much experience with SATA RAID but I would do the following: Start from scratch: disconnect all drives, then plugin IDE reset the BIOS to default using the jumper (or screwdriver) - which should disable onboard as well install the OS plugin Promise controller - make sure OS sees it ok and boots after its installed install Promise drivers (once again doublecheck the O/S boots after this) reinstall SATA drives reset RAID config Ok it sounds like the long way round, but sometimes its got to be done this way	Myth (110)
356467	2005-07-04 01:56:00	sounds like youve done everything under the sun.... however something silly to try... why not set it to boot off the raid first, with no OS or boot flag it should just skip it and go onto the other drive and boot of that. does the system see a lan card rom at all?	tweak'e (69)
356468	2005-07-04 05:52:00	How many threads did I start about this? I forget sometimes. Anywhonani - I still, to date, haven't solved this problem. Thanks for your suggestions Mythix and tweak'e, unfortunately I'm afraid they won't do much :( Mythix, I had tried what you suggested - the result was an accessible array, but no Raptor. Back to square one, huh? It was fast becoming clear, what I should blame... I thought of what you had said, tweak'e, but unfortunately the Promise Controller requires that one array is bootable at all times, unless there are no drives. I gave up trying to fit it into my main desktop, primarily because it was so big, and secondly because I was swamped with other issues at the time. However, numerous reads and rereads of the exceptionally large manual since that time gave me the courage to attempt it again, this time in my amazing server(s) of doom. But alas, the same problem. I then launched an extensive investigation into the whole thing. The reason it breaks is because the onboard SATA controller is not actually on the same INT as any of the PCI slots, and so booting from it is nigh on impossible with other cards installed. Takeing due care to note the PCI slot INT levels, I bought a $50 two port SATA controller (with the same chipset as the onboard, how ironic) and plugged my drives into that. Problem solved. The machine behaves as it should; it boots from the first PCI device in the INT queue, and that just happens to be the el-cheapo controller. I was never able to remedy the situation, and it became apparent within due course that this was not infact possible. The manual shows that the PCI slots, for my Asus, were INTs A, B, C & D. But the onboard was H. When set to boot from onboard, it would seek H but would hit B or C, and would freeze there - confused. I blame the BIOS.	Growly (6)
356469	2005-07-04 17:11:00	Have anyone tried asking support from ASUS? Or does anyone know if it would be possible to get another BIOS onto this MB? ivan	ivanoe (8154)
1