IRQ conflict

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

That's the nuttiest explanation I've heard yet. IRQ's are not a "legacy"
item. They are most definitely still used, it's the only way a
peripheral can get the attention of the processor, without needing the
processor to constantly poll it.

Yousuf Khan

Yousuf Khan wrote:

Bob I wrote:

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


That's the nuttiest explanation I've heard yet. IRQ's are not a "legacy"
item. They are most definitely still used, it's the only way a
peripheral can get the attention of the processor, without needing the
processor to constantly poll it.

Yousuf Khan

A general description of IRQ sharing in Windows XP
http://support.microsoft.com/kb/314068

"Yousuf Khan" wrote in message
...
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...q-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

If I were you I would carry out an inplace upgrade (repair install) then use
the motherboard driver disk to install the chipset drivers.

http://michaelstevenstech.com/XPrepairinstall.htm

http://support.microsoft.com/kb/978788

Neil

Bob I wrote:
A general description of IRQ sharing in Windows XP
http://support.microsoft.com/kb/314068

Yes, this is one of the articles I read that basically said that ACPI
doesn't allow you to change IRQ settings. But I'm trying to find out if
somebody knows of a utility that will allow you to manipulate the ACPI
assignment tables.

Yousuf Khan

Yousuf Khan wrote:
Jerry Peters wrote:
Yousuf Khan wrote:
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

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

You'd eliminate one *possible* source of the problem. Eliminating
possible problems helps narrow the possibilities.

Bad memory can cause all sorts of symptoms.
I had an ASUS P3V4X motherboard that had 4 dimm slots, 2 of the slots
were unusable, any dimms in those sockets caused memory errors. The
errors usually happened when I was doing disk io via the SCSI
controllers; I'd start getting all sorts of io errors.

One additional tip for debugging: don't become so wedded to your
original diagnosis that you stop looking at other possibilities.

Jerry

Jerry Peters wrote:
Yousuf Khan wrote:
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.

You'd eliminate one *possible* source of the problem. Eliminating
possible problems helps narrow the possibilities.

Bad memory can cause all sorts of symptoms.
I had an ASUS P3V4X motherboard that had 4 dimm slots, 2 of the slots
were unusable, any dimms in those sockets caused memory errors. The
errors usually happened when I was doing disk io via the SCSI
controllers; I'd start getting all sorts of io errors.

One additional tip for debugging: don't become so wedded to your
original diagnosis that you stop looking at other possibilities.


Okay, I got another small window of opportunity to test the memory again
yesterday. Ran Memtest86+ for a couple of hours, but it found nothing
wrong again as expected. That plus the additional previous testing that
was done on this RAM under the old system indicates to me that there is
nothing yet wrong with this RAM.

I'm coming to the conclusion that the only way I'm going to get Windows
stable again is to run it as a virtualized client under Linux. That way
it will hopefully inherit the Linux ACPI settings.

Yousuf Khan

neil wrote:
If I were you I would carry out an inplace upgrade (repair install) then use
the motherboard driver disk to install the chipset drivers.

http://michaelstevenstech.com/XPrepairinstall.htm

http://support.microsoft.com/kb/978788


Yeah, it looks like that's the only solution for XP. However, now I'm in
the process of upgrading some machines on my network to Windows 7, and
it looks like this odd behaviour of XP's is gone. There's hardly any
shared IRQ's in Windows 7, and there are hundreds of IRQ's available to
it too.

Yousuf Khan

Hi Guys.
In computing, an IRQ conflict is a once common hardware error, received when two devices were trying to use the same interrupt request to signal an interrupt to the Programmable Interrupt Controller.

IRQ conflicts can occur when new hardware is installed or reconfigured.
Thanks for information.

Hello Exports,
In computing, an IRQ conflict is a once common hardware error, received when two devices were trying to use the same interrupt request to signal an interrupt to the Programmable Interrupt Controller (PIC).