Ok. I built a Intel source 4.3.15 driver with MAX_SKB_FRAGS undef'd. It ran 400Mbits/sec for quit a while with no problem. The same 4.3.15 source based driver with MAX_SKB_FRAGS defined, i.e. zero-copy enabled, I ran 400Mbits/sec for a little while and was a little surprised it ran as long as it did. So I started to add more load (another 100Mbits/sec) and before the extra load ramped up, the kernl BUG'd. The msec_delay barfed because "in_interrupt()" was true - and rightly so - the dev_timeout bh code called e1000_tx_timeout. The "linux-ized" version schedules a separate task to do this preventing the BUG. So, I am assuming there are still problems with "zero-copy" enabled because of the dev_timeout call. I will try it again and see what happens. larry -----Original Message----- From: Feldman, Scott [mailto:scott.feldman@intel.com] Sent: Sunday, October 06, 2002 5:05 AM To: Larry Sendlosky; linux-net@vger.kernel.org; Linux NICS Cc: Mala Anand; Jeff Garzik Subject: RE: xmit timeouts with new e1000 driver > After some experimentation, it looks like the > zero-copy/"frag" logic in the e1000 driver broke after > 3.6.8.1. I performed my tests without using sendfile and had > no problems, except running out of cpu way too early... Larry, to prove that, try undefining MAX_SKB_FRAGS in 4.3.15 and rerun the test. In e1000_main.c, after #include "e1000.h", add #undef MAX_SKB_FRAGS. That should disable zerocopy in e1000. -scott - : 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
