On Fri, Sep 24, 2004 at 04:15:58PM -0400, Jeff Garzik wrote: > Last I heard from you on this issue, _you_ agreed the problem was solved > by proper ordering of unregister_netdevice() and pci_disable_device() in > tulip_remove_one(), thereby eliminating the need for this patch. Jeff, I wrote it sounds right even if it doesn't solve my problem. (I just checked - I'm certain) The patch you are talking about was from Krzysztof Halasa <khc@pm.waw.pl> and it switched the order of unregister_netdev() and pci_free_consistent() in tulip_remove_one(). Becuase I'm paranoid about active devices, I additionally asked for the pci_disable_device() be added before pci_free_consistent(). > Incorrect ordering of unregister_netdevice() in earlier kernels was > causing there to be activity when there should not have been. > > Further, I don't see the need to poll the chip state given all this... As it stands, tulip_stop_rxtx() does not guarantee the chip will stop doing DMA for worst case (10bt) of about 1200us. The CPU needs to poll to provide that guarantee. Or can you suggest a different mechanism than polling either CSR5 or CSR6? thanks, grant - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
