IRQ conflict

In comp.sys.ibm.pc.hardware.chips Yousuf Khan wrote:
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.

--
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."

On Jan 28, 4:40*pm, (Nate Edel) wrote:
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.

On Thu, 28 Jan 2010 14:04:17 -0500 Yousuf Khan
wrote in Message id:
:

Robert Myers wrote:
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:

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.

Trent wrote:
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

YKhan wrote:
On Jan 28, 4:40?pm, (Nate Edel) wrote:
Have you run memtest86/memtest86+ or some other memory tester?

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.

--
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."

Nate Edel wrote:
YKhan wrote:
On Jan 28, 4:40?pm, (Nate Edel) wrote:
Have you run memtest86/memtest86+ or some other memory tester?
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.


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

Yousuf Khan wrote:
Nate Edel wrote:
YKhan wrote:
On Jan 28, 4:40?pm, (Nate Edel) wrote:
Have you run memtest86/memtest86+ or some other memory tester?
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.


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

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

Nate Edel wrote:
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.


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

Yousuf Khan wrote:

Nate Edel wrote:

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.



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.