Well, I seem to have a disaster on my hands. I recently upgraded/rebuilt my main machine, using a Gigabyte N680SLI-DQ6 mobo. I specifically choose this board because it was:
1. state of the art
2. SLI capable
3. 3 PCI slots positioned correctly
This board allows me to have two 7800GTX cards in SLI configuration, and all my Creamware cards installed together, which was the goal. The machine serves as a DAW but also as a game development platform.
Unfortunately, after installing XP Pro and all the related drivers, I discovered that the machine simply hangs after a while. No crash, no blue screen, but the keyboard and mouse freeze, as well as all visible activity. It usually takes between three and five minutes to freeze. Very difficult problem to track down.
Well, one of the first things I tried made the difference. If SCOPE isn’t running, everything works just fine. Start SCOPE, wait a few minutes, and freeze…
First of all, with SCOPE not running, I have executed several different stress tests, all of which pass with flying colors. Prime 95 runs in “torture test” mode for many hours with no errors. Memtest – no errors. BurnInTest – no errors. The system behaves flawlessly, running games, all kinds of large complex programs, everything I can throw at it. Until I start SCOPE. Then all I have to do is wait a few minutes, without doing anything, and it freezes. No error messages, nothing in the event log.
I’ve tried SCOPE 3.1, 4.0 and 4.5. So far, there is no difference. The video cards are on the PCIe bus, so they don’t even share a common bus with the Creamware cards. I’m clueless as how to proceed from here, so I’m desperately hoping that someone out there has confronted and resolved this problem.
I have quite a bit of money and time invested in this upgrade already, and it looks like perhaps the advancing technology of almost everything has finally become incompatible at some level with my aging Creamware boards. I hope this isn’t the case, but I fear the solution to this problem may be to abandon Creameware, or to invest even more money and build two computers. Neither solution appeals to me. Anyone?
Many thanks in advance.
PS - I'm reminded again that there is no specific XP driver for Creamware cards, only 2K and 98. Has this limitation finally defeated me?
A serious disaster...
Removing the cards and cleaning the gold pci contacts as well as the stdm connectors helped me to fix serious instability issues. Use pure ethylic alcohol or special contact cleaner, other things leave residues. I also need a fan blowing directly on my 3 cards for my system to work normally. I was having all kinds of problems before Gary suggested this simple cleaning, thanks mate!
E
E
I doubt the 'win2k' driver is the sole source of your problems, although it does have its ups & downs for many users. SLI has quite a bit of overhead to begin with, and Nvidia/Ati drivers are known to be set to hog bus bandwidth. Tack in the fact that the only known truly 'stable' nvidia platform for dsp cards (not just scope) was nforce3. Nforce4 was known to work for some and not at all for others, and now that particular motherboard is based on yet a new Nvidia chipset and was also described by several tech sites as having "more onboard peripherals than we've seen from any other desktop motherboard".
Creative Labs is 100x the size Creamware ever was and their 'WinXP' branded & registered drivers were still bad enough that many people prefer the default set that ships with WinXP.
In any case I suspect your issue might have something to do with the amount of peripherals you have installed in your system. The usual place to start with problems such as these is to see if you can identify potential hardware conflicts. Posting up a list of IRQ's is one good starting point. Also if there are any specific tasks that seem to result in lockup it's good to note these as well. There's a big difference between "Cubase crashes", "Myspace music players crash my pc" or media Player, gigastudio etc.
Also I recommend you disable any of the onboard stuff you may still have active and are not using (unless of course you've done this already).
Creative Labs is 100x the size Creamware ever was and their 'WinXP' branded & registered drivers were still bad enough that many people prefer the default set that ships with WinXP.
In any case I suspect your issue might have something to do with the amount of peripherals you have installed in your system. The usual place to start with problems such as these is to see if you can identify potential hardware conflicts. Posting up a list of IRQ's is one good starting point. Also if there are any specific tasks that seem to result in lockup it's good to note these as well. There's a big difference between "Cubase crashes", "Myspace music players crash my pc" or media Player, gigastudio etc.
Also I recommend you disable any of the onboard stuff you may still have active and are not using (unless of course you've done this already).
Wow, I love this forum. Such good ideas and such quick response.
I will definately pull the boards and clean everything, the mobo is new and shiney but the Creamware boards are old and dusty. Those contacts probably have accumulated a layer of non-conductive something-or-other. Thanks.
Let's see, most but not yet all of the unused on-board devices are already turned off. There are a few SATA ports I can still shut down.
It's true that the SLI configuration is a bus hog, but it's also on a separate bus from the Creamware cards, so I doubt that's the problem. I will investigate to the extent I'm able.
IRQs - Well, XP is posting no conflicts, although I have been perplexed for years why multiple cards are loaded on to the same IRQ when others are left completely unutilized. Some mobos give you more control over this than others, the one I'm using is fairly primitive in this regard (surprisingly, it seems to have everything else but the kitchen sink).
There is no particular process which seems to cause the freeze. In fact, I haven't even tried audio oriented applications like Cubase - it freezes regardless of what tiny little stupid app I'm using.
Here is what I have done for the current test (still running):
I updated the BIOS to the latest released version (not beta), and in the properties pages of Device Manager I unchecked an option for the Creamware boards that said "reset when idle". I'm not exactly sure I understand the purpose of doing something like that, but in any case it's not being done now. The 2k drivers are installed, but SCOPE isn't running. I'm stress testing the system (100% CPU utilization, 100% RAM utilization) and it's been running for over an hour so far without problems. I'll let it run several hours, and if everything is OK, I'll start SCOPE and run the same stress test.
The Creamware 2k drivers may still be adequate. My intuition tells me that it is the SCOPE app itself which is causing the problem. I'll try setting it to 2k backward compatability mode in its properties page and see if that makes a difference.
Keep those ideas coming, I need the help! And thanks.
Husker, no MIDI ports in use. In fact, the Creamware system has almost no load on it, less than 20% of the DSP power is utilized and I'm not running any audio through it. Just the presence of SCOPE running seems to cause the freeze.
I will definately pull the boards and clean everything, the mobo is new and shiney but the Creamware boards are old and dusty. Those contacts probably have accumulated a layer of non-conductive something-or-other. Thanks.
Let's see, most but not yet all of the unused on-board devices are already turned off. There are a few SATA ports I can still shut down.
It's true that the SLI configuration is a bus hog, but it's also on a separate bus from the Creamware cards, so I doubt that's the problem. I will investigate to the extent I'm able.
IRQs - Well, XP is posting no conflicts, although I have been perplexed for years why multiple cards are loaded on to the same IRQ when others are left completely unutilized. Some mobos give you more control over this than others, the one I'm using is fairly primitive in this regard (surprisingly, it seems to have everything else but the kitchen sink).
There is no particular process which seems to cause the freeze. In fact, I haven't even tried audio oriented applications like Cubase - it freezes regardless of what tiny little stupid app I'm using.
Here is what I have done for the current test (still running):
I updated the BIOS to the latest released version (not beta), and in the properties pages of Device Manager I unchecked an option for the Creamware boards that said "reset when idle". I'm not exactly sure I understand the purpose of doing something like that, but in any case it's not being done now. The 2k drivers are installed, but SCOPE isn't running. I'm stress testing the system (100% CPU utilization, 100% RAM utilization) and it's been running for over an hour so far without problems. I'll let it run several hours, and if everything is OK, I'll start SCOPE and run the same stress test.
The Creamware 2k drivers may still be adequate. My intuition tells me that it is the SCOPE app itself which is causing the problem. I'll try setting it to 2k backward compatability mode in its properties page and see if that makes a difference.
Keep those ideas coming, I need the help! And thanks.
Husker, no MIDI ports in use. In fact, the Creamware system has almost no load on it, less than 20% of the DSP power is utilized and I'm not running any audio through it. Just the presence of SCOPE running seems to cause the freeze.
it's hardware related thru the os most likely. the problem isn't the driver or the app, for sure.
disabling sata is unnessesary. you can only force irqs via bios in "standard pc" mode, a bad choice with that motherboard, i'd think. in acpi mode, interrupts are set by the windows. when windows says "no conflicts", that's very different than "no sharing". go to start/programs/accessories/system tools/system information/hardware setup/conflicts-sharing and if any scope cards are there, tell us what they are sharing with.
as to nforce4 and audio, here RME says "At present the NF4 single cpu chipset cannot be recommended for demanding pro DAW work. Multimedia users, recording hobbyists or semi-pro DAW users who use a limited combination of streamed audio tracks, samples and/or VSTis may not face the aforementioned limitations and performance may be as good as on any comparative platform."
http://www.rme-audio.de/english/techinf ... _tests.htm
as you can see, the "latest" is not always the "best". actually, the latest intel chipsets work as well or better than ever with the same old "win2k" drivers.....
still, i'm sure yours should work just fine. it's likely an irq conflict, but possibly it's midi related. you don't have a midi feedback loop possible when scope is started ,do you?
disabling sata is unnessesary. you can only force irqs via bios in "standard pc" mode, a bad choice with that motherboard, i'd think. in acpi mode, interrupts are set by the windows. when windows says "no conflicts", that's very different than "no sharing". go to start/programs/accessories/system tools/system information/hardware setup/conflicts-sharing and if any scope cards are there, tell us what they are sharing with.
as to nforce4 and audio, here RME says "At present the NF4 single cpu chipset cannot be recommended for demanding pro DAW work. Multimedia users, recording hobbyists or semi-pro DAW users who use a limited combination of streamed audio tracks, samples and/or VSTis may not face the aforementioned limitations and performance may be as good as on any comparative platform."
http://www.rme-audio.de/english/techinf ... _tests.htm
as you can see, the "latest" is not always the "best". actually, the latest intel chipsets work as well or better than ever with the same old "win2k" drivers.....
still, i'm sure yours should work just fine. it's likely an irq conflict, but possibly it's midi related. you don't have a midi feedback loop possible when scope is started ,do you?
I suggest a hardware MIDI processor, and patchbay also. Creamwares MIDI filter is fine for working inside the project window, but modern controllers send hordes of useless information, and when using muliple controllers it is wise to send the project window the precise, and needed information, so the MIDI filter in the project window doesn't become clogged with extra useless information. Trouble can occur prior to the project window.
I bought a couple of Digital Music MX8's, they are the cure for any loops and overbloated messages that are uneeded.
May You Succeed In Your Endeavors,
I bought a couple of Digital Music MX8's, they are the cure for any loops and overbloated messages that are uneeded.
May You Succeed In Your Endeavors,
-
dr cold hand
- Posts: 7
- Joined: Fri Nov 19, 2004 4:00 pm
This sounds exatly like a problem i had with a new pc. It was completely solved by putting the creamware card's pci slot onto another irq channel in the bios.
Other things to note: My Creamware stuff really dosn't like peer to peer software running, online games running and i dont think its keen of my printer.
If any of those things are running when i start scope or load another project it goes all wrong. Otherwise it's solid.
Dr
Other things to note: My Creamware stuff really dosn't like peer to peer software running, online games running and i dont think its keen of my printer.
If any of those things are running when i start scope or load another project it goes all wrong. Otherwise it's solid.
Dr
-
dr cold hand
- Posts: 7
- Joined: Fri Nov 19, 2004 4:00 pm
Garyb and Dr Cold Hand – yes there is IRQ sharing. I can’t tell you exactly what at the moment, I have the system apart for cleaning contacts, but as soon as I get it up again I will investigate. Trouble is, I have very little control over this, since as you stated, in ACPI mode the OS assigns IRQs automatically. There are a few controls in the BIOS, I will investigate. Although there is no MIDI communication going through the project window, I do have two hardware MIDI ports defined (not currently used). I will remove them and see what happens.
Stardust – Well, as stated above, this machine doubles as a DAW and a video game DEVELOPMENT platform. This kind of work is not too meaningful today on a non-SLI configured platform, unless you are testing how slow your game can become until it becomes unplayable. Along with developing the video portion of the games, I’m also in charge of sound/music. So, the concept isn’t so strange IMO…
The machine ran for six hours last night under extreme stress (and I mean EXTREME) without a single logged error. I started SCOPE and the machine froze within a few minutes, under NO stress testing. About the only thing I can positively state about the problem so far is that it is caused by running SCOPE. And BTW, SCOPE was running in Windows 2000 backward compatability mode when it froze the machine, so that didn’t seem to make a difference either.
So, I’m putting the machine back together with cleaned contacts. I will look into IRQ and see what I can re-distribute, but if there is no solution there, I’m out of ideas.
Stardust – Well, as stated above, this machine doubles as a DAW and a video game DEVELOPMENT platform. This kind of work is not too meaningful today on a non-SLI configured platform, unless you are testing how slow your game can become until it becomes unplayable. Along with developing the video portion of the games, I’m also in charge of sound/music. So, the concept isn’t so strange IMO…
The machine ran for six hours last night under extreme stress (and I mean EXTREME) without a single logged error. I started SCOPE and the machine froze within a few minutes, under NO stress testing. About the only thing I can positively state about the problem so far is that it is caused by running SCOPE. And BTW, SCOPE was running in Windows 2000 backward compatability mode when it froze the machine, so that didn’t seem to make a difference either.
So, I’m putting the machine back together with cleaned contacts. I will look into IRQ and see what I can re-distribute, but if there is no solution there, I’m out of ideas.
scope cannot share interrupts!
it''s reallly no big deal, you'll just need to disable a couple of extra usb controllers most likely(all or most of your usb PORTS will still work!). there's no bios or software correction other than installing the os in standard pc, otherwise. when it's back up, just tell us what the card is sharing with and i or someone else can help you.
it''s reallly no big deal, you'll just need to disable a couple of extra usb controllers most likely(all or most of your usb PORTS will still work!). there's no bios or software correction other than installing the os in standard pc, otherwise. when it's back up, just tell us what the card is sharing with and i or someone else can help you.
Running in backwards compatibility mode will have no effect and may worsen the performance of the UI, disable that.
IRQ sharing is 'controlled' by swapping cards around. Your 'primary' Scope card will be the point of the PCI-load for Scope. It's good to understand how Scope determines the 'primary' card so that u can track this down.
IRQ sharing can be seen in device manager (right click on my computer & choose manage). Once in device manager do View>Resouces by type and expand the 'IRQ' section, type the results here.
The mention of MIDI as the source of potential lockups is another good idea. If you have a keyboard that has active sensing connected directly to the Scope midi input this will definately cause lockups on modern multicore / HT capable systems. This is a well known bug around here, the workaround is either filter the active sensing externally (as Scope4Live suggests) or get a usb based midi i/o box and connect the offending keyboard there.
IRQ sharing is 'controlled' by swapping cards around. Your 'primary' Scope card will be the point of the PCI-load for Scope. It's good to understand how Scope determines the 'primary' card so that u can track this down.
IRQ sharing can be seen in device manager (right click on my computer & choose manage). Once in device manager do View>Resouces by type and expand the 'IRQ' section, type the results here.
The mention of MIDI as the source of potential lockups is another good idea. If you have a keyboard that has active sensing connected directly to the Scope midi input this will definately cause lockups on modern multicore / HT capable systems. This is a well known bug around here, the workaround is either filter the active sensing externally (as Scope4Live suggests) or get a usb based midi i/o box and connect the offending keyboard there.
OK. Too soon to tell, but we have an hour on the stress test clock with SCOPE running. What did I do?
Well, very curiously, there is no way to disable ACPI with this particular mobo. I guess the assumption is that if your messing around with this technology, you’re using XP or Vista or whatever and ACPI is a given (along with APIC). So that being the case, why does the BIOS provide controls for assigning IRQ numbers to the three PCI slots? Well, messing around with those controls does change the assignment of the IRQ at the BIOS level (as noted in the table that appears on-screen just before XP is booted) but then XP gets hold of everything and does whatever it wants, so in effect the BIOS controls are useless. I was about to sell my Creamware cards when I noticed something. (Valis and GaryB were dead on the money here). Two of the cards had their own IRQ, but the third one was sharing an IRQ with lots of other devices. What I noticed was that the card which was sharing was considered by the system to be the primary card (Pulsar2) while the other two were listed as “Creamware DSP-Boards”. So I swapped the PCI slot of two cards, which was the only way I could have ANY effect on the IRQ configuration. Sure enough, the primary card (Pulsar2) now has its own dedicated IRQ, and one of the slave cards is sharing. And that, at least so far, has made all the difference. It seems to be working. Since all system freezes in the past only required a few minutes to occur, and we have 60+ minutes clocked under full stress test as I’m writing, I’m hopeful.
Oh, I also found a few more things in the BIOS to shut off, mostly having to do with Intel’s twisted concept of power saving features, but also two unused networking ports. I don’t think this had anything to do with my “apparent” success, but it can’t hurt. The fewer devices competing for IRQ resources the better.
So, it looks as though the lifespan of the caps on the boards is going to determine the fate of the boards after all, and not the software. This is the thrid machine incarnation for these puppies, pretty remarkable when you think about it. Unless you hear from me on this thread again, this issue is resolved. Whew!
Thank you everyone for being so helpful
I was very worried there for a while.
Well, very curiously, there is no way to disable ACPI with this particular mobo. I guess the assumption is that if your messing around with this technology, you’re using XP or Vista or whatever and ACPI is a given (along with APIC). So that being the case, why does the BIOS provide controls for assigning IRQ numbers to the three PCI slots? Well, messing around with those controls does change the assignment of the IRQ at the BIOS level (as noted in the table that appears on-screen just before XP is booted) but then XP gets hold of everything and does whatever it wants, so in effect the BIOS controls are useless. I was about to sell my Creamware cards when I noticed something. (Valis and GaryB were dead on the money here). Two of the cards had their own IRQ, but the third one was sharing an IRQ with lots of other devices. What I noticed was that the card which was sharing was considered by the system to be the primary card (Pulsar2) while the other two were listed as “Creamware DSP-Boards”. So I swapped the PCI slot of two cards, which was the only way I could have ANY effect on the IRQ configuration. Sure enough, the primary card (Pulsar2) now has its own dedicated IRQ, and one of the slave cards is sharing. And that, at least so far, has made all the difference. It seems to be working. Since all system freezes in the past only required a few minutes to occur, and we have 60+ minutes clocked under full stress test as I’m writing, I’m hopeful.
Oh, I also found a few more things in the BIOS to shut off, mostly having to do with Intel’s twisted concept of power saving features, but also two unused networking ports. I don’t think this had anything to do with my “apparent” success, but it can’t hurt. The fewer devices competing for IRQ resources the better.
So, it looks as though the lifespan of the caps on the boards is going to determine the fate of the boards after all, and not the software. This is the thrid machine incarnation for these puppies, pretty remarkable when you think about it. Unless you hear from me on this thread again, this issue is resolved. Whew!
Thank you everyone for being so helpful
I was very worried there for a while.
When you install windows you can install as "Standard PC" this will then pick up the BIOS IRQ assignment and windows will not assign IRQ's itself. The problem with this is the number of IRQ's that are free to use are limited among other things like no support for Multiple processors.
You still need to fix that IRQ share on the slave board.
You still need to fix that IRQ share on the slave board.
Stuart.
I don’t think the slave board sharing is fixable. It’s sharing with a GPU card (same IRQ, different bus). Since I have three cards, three PCI slots, and no way to alter the IRQ configuration except to swap boards… The IRQ for the video card is not selectable, I must accept what XP assigns, and it always assigns that one PCI slot and one GPU card to the same IRQ.
Everything is turned off which can be turned off. The last board sharing has not seemed to be a problem, I’m into several hours of stress testing at this point.
However, I would like to know what in the world XP uses for brains when it allocates IRQs. I have several unassigned IRQs available, and multiple devices ganged up on the same IRQ. I’ve noticed this before, in other machines, that XP seems to do a really poor job of assigning IRQs so they are all in use. How difficult can it be? Lets see, we have sixteen devices, sixteen IRQs, let’s put two devices on each of the first eight interrupts and leave the remaining eight unused? What kind of programming is that? If there are hidden rules here I would really like to know what they are. And why isn’t there an interface in the OS for changing all this, or at least giving the OS “hints” about what it should do, like a prioritization list based on expected bus utilization?
Anyway, worst case seems to be that if the slave board sharing becomes a problem, I can pull the card. Having three less DSPs in my system isn’t going to kill me. Still, why am I always seeming to make compromises to accommodate apparent stupidity on the part of Microsoft? It stopped being entertaining years ago
Well, I’m just complaining now, and that’s a good sign, it means I have expendable energy for other things besides solving the problem. Cheers.
And thanks again to all…
Edit - I might add that the GPU card hangs directly off the Northbridge, while the Creamware card on the PCI bus talks to the Southbridge. So although they might share an IRQ, they are quite separated from one another as far as bus contention issues are concerned.
Everything is turned off which can be turned off. The last board sharing has not seemed to be a problem, I’m into several hours of stress testing at this point.
However, I would like to know what in the world XP uses for brains when it allocates IRQs. I have several unassigned IRQs available, and multiple devices ganged up on the same IRQ. I’ve noticed this before, in other machines, that XP seems to do a really poor job of assigning IRQs so they are all in use. How difficult can it be? Lets see, we have sixteen devices, sixteen IRQs, let’s put two devices on each of the first eight interrupts and leave the remaining eight unused? What kind of programming is that? If there are hidden rules here I would really like to know what they are. And why isn’t there an interface in the OS for changing all this, or at least giving the OS “hints” about what it should do, like a prioritization list based on expected bus utilization?
Anyway, worst case seems to be that if the slave board sharing becomes a problem, I can pull the card. Having three less DSPs in my system isn’t going to kill me. Still, why am I always seeming to make compromises to accommodate apparent stupidity on the part of Microsoft? It stopped being entertaining years ago
Well, I’m just complaining now, and that’s a good sign, it means I have expendable energy for other things besides solving the problem. Cheers.
And thanks again to all…
Edit - I might add that the GPU card hangs directly off the Northbridge, while the Creamware card on the PCI bus talks to the Southbridge. So although they might share an IRQ, they are quite separated from one another as far as bus contention issues are concerned.
Last edited by odlumb on Mon May 28, 2007 10:59 pm, edited 1 time in total.
He swapped the cards around and the slave card is now the one sharing, so no need to mess with cset.ini. If your cards are properly connected with stdm cables the primary could should be the primary point of contact with the PCI bus, and the impact on PCI performance & irq conflicts from the 'slave' cards should be negligable (this was always my understanding).
The graphics card ALWAYS 'hangs off the north chip', since AGP days on. The problems with bus contention aren't due to 'bandwidth' per se, but due to latency overhead with certain drivers and hardware addressing (specifically chipsets like Nforce4 have some serious problems in their hardware). With more stable chipsets this is less of an issue and using Doubledawg to clock down the PCI latency of the graphics card can be unnecessary, but can still yield improvements (masterverb test tells all).
And as for Xp's strange allocation of interrupts, with a modern 2.x APIC controller on your motherboard and Xp's ACPI implementation (as of sp1/2) you should have NO REASON to do 'standard pc' mode. This is something leftover from Win2k days (old ACPI) and older APIC hardware implementations. ACPI/APIC supercedes any pre-ACPI ideas of how irq's work btw, go read up on it at ars techica if you're interested.
Basically, a modern Intel or AMD chipset shouldn't be installed this way (non-ACPI) unless it's an absolute LAST RESORT. There's too much modern technology being bypassed at this point, and provided you choose your hardware somewhat carefully there should be absolutely no reason for it to not work. A bit of shuffling of PCI cards is the usual thing to do, as you have seen. Usually I map out my 'irq sharing' by using a boot cd into some linux or DOS OS mode that is devoid of ACPI. The IRQ's are not the important thing, what is important is to see what cards share where, I find using a stripped down OS boot disk to be the easiest way to do this (or you can even just hit pause/break during the boot POST screen if you're fast enough).
Creamware uses the standard PC answer as in support emails out of habit. It's a fast fix that's really unnecessary but since people often prefer teh quick fix over the proper one it's been repeated here ad naseum.
Anyway, happy to hear that with some system tuning things are looking more stable.
The graphics card ALWAYS 'hangs off the north chip', since AGP days on. The problems with bus contention aren't due to 'bandwidth' per se, but due to latency overhead with certain drivers and hardware addressing (specifically chipsets like Nforce4 have some serious problems in their hardware). With more stable chipsets this is less of an issue and using Doubledawg to clock down the PCI latency of the graphics card can be unnecessary, but can still yield improvements (masterverb test tells all).
And as for Xp's strange allocation of interrupts, with a modern 2.x APIC controller on your motherboard and Xp's ACPI implementation (as of sp1/2) you should have NO REASON to do 'standard pc' mode. This is something leftover from Win2k days (old ACPI) and older APIC hardware implementations. ACPI/APIC supercedes any pre-ACPI ideas of how irq's work btw, go read up on it at ars techica if you're interested.
Basically, a modern Intel or AMD chipset shouldn't be installed this way (non-ACPI) unless it's an absolute LAST RESORT. There's too much modern technology being bypassed at this point, and provided you choose your hardware somewhat carefully there should be absolutely no reason for it to not work. A bit of shuffling of PCI cards is the usual thing to do, as you have seen. Usually I map out my 'irq sharing' by using a boot cd into some linux or DOS OS mode that is devoid of ACPI. The IRQ's are not the important thing, what is important is to see what cards share where, I find using a stripped down OS boot disk to be the easiest way to do this (or you can even just hit pause/break during the boot POST screen if you're fast enough).
Creamware uses the standard PC answer as in support emails out of habit. It's a fast fix that's really unnecessary but since people often prefer teh quick fix over the proper one it's been repeated here ad naseum.
Anyway, happy to hear that with some system tuning things are looking more stable.