If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#11
|
|||
|
|||
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." |
#12
|
|||
|
|||
IRQ conflict
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. |
#13
|
|||
|
|||
IRQ conflict
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. |
#14
|
|||
|
|||
IRQ conflict
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 |
#15
|
|||
|
|||
IRQ conflict
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." |
#16
|
|||
|
|||
IRQ conflict
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 |
#17
|
|||
|
|||
IRQ conflict
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 |
#18
|
|||
|
|||
IRQ conflict
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 |
#19
|
|||
|
|||
IRQ conflict
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 |
#20
|
|||
|
|||
IRQ conflict
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. |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
conflict | Teranews | Asus Motherboards | 0 | March 23rd 08 02:46 PM |
SATA conflict | Terry | Homebuilt PC's | 3 | August 25th 07 04:42 AM |
Conflict I/O Ports: 378 3F8 | 00ignacio00 | Homebuilt PC's | 9 | October 3rd 05 04:12 PM |
LG CD/RW conflict !!! | Jarek | General Hardware | 1 | May 14th 04 04:04 AM |