View Full Version : IRQ Conflict

17-10-2002, 01:53 PM
The Son’s computer, which I’ve inherited whilst he’s overseas, has a habit of locking up.

The operating system is Win98 and using the device manager facility I find there is a IRQ conflict.

The problem is displayed in Hard Disk controllers.
Standard IDE/ESDI Hard Disk Controller
This device cannot find any free IRQ Resources to use (Code 12)
This device requires on of the following IRQ resources 10 11 12

Now the problem is:

IRQ 10 is possessed by S3 ViRG – DX/GX PCI Video card
IRQ 11 is taken by Universal Serial Bus Controller
IRQ 12 has the PS/2 Mouse with it’s tail firmly rapped around it.

So, this leaves the Standard IDE/ESDI Hard Disk Controller homeless!

Not sure that we’re actually using this controller but I suspect it may be causing us grief?

Don’t know about you guys but every time I’ve encountered a hanging problem a fight over IRQ’S seems to be behind the trouble.

Any suggestions??


Babe Ruth
17-10-2002, 02:02 PM

Have you had a look at the following Microsoft articles Code12_1 (http://support.microsoft.com/default.aspx?scid=KB;EN-US;q245682&) and Code12_2 (http://support.microsoft.com/default.aspx?scid=kb;en-us;Q125174)
and Code12_3 (http://support.microsoft.com/default.aspx?scid=kb;en-us;Q133240)


Terry Porritt
17-10-2002, 02:03 PM
A vexing problem, IRQs. You could check in Device Manager-System Devices-PCI Bus-IRQ Steering that IRQ Steering is enabled. If disabled see if it can be enabled.
If you are not using any USB devices that controller could be disabled, and also in the BIOS.
IRQs should be able to be shared with the IRQ steering, but a bit of manual manipulation rather than letting Windows decide can be better.

17-10-2002, 02:57 PM
Thanks Babe & Terry

Those sites you gave certainly pertain to the problem Babe. I’ll inwardly digest them shortly.

Followed your lead toTerry and got some odd answers. Out of my depth now I think.

Starting with the BIOS


(Other choices available: ISA, PCI-SLOT1, PCI-SLOT2, PCI-SLOT3, PCI-SLOT4)

Onto the Steering:

PCI bus

Use IRQ Steering (tick)
Get IRQ table using ACPI BIOS (tick)
Get IRQ table using MS Specification table (tick)
Get IRQ table from Protected Mode PCIBIOS 2.1 call (NOT ticked)
Get IRQ table from Real Mode PCIBIOS 2.1 call (ticked)

IRQ Routing Status

IRQ Steering Disabled (don’t know where?)

IRQ Table has some errors (oh yea!)


No conflicts (??????)

Does this make any sense????



17-10-2002, 03:23 PM
I probably should have pointed out in Device Manager we have the following:

Hard disk controllers

Intel 82371AB/EB PCI Master IDE Controller

Primary IDE controller (dual fifo)

Secondary IDE controller (dual fifo)

Standard IDE/ESDI Hard Disk Controller (The homeless one)


17-10-2002, 03:46 PM
Try shuffling the IRQs around. it is possible that the range of IRQs that one of the other devices uses is different to the homeless one. change it to this and then change the Homeless device to the now free IRQ


Terry Porritt
17-10-2002, 04:00 PM
Well, it would seem that IRQ steering is disabled even though the enable box is ticked because the IRQ routing table information from the BIOS has errors. Big deal! But how to fix that? Struggles with decaying brain cells.....

Fall back position is to remove the Standard IDE/ESDI Hard Disk Controller altogether from Device Manager, and then re-boot and see what happens.
I dont think you need it, I have more experience of Via chipsets and their IDE drivers, and with those the Standard controller is dispensed with.

I'll study some more, and if I find anything will get back.

Peter H
17-10-2002, 04:24 PM
My system only has - Prim IDE - Sec IDE & Via bus master PCI IDE - Could try removing your last one as suggested.

Graham L
17-10-2002, 04:50 PM
Usually (legacy :D) the IDE IRQs are: IDE1 : 14, IDE2 :15. 12 is reserved for PS/2 mouse, if it's there. If this extra one wants yet another IRQ, it might be SOL. :D If it's a master driver, which controls the 2 interfaces, you'd think it could take one IRQ and arbitrate between the interfaces itself.

Does the system boot and run, despite the "error"?

17-10-2002, 05:12 PM

Tried removing Standard IDE/ESDI Hard Disk Controller from Device Manager.
Removed it OK, but when I re-booted, Windows comes up with “Found new Hardware Installing Drivers etc.” Whoooh too late!

So tried dispensing with USB controller to free IRQ11 but no luck there either.
Got rid of the controller but never freed IRQ11.
Again, it was restored when Windows restarted.


I checked my machine, which is similar, and I don’t have a standard IDE/ESDI controller. Same as you Peter. Can’t get rid of the beastly thing.

How do I shuffle the IRQ’s Nathan? I’m not sure some would appreciate me doing that?

Think you’ve got a handle on the problem Terry, question is what to do???????


Terry Porritt
17-10-2002, 05:15 PM
My system (win98se) is as Peter H's, but it has Via chipset, yours is Intel, but I think the same argument applies. However with a win95 setup in my backup computer, also with Via chipset but much older board, I cant remove the Standard controller, windows 95 keeps re-detecting it and putting it back. However disabling it in its Properties window in Device Manager removes its IRQ from the list, and the system doesnt need it.

If you find you cant remove it permanently, just try "disable in this hardware profile".

Terry Porritt
17-10-2002, 05:22 PM
I didnt see your last post BM when I posted. If USB is disabled in the BIOS then Windows shouldnt try to re-detect it, but what we have to do is to get IRQ steering working so that IRQs can be shared if neccessary.

17-10-2002, 05:24 PM
Sorry Graham our posts crossed.

Yes the machine works good as gold 90% of the time!

The problem seems typical of IRQ and hardware conflicts, which is why I went looking in Device Manager. I guess there is no guarantee that having fixed the problem all will be well but history suggests there is a good chance.

Terry Porritt
17-10-2002, 07:39 PM
Have been giving more thought to this, and am probably repeating things....

It is possible that the USB controller is the cause of disabling IRQ steering, if it isnt being reported by the BIOS in the IRQ routing table.

IRQ steering in itself doesnt enable IRQ sharing, thats what PCI bus is supposed to do, but I 'believe' that when the steering is disabled even when the enable box is ticked, then it can lead to sharing problems.

So if you are not using any USB devices, disable USB in the BIOS, Windows wont detect it, an IRQ will be freed up, and if you have any ISA or non plug and play cards, IRQ Steering may then hopefully work and do its stuff. The Standard IDE controller may find a home, if it does, then you can play at re-enabling USB and see what happens, and what IRQ is assigned to it.

If you do need USB then just disable the Standard IDE controller in the hardware profile, as the Intel IDE controller is presumably doing the work.

It is not essential to have the IRQ steering working, in fact disabling it can be a useful diagnostic tool in some instances, but I think it should be able to work properly when told to!

17-10-2002, 09:19 PM
We think alike Terry.

I thought it might be the USB Controller too. Unfortunately I can’t for the life of me find where to turn it off in the BIOS. I even looked at my computer (remember this is the sons) and couldn’t find anything there either. Must be going mad and blind! Both are Award Bios configurations and very similar.

I had a brainwave and went to start/programs/accessories/system tools/system information/Conflicts/Sharing and had a look at what IRQ’s were shared and what were allocated. Nothing hit me between the eyes as being untoward. Although interestingly, IRQ 10 is shared by S3 ViRGE & IRQ holder for PCI steering.. IRQ 11 is shared by Intel PCI to USB Universal Host Controller & again IRQ holder for PCI Steering. The only other address that our Hard Disk Controller was interested in was IRQ 12 which is held by the PS/2 Mouse.

So, to summarise PCI Steering gets mentioned twice in dispatches and shares IRQ’s 10 & 11.

There is no forced Hardware.

In the meantime I’ve disabled the Standard IDE/ESDI Hard Disk Controller in the hardware profile of Device Manager and still got a lock-up!

Another sleepless night! Damn computers!

17-10-2002, 09:34 PM
What I mean by shuffling IRQs is.

I take it you have tried to change the IRQ of the conflicting device.
I also take it that you know everything needs a different IRQ
Each device usually has more than one IRQ that it can use.
The IRQs are not always the same.

For example of your problem (please note the IRQs are made up)

Device 1 uses the IRQs 132 22f F43
and Device 2 the IRQ 132 4432 F43
Device3 132 22f F43
Device4 132 22f F43

now Device 2 is using 132
Device3 is using 22f
and Device4 is using F43

Device 1 is missing out. But as you can See Device has other IRQs it can use. the only one free in this case is 4432. so you would change Device 2 IRQ from 132 to 4432 and then Change device 1 IRQ to 132

That is IRQ shuffling. I hope you understand all that


Terry Porritt
17-10-2002, 11:13 PM
Well, I think I followed that Nathan, but real IRQ numbers would be easier :). The problem is often the difficulty of manually changing the IRQs, sometimes you have to change settings in the PNP/PCI configuration setup in the bios in order that device resources tab in device manager will let you go to manual change settings instead of automatic, to over-ride the 'settings cant be changed' message.

However devices can share IRQs, they dont have to each have different IRQs, that is the purpose of the PCI bus and IRQ steering. When IRQs are shared then if you check under the Resources tab, I think the other resources are different for the devices.

The IRQ Holder basically means the IRQ is reserved for PCI and is unavailable for an ISA device.

I must admit to getting confused over all this though, so am happy to be corrected.

In my Award Bios setup, the USB controller can be disabled in the Integrated Peripherals section, whilst in PNP/PCI Configuration setup, Assign IRQ for USB can be disabled. This would free up an IRQ.

Even after all this the lockups you get BM every now and again may be nothing to do with the Standard IDE controller setting :)

18-10-2002, 09:37 AM
Well Terry after a night of IRQ’s to my sleep I’ve got a couple of things I going to try.
However, the machine has become totally unstable with the Standard Hard Disk Controller turned off in the Hardware Profile. Sometimes these things work even though they’re shown as not working properly.

To the BIOS.

My PNP/PCI Configuration page is very short and sweet. It goes:

PNP OS Installed : Yes
Resources Controlled By : Auto
Reset Configuration Data : Disabled

Primary IDE INT# : A
Secondary IDE INT# : B

That’s it.

If I change the Resources Controlled By to Manual there is just a list of IRQ’s & DMA’s in numerical order all of which read as follows.
IRQ-3 assigned to : PCI/ISA PnP
The alternative to the PCI/ISA PnP is Legacy ISA.

Those sites Babe Ruth provided threw some light on the subject and there appears to be a known fault within Win98. Question is why does one computer work perfectly on the same OS?

As you say Terry you shouldn’t need a separate IRQ for every device. In fact you can’t have one for every device. An old problem used to be COM1 & COM3 sharing the same interrupt. If you had a Mouse on COM1 & Modem on COM3 and you moved the mouse whilst the Modem was working sorry data. This was overcome by changing COM3 I/O address usually to IRQ5.
That’s the other thing Nathan there is a fair bit of “Convention” as to what should be where although the above is an example of two devices not being able to live together and a shuffle as you put it required.

Anyway, I’ll keep you posted as to what damage I’ve managed.


18-10-2002, 09:53 AM

Go into your cmos setup utility and disable one of your unused COM ports. Reboot. alt click my computer, select properties then device manager. select your mouse, uncheck "use automatic settings" (or something that achieves same result - haven't used win98 in a long time), assign the freed up IRQ (IRQ3 or IRQ4) apply the new settings and restart. this should fix your problem.

18-10-2002, 10:32 AM
That was close rage32. Thought that would crack it myself.

Unfortunately, when I went to change settings I got the dreaded message

“No Modification Allowed”

! “This resource setting cannot be modified.”

PS/2 Mouse seems very happy in his little hole and ain’t moving!

Where’s the Cat?

Terry Porritt
18-10-2002, 10:33 AM
Hi rage32, good idea, this is where the 'shuffle' may come in. The Standard IDE controller wants to go on IRQ10, but the S3 video card is on that. S3 Virge cards according to MS are also known to cause a problem but they dont tell you what to do about it. Video cards dont like sharing.

Often shuffling the cards around between PCI slots can make a difference too.

The shuffle around to aim for is to move the video card on to IRQ11, and the Standard IDE controller onto IRQ10. But USB controller is on IRQ11, so that wants to be moved to a disabled comport IRQ, or be removed altogether if its not being used.

Terry Porritt
18-10-2002, 10:35 AM
Yes, IRQ12 is reserved for the PS/2 mouse, but you could free up IRQ3 or 4. and see if the USB can be moved to one of those.

18-10-2002, 10:56 AM
That was close rage32. Thought that would crack it myself.

Unfortunately, when I went to change settings I got the dreaded message

“No Modification Allowed”

! “This resource setting cannot be modified.”

PS/2 Mouse seems very happy in his little hole and ain’t moving!

Where’s the Cat?

18-10-2002, 10:59 AM
Whoops Sorry, My fault clipboard not cleared.

18-10-2002, 12:19 PM
well, Terry ur absolutely correct (I can convert Binary to decimal and back but can't remeber basic IRQ assignments - Go figure!!) Question? isn't IRQ's 14 & 15 reserved for IDE controllers? any how I agree, maybe you try the USB on IRQ 3 or 4. How old is this machine? Irq assignment shouldn't be a problem.

Terry Porritt
18-10-2002, 12:38 PM
Yes, as Graham said 14 & 15 are used by IDE controllers, there is the Intel Master IDE controller and then the primary and secondary controllers. These will take up 14 and 15. Then there is the vexed problem of the 'homeless' Standard IDE controller, it shouldnt really be necessary when the m/b chipset controller drivers have been loaded, yet disabling seems to cause even more lockups.

I keep getting this nag about USB, since the board has a PCI video card and assuming there is no AGP slot, then the BIOS will be a bit old, and may not report USB properly. Maybe thats why the IRQ routing table has errors.

18-10-2002, 01:54 PM

Getting real basic now team.

Turned off machine and unplugged PS/2 Mouse.

Fired machine back up and got the windows message "Windows can not find your Mouse" "You can plug in your Serial Mouse Now"

Sure, Plugs in Serial Mouse. Away we go no problems.

Check out "System Properties" and would you believe there's the Standard IDE/ESDI Hard Disk controller happy as Larry in IRQ12.

Check everything else and not a conflict to be found!

Now have 1 spare PS/2 Mouse.

So far so good, I feel I should get a Nobel Peace Prize for sorting that scrap out.

Early days yet but so far no crashes.

Graham L
18-10-2002, 04:36 PM
Bloody hell. Take that :D of your face B.M. The system will find another way to bite you. ;-)

About 1971, DEC started shipping the PDP11 minis. They used interrupts extensively. They actually used 2 interrupt "levels". For as many devices as you could fit cards for in the backplane. The trick was, they used open-collector drivers, so they could all interrupt. The CPU acknowledged, and the nearestcard to the CPU which was interrupting had its go. When it had finished, the interrupt would still be asserted, so the process would be repeated, until there were no devioces wanting service. (You gave the fastest devices the closest position, so they got priority).

Worked nicely ... you could put lots of similar devices in, and it all worked.

IBM used tri-state TTL, and edge-triggered instead of level-sensed interrupts for the ISA bus. So we're still getting problems. :_|

PCI uses level-sensing, so can share, but it doesn't have the priority based on position(AFAIK) , so it's not as good.

18-10-2002, 09:14 PM
Still working, no sign of a crash yet.

I’m sure your right Graham, these thing never give up.

However, if we still haven’t crashed by Monday I recon this ones beat.

Babe Ruth
18-10-2002, 09:26 PM
Graham L,

Jeesh mate you take me back... my Digital career started on PDP-8e, PDP-11's (various), Vax11-780,750,730 MV1,2 all the way through until 1992 on top-end Alpha systems... sigh!

Well let's keep the fingers crossed then.

Cheers, Babe.