On Wed, 1 Jul 2009, Yosuke HIZUME wrote: > I'm using e1000e-0.5.8.13 *Non-NAPI* on kernel 2.6.10 with 82573L. > I found the receiving data was occasionally corrupted just after I > changed the mtu or the speed and duplex setting.
you also apparently are not using MSI interrupts. > Then I inserted some printk codes to investigate and found that > e1000_intr() was infrequently called sometime in between the beginning of > e1000e_down() and the end of e1000e_up() despite the irq was disabled. this was probably a shared interrupt, does /proc/interrupts show ethX sharing? > In such case, the register ICR.INT_ASSERTED was not set and > ICR.RX_DESC_FIFO_Par0 was set. (ex. icr=0x00100000h) If INT_ASSERTED was not set it was not our interrupt, but it is normal to have e1000_intr called in a shared interrupt case. We have fixed a bug in the latest release of e1000e, which is available now, look for e1000e-1.0.2.5 > I want to know the reason why the interrupt handler was called > nevertheless interrupt disabled, and also the reason why > RX_DESC_FIFO_Par0 was set. par0 was probably set as part of the reset process. > And hopefully, please let me know if there are any workarounds. yes, the e1000_intr routine can check to make sure it is not running when the __E1000_DOWN flag is set, you'll see that code in the new driver. Jesse ------------------------------------------------------------------------------ _______________________________________________ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel
