I also appear to be experiencing the same issue. I am attempting to use the Intel-provided e1000 driver on my company's PowerPC based hardware running embedded Linux. I am having issues with using the driver after restarting an interface. Some background information: I am using version 5.2.30.1 of the e1000 driver downloaded from the Intel web site. Our hardware contains a Motorola PowerPC 8265 CPU running a modified 2.4.21-pre4 Linux kernel compiled with GCC 3.2.3. I am using an Intel-provided demo PCI card containing the Intel 82541ER GigE controller. Our hardware supports PMC (PCI Mezzanine Card) cards. The demo card is connected via a transparent PCI to PMC conversion board. The e1000 driver is compiled with support for NAPI although the problem manifests without NAPI support. Now for the description of my problem. Upon booting the hardware, I can insmod the e1000.o driver without any options (insmod e1000.o), ifconfig the interface (ifconfig eth1_1 192.168.10.10 netmask 255.255.255.0), and successfully ping the interface. However, if I restart the interface (ifconfig eth1_1 down; ifconfig eth1_1 up), I can no longer ping the interface. If I restart the interface enough times, sometimes as few as two, the interface eventually starts working again. Simply stopping the interface and reinstalling the kernel module does not cause the interface to work again. As part of my debugging, I decided to print the contents of each packet received in the e1000_clean_rx_irq method. The packet was dumped immediately after the pci_unmap_single call and the length was converted from little endian to that of the CPU. The returned length is correct. When the interface stops pinging, however, the contents of the packets appear not to have been updated via the DMA transfer from the card. If I set the contents of the sk_buff to a known pattern in e1000_alloc_rx_buffers before the call to pci_map_single, I see the same contents when I dump the packets. The address of the sk_buff is the correct address setup in the DMA ring in e1000_alloc_rx_buffers. I also see the IRQ firing as each packet is received from the ping. Sometimes while pinging the interface while the problem is occurring, the driver will stop receiving interrupts for incoming packets. When the interface is restarted and works, the driver sometimes receives interrupts for packets which were received while no interrupts were being generated. The packets received contain the correct packet data. When the interface is working, I do not stop receiving interrupts. I doubt that the problem is an endianness issue since the card works predictably after the first boot and will eventually start working again with enough restarts. In thinking that the problem may be a cache coherency problem, I added explicit cache invalidation and flushing calls around the pci_unmap_single and pci_map_single calls. The calls had no effect on the problem. So, it appears that, for whatever reason, the card has stopped performing the DMA transfers of the contents of the received packets. If I place the card into a Intel-based PC running RedHat 8 and use the same driver, I have no problems with restarting the interface. I would appreciate any thoughts you may have on the solution to this problem. Thanks, Jeff - : 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
