From: neil on
"Yousuf Khan" <bbbl67(a)spammenot.yahoo.com> wrote in message
news:4b611686(a)news.bnb-lp.com...
> 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


From: Yousuf Khan on
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
From: Jerry Peters on
Yousuf Khan <bbbl67(a)spammenot.yahoo.com> wrote:
> Jerry Peters wrote:
>> Yousuf Khan <bbbl67(a)spammenot.yahoo.com> 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
From: Yousuf Khan on
Jerry Peters wrote:
> Yousuf Khan <bbbl67(a)spammenot.yahoo.com> 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
From: Yousuf Khan on
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