[E1000-devel] e1000 Driver Support on PPC

[Harris, J. <Je...@ai...>]

Hi,

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.

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