Safe Mode bootup after installing NIC

WAG -- Windows may not have seen any conflict, even though one existed.
Windows 98 is capable of IRQ Sharing. It doesn't necessarily see anything
wrong with two or more devices sharing an IRQ, provided a couple of other
settings are different. It just so happens that your new NIC can't play the
IRQ sharing game according to Win98 specs, or, maybe, the fault lies in the
other device(s) that were sharing that IRQ. The fact that modem and NIC are
rather similar in purpose, and presumably share many other built-in
routines, may also have something to do with it. Just too many similarities,
and when you throw in the shared IRQ, they started resembling two very large
people trying to get to somewhere sharing the same narrow hallway that only
fits one of them. The IRQ is the starting gate, and they both use the same
one at the same time. On your mark, get set, Ooof!

--
Gary S. Terhune
MS MVP Shell/User

wrote in message
oups.com...

Gary S. Terhune wrote:
Just the opposite. You want a Normal startup to look for conflicts.


Immediately after I installed the NIC that was conflicting with my
installed modem, I rebooted and got that long "hanging" boot that I
described above. But when I got to the desktop and went to Device
Manager, I did not see any ! icons next to either the NIC or the modem.
Do you have any idea why that would be? That's what confuses me the
most, now that I have identified the problem as a resource allocation
problem and resolved it.

Franc Zabkar wrote:

Well, I guess that bears out what was stated almost from the outset,
namely that you had an undetected resource conflict. In hindsight you
could have saved yourself a lot of trouble had you posted the resource
list.

Indeed it does bear it out. From now on, my procedure will be to check
the resource configuration BEFORE doing any device installation. Then
I'll be able to track whatever changes are made thereafter.


Franc Zabkar wrote:
I suspect that you had two situations where an ISA device was
competing for the same IRQ as a PCI device. Initially it was a PCI NIC
and some ISA device on your motherboard or in a slot, then it was an
ISA NIC and some existing PCI device.

An ISA NIC? I do not have one. The Belkin NIC is PCI. My only ISA
device was the modem.

Franc Zabkar wrote:

In my system I occasionally have problems when my onboard sound (an
ISA device) finds itself sharing an IRQ with an onboard PCI device.
Win98SE's Device Manager identifies the sharing but does not flag it
as a problem.

Why wouldn't Win98se flag it as a problem if it was one?
And does that mean that any instance of shared IRQs could conceivably
be the cause of the problem, even if DM does not flag them as such?

Franc Zabkar wrote:
PCI devices can share IRQs as long as IRQ Steering is enabled. My
plug-in PCI NIC shares one IRQ with the onboard USB controller and the
onboard graphics.

In that case, why did the PCI NIC try to use the modem's IRQ3 instead
of sharing an IRQ with another PCI device, like the Video card or TV
tuner card?
For reference, here is my current IRQ configuration:
0 System Timer
1 Keyboard
2 Cascade
3 NIC
4 COM1
5 Sound
6 Floppy disk controller
7 LPT1
8 Real Time Clock
9 Video
10 Promise IDE Card
11 TV Card and USB Host controller
12 Mouse port
13 Math Co-Processor
14 Primary IDE Controller and Bus Master IDE Controller
15 Secondary IDE Controller and Bus Master IDE Controller


Franc Zabkar wrote:

I presume you are referring to your internal dial-up modem, not the
DSL modem. If this is an ISA "hardware" non-PnP modem, then it would
most likely have occupied IRQ 3 or IRQ 4 and would have appeared as a
standard COM port in DM.

Yes, the dial-up USRobotics modem. It used IRQ3 and appeared under the
"Modems" icon in DM.

Franc Zabkar wrote:

In any case, just because you solved your problem by removing your
modem doesn't prove that your modem was the culprit. The nature of PnP
is such that resources are shuffled about like musical chairs whenever
the device list changes. It could be that the actual problem device is
now occupying an IRQ vacated by your modem.

I think the fact that the modem stopped working at one point strongly
indicates a conflict between it and the NIC, don't you?

Thanks for your help with this Franc.
Patrick

Gary S. Terhune wrote:
WAG -- Windows may not have seen any conflict, even though one existed.
your new NIC can't play the
IRQ sharing game according to Win98 specs, or, maybe, the fault lies in the
other device(s) that were sharing that IRQ.

That makes a lot of sense to me. Now that I look back on it, this is
what must have happened: The NIC had to share an IRQ with one of the
other PCI devices installed, but it doesn't like sharing its IRQ and it
had no free IRQ to use, so it caused a conflict.
I suppose that the fact that DM didn't display any ! even though there
was indeed a conflict is a testament to Win98's poor implementation of
PnP. Do you agree?


Gary S. Terhune wrote:
The fact that modem and NIC are
rather similar in purpose, and presumably share many other built-in
routines, may also have something to do with it. Just too many similarities,
and when you throw in the shared IRQ, they started resembling two very large
people trying to get to somewhere sharing the same narrow hallway

Based on what Franc wrote above, I don't think this is true. He said
ISA devices, like my modem, don't like to share IRQ's, so the modem
COULDN'T have been sharing its IRQ with the NIC. (In fact, I remember
seeing this in DM). Thus, the NIC must have been sharing the IRQ of
another PCI device. What removing the modem did was simply to free its
IRQ for use by the NIC -- but its IRQ was never shared with the NIC.
Thanks for your explantion.
Patrick

Let me amend my previous post. Actually, the modem and NIC could
indeed have been trying to share the same IRQ at one point.
I installed and removed the NIC multiple times. On ONE of those
occasions, the NIC and modem were not using the same interrupt, but on
other occasions they might have been. That would explain why after one
reinstallation of the NIC the modem stopped working.

PnP is *still* a work in progress, but I would suggest that the manufacturer
of the NIC or the modem, or rather the drivers developers, might be as much
or more to blame. They have to provide the proper instructions to Windows in
order for Windows to properly handle them.

If this is a new model NIC, Belkin may simply not have bothered to heavily
test it against 98 PnP. But my guess is the modem... Those things *often*
wreak havoc with Win98 PnP. Some of them are just horrible.

--
Gary S. Terhune
MS MVP Shell/User


wrote in message
oups.com...

Gary S. Terhune wrote:
WAG -- Windows may not have seen any conflict, even though one existed.
your new NIC can't play the
IRQ sharing game according to Win98 specs, or, maybe, the fault lies in
the
other device(s) that were sharing that IRQ.

That makes a lot of sense to me. Now that I look back on it, this is
what must have happened: The NIC had to share an IRQ with one of the
other PCI devices installed, but it doesn't like sharing its IRQ and it
had no free IRQ to use, so it caused a conflict.
I suppose that the fact that DM didn't display any ! even though there
was indeed a conflict is a testament to Win98's poor implementation of
PnP. Do you agree?


Gary S. Terhune wrote:
The fact that modem and NIC are
rather similar in purpose, and presumably share many other built-in
routines, may also have something to do with it. Just too many
similarities,
and when you throw in the shared IRQ, they started resembling two very
large
people trying to get to somewhere sharing the same narrow hallway

Based on what Franc wrote above, I don't think this is true. He said
ISA devices, like my modem, don't like to share IRQ's, so the modem
COULDN'T have been sharing its IRQ with the NIC. (In fact, I remember
seeing this in DM). Thus, the NIC must have been sharing the IRQ of
another PCI device. What removing the modem did was simply to free its
IRQ for use by the NIC -- but its IRQ was never shared with the NIC.
Thanks for your explantion.
Patrick

I just thought of another possibility.
Does the resolution of the problem after removing the modem
necessarily prove that it was a resource allocation problem? If the
device is no longer there, then its driver won't be loaded, right?
Thus, couldn't the problem have been with the driver and not the IRQ's?

Could be. Could be that the modem itself is the problem, regardless of
drivers. It's kind of a total-Gestalt situation. Only testing would prove
things one way or another. Different drivers for the modem, if available,
for instance. My guess is that the NIC and Modem just don't play well
together when on the same IRQ. Changing the modem or the NIC for a different
model, particularly if they are based upon different strategies, would
probably resolve the issue. But I say again that modems are notorious for
not playing well with other devices. That's just the nature of the beast.
That's why it's common to assign a specific IRQ to the modem (like IRQ5, if
my memory serves me right) and take it out of the IRQ Sharing queue in BIOS.

--
Gary S. Terhune
MS MVP Shell/User

wrote in message
ups.com...
I just thought of another possibility.
Does the resolution of the problem after removing the modem
necessarily prove that it was a resource allocation problem? If the
device is no longer there, then its driver won't be loaded, right?
Thus, couldn't the problem have been with the driver and not the IRQ's?

On 11 Oct 2005 12:49:47 -0700, put finger to
keyboard and composed:

Franc Zabkar wrote:

Well, I guess that bears out what was stated almost from the outset,
namely that you had an undetected resource conflict. In hindsight you
could have saved yourself a lot of trouble had you posted the resource
list.

Indeed it does bear it out. From now on, my procedure will be to check
the resource configuration BEFORE doing any device installation. Then
I'll be able to track whatever changes are made thereafter.


Franc Zabkar wrote:
I suspect that you had two situations where an ISA device was
competing for the same IRQ as a PCI device. Initially it was a PCI NIC
and some ISA device on your motherboard or in a slot, then it was an
ISA NIC and some existing PCI device.

An ISA NIC? I do not have one. The Belkin NIC is PCI. My only ISA
device was the modem.

Sorry, I was under the wrong impression that your second NIC was an
old Linksys ISA device. It's been a long thread and yesterday was 1440
minutes ago ...

Franc Zabkar wrote:

In my system I occasionally have problems when my onboard sound (an
ISA device) finds itself sharing an IRQ with an onboard PCI device.
Win98SE's Device Manager identifies the sharing but does not flag it
as a problem.

Why wouldn't Win98se flag it as a problem if it was one?

I don't know.

And does that mean that any instance of shared IRQs could conceivably
be the cause of the problem, even if DM does not flag them as such?

That's what I see in my system. I also found a reference to this
effect in Scott Mueller's "Upgrading and Repairing PCs". He
specifically states that ISA and PCI don't share.

Franc Zabkar wrote:
PCI devices can share IRQs as long as IRQ Steering is enabled. My
plug-in PCI NIC shares one IRQ with the onboard USB controller and the
onboard graphics.

In that case, why did the PCI NIC try to use the modem's IRQ3 instead
of sharing an IRQ with another PCI device, like the Video card or TV
tuner card?

I don't know. All I know is that my old socket 7 PC of the same
vintage has difficulty assigning non-conflicting resources due to the
high number of ISA components. I've had to go to extreme lengths to
make everything work harmoniously. For example, I've added an IRQ 9
jumper wire to my ISA modem (it doesn't normally support this IRQ).

One thing you could check is whether you have IRQ steering enabled.
This should be enabled by default, but you never know. AFAIK, if IRQ
steering is disabled, then PCI devices will not be able to share IRQs.

Go to Device Manager, System Devices, PCI bus, Properties, IRQ
Steering. In addition to the main check box, there will be 4 check
boxes which tell Windows where to look for resource information. I
don't claim to understand them, but I suppose you could experiment
with these options if things get desperate.

For reference, here is my current IRQ configuration:

0 System Timer
1 Keyboard
2 Cascade
3 NIC
4 COM1
5 Sound
6 Floppy disk controller
7 LPT1
8 Real Time Clock
9 Video
10 Promise IDE Card
11 TV Card and USB Host controller
12 Mouse port
13 Math Co-Processor
14 Primary IDE Controller and Bus Master IDE Controller
15 Secondary IDE Controller and Bus Master IDE Controller


Franc Zabkar wrote:

I presume you are referring to your internal dial-up modem, not the
DSL modem. If this is an ISA "hardware" non-PnP modem, then it would
most likely have occupied IRQ 3 or IRQ 4 and would have appeared as a
standard COM port in DM.

Yes, the dial-up USRobotics modem. It used IRQ3 and appeared under the
"Modems" icon in DM.

Franc Zabkar wrote:

In any case, just because you solved your problem by removing your
modem doesn't prove that your modem was the culprit. The nature of PnP
is such that resources are shuffled about like musical chairs whenever
the device list changes. It could be that the actual problem device is
now occupying an IRQ vacated by your modem.

I think the fact that the modem stopped working at one point strongly
indicates a conflict between it and the NIC, don't you?

Yes, it looks that way.

Thanks for your help with this Franc.
Patrick

This is how msinfo32 identifies my hardwa

[Conflicts/Sharing]

IRQ 12 PCI Ethernet Adapter
IRQ 12 SiS 7001 PCI to USB Open Host Controller
IRQ 12 SiS 5597/5598
IRQ 12 IRQ Holder for PCI Steering
IRQ 12 IRQ Holder for PCI Steering
IRQ 12 IRQ Holder for PCI Steering
IRQ 14 Primary IDE controller (dual fifo)
IRQ 14 SiS 5513 Dual PCI IDE Controller
IRQ 15 Secondary IDE controller (dual fifo)
IRQ 15 SiS 5513 Dual PCI IDE Controller

The above is a problem free configuration. There are no actual
conflicts, and Device Manager is also happy with this resource
assignment. Each of the three PCI devices get along with each other
due to their respective "IRQ Holder for PCI Steering".

However on the odd occasion I find that the above PCI devices will be
assigned to IRQ 10 which is where the WSS component of my onboard ISA
sound device also lives. Even though DM does not flag this situation
as a conflict, my sound doesn't work properly. I have to shuffle my
resource list until the WSS device is on its own. Another annoying
complication is that no ISA device will work on IRQ 12 because of a
design limitation of the chipset (IRQ 12 and PS2 Mouse Data share a
common pin).

To complicate matters further, even in those situations where there is
no real conflict, and where sharing is allowed, sometimes you will
experience operational issues. For example, certain graphics drivers
are aggressive in that their interrupt service routines hog the CPU
for too long, leaving other devices waiting for service.

-- Franc Zabkar

Please remove one 'i' from my address when replying by email.

On 11 Oct 2005 22:33:02 -0700, put finger to
keyboard and composed:

I just thought of another possibility.
Does the resolution of the problem after removing the modem
necessarily prove that it was a resource allocation problem? If the
device is no longer there, then its driver won't be loaded, right?
Thus, couldn't the problem have been with the driver and not the IRQ's?

If your USR modem was a "hard" ISA modem rather than a "softmodem" or
controllerless Winmodem, then it would have required no drivers, only
an INF file. The COM port that it occupied would have used the same MS
drivers that your other serial port (COM1) is presently using.

Speaking of which, if nothing is attached to COM1, and assuming it is
located on the motherboard, then you could probably disable it in the
BIOS setup. This would free up an IRQ for your USR modem.

-- Franc Zabkar

Please remove one 'i' from my address when replying by email.

Franc Zabkar wrote:

Patrick wrote:
Why wouldn't Win98se flag it as a problem if it was one?

I don't know.

I think another poster has answered this. He said that PnP is only as
good as the device drivers that communicates with it and tell it the
resource requirements of that device. Thus PnP probably simply didn't
know about the conflict because the devices' drivers didn't tell it
there was one.


Patrick wrote:
And does that mean that any instance of shared IRQs could conceivably
be the cause of the problem, even if DM does not flag them as such?

Franc Zabkar wrote:
That's what I see in my system. I also found a reference to this
effect in Scott Mueller's "Upgrading and Repairing PCs". He
specifically states that ISA and PCI don't share.

But does it apply to ANY instance of a shared IRQ? In other words,
could 2 PCI devices sharing an IRQ actually be in conflict even if DM
says they're OK?


Franc Zabkar wrote:
PCI devices can share IRQs as long as IRQ Steering is enabled. My
plug-in PCI NIC shares one IRQ with the onboard USB controller and the
onboard graphics.

In that case, why did the PCI NIC try to use the modem's IRQ3 instead
of sharing an IRQ with another PCI device, like the Video card or TV
tuner card?

I don't know.

To answer my own question, I suspect that it comes down once again to
the drivers not telling PnP about their resource requirements.

Franc wrote:
One thing you could check is whether you have IRQ steering enabled.

I do.

However on the odd occasion I find that the above PCI devices will be
assigned to IRQ 10 which is where the WSS component of my onboard ISA
sound device also lives. Even though DM does not flag this situation
as a conflict, my sound doesn't work properly. I have to shuffle my
resource list until the WSS device is on its own.

That's not surprising. Sound cards are notorious for needing to get
their own way when it comes to allocating resources. If PnP didn't
catch it, I guess that's why they call it Plug and Pray, after all.

Patrick