Re: High DPC Use and a Method to Reboot a network card?

Tech-Archive recommends: Speed Up your PC by fixing your registry

Hi Bill, Thanks for responding...

I'm not sure exactly how to do it, but it sounds like you need to get
the driver's MiniportHalt() and MiniportStart() routines to be invoked
in order to stop and restart the NIC. You can't really 'reboot' the NIC.
There is a MiniportReset() method, however I think you're only supposed
to call that if MiniportCheckForHang() tells you the device has become
wedged.

Could the device be wedged? What happens when a device is wedged? Also, I
see numerous methods that I'd like to call but I have to be running at a
level lower than user level to run those.

The actual problem sounds like a driver bug. I don't know what chipset
the 3c2000 card you have is using (I think it's a Marvell Yukon), but I
suspect it has hardware statistics counters. Typically, when a counter
reaches its wraparound value (and it's very likely the frame counters
wrap at 32 bits), the chip will generate a 'statistics overflow' interrupt
to notify the host of the counter wrap. Exactly how you cancel the
interrupt varies depending on the chip. Generally you have to read all
the stats registers, which automatically resets them to zero.

Is there something I could do via DeviceIOControl that would allow me to do
this or would I need to know the correct IOCTL commands that might initiate
such a read?

It sounds like the card is generating a stats overflow interrupt, the
ISR is acknowleding it and scheduling a DPC to handle the condition,
but the interrupt handler is not clearing the stats counters, which causes
the interrupt to fire again once the handler completes. This causes the
handler DPC to be resumbitted by the ISR over and over again.

Yes, my inital thought was that a DPC was being scheduled for the same event
over and over again. However when I view the DPCs Queued/Sec during normal
operation I see a peak of around 3000 when recording a combined bandwidth of
30Mbits/sec. When the machine enters this high DPC Time we still appear to
continue recording but windows becomes sluggish. If I view the DPC
informaton remotely via the Windows Performance Counter interface I see DPC
time of 50% and one of two cases; case 1, the DPCs are scheduled evenly on
both processors but yielding a total DPC time of 50%, or case 2, the DPCs
are ALL scheduled on 1 processor (it sits at 100%) but the other sits at 0%,
yielding a total DPC time of 50%. In case 1 the machine is still usable,
but quite poorly, in case 2 the machine is unusable but continues running
for a time at least (perhaps until the next 2 ^ 32 packets have been
received). Observing a machine in case 2 remotely via the WPC interface I
see DPCs queued/sec has dropped from a peak of 4000 to a peak of around 100.
I like the theory you are suggesting here but would this drop in DPCs
queued/sec support this? I ask in all ignorance as I have no idea, having
barely no experience at driver/hardware development.

Stopping and restarting the NIC should reinitialize it and clear the
counters, however ideally you shouldn't have to do this.

Tell me about it! :)

Also, it's very likely that doing this will cause the NIC to drop and
reacquire the link,
which may take several seconds. This could cause a significant disruption
in traffic reception.

Yes that might be a problem but it might be acceptable short term provided
the device doesn't alter. I suspect we'd need to re-open the device through
winpcap however?

I suggest you either search for an updated driver that has this bug fixed,
or else switch to a different card which doesn't suffer from this problem.

We are testing 2 alternative gigabit network cards at present and I am in
communication with 3Com. There is no new driver for the card at present
however.

Thanks a lot for your input Bill

Cheers
IMH


-Bill

--
=============================================================================
-Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu
wpaul!#%removethis%^%#windriver.com | Wind River Systems
=============================================================================
<adamw> you're just BEGGING to face the moose
=============================================================================


.

Relevant Pages