(CC'ing our newly minted tulip maintainer, Val)
Grant Grundler wrote:
Jeff,
SLES10 testing exposed an MCA that was confirmed to be a DMA IO TLB miss.
This means tulip device was attempting to DMA to memory that was already
unmapped. The test was crashing in the "ifconfig down" step when a 4-port
tulip card was under this work load:
while :
do
ifconfig eth24 up
ifconfig eth25 up
ifconfig eth26 up
ifconfig eth27 up
# Pound both interfaces with ethtool
for i in `seq 1000`
do
ethtool eth24 &>/dev/null
ethtool eth25 &>/dev/null
ethtool eth26 &>/dev/null
ethtool eth27 &>/dev/null
done
# Bring interfaces down
echo ifconfig $nic1 down
ifconfig eth24 down
ifconfig eth25 down
ifconfig eth26 down
ifconfig eth27 down
sleep 5
done
[ And yes, I know tulip doesn't support ethtool. Don't ask.
It's still a sore point at the moment. Just consider it
a delay loop or use "sleep 5" instead. ]
The real "network load" comes from another box(en) running 4 instances
of "ping -f -s 1450 192.168.x.y" where "x.y" is the subnet/IP of eth24-27.
The parisc and ia64 machines will crash in minutes.
I believe the problem is a race condition between an interrupt coming
in and the tulip_down() code path. Moving the "free_irq()" to before
tulip_down() call fixes the problem. I've been able to run the above
test for several hours now.
NAK. This is a band-aid, and one that creates new problems even as it
attempts to solve problems.
Calling free_irq() while the chip is still active is just a bad idea,
because the chip could raise an interrupt, creating a
screaming-interrupts situation. Consider especially the case of shared
interrupts here, as a concrete example of how this won't work.
Perhaps cp_close() in 8139cp.c could be an example of a good ordering?
It stops the chip, syncs irqs, frees irq, then frees [thus unmapping]
the rings.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
