IRQ conflict

[Yousuf Khan]

Looks like I'm having a good old fashioned IRQ conflict. Even though
IRQ's are theoretically shareable these days, in practice it may not be
such a hot idea. The problem first occurred after I replaced my
motherboard and processor on one of my systems, a couple of weeks back.
I was getting a BSOD once every couple of days. I've had 5 BSODs so far.
There has been 3 different types of Stop messages: variously involved
the DRIVER_IRQL_NOT_LESS_THAN_OR_EQUAL (twice), the BAD_POOL_HEADER
(twice), and the UNEXPECTED_KERNEL_MODE_TRAP (once) errors.

Initially, they involved TCPIP.SYS and IPNAT.SYS, both of which were
network-related. So I thought it's a network card issue and I updated
the Realtek Gigabit Ethernet driver, but that didn't help.

Then a couple of days ago, I got another BSOD, but this time it involved
the driver NV4_MINI.SYS, which is an Nvidia video card driver -- seemed
completely unrelated. Then earlier today, I got another
DRIVER_IRQL_NOT_LESS_THAN_OR_EQUAL error, and this time it came from
both the TCPIP.SYS and the NV4_MINI.SYS drivers together! That clued me
into the idea that perhaps these two are sharing the same IRQ. I looked
in Device Manager, sorted it by Resource Connections, and sure enough
the gigabit ethernet and video card are both sharing IRQ 18! And that's
not all, there's 5 other devices sharing this same IRQ too! Seven
devices on the same IRQ line! There's only one other line, IRQ 16, that
has multiple devices on it too, at comparatively paltry 3 devices. Every
other IRQ line that is used only has one device on it, and there are
several empty unused IRQ lines all over the place.

So I went into the BIOS settings, but couldn't find any IRQ setting
functions available to it. The only option I found was something that
either enabled or disabled Plug'n'Play OS support, but not much else.

I tried to go into Windows' Device Manager to manually configure the
IRQ's, but the manual setting of resources was grayed out. According to
this webpage, you can't manually set anything inside an ACPI-compliant PC:

"You may find you cannot manually change your IRQ settings (the Use
automatic settings will be greyed out), this is usually related to the
ACPI function used by Win XP. "
http://www.helpwithpcs.com/upgrading/change-irq-settings.htm

So now I'm stuck, is there some kind of program available to reset the
ACPI tables? Some sections of the Registry that I can change?

Yousuf Khan

 

[Yousuf Khan]

Did you replace the motherboard and processor with the same make and
model numbers? If either was replaced with a different component, what
procedure did you use to reconfigure the OS to the new hardware
configuration (backup data and clean reinstall or repair install)?

Nope, both the motherboard and processor were upgraded to newer models.
The processor came from the same manufacturer, but is a generation or
two newer (AMD, old: Athlon 64 X2, new: Phenom II X3). The motherboard
is from the same manufacturer, but different models/chipsets (Asus, old:
M2NPV-VM/Nvidia Nforce 430, new: M4A785-M/ATI 785G).

The method used to reconfigure was closer to a repair install. It was
merely an install of the drivers for new components as they got
discovered Windows. Processor information drivers were updated to the
latest versions. All attached hardware have been completely matched to
appropriate drivers. There are no yellow exclamation points or red X's
among any of the Device Manager entries, if that's what you're getting at.

Was the original (with the old hardware) installed by the computer
manufacturer? Customized OEM installation, generic "grey box" OEM, Full
retail OS or upgrade from an earlier version of Windows? Were the old
drivers installed from the OS installation media or media that came with
the hardware (graphic accelerator, Ethernet card, sound accelerator,
motherboard chip set etc)? Same information about driver sources after
replacing the hardware.

The machine is a home-built. It was completely built and upgraded by me
over the years. Windows XP was originally installed on this system as an
upgrade from Windows 2000, which must've been 7 or 8 years ago; it's
been upgraded between that time too. The old and new drivers were
installed by a combination of OS install media and hardware install
media. Some drivers had sources pre-included in the OS install disk, and
some came from a later hardware installation disk.

This latest motherboard and processor upgrade was actually quite smooth
and trouble-free, comparatively. All new hardware drivers were installed
and working in the first try, without incident.

Others with similar hardware might be able to compare their driver
versions to yours if in a further post you list equipment descriptions
and any version numbers from the problematic computer. You may be able
to use software like the DirectX diagnostic, Windows System Information
or a third party hardware reporting tool to copy that information to a
text file or the Windows clipboard, allowing you to paste the relevent
sections of those report information into a post.

You just needed to ask. Here's the full list of IRQ assignments on the
machine:

IRQ 00 Exclusive System timer
IRQ 04 Exclusive Communications Port (COM1)
IRQ 08 Exclusive System CMOS/real time clock
IRQ 09 Shared Microsoft ACPI-Compliant System
IRQ 13 Exclusive Numeric data processor
IRQ 14 Exclusive Primary IDE Channel
IRQ 16 Shared Standard OpenHCD USB Host Controller
IRQ 16 Shared Standard OpenHCD USB Host Controller
IRQ 16 Shared Microsoft UAA Bus Driver for High Definition Audio
IRQ 17 Shared Standard Enhanced PCI to USB Host Controller
IRQ 18 Shared Realtek PCIe GBE Family Controller
IRQ 18 Shared Standard OpenHCD USB Host Controller
IRQ 18 Shared Standard OpenHCD USB Host Controller
IRQ 18 Shared Standard OpenHCD USB Host Controller
IRQ 18 Shared PCI standard PCI-to-PCI bridge
IRQ 18 Shared PCI standard PCI-to-PCI bridge
IRQ 18 Shared NVIDIA GeForce 8600 GT
IRQ 19 Shared Standard Enhanced PCI to USB Host Controller
IRQ 22 Shared Standard Dual Channel PCI IDE Controller

As you can see, there are 7 devices using the same IRQ 18.

Yousuf Khan

 

[Jose]

Nope, both the motherboard and processor were upgraded to newer models.
The processor came from the same manufacturer, but is a generation or
two newer (AMD, old: Athlon 64 X2, new: Phenom II X3). The motherboard
is from the same manufacturer, but different models/chipsets (Asus, old:
M2NPV-VM/Nvidia Nforce 430, new: M4A785-M/ATI 785G).

The method used to reconfigure was closer to a repair install. It was
merely an install of the drivers for new components as they got
discovered Windows. Processor information drivers were updated to the
latest versions. All attached hardware have been completely matched to
appropriate drivers. There are no yellow exclamation points or red X's
among any of the Device Manager entries, if that's what you're getting at..


The machine is a home-built. It was completely built and upgraded by me
over the years. Windows XP was originally installed on this system as an
upgrade from Windows 2000, which must've been 7 or 8 years ago; it's
been upgraded between that time too. The old and new drivers were
installed by a combination of OS install media and hardware install
media. Some drivers had sources pre-included in the OS install disk, and
some came from a later hardware installation disk.

This latest motherboard and processor upgrade was actually quite smooth
and trouble-free, comparatively. All new hardware drivers were installed
and working in the first try, without incident.


You just needed to ask. Here's the full list of IRQ assignments on the
machine:






As you can see, there are 7 devices using the same IRQ 18.

        Yousuf Khan

There are also 3 sharing IRQ 16. Wouldn't that also be a problem?

How did you obtain this list of IRQ information?

What are ACPI tables that need to be reset?

Do you show IRQ conflicts in Device Manager, Interrupt Request,
Resources tab?

If you could change the IRQs, what would you change them to?

Please provide additional information about your system:

Click Start, Run and in the box enter:

msinfo32

Click OK, and when the System Summary info appears, click Edit, Select
All, Copy and then paste
the information back here.

There will be some personal information (like System Name and User
Name), and whatever appears to
be private information to you, just delete it from the pasted
information.

This will minimize back and forth Q&A and eliminate guesswork.

For IRQ information, expand the Hardware Resources, click IRQs, click
Edit, Select All,
Copy and then paste the information.

For video driver information, expand the Components, click Display,
click Edit, Select All,
Copy and then paste the information.

For audio information, expand the Components, click Sound Device,
click Edit, Select All,
Copy and then paste the information back here.

 

[Bob I]

You don't have an IRQ conflict, you have a bad driver for the hardware
installed. NT uses Virtual IRQs for legacy support and the number of
items listed on a particular IRQ is immaterial.

 

[Yousuf Khan]

There are also 3 sharing IRQ 16. Wouldn't that also be a problem?

Yes, that was mentioned in the original posting too.

How did you obtain this list of IRQ information?

From Device Manager and Everest.

What are ACPI tables that need to be reset?

The IRQ assignments.

Do you show IRQ conflicts in Device Manager, Interrupt Request,
Resources tab?

Read the original post.

If you could change the IRQs, what would you change them to?

My main concern is to remove either the video card or ethernet port from
that sharing arrangement as those are the two that have caused most of
the Stop messages. I don't care if anything else is sharing resources.

Please provide additional information about your system:

Click Start, Run and in the box enter:

msinfo32

Click OK, and when the System Summary info appears, click Edit, Select
All, Copy and then paste
the information back here.

There will be some personal information (like System Name and User
Name), and whatever appears to
be private information to you, just delete it from the pasted
information.

Sorry, none of that information is relevant to this discussion. I'll
show you the Resource Sharing/Conflict summary from Msinfo32 instead:

I/O Port 0x00000000-0x00000CF7 PCI bus
I/O Port 0x00000000-0x00000CF7 Direct memory access controller

I/O Port 0x00000060-0x00000060 Motherboard resources
I/O Port 0x00000060-0x00000060 Motherboard resources

I/O Port 0x000003C0-0x000003DF PCI standard PCI-to-PCI bridge
I/O Port 0x000003C0-0x000003DF NVIDIA GeForce 8600 GT

I/O Port 0x00000064-0x00000064 Motherboard resources
I/O Port 0x00000064-0x00000064 Motherboard resources

Memory Address 0xFEC00000-0xFEC00FFF Motherboard resources
Memory Address 0xFEC00000-0xFEC00FFF System board

IRQ 16 Standard OpenHCD USB Host Controller
IRQ 16 Standard OpenHCD USB Host Controller
IRQ 16 Microsoft UAA Bus Driver for High Definition Audio

Memory Address 0xD0000000-0xDFFFFFFF PCI bus
Memory Address 0xD0000000-0xDFFFFFFF PCI standard PCI-to-PCI bridge
Memory Address 0xD0000000-0xDFFFFFFF NVIDIA GeForce 8600 GT

IRQ 18 PCI standard PCI-to-PCI bridge
IRQ 18 NVIDIA GeForce 8600 GT
IRQ 18 PCI standard PCI-to-PCI bridge
IRQ 18 Realtek PCIe GBE Family Controller
IRQ 18 Standard OpenHCD USB Host Controller
IRQ 18 Standard OpenHCD USB Host Controller
IRQ 18 Standard OpenHCD USB Host Controller

I/O Port 0x00000B00-0x00000B3F Motherboard resources
I/O Port 0x00000B00-0x00000B3F Motherboard resources

Memory Address 0xA0000-0xBFFFF PCI bus
Memory Address 0xA0000-0xBFFFF PCI standard PCI-to-PCI bridge
Memory Address 0xA0000-0xBFFFF NVIDIA GeForce 8600 GT

I/O Port 0x000003B0-0x000003BB PCI standard PCI-to-PCI bridge
I/O Port 0x000003B0-0x000003BB NVIDIA GeForce 8600 GT

Memory Address 0xFA000000-0xFEAFFFFF PCI standard PCI-to-PCI bridge
Memory Address 0xFA000000-0xFEAFFFFF NVIDIA GeForce 8600 GT

This will minimize back and forth Q&A and eliminate guesswork.

No it won't. I've already been asked to repeat information that was in
the original posting, twice already.

Yousuf Khan

 

[Yousuf Khan]

You don't have an IRQ conflict, you have a bad driver for the hardware
installed. NT uses Virtual IRQs for legacy support and the number of
items listed on a particular IRQ is immaterial.

Incorrect, my last 5 set of BSODs disagrees with you. I need to move my
ethernet IRQ or my video card IRQ to something else. The ethernet
especially, since it's the most active of the interrupts. The second
most would be the video card. The remaining 5 devices are occasional
interrupters and can remain where they are.

Yousuf Khan

 

[Robert Myers]

Incorrect, my last 5 set of BSODs disagrees with you. I need to move my
ethernet IRQ or my video card IRQ to something else. The ethernet
especially, since it's the most active of the interrupts. The second
most would be the video card. The remaining 5 devices are occasional
interrupters and can remain where they are.

I increasingly think that you have a generic "BSOD after upgrading
motherboard without reinstalling Windows" problem.

One fix that you may or may not have tried is booting into safe mode
and forcing a reinstall of device drivers.

Robert.

 

[Yousuf Khan]

I increasingly think that you have a generic "BSOD after upgrading
motherboard without reinstalling Windows" problem.

Sure, but that's the way I've always done things. I find the whole idea
of Windows behaving differently depending on which method you used to
install it, somewhat troublesome. Why should a pre-existing installation
of Windows be unfixable compared to a freshly installed copy? It's the
same software in both cases.

I've been able to muddle through it in the past, and fix Windows when
most other people would've just reinstalled it.

I'm also trying to buy a corporate copy of Windows 7 soon, so all this
might be moot soon. I'll have no choice but to reinstall the OS from
scratch in that case. So I don't really want to reinstall XP from
scratch now, only to do it again with Win7.

One fix that you may or may not have tried is booting into safe mode
and forcing a reinstall of device drivers.

It's certainly something to try. By comparison, I've had Linux installed
on this same machine for nearly as long as I've had XP, and it's not
been reinstalled either. However, it's behaving much better, it's
managed to reassign the ethernet to a different IRQ (27). There's also 3
fewer devices sharing IRQ 18 under Linux than under Windows. Here's the
"/proc/interrupts" listing from Linux:

 

[Robert Myers]

Sure, but that's the way I've always done things. I find the whole idea
of Windows behaving differently depending on which method you used to
install it, somewhat troublesome. Why should a pre-existing installation
of Windows be unfixable compared to a freshly installed copy? It's the
same software in both cases.

I've always assumed that Windows checked certain things having to do
with the motherboard only on install. I also assume that's by design,
since Microsoft thinks you have to buy a new OEM edition for every new
motherboard.

Robert.

 

[Nate Edel]

Have you run memtest86/memtest86+ or some other memory tester?

 

[Nate Edel]

I'm also trying to buy a corporate copy of Windows 7 soon, so all this
might be moot soon. I'll have no choice but to reinstall the OS from
scratch in that case. So I don't really want to reinstall XP from
scratch now, only to do it again with Win7.

Well, you COULD do a XP/Vista/Win7 upgrade. I don't think it's recommended.

It's certainly something to try. By comparison, I've had Linux installed
on this same machine for nearly as long as I've had XP, and it's not
been reinstalled either.

Linux does much more sensible things about hardware detection and
initialization; for the most part, it's dynamic, and can get moved
between hardware FAR more easily than windows.

 

[YKhan]

Have you run memtest86/memtest86+ or some other memory tester?

--
Nate Edel                              http://www.cubiclehermit.com/
 preferred email  |
 is "nate" at the | "I do have a cause, though.  It's obscenity. I'm
 posting domain   |  for it."

I've run it overnight under the old system, and the new system is
using the same RAM. I don't really have time to run it 24 hours.

 

[Trent]

Sure, but that's the way I've always done things. I find the whole idea
of Windows behaving differently depending on which method you used to
install it, somewhat troublesome. Why should a pre-existing installation
of Windows be unfixable compared to a freshly installed copy? It's the
same software in both cases.

I've been able to muddle through it in the past, and fix Windows when
most other people would've just reinstalled it.

I'm also trying to buy a corporate copy of Windows 7 soon, so all this
might be moot soon. I'll have no choice but to reinstall the OS from
scratch in that case. So I don't really want to reinstall XP from
scratch now, only to do it again with Win7.



It's certainly something to try. By comparison, I've had Linux installed
on this same machine for nearly as long as I've had XP, and it's not
been reinstalled either. However, it's behaving much better, it's
managed to reassign the ethernet to a different IRQ (27). There's also 3
fewer devices sharing IRQ 18 under Linux than under Windows. Here's the
"/proc/interrupts" listing from Linux:

Have you tried this?:

Make a .cmd file with the following:
set devmgr_show_nonpresent_devices=1
%windir%\system32\devmgmt.msc

Run the created .cmd file

Go into device manager, select view, "Show hidden devices" and uninstall
all the devices that you believe to be in conflict. Also, uninstall all
the phantom devices - they will be the ones that are grayed out.

Reboot and go into BIOS setup. Under PnP/PCI configurations see if there
is something like "reset configuration data" if there is, set it to
enabled. Save and re-boot. Windows should re-enumerate all the deleted
devices that are still present in the system and (hopefully) correct the
issue.

 

[Yousuf Khan]

Have you tried this?:

Make a .cmd file with the following:
set devmgr_show_nonpresent_devices=1
%windir%\system32\devmgmt.msc

Run the created .cmd file

Go into device manager, select view, "Show hidden devices" and uninstall
all the devices that you believe to be in conflict. Also, uninstall all
the phantom devices - they will be the ones that are grayed out.

Thanks, no I hadn't tried that yet, and now that you reminded me, I
remember having seen this years ago, so it was a good idea to try.

However, it didn't help, even after removing all phantom devices, and
even some of the live devices, the live devices just got re-detected and
put right back in their original slots.

Reboot and go into BIOS setup. Under PnP/PCI configurations see if there
is something like "reset configuration data" if there is, set it to
enabled. Save and re-boot. Windows should re-enumerate all the deleted
devices that are still present in the system and (hopefully) correct the
issue.

There wasn't anything like that in the BIOS.

Yousuf Khan

 

[Nate Edel]

I've run it overnight under the old system, and the new system is
using the same RAM. I don't really have time to run it 24 hours.

So give it a shorter run.

 

[Yousuf Khan]

So give it a shorter run.

As I said, it was already given a shorter run under the previous system,
and it's the same RAM that used to be in the old system.

Yousuf Khan

 

[Jerry Peters]

As I said, it was already given a shorter run under the previous system,
and it's the same RAM that used to be in the old system.

Yousuf Khan

So what if it's the same ram? It's a different motherboard, right?
That means there could be new problems, from something as simple as a
poor or dirty socket contacts to loading problems with the ram drive
circuitry. The only way to be sure is to actually *test* it.

Jerry

 

[Yousuf Khan]

So what if it's the same ram? It's a different motherboard, right?
That means there could be new problems, from something as simple as a
poor or dirty socket contacts to loading problems with the ram drive
circuitry. The only way to be sure is to actually *test* it.

Jerry

Well, I'm not convinced there is anything wrong with the RAM at all, the
types of blue screens I'm suffering have a definite pattern to them.
They are afflicting certain families of device drivers, and I've already
determined that they are related by their shared IRQ. If I didn't have
this much evidence for a pattern, then I would try last resort RAM
testing. If I were to bother with RAM testing now, then I'd just be
humouring you and me.

Yousuf Khan

 

[Yousuf Khan]

Linux does much more sensible things about hardware detection and
initialization; for the most part, it's dynamic, and can get moved
between hardware FAR more easily than windows.

I just removed my Nvidia video card, since it was one of the sources of
the crashes. I'm now using the integrated ATI video to see if the
integrated video will be assigned to a different IRQ, looks like Windows
is hell-bent on assigning this thing to IRQ 18, no matter what. Linux on
the other hand properly assigned it out to a completely different IRQ
(27), than the ethernet or the previous video card was on.

Strange thing is that prior to driver installation, Windows just assumes
it as a standard VGA adapter. This was the case with both the onboard
ATI and the discrete Nvidia. While it was an assumed VGA, it was
assigned to IRQ 10. After the proper drivers were installed, beit ATI or
Nvidia, the device automatically gets assigned IRQ 18. Who came up with
this no manual adjustment possible on ACPI crap?

Yousuf Khan

 

[Bob I]

I just removed my Nvidia video card, since it was one of the sources of
the crashes. I'm now using the integrated ATI video to see if the
integrated video will be assigned to a different IRQ, looks like Windows
is hell-bent on assigning this thing to IRQ 18, no matter what. Linux on
the other hand properly assigned it out to a completely different IRQ
(27), than the ethernet or the previous video card was on.

Strange thing is that prior to driver installation, Windows just assumes
it as a standard VGA adapter. This was the case with both the onboard
ATI and the discrete Nvidia. While it was an assumed VGA, it was
assigned to IRQ 10. After the proper drivers were installed, beit ATI or
Nvidia, the device automatically gets assigned IRQ 18. Who came up with
this no manual adjustment possible on ACPI crap?

Yousuf Khan

You are still barking up the wrong tree. You have driver issues, NOT
"IRQ" problems. Windows only "assigns" IRQ numbers for legacy purposes.