Issue with GA-EP45-DQ6 board and two SX4060 RAID card.

[thearm]

Hello. I posted this question here since my problem is more related to compatability with my RAID card and motherboard and not so much a storage issue. I hope this is correct...

Problem: I just purchased a brand new GA-EP45-DQ6 board. I'm trying to run two Promise SX4060 PCI RAID cards in the only two PCI slots. If I put two SX4060 cards in, one of the cards will beep non stop and won't load the SX4060 BIOS with an error something like "DRAM not supported. The BIOS will not load". If I remove one of the two SX4060 cards, the card's BIOS will load and the beep will stop. BUT, in Windows, I cannot install the driver for the SX4060 card. It will act like it installs and prompt me to reboot. but when I reboot, I will have an exclamation mark on the card in device manager and I get, I think, a device code 10 error. This is on a fresh install of Windows XP and I have three SX4060 cards (one brand new) and all of them perform the same way. The two SX4060 cards I"m trying to install are currently working fine in my 8KNXP board.

I tried updating the BIOS on the motherboard and turning the board speed down from turbo to normal (I think it's called normal). I tried assigning an IRQ to each of the PCI slots. I've tried three different types of system memory and tried two different types of memory on the SX4060 cards.

I already went to Promise and they are no help. They don't even want to try to figure out why this won't work. I also currently have a pending question with Gigabyte on the issue and I'm waiting for a response.

Does anyone have any idea why not even one SX4060 card will work? The card supports both 33 and 66 Mhz bus speeds and the motherboard does as well. Are the PCI slots in this board a standard I'm not familiar with? Everything in the manual says they are normal PCI slots. Does anyone think this will work if I use a 20 pin ATX power supply? I ask that because I read the extra four pins are for power to the PCIe slots so I'm thinking maybe it is a power issue on the bus. I have seen power issues cause a drive to not be install properly in Windows.

Thanks again,

Thearm

 

[thearm]

Bump

 

[thearm]

bump

 

[thearm]

bump

 

[bilbat]

Well, it looks like no one else is going to tackle this, so I suppose I'll give it a try - but I certainly won't promise much (pun intended)!

I went over the Promise knowledge base, and frankly didn't find much about these cards, and nothing at all about using multiple cards. I believe your problem has to do with the info on pages 49 & 50 of your manual. Before I attempt to write something up, that I might avoid insulting your sense of level of expertise, I have a couple questions:

How much do you know about computers' interrupts? Do 'interrupt controller', and 'interrupt service routine' mean anything to you? (Much of the answer depends upon your age, and how long ago you started 'fiddling around' with computer hardware...) I just need to know at what level to start discussing this, to have it make some kind of sense.

 

[thearm]

lol Wow someone actually responded! Thank you sir. I usually hate puns (In the news) but that was pretty awesome.

I've been a computer tech (Everything from dot matrix printers to servers) for Northrop Grumman and IBM for over seven years. So I would say I'm very experienced w/ hardware and software (not programming). So I've been actual professional for seven years. Fiddling w/ computer probably since the Apple II and Commodore 64. But, I wouldn't say I'm very experienced with IRQ's but I do know what they do. I have dealt with IRQ conflicts quite a few times in the past with mixed success.

It's been a long time since I thought about this issue, but I do remember messing w/ the IRQ's in the BIOS and putting the cards on their own IRQ channel. Weather I did that right, I'm not sure. 'interrupt controller' does mean something to me but 'interrupt service routine' sort of does not. I think I can imagine what it means.

Thanks again. I look forward to a response!

 

[bilbat]

Ah-Ha! OK - now I have a starting point. Might take a look here, for a non-technical, non-specific re-hash, while I try to come up with something useful.

My problem is that, while I know a lot about the mechanics of interrupt management from the 'bad old days', when we had to struggle endlessly with it, and the occasional use I have for embedded CPUs - the new generation of interrupt controllers/mechanisms are so smart, that we never have to even know about them... While I've seen the BIOS page GB uses for this stuff (shown on page fifty-seven of your particular MOBO's manual...), documentation is minimal, and I've no experience of what the mechanics of setting it up are - so I need to dig a bit! It appears that (from the Promise manual, page forty-nine) they are looking for "IRQ 14 and/or 15"; so it may be as simple as going into that BIOS page and assigning those interrups to a slot each, then <F10> to save changes and reboot, followed by reattempting to install the driver. My system doesn't show anything on either of those IRQs, and I have a crapper-load of stuff in this thing...

You can get a look at where yours are by opening Device Manager, and doing 'View' > 'Resources by type', and then opening the resultant 'IRQ' item:

The number you are interested in is the decimal one to the right in parentheses...

 

[thearm]

lol, man it was fun reading the thread at your first link! Yes, that all corresponds with what I know ( learned in collage : / ) about IRQ's.

This weekend, maybe Sunday, I'll get my GB manual, pull up this thread, and tinker w/ it once again. If you have any ideas, post them in here and I'll look at them on Sunday. The first thing I'll do is try to assign IRQ's 14 and 15 to those PCI slots.... But now that I think about it, I don't think I was able to before. I think 14 and 15 couldn't each be assigned to a PCI slot. I had to assign them both to one slot or the other. I think they where shared. Like I said, it's been a year since I messed w/ this setup so I could be wrong. But still, I'm surprised I couldn't use at least one card in this motherboard. Plus, I've had every single slot used up on my 8KNXP Gigabyte board (two slots where SX4060 Promise cards) and I didn't have any conflicts. I know that doesn't mean much since they where different boards but I'm still surprised.

But anyway, I'll give it a try now that I have an EXPERT to talk to... lol No really though, thanks for your attention. If I can get this resolved, I will have one server running instead of two.

 

[bilbat]

Awww - now you've gone and made me blush [:huntluck:2]
EXPERT - I don't know - OLD, I can claim [:bilbat:6]

I took a bit of time to dig a little, shot some pics, may have some ideas - random thoughts, scientific wild ass guesses, flashes of 'where things are', and a couple (reasonable, I hope...) conjectures - kind of reminds me of string theory!

First, as another re-hash, I thought I'd list the old interrupts - I think your last board may be old enought to use (or emulate) the original 8259 PIC (programmable interrupt controller):

Master 8259
IRQ0 – system timer
IRQ1 – controller
IRQ2 – cascaded to slave 8259 INT line
IRQ3 – serial port COM2 and COM4
IRQ4 – serial port COM1 and COM3
IRQ5 – parallel port LPT2
IRQ6 – floppy disk controller
IRQ7 – parallel port LPT1

Slave 8259
IRQ8 – real-time clock (RTC)
IRQ9 – no common assignment
IRQ10 – no common assignment
IRQ11 – no common assignment
IRQ12 – PS/2 mouse controller
IRQ13 – math coprocessor
IRQ14 – hard disk controller 1
IRQ15 – hard disk controller 2

The old stuff ended with WinME - that was the last rev that didn't support shared interrupts and the newer apic (advanced programmable interrupt controller) standard - which is more of a bus than a discretely wired solution.

I'm going to repeat the pic I posted earlier, along with the lower numbered IRQ's, toward the top of the list - everything in between (a looong scroll...) is claimed by the ACPI subsystem:

Then, it dawned on me where to find some more IRQ info - the POST screen:

This kind of worries me, as the two we're interested in, 14 & 15, show up not only as drive controllers, but appear in a few other functions as well - don't know what to think of that, nor have I a guess as to why the POST and Device Manager display info that differs in several respects...

First place I went to look into adjusting this is the BIOS' "PnP/PCI Configurations" page - note that it only shows two items, lets you pick an interrupt to correspond to a slot # - seems simple, let's call it "procedure A - slot assignment"...

Now - the GIGABYTE board destroyers' club secret handshake: go to the BIOS' main page, and do a <CTRL><F1>

This is the keystroke to 'unlock' the BIOS elements that aren't normally visible or accessible. Note the new elements:

Now, if you change the "Resources Controlled By" item from "Auto" to "Manual":

...the "IRQ Resources" item changes color to become available:

...hitting <ENTER> there gives you another possibility:

...we'll call this one "procedure b - IRQ reservation"...

As these are the two tools we have, I guess if I were doing this, first, I'd try one, save, reboot, test - then the other rinse, lather, repeat... But, I'm thinking a combo might be possible/requisite too: might have to do the "IRQ reservation" first, then save, exit, reboot (to 'grab' the interrupt away from whoever is currently using it); then do the "slot assignment" to actually 'hand out' the interrupts to your controller boards.

It may be easier to get one board working first - then you're sure that the problem isn't a conflict between them - can always add the second once the first is working. 'Nother possible strategy is to start by disabling every single thing in the BIOS that you aren't actually using - I forgot to ask if you intend drives that are hooked up to the MOBO controllers, in addition to the ones off the Promise boards. Com port, parallel port, 1394 - anything that can go, should - before you try the interrupt adjustment/testing...

 

[thearm]

Wow, that's a lot of great information. I had no idea that second option up there existed (ctrl+F1). That may be what I'll have to do since I remember trying step 1 and not getting anywhere. This doesn't seem like a compatibility issue to me since with one board in, I can see the Promise card boot screen. So I feel this is possible to get working. This is a great place to start.

I have three RAID1 arrays currently operational in this PC. I have to back up their data before I get started. I'll report back later today since the backup may take a few hours.

Thanks Bilbate! I knew I was in good hands!


EDIT:

Ok, I didn't want to mess w/ IRQ 15 because my Intel RAID controller was using that. So the first thing I did was change the PCI 1 slot to IRQ 14 > shut down the PC > put in the the promise card > booted to Windows normally > but the device manager states the device can't start (same issue I had a year ago). Even if I install the driver and reboot, 'cannot start.' I went back into the BIOS and did the ctrl F1 > left PCI 1 assigned to IRQ14 > set the IRQ assignment to manual > put IRQ 14 on 'reserved' (was that right?) > saved and reboot > same issue.

But, I'm thinking a combo might be possible/requisite too: might have to do the "IRQ reservation" first, then save, exit, reboot (to 'grab' the interrupt away from whoever is currently using it); then do the "slot assignment" to actually 'hand out' the interrupts to your controller boards.

So are you saying here I should do step 2 above first (set IRQ14 to reserve, reboot) and then step 1 (simply set PCI 1 to IRQ 14 in the main PCI Configurations window)?



I feel like the BIOS has no problem using at least the one Promise card since I can get into the cards setup and define an array in the cards BIOS utility. Then again, when I use two card, I hear that constant beeping sound throughout the boot process, so, maybe not. I feel like Windows has the issue. Doesn't the BIOS hand off IRQ responsibility to the OS after POST? It's been a while since I've had to deal w/ a problem at this level so I can't quite remember.

PIC of my IRQ's (after both of your steps where done):

 

[bilbat]

Hmmph - dammit!

Sorry for the delay, I've been on-line for a while, but still digging. The current stuff is xAPIC2; wanted to see what I could find about the original APIC structure and handling - pulled up an old copy (P4-P6) of Intel's System Programming Guide - learned a lot, but nothing we can use (again, eerie similarity to string theory!) to fix anything.

So, if I'm understanding you correctly, the end picture is after having done procedure B, followed by save & reboot, and then procedure A, and again a save and reboot?

Just for giggles, let's try this:

Shoot me a pic of the original POST display of the assignments with nothing done in the BIOS; then a pic after (AACKK! ...just dawned on me - I mean picture - dumb to use pic here, as it's also programmable interrupt controller!!) doing just A (to one slot only to IRQ14), and one after doing just B, then another after B followed by A. I want to see if anything is changing at all! Probably wouldn't hurt to capture the top & bottom of device manager IRQ section for each situation as well.

One of the things I'm hunting in old docs for is info re if you have to move the disk controller to a different IRQ (say, 10 & 11), is this possible/practical - and how??

I think the sense of this, and the etiology of the errors makes sense - unless an IRQ is handed out by the slots, the boards don't know 'who they are' (and where); with one card in, the onboard memory still maps OK, so it can find the on-card BIOS; when you get two cards in, I'm betting the proper sequence is that the card 'finds' its IRQ, and then, based on that as an ID, one card maps its BIOS to address xxxx, ant the second card maps it to yyyy... As these cards can't tell who's who, when they're both in, the cards' BIOS aren't at different addresses - they're mapping on top of one another, which is the likely cause of your "DRAM not supported. The BIOS will not load" message...

 

[thearm]

Ok, I reverted the BIOS back to normal. I then reserved IRQ14 and rebooted to Windows > I then reboot back to BIOS and assigned IRQ14 to PCI slot 1 > rebooted with no changes.

OK, Images from top to bottom are as follows:


Top half of device manager after IRQ was assigned to PCI slot 1 (Middle part of this list was all the same)

Bottom half of device manager after IRQ was assigned to PCI slot 1

ACAPI before any changes

ACAPI after reserving irq 14

ACAPI after assigning irq 14 to pci slot 1

 

[bilbat]

(links were broken - not showing; added the 'i.' prefix, & '.jpg' to end - pictures!!)

 

[thearm]

If we come up w/ a resolution for this, I would implement it. But if we don't, that's ok also. I need to get away from IDE interfaces anyway. So, don't spend to much time on this unless you have time to spend. I appreciate you help thus far.

EDIT:

Note in my last few screenshot IRQ 14 is not being used at all. Then note in my very first screenshot ( From 02-13-2011 at 07:54:39 AM) it is being used. I went back into the BIOS and set the IRQ Resources back to PCI instead of Reserved. I think this freed up IRQ 14 and allowed it to be used by the RAID card. The when I booted up, the RAID card is now using IRQ14. So, that a positive step I think. Still, when I boot into Windows, no change.

I'm at the latest BIOS revision just so you know. I've tried resetting the BIOS to it's defaults, fail safe defaults and set it to normal instead of turbo.

Maybe that will spark an idea. Let me know what you think.

EDIT:

Are 2.3 PCI slots backward compatible with 2.2 cards? Because the Promise manual states the slot has to be 2.2 compliant. I would think I wouldn't be able to make it to Windows or the cards BIOS if that was the case. I can't find if the slots in this board are 2.3 PCI. I'm still looking. They are 33mhz according to the manual.

EDIT:

Check out this link: http://support.microsoft.com/kb/314068

What I found interesting was the third and last paragraph. Maybe now that I set an IRQ to the PCI slot, all I need to do is reinstall Windows? What do you think?

EDIT:

Found a few more ideas to try but I don't know if I will. I'll probably try installing Windows with my IRQ14 associated w/ the PCI slot. But one idea I found was to put a /pcilock switch in the boot.ini file. From what I'm reading, it will force Windows to use the BIOS's IRQ settings. Another was to use a 'standard PC' for my ACPI in the device manager under the 'computer' tree. But, that doesn't look like a good idea from what I'm reading. I have data on RAID arrays on this PC to think about.

EDIT:

With my PCI slots bound to IRQ's 14 and 15, I tried to reinstall Windows XP with no change.


Let me know if you have any ideas. I feel like this may be possible.

 

[thearm]

bump

 

[thearm]

bump