:> It appears that the 'dc' driver continues to take receive interrupts
:> (see the systat -vm snapshot at the end), but winds up not processing
:> any of the packets. Except when 64 packets accumulate then suddenly all
:> 64 get processed all at once! Then nothing again until the next 64
:> accumulate.
:
:Uh. That's... strange. First of all, you haven't said if this is the
:same machine that experienced the problems with the xl driver. Second,
:the number 64 sticks out in this case. If you look at if_dc.c (uh...
:you did actually look at the code, right?), you'll see that dc_encap()
:will only ask for a "TX done" interrupt every 64 packets. Why? Well,
:reclaiming transmit buffers is a fairly unimportant task and I wanted to
I'm trying to narrow down the area enough that I can mess with the
driver myself and hopefully locate the problem, since it can't be
reproduced easily. I was hoping the magic number 64 could be
related to something - and you have apparently been able to do that,
which gives me a place to start anyway. netstat shows the trigger
to be the reception of 64 packets rather then the transmission, though.
Is there anything at all about the number 64 that could be related to
the receiver?
I'm pretty sure that the box was getiting receive interrupts because
every time I sent a packet to it from the outside systat -vm showed
a PCI interrupt for the network device. However 'netstat -in 1' did
not show the statistics for the received packets until 64 had
accumulated. It could be that the statistics are not being accumulated
on a per-reception basis and that the receive packets are actually
getting through, and that its the transmit side which is broken. I don't
know the code well enough yet to make the determination.
Previously it was not possible to add debugging code due to the amount
of network traffic involved. With the new card, though, it should be
possible to add conditional debugging code that could then be turned on
with the sysctl because the network does not lock up completely (so I can
still run 'sysctl' even if it takes it 5 minutes to load over NFS).
:Yes, but the one vital fact you keep leaving out is: does this always
:happen with the same machine. If so, then describe this machine. What
:PCI chipset does it have? And more to the point, what cards have you
:used in this machine that *didn't* exhibit this problem.
:
:No wait, let me guess: Intel fxp. Right? Grrrr.
I only have one machine with this configuration (diskless workstation,
everything running over NFS, plus X Display), so yes. The problem only
occurs on one machine. It started occuring mid-year, after I threw the
card in that used the xl driver. The previous ethernet card used a 'de'
driver I believe and didn't have the problem. The only 'fxp' ethernets
I have are in two of my test boxes - built into the motherboard. I
don't think I have any PCI cards that use that driver. The LinkSys
card in my server has never locked up, and the card using the 'xl' driver
in my other diskless test machine (which doesn't have an X display)
has never locked up either.
:> And watch what happens after I managed to 'ifconfig dc0 media auto',
:> it goes back to normal... suddenly everything is working properly
:> again.
:
:And what happens if instead of auto, you use "ifconfg dc0 media 100baseTX
:mediaopt full-duplex" to lock the media setting down? Or what happens if
:you shut down and restart the X server?
:
:-Bill
I'll try that next time the problem occurs but I doubt it will have
any effect. Changing the duplex mode does not appear to reset the port
whereas forcing the media to 'auto' does appear to reset the port. This
is actually another problem (switches don't appear to pick up the duplex
change if the port isn't reset), but not one I'm concerned with.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
