IRQ conflict

Y

Yousuf Khan

Bob said:
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
 
B

Bob I

Yousuf said:
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
 
N

neil

Yousuf Khan said:
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

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
 
Y

Yousuf Khan

Bob said:
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
 
J

Jerry Peters

Yousuf Khan said:
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
 
Y

Yousuf Khan

Jerry said:
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
 
Y

Yousuf Khan

neil said:
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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top